There is more to Agile Transformations than Implementing Scrum

 

With some basic agile training and help from an agile coach it can be relatively straightforward to enable several teams to be able to produce increments of consumable software every two weeks.  Unfortunately many organizations stop there, believing that they are “now agile”.

For enterprise agile adoptions starting a few agile teams is the easy part and is just the beginning of your agile transformation.  Proving the benefits and sustaining the change is significantly more challenging.

For illustration purposes, let’s assume that over a six month period we have conducted a series of Disciplined Agile workshops and kickstarted twelve teams.  The teams have separate product owners with their own work item lists.  Some of the teams use the DAD basic Scrum-based lifecycle while others use the DAD Lean lifecycle.  The Scrum teams adapt their lifecycle for their context with the simpler projects having a one week Inception phase while the more complex projects use a two week Inception.  For the Construction phase novice Scrum teams use two week iterations while the more advanced teams chose one week iterations.  The teams vary in size from four to twelve team members.  By rolling out the teams in an incremental fashion, with some coaching the teams have learned the key DAD practices for being effective on both the Scrum and Lean teams.  Word is spreading that the teams are impressing stakeholders with regular demonstrations of new functionality.

However, after the honeymoon period is over, people start to ask some interesting questions such as:

• What are the limits of self-organization?  I understand that teams are free to customize their own processes but isn’t some consistency good across teams?
• What are the key milestones for each team?  What is the release schedule for each team?  Are the teams on track for delivering the solution consistent with their Inception vision?  How do I see this information?
• How do I know which teams have the greatest risks outstanding?
• What is our product roadmap strategy across teams?
• How do we measure the effectiveness of one team vs. another?
• How do we measure the effectiveness of individual team members?
• What is the new career path for agile team members?
• How to we adjust compensation plans to encourage effective team behavior and reward individual contributions?
• Has our quality assurance group adapted for agile to have the appropriate mix of embedded vs independent testers?
• Do we have less technical debt than before agile?  How do I know if our quality is improving?
• How do I know that teams are effectively engaging with enterprise authorities such as architecture, data, and quality assurance?
• How can management use agile and lean principles themselves?

These are all fair questions.  For your agile adoption to be effective and sustainable you need a strategy to address all of these issues.  The Disciplined Agile Manifesto adds a principle to the Agile Manifesto regarding the need to adapt your organizational ecosystem to be effective for enterprise agile adoptions:

The need for good governance doesn’t go away with agile.  Your stakeholders deserve the right to gauge the health of their investments in your agile initiatives just like any other project.  There are indeed answers and various strategies for all of the above questions which will vary depending on the context of your situation.  Like it or not, the reality is that effective and sustainable agile transformations can take several years in order to achieve the level of capability and maturity that you expect.  A transformation is a journey, not a destination.  Make sure that your agile coaches have answers to the questions above and know what to do after your Scrum honeymoon period is over.  We will outline some DAD strategies for the questions above in future posts.

For a more detailed discussion of how DAD extends Scrum, please read the whitepaper Going Beyond Scrum.