Agile cartoon about multi-tasking

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.

Request a Call

Looking for support?

Send Us Your Feedback

Provide us with some information about yourself and we'll be in touch soon. * Required Field