RallyDev.com
Wed 25 Feb 2009
What’s with all the Agile Process Overhead? Part 1
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:
Hi,
We use Rally for our Scrum and found it good. When we started Scum and started using rally for it we also started putting everything in sprint backlog and found it is not good. So we did following
1. We removed everything from Sprint backlog not it was decided not to use Rally as time sheet tool, for that you have other tools which you use for time sheet.
2. We looked into our history and found no one can work for 8 hrs so we decided to barin storm and find out what is the time members actually work on development keeping aside meetings, emails and other stuffs. We found it is actually 6 hrs which productive and 2 hrs goes into discussion, meeting, issues , emails and other stuffs
3. We use another tool, Change Point, for request tracking from customer which has epic stories. We do have initial estimates for those epic stories
4. In the “Change Point” we decide which story goes in what release, so we do our release plan with this tool
5. Once we know our release then we start importing stories for the current and next release into rally.
6. In rally now we have stories for next release in the sprint backlog and stories for current release are in release backlog.
7. In release back log we start breaking up the epic stories into smaller stories.
8. Now Product owner rank these stories in release backlog ( he also ranks the stories in sprint backlog but that is very high level fron 20000 ft)
9. In iteration planning team members start breaking the stories available in release backlog into smaller stories and tasks.
10. once we finish that we start estimating tasks and team members start taking responsibility for the tasks,
11. Here we start keeping track of each story estimate and team members assigned tasks estimates.
12. we keep comparing the estimates with the previously calculated velocity for the team and each team so that we should not over commit or over allocated
13. We plan for iteration only for 85 % of its capacity keeping 15% for support.
14. Before we goes into iteration Scrum Master do calculate each team members availability for that iteration considering Vacation and other stuffs
15. Once we reach upto 85% of capacity we move those stories in Iteration and commit
16. Stories left in release backlog will be considered in next iteration plan
Here you may say 1st we have cut productive hrs and considered only 6 hrs out of 8 hrs and then plan for 85% of the capacity. Yes that’s valid but we actually compared the output and cost and found we have saved 3000Hrs @ $100/member = 300000.
This we could achieved only because team was so committed to its commitments and free to take any task and doing other tasks like testing, reviewing documentation.
Ravi, You look as though you and your team have a sound process for continually improving how you allocate your work in a Sprint. In my next post, you will see that I refer to your comment. I stress the need to think about ideal effort hours and then even add on a buffer for unknowns on top of that. Thank you for your feedback! Jean