Agile in government. Sounds easy at first glance but then you find so little or none of it in reality. Why is this?

If you were to ask Barack Obama, he would say that it is due to the structure of government being stuck in its current form for the last 70 years. With the IT trouble both in the VA and with his flagship medical insurance policy. As a president, he has suffered more than those before him. The next one I am sure will suffer more than he has if he can’t resolve this problem. The simple reason is that IT has become more and more ingrained in business both public and private.

This same question has been worked through in the UK. With a constant going forward and backward on the issue. It has been stated that yes Agile works, but we don’t think it will work for the UK government?  Without management “buy in” it won’t. Will there be management buy-in for the champions of what came before? I think not.

Which brings us back to structure and the speed with which it can change. Well from what I have seen, the structure and the champions that maintain it would take two generations to work out of the system naturally. Now, this is only limited to government structure and the IT management structure in particular. 50-60 years, a blink of an eye for the earth, a long time for IT and governments and the average taxpayer.

But it is becoming very clear that governments will go through Agile adoptions sooner than that and that there will be lots of pain for those involved.

If you are in IT or have some knowledge in the Agile field, it would be great if you could help your government see the light in every possible way you can. The sooner we start the better. 50 years is too long so you can’t leave it up to them.

The world is changing, and becoming more digital. Terms like digital native and internet of things are filling the news. But what does it all mean and is there anything you could do to prepare for it.

The answer is yes: Learn JavaScript this will help you understand the language of the internet. You’ll then be able to find out more about how your favorite social media site works. You’ll be able to create your own sites and do more on the ones you already go to.

It’s an internet Superpower.

And with the internet of things – Phone, fridges, lights, heat pumps and clothes are all being plugged into the internet. Without some way of talking to them, you may soon not be able to understand your jeans.

To help start the journey and follow these links:

http://www.w3schools.com/

http://jsfiddle.net/

Good Luck

How do you learn?

As a member of a scrum team, it’s an important question. How does the team learn? I mean we spend a significant amount of time in retrospectives for the purpose of learning and improving.

For me as an individual, I need to do something before I really understand it. I learn by doing. I learn about agile by delivering working software as a member of a cross-functional team. Is there another way of learning about Agile without doing it in practice?

Our fail wall has failed because it was taken down for saying a fail wall. This is only a reasonable reason in an earthquake zone after a major earthquake. So what was learned? Timing and wording are important when putting up a fail wall.

This talk has a nice explanation of the fragility of large IT projects and large top-down organizations.

http://www.thersa.org/events/video/vision-videos/nassim-nicholas-taleb

 

The fist of five sounds like an old kung-fu movie. But if you are new to scrum and your team has been failing to make their points for three sprints or more and you don’t have large stories of 13 points or more. You need to look at how you get the team to commit during the planning meeting.

Does the scrum master or project manager decide how many points should be achieved or are you using the fist of five technique?

This is the basic way it works.
You put the sprint backlog on the board and ask the team to do the fist of five.
No fingers mean – no chance.
One finger means – snowball chance in hell.
…(Two to Four is the warmer feelings)
Five fingers mean – hell yes we can.

If anyone puts up anything except a fist with five fingers you remove a story from the bottom and go again.
You only stop when the most pessimistic person says the team will make that number.

An achieving team is a happy team.

In the last week, I have been listening to a lot of reasons why Architects should not be involved in code. They don’t have the time. It’s not in their role description. They’ll get bogged down in specific applications. They should spend their time at a higher Enterprise level.

So through a full vertical slice, there is a point through which they don’t want to go as it is too far down. I suspect that this point is above anything that requires a knowledge of current technology and implementation thereof as it is based on documentation and models. These models are supposed to then enter the sprint as a user story where the Agile Architect takes over the responsibility of its delivery. So our architects are stakeholders and the Role of the Agile architect moves over to the most senior developer in the team.

For the rest of the discussion, I’ll give some points I and others think is important to an Agile Architect.
First is the 10 things that Tom Hollander thinks is important to an Agile Architect.

10. “Just enough” up front design
9. Start with a vertical slice
8. Just-in-time design each iteration
7. Trust your team… but be there for them
6. Write code!
5. Be involved in everything
4. Drive a culture of quality
3. Know when changes are required
2. Shield the team from external randomization
1. Write docs only if someone needs to read them

Nearly all these are also this post by Peter:
http://agilescout.com/the-role-of-the-agile-architect/
Architecture Is a Frame of Mind
The War Room Is Where It’s At
Listen First
Mentoring
Shepherd the Team
It’s All About the Code…

Peter is a little more direct and dismissive of the Ivory Tower Architects.
“The agile architect must understand the current state of the software and know where it is going. He must spend his time with the team and be involved in all aspects of the project. The days of the ivory tower architect, sitting in an office producing diagrams and documents that may or may not be relevant, are dead.”

The only thing I asked from our Architects was to be directly involved using Pair programming for the first vertical slice. So that they can have a closed feedback loop with the developers during the time when the trend for the solution will be set and the architecture concept is set and tested in the code.

During this first vertical slice a few trends are set:
The coding standards are started for the solution.
The first unit tests are written.
The first pattern implementation occurs.
The architecture becomes reality.

The trend for the whole project is set. A trend not easily diverted from. Bad coding standards set during this time are kept consistent until the project’s end. Lack of unit tests becomes an overwhelming problem until adding a new one becomes a nearly impossible task as the code simply doesn’t allow for it.

But I suspect that from the Ivory Towers perspective the lowly actual delivered software code is not really relevant or worth the time spent on it. Shame the poor maintenance developers and users can’t share this perspective.

An agile developer, to waterfall project manager: “You’re not going to let logic or reality spoil your seemingly perfect plan are you?”