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.
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:
A “catch 22” for those that don’t know is a term that came from the famous book about WW2 bomber pilots who were forever caught up in an impossible position. It can be distilled down into the simple choice between stating you are insane and thus no longer fit for duty and being denied being declared insane because only a sane person would like to stop flying in the bombing raids.
My favorite part of the book is the end result of a world filled with “Catch 22”’s. Where wanting to progress in this world forces people to plan and execute very successful bombing raids on their own airfield and base. A result clearly not intended by any of the people involved in the creation of the parts that make up the “Catch 22”’s.
“Catch 22”’s are clearly a great reason to always value individuals and interactions over processes and tools. Because they get their strength and are created by those processes and in most places they override both the people they are there to serve and the people who created them. So it’s pointless getting frustrated by the people who create them because they most likely value processes more than you do and more likely more deeply caught up.
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.
Went to the second code kata focused on Test Driven Development at Adscale. Code katas is a very Agile thing to me. The more exposed I become the more I prefer it to normal sessions and discussions.
The katas are:
Focused on working software.
Face to face.
To learn with using close collaboration.
The focused on doing.
Fail fast and learn from it.
Set for continually improving.
Definitely going to the next one.
Antoine de Saint Exupery wrote: As for the future, your task is not to see it, but to enable it.