CMMI and Agile Blog

July 8, 2011

Reducing the Risk of Your Agile Adoption

Filed under: CMMI And Agile — pemcmahon @ 1:35 pm

Reducing the Risk of Your Agile Adoption

Just as we are reaching the ten year anniversary of the signing of the Agile Manifesto, there seems to be a significant increase in agile disillusionment.  Last month in an article titled,  “Agile Development: What’s behind the backlash against Agile,” [1] we heard about the hundreds of pages that will show up if you do a Google search on “hate Agile”, “Agile sucks” and “Agile fails”.   The article highlights three reasons for the backlash:   

  • Too little analysis being done to address Agile’s appropriateness to an  organization’s situation (people, culture, management structure, business needs, development processes and tools).
  • Trying to force a strict Agile approach when it is not appropriate for every environment. 
  • Misunderstanding Agile principles as a replacement for discipline.

At the Agile Development Practices West/Better Software Conference inLas Vegaslast month, Martin Fowler also addressed this backlash when he referred to the four values of the Manifesto saying those who signed it weren’t trying to say there wasn’t value in processes, tools, documentation and plans.  He said those of us who signed the Manifesto were just trying to counter a strong movement at the time that was taking the industry too far in the other direction.  The main point of his talk centered on the need for the software industry to get back to being guided by value. 

Recently I caught myself trying to push a client too far down the “pure Scrum” path.  They had tailored their Scrum approach and I was concerned their tailoring had gone too far leading them away from key values Scrum provided.   They were not maintaining a consistent length for each Sprint, and they were allowing new work to be introduced in the middle of a Sprint.  I argued, as a good ScrumMaster, that keeping the Sprints a consistent length helps the team accurately predict its velocity, and  allowing new work in the middle of a Sprint was part of the reason they were often in chaos as release dates approached. 

But they forcefully argued back that the reasons they operated as they did were due to issues outside their control. This was a military environment, and I heard, “when the commander changes the top priorities he doesn’t mean wait until the end of the current Sprint.”  And I heard, “when they give us new high priority work we have to figure out the best way to get it all done, and sometimes it doesn’t all fit in a standard size Sprint.”

I backed off recognizing they had figured out what worked best for them given their environment.  As I thought about what happened, I realized the truth behind something Ivar Jacobson recently said to me while we were working together on a Semat blog [2].  Ivar said,  each team involved in developing software has its own method and they only need enough help to know that the approach they are taking is sound. 

The Agile movement of the past ten years has helped us understand the importance of individuals and interactions, working software, customer collaboration, and responding to change.  The risk we now run is becoming too dogmatic in the implementation of our values without adequate consideration to the context of each endeavor.  Agile is not a license to eliminate analysis and discipline. 

Agile, like lean, is more a way of thinking than a specific methodology.  I view agile as a set of tools that can help each team find whatever way of working works best for their current situation.  An agile way of thinking shouldn’t stop at software, but should include interfacing disciplines, such as systems engineering and project management. 

In all my years of helping organizations increase their agility and discipline I have never seen a “pure agile” approach work for even a single team.  There are always some conditions (regulations, staff skill constraints etc.) that require some tailoring.

If you want to reduce the risk of your agile adoption, give your team the freedom and the help they need to figure out the best approach, and the right degree of agility, given their specific situation.  Don’t dictate answers.  Just make the goal clear, and let them know the options they have to get the job done.   


[2] Referenced Semat blog by Ivar Jacobson and Paul McMahon:


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

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 )

Google+ photo

You are commenting using your Google+ 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

Create a free website or blog at

%d bloggers like this: