Agile Stall

During “Agile Transformations” teams and management alike often feel like they are stalling and regressing rather than achieving the benefits that Agile promises.

Well, most of this is due to the marketing of Agile and even books by some of the Agile signatories such as “Scrum: The Are of Doing Twice the Work in Half the Time” by Jeff Sutherland. I will not go into to much detail about that book except to say “WTF!”

But any “Agile Transformation” that I have been a part of, does experience a slow down due to the disruptive nature of such an undertaking. When an organization decides to invest in changing their systematic way of working to an agile systematic way of working, things are going to slow down for a bit. Learning needs to occur, and that learning takes time. In most cases I have seen, it is probably somewhere around a 25% drop in productivity for roughly 6 months.

Consider what happens leading up to and included in that time frame:

  • Creating dedicated cross-functional, self-managing teams with all of the skill sets necessary to deliver
  • Management training to shift their focus on managing the system they work in instead of managing the task assignments and people they work with.
  • Updating any organization governance policies that contradict agile values and principles
  • If scaling with multiple teams, make sure some kind of coach is working with these teams that has some experience with real agility
  • Giving teams the empowerment, authority and trust to own their process from end-to-end. (Development, Build, Test, Deployment)

Think about the effort and time investment that is needed for that first bullet-point. Creating cross-functional, self-managing teams with all of the skills necessary to deliver is quite an investment. These people may have never worked together before. Relationships are being forged, collaboration and communication issues are going to occur. More than anything, trust needs to be established.

What is not mentioned in those bullets is a fundamental shift in the approach to the work itself. Agile teams focus on delivering on a single objective at a time before moving onto the next one. Traditional management and stakeholders naturally start to worry, and some even step in in destructive ways, when they see that instead of 10 things going at once, only 1 is. The reality is that not only are teams only focused on a single objective now, but in every single case I have been a part of the same issue arose. The teams had to organize how to finish all of the things that were “90% done with 90% to go” before they could even focus on a single objective.

It is critical in this time to avoid the pull towards focusing on just delivering the software and remain focused on learning the agile values and principles. It will pay-off, but the investment has to be made now.

Conversations need to be had, and shared understanding needs to be gained with our business partners. We all have to realize that this change to our system means that not everything can be the same priority. And not everything can be worked on at the same time. In most organizations that are looking to work in an agile way, this reason is part of the why. “Start Finishing.” Here is a short list of the most common reasons I have heard;

  • Start Finishing
  • Improved Quality
  • Predictability
  • Accountability – Although this is not usually for healthy reasons and requires its own discussion

If the organization you are with can not invest the time in learning and risk this stall, then now is not a good time to promote these types of changes.

Agile can be easy once you have experienced it, and the industry makes it seem at times like it is painfully simple. But to those that have no experience with working in an agile way, or have only experienced things like “Dark Scrum” (“We have daily standups, and work in 2 week sprints, and estimate with story points, so we are Agile.”) this type of investment and change is very difficult to even imagine.

It has been said many times, and I will repeat it now, Agile is not a silver bullet. And there is no final destination or utopia to an “Agile Transformation”. It will take time, and it will have many ups and downs throughout. Know that going in and the pain when it happens will be muddled. Well, at least a little bit. But if you go in thinking “We are going to do Scrum with our software teams and then we will be “Agile”.” Then you are in for quite the surprise.

The best I can lay out at this point in my career that might help anyone is to expect the stall, embrace some of the chaos that comes from learning, review your process regularly, make changes in your process and culture as needed, and do this with the values and principles in mind that were laid out in the Agile Manifesto.

Now since the Agile Manifesto was created in 2001, I do like to provide some other agile thought leaders who have insights into how the world has changed and some of their content that may help.

Ron Jeffries:

Kent Beck:

Allen Holub:

Jeff Patton:

As always, I am open to any comments or feedback anyone has on anything I publish.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: