An agile government

Agile government

Government and Agile don’t mix, they’ve always seem like complete opposites to me. The red tape that caused Agile into existence, or at least Kaizen within Lean is abundantly present in government organizations.
This of course does not mean that certain departments in the government structures want things to be like this. Civil servants are still human, and nothing annoys as much as red tape.
The danger is that you get complacent and accept that red tape is a part of your life, but that’s definitely not an agile thought.

Let’s grab that Agile Manifesto: Individuals and Interactions are preferred above Processes and Tools.

To me red tape fully falls in the category Processes. And as far as I have seen process is what drives many within government organizations.

I remember a computer game from my youth. It was called Civilization and it was loosely based on a board game me and my friends used to love. This game by MicroProse was awesome, I could play it all night – and I did.

There were several inventions that would further your civilization. One of them was the choice of government structure. Of course this started out as Anarchy, then it went to something like Monarchy, then evolved into Democracy. I always expect to have my civilization grind to a halt when I do that. But then you need a good structure in organizations. And the more organizations grow, the more structure you add. At least when you grow as an organization from a small one.
Government organizations are big, if not huge, and what I am dealing with in my project is an organization that serves all of the ministries. IT is a service organization. Where every ministry used to have their own service departments, they have now made one singular organization responsible for IT services.

Obviously this kind of centralization is part of decisions that are made to reduce costs. Personally I think that decisions made solely on the merit of cheapness always turn out to make things worse, not better.

What I noticed is that the ministry we’re building a suite for is not happy with the fact that they have to go to this huge service organization to get things done. Who is the most important, what department gets their work done first. In these huge organizations this is usually the one who screams loudest, or who has the best and highest connections (minister level)

I should soften my words a little. The people I work with (of all the organizations involved) are awesome in that they want to work together and want to GO for the result we try to achieve. Unfortunately they run into the same walls everyone does.

Of course the organization is set up in a traditional way. The deliverables are usually measured by waterfall structures. We need to deliver a Functional Design, Technical Design, they talk about phases and toll-gates. All deadly for agile.

This all leads to slow delivery of knowledge on the interfaces we need to connect to and it means we have to wait long times for environments to get finished. Environments they demand us to test in (TAP).
People in their organization are used to have enough time to get their work done. They don’t procrastinate, but they have to divide their time between a dozen different projects. As said this mean that projects that scream loudest get served first.

Guess what I’ve been doing?

Fortunately I have an awesome project manager on the ministry side. He is also certified in Scrum and knows where to put his foot in the door and when to leave the room (when things get done).

We’ll get this project done, but it has resulted in my request for two more sprints to deliver anything of value. I got it, but I’m not sure at the costs yet.

Leave a Reply

Your email address will not be published. Required fields are marked *