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.

Yesterday, I mentioned a Rally client team I visited that was concerned about the Rally tool’s inability to create individual team member burndown charts.  We swam through that torrent of misperception only to enter a shark-infested tank around all of the overhead involved in adopting Scrum. Wait! Isn’t Agile supposed to cut costs, not add them? Big overhead sounds like cost and waste to me. Where is this overhead? We quickly zeroed in on their overhead: the Sprint Backlog. Specifically, what should be tracked in the Sprint Backlog?

To start the conversation, they told me that they are always 100% allocated. Huh? “What do you mean you assume 100% allocation?” They helped me understand that, in the Sprint Backlog, they assumed that they worked 8 dedicated hours everyday. For them, Sprint Backlog should reflect all of that time.

This was followed up with, “So how do we plan for work that we didn’t know would come up, like production issues?“  Clearly, they hadn’t read Slack by Tom DeMarco or heard of the Theory of Constraints and The Goal by Eliyahu Goldratt and the notion of buffer. So, we had a few things to clarify around this “process overhead”:

• What goes in the Sprint Backlog?
• How do you allocate your time effectively?
• How do you “plan” for unplanned work?

In this first post on the Sprint Backlog and using Agile to cut costs, I’ll concentrate on the first bullet:

What goes into the Sprint Backlog?

The Sprint Backlog emerges from the Sprint Planning meeting as the team:

• Identifies the highest priority value items
• Breaks them into tasks
• Determines the effort necessary to complete the value items
• Commits as a team

We cut costs by only committing to and tracking the highest priority items that deliver value in that timebox.

We cut overhead by not tracking items in the Backlog that do not contribute to the potentially shippable product increment.

So back to our overprocessed team. We opened up the Rally tool and moved to their Iteration Backlog view. I saw over 50 items, at least. And then, I understood.

The team was putting EVERY task they do throughout the timebox into the Sprint Backlog, whether it added value to the product increment or not.

Imagine having to track all of your day’s activities. Imagine having to, 2-4 weeks in advance, absolutely commit to these full days’ worth of activities. So, indeed, here was the overhead. Vacation days were in the Sprint Backlog: they had 8 hours of effort. Holidays were in the Sprint Backlog: again 8 hours of effort. The book club had to be tracked separately for each individual who attended it.

The result was that the overall team’s Sprint Backlog would show effort being completed, backlog items being marked “Completed”, the burndown chart burning down nicely, and yet no work of product value was started or in progress. This was not a tool issue; this was an Agile adoption issue.

What is the lesson in all of this?

Be careful about what you choose to track in your Sprint Backlog.

Ensure that what you commit to in that Backlog reflects the delivery of product value.

Abiding by this simple guideline will not only dramatically reduce process overhead, but it will also ensure that what we DO choose to track, whether through a taskboard or an automated tool, is work that is intended to produce product value by the end of the timebox.

Now about their allocation percentages and how it contributes to overhead. That is fodder for another post.

Further Reading:

• Part 2: How Do You Allocate Your Time Effectively?
• Part 3: How Do you Plan for Unplanned Work?