Agile Development Blog

Sarah: “Walter, I just want to check in with you following the team demonstration and see how you are doing with the new Agile approach”

Walter: “Sarah the results were thrilling for the customer and the team.  Everyone seemed engaged and the dialogue was very healthy. I see it, but it does not make sense.  We are moving features through the team faster, but I had to do this with dedicated resources.  I am sure this is costing me more.”
Sarah: “Walter, this is totally normal.  You are seeing the difference between single tasking and multi-tasking as well as optimizing the whole versus a certain roles or steps.  We can do a little model to show you that this Agile approach is better, faster and cheaper.”

Walter: “Well that would be very good because it is very counter-intuitive to me and all my management tools and tricks seem to run at odds with this approach.”
Sarah: “Great observation, Walter!  As you told me earlier, you tend to focus on fully allocating engineers.  In Agile we focus on increasing the throughput of value by optimizing the whole flow through all roles.”

Walter: “Right now I just want to stay out of the way, because I do not know how to help.”
Sarah: “Walter, let’s spend some time to get you comfortable with the impacts of batching, queuing and task switching.  Once you see the math, we can talk about how to serve the team by proactively clearing impediments to smooth flow and taking some savings to invest more in them.  The team will love you for this commitment.”

What benefits will you see when teams are in Flow?

As we described in “What so Great about Flow?“, we think of attaining Flow as the first step in our recommended approach to enterprise Agile adoption.  For this step, we focus groups on adopting agile by the book by team; thus the impact from Flow is only incremental and isolated to the specific team.  However, this does not mean the results of this effort are not noticeable and infectious.

Foremost, groups that attain Flow make changes on the way to becoming a team.  When given space and dedicated members and short time box, new agile teams take three key steps:

1. First the collection of individual contributors comes together to plan a limited portion of their own work. 
   
2. Second they set norms and limits that lead to common commitment to deliver working, tested increment. 
   
3. Finally, they open their increment up to feedback and open themselves and their process up to feedback, introspection and adjustments for continuous improvement. 
   

The benefits seen from doing this are many:

• A team is forming and that makes work more fun and easier for them to manage
• Work-in-process is getting reduced by focusing the work on a small increment of functionality
• Testing is coming forward in the process and quality is beginning to become a team issue
• Hand-offs and delays are declining by dedicating a cross-functional team to working on one thing at a time
• Feedback loops are shortening in the demonstration and review process helping to prioritize the next step

Typically these benefits take one to three iterations to manifest themselves and translate into incremental productivity increases of 15%, 25% faster cycles and a reduction in downstream defects (See the Agile Impact report for more details of business improvements from Agile).  Most of these teams are reporting the benefits of flow.  Teams in Flow settle into a predicable pattern of delivery.  They are not perfect, but you can count on them and estimate based on their historical velocity. We look for these metrics to know if a team is in the state of Flow including:

• a rate of 90% or greater of Story Acceptance per Iteration on an iteration over iteration basis
• an average of zero net, new Defects added to Defect list across iterations
• A reduction in 1/2 of the amount of stories that are in-process across iterations
• A continuous build success rate of 90% or greater for the team’s isolated code base

In general, they are starting to do things in a more lean and less wasteful way.  By working together on a small batch of work with a clear definition of done, it allows the team to focus and reduce the task switching.  To understand why multi-tasking and task switching do not work, you should read this post from Mark McGuinness at Lateral Action or check out Tom Demarco’s book “Slack” and specifically pages 16-21.

However, the most important benefit is the positive feedback from the team members with regard to forming a team and working in this intuitive and social approach.   It is this positive feeling that propels teams to move past Flow and into Pull.  Congratulations if you have the continuous improvement snowball beginning to roll downhill at your organization.  Building the trust and capabilities of the team is the most effective path to more value delivery.  (See “The Scrum Picture is wrong” and the comment/link about the Lean Journey from Jason Yip.)

If your team does not find this benefit, it is clear that there is a fundamental issue that needs to be resolved.   This is a great time to bring in an outside coach to help the team retrospect and give them space to form.  In these situations, it is easy overlook the fact that teams need to go through the process of of forming, norming, storming as they reach toward performing.  Remember this is a journey and you can not go there without building the team.

About the Author: Ryan Martens is a fly-fisherman, founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

I do not believe there is a recipe for Agile enterprise transition plans because good ones must take the context and setting of the organization into account.

I do believe that starting step-by-step is the only way to get the snow ball of incremental improvement rolling down hill.  Our model, Flow-Pull-Innovate, is based on a strategy of creating a self-funding sustainable approach to adopting Agile; where some of the savings/profits from each step are reinvested in the next improvement step. (See my post An Alternative to Agile Adoption Cookbooks – Flow, Pull, Innovate for details on this approach.)

In addition to a step-by-step transition plan, you need a vision, shared commitment and social contract to be successful. Although, The Flow-Pull-Innovate model does provide sign-posts for your roadmap, the actual stories necessary to transition vary.  When we work with groups or organizations to build a plan that will take them from one step to another, we use a transition planning model that I helped define in the mid-1990′s.  This planning model is based on organizational change work from Peter Senge’s Dance of Change and Michael Hammer’s Reengineering the Corporation.

In this step-by-step plan, we use these high-level variables for planning change; “Strategy, Process, Organization and Technology.” In these transition steps, a typical story starts with the implementation of new technical and organizational infrastructure to support new methods, tools and techniques that lead to new way of working.  Download An Example Transition Plan (PDF).

An Example Transition Plan based on the Flow-Pull-Innovate model for Enterprise Agile Adoption

Again, please note this plan is very high-level and a fairly generic application of the Flow-Pull-Innovate approach. (See Jean’s post on What’s So Great about Flow? for more details on the first step.)  I have seen many variations on these detailed plans over that last 6 years.  Use this as a simple starting point for you and your group to think about your own situation.  If you work with Rally coaches to help you plan your organization’s transition, you benefit from their years of experience and ability to start with a clean white version of this model.

Transitioning to Agile at the enterprise level can be a very simple step-by-step process as long as you and your group thinks about it in this way. If you do a good job of defining “Done” for your steps, you will then be able to inspect your progress and adjust your plans based on empirical feedback.  In this way your adoption approach is just like the Agile process your adopting for software development; an empirical process that you steer with regularly schedule inspection and adjustment.

If, on the other hand, you think about the adoption as a “Big-Bang” that will be done on a certain date, I believe your “plan-driven” thinking will cause you to miss the real opportunity.  You will typically end up with only incremental improvement and not have the momentum to enable your teams to keep up the good work.  And, you will fail to get on the continuous improvement curve that will lead towards Agile/Lean expertise.  Given that most organizations are operating in a “plan-driven” world, this is not a surprising reaction to Agile adoption.   Agile success comes as you gain success incrementally by taking one step after another, while keeping process, technology and organization change areas aligned.

In CMMI, Level 5 teams get to a place where they “become continuous improvement teams.“  In enterprise Agile adoptions, we start folks at continuous improvement and watch them benefit from creating employees and teams that both solve their own problems and continue to re-focus on value delivery through each step.

About the Author: Ryan Martens is a fly-fisherman, founding board member of Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.