RallyDev.com
Mon 2 Mar 2009
What’s with all the Agile Process Overhead? Part 2
In my post “What’s with all the Agile Process Overhead? Part 1″, I reviewed the contents of the Sprint Backlog. Hold, commit to, and track items of value there. Nothing else.
I eluded to two other perceived Agile Process overheads, one of which I’d like to peek at today: how do you allocate your time effectively?
This came about from the same client discussion that prompted the post on the Sprint Backlog. In conversation, I discovered that the team believed that they had to be 100% allocated for the entire duration of their Sprint. Hence, the lengthy, detailed nature of their Sprint Backlog. Time to back up.
Team Members determine their ideal effort availability
We’ve already covered one problem with this allocation paradigm: you are tracking the wrong thing in your Sprint Backlog if it is not showing value-add work completion. Now, here is the second villain. No-one can accurately account for all hours of every working day as “ideal effort hours”; that is, hours of completely uninterrupted, undistracted work. Ravi Jha stole some of my thunder on this with his great comment to my previous post. Heed his advice from February 27!
Teams preparing to plan their commitment for a Sprint/Iteration look at their capacity; that is, how much work do we believe we can take on and complete by the end of the Sprint? As Ravi pointed out, a good team assumes from the start that it cannot devote a full 8-hours a day strictly to product backlog value-add work. A good beginning capacity number is 6. Why 6? Because it is not 8. Until informed otherwise, of our 8-hour work day, we believe each of us can truly be heads-down concentrating for 6 of those hours. The rest of the time will be swallowed up by interruptions, emails, unplanned meetings, and other distractions.
Now, here is the sticky part. As I mentioned in Part 1 of this series, Agile teams must also take into account slack for what they can’t know. This is different than the 6 hour number of ideal effort hours. When we make a commitment in a Sprint Planning meeting, the commitment is:
- We are committing to moving forward with what we currently know so that we can continue to learn by building a potentially shippable increment of the product.
- Our intention is to complete all of these Sprint Backlog items based on the analysis and conversation that has happened to this point.
- We think it will take these many ideal effort hours and we believe we have this many hours available.
- Everyday, we will honestly evaluate how we are doing with our commitment so that we can improve on meeting this commitment AND improve on how we make commitments in the future.
Therefore, a team, not knowing what it doesn’t know, applies a certain additional level of slack or buffer to how it commits. Call this the “Commitment – Buffer of Unknownables” (or C-BOUs). Now the team that has 6 uninterrupted hours per team member per day may additionally say, “Our C-BOU is about 1 hour person right now per day because we just don’t know this product or this process very well. We don’t know what we don’t know, though we know we want to get better.” As the team evaluates the Product Backlog Items with the Product Owner, and as they determine tasks and estimates for this work, they are keeping in mind:
- what ideal hours they will need
- what ideal hours do they have
- how much C-BOU should they hold back
By the end of the Sprint Planning meeting, a commitment then truly represents:
- Items of value we intend to deliver
- Commitment by the team to learn about commitment
- Intention to use the buffer for what they couldn’t have known
- Agreement to evaluate the C-BOU at each retrospective to see if it needs to be bigger or smaller
Some teams call for a bigger C-BOU due to the volatility of their environment. (Okay, they prefer to say their business is very “organic”.) Tracking this capacity buffer is a great way to enable getting to the root of that “organic” nature. Without paying explicit attention to the truth of unknowns and the amount of time they take, a team and the agile project management can create waste and overhead. Teams go into a frenzy mode to meet a commitment that allowed for no buffer, no unknowns. Management applies pressure to meet the commitment despite the clear and present issues that are eating up the efforrt. None of these tactics improve team commitment; they create overhead, waste, and low morale. And they add the cost of manaing all three of these.
That’s it for Part 2. In Part 3, I’ll talk about how you plan for unplanned work, without using a crystal ball :- )
Jean I love to read your blogs, these are informative and useful. I would like add few more things to this “over head Part2”
You are right we should keep some buffers for unknown for what we keep 15% of our capacity (as I written in my last comment, February 27). There are two unknowns we consider
a) Known unknowns
b) Unknown Unknowns
Known Unknowns – The versions of packaged product deployed on different environments are different. You may have different versions deployed on
1. Development environment
2. Testing environment – this is the environment where a different quality center team does test the product’s features, integrity, functionalities and other stuffs.
3. User acceptance (Real user) environment – this may not be the case with every one but this is with us. A small number of users are given access to this environment to test
4. Production environment – this is obvious
Now the team is working on , say Iteration 12, and Testing environment has the product delivered on It 10 and in production we have product delivered after Iteration 8. You never know what bugs may appear in what environment, so we keep these as Known Unknowns.
To tackle this we already have 15 % buffer and we think that’s enough as when we delivered we did the testing and delivered it with confidence. User may say some thing as bug but most of the time that turns out to be data problem or some thing else.
Unknown Unknowns – The name indicates that as a team we are not able to define this. So what we do – we do keep a story some tine 10 hrs some time 20 Hrs in Rally. We do keep two releases in Rally for same Iteration
1. First release is the actual enterprise level release name and number to which our product development is attached with
2. Second release is a maintenance release – Story and support work stories are attached with this release
The reason for having two release are
1. Keep track of actual release development with plan estimates, actual hrs spent etc
2. Keep track of maintenance work or support work we do – this helps us to identify issues or risks
Now as weeks passes and team members’ uses their time to finish stories and still don’t have any support or maintenance tasks then we bring in other stories from release backlog
Some time we have lot of dependencies on other external sources we do know very little when we did our planning and started our iteration. After one or two weeks we do find that the plan we did is not enough then we abort the iteration and plan it afresh.
Risk handling We do have our risk register and we do maintain impact analysis and mitigation plan. When we identified risk (initially) and plan the mitigation we did it as one story. As Scrum Master I do keep updating this on regular basis.
>> The rest of the time will be swallowed up by interruptions, emails, unplanned meetings, and other distractions.
I think those interruptions aren’t too much agile, thats the kind of stuff that Agile teams try and should avoid.