Large organizations are just not set up to be agile

There is something going wrong in the organization I am currently part of an onsite project, yet I can’t get my head around the specifics.

This very large governmental organization is growing agile initiatives all over the IT department. Development teams are having fun talking to their customers and are trying to create the best solutions to the needs of their stakeholders, yet everything agile about Agile halts when a shippable increment is ready to begin its journey through the rest of the organization.

A few weeks back I received an email from the team that is tasked with the becoming agile of our organization, asking me to fill out a form so I could show how SCRUM we were. I know it was meant to let us see for ourselves how agile we were, but to me it felt as if we were proving our agility through a checklist.

I know I checked every box there was, so according to the person sending it we were 100% Scrum. I just knew we weren’t agile, so there must be a flaw in checking of the Scrum checklist to see if you are agile.

I then got the urge to use the same principle to show how NOT agile we were. I wanted a well-known checklist to prove how NOT agile we were.

The easy choice of list is the Agile manifesto. I should find proof in there that we weren’t being agile. I kind of hoped that going through the values would blatantly prove my point of view.

Hmm, four out of four. Not what I hoped for. I know that we aren’t agile, yet the values don’t agree with my feelings.

The principles (http://www.agilemanifesto.org/principles.html) are less abstract. I know they should help me show weren’t agile. I could check off everyone.

Now why am I sure we are not being agile.

In my opinion it is called agile, because you can adopt to changes in your user’s needs QUICKLY. Therefore you need speed to be agile. And our change process to go from potentially shippable to actually shipped is far from quickly.

All traditional projects are only releasing about once a year, so to accommodate our wish to go fast, we are allowed a whopping 6 to 7 releases a year.

So now we save up shippable increments until we have four of them and then we fire those one off into our change process. We hand over software that is created based on agile principles into a process that has grown into its current form based on traditional values.

This process is designed to take a minimum of 5 weeks. In these weeks the performance is being tested by the performance testing department and the installation guide is being tested, by installing it using the guide, by the installation department. The pre-release has to be done by the pre-release department and the time these steps take is a minimum of a week, since there is a policy that you can only sign off if the build has been stable for week.

So, while the team is maturing to measure and watch the user’s behavior and distill the feedback to groom the scope (backlog), we aren’t getting the feedback as fast as we could have it. We have a feedback cycle of about 26 weeks. So with sprints of 2 weeks, we are still not even close to being agile. But since this delivery process is completely out our sphere of influence we just don’t talk about it.

During retrospectives we only focus on optimizing going from user’s needs to shippable, but we never touch the part where shippable becomes shipped. And where we went from needs to shippable from weeks to days (or if pushed hours) the second part remains. This automatically leads to a futility in optimizing the parts the process that we actually can influence.

This leads me to believe that the inability of large organizations to be agile, lies in a Lean principle instead:

Optimize the Whole

The synergy between the parts of a system

is the key to the overall success of the system.

So while a lot of agile initiatives are growing all over large organizations and these initiatives are optimizing their own processes, the agility of the entire organization will never be achieved until you can create a synergy between all parts of the organization.

Is it wrong to realize your large organization will always be in methodological limbo? I don’t know.

I do know that if you realize there are agile aspects of your company and traditional aspects, you have to put in more effort on higher levels to have the both sides be aware of each other’s values and needs.