More Adjusting…
In my last post we explored an example of using Active Time, by project / team, by activity type to explore whether a teams' effort is balancing appropriately for a given project. We’re going to extend that example to cover a specific methodology.
In this case, our team is using Extreme Programming (XP) for development – so they are Agile in nature. They actively pair program and subscribe to TDD principles. Iterations are 2 weeks in length. When we analyzed Active Time / workflow over the iterations we noticed the following patterns for a “normal” iteration:
| Iteration Period | Analysis & View | Code | Test | Debug |
|---|---|---|---|---|
|
Day 1-2 |
60% |
10% |
25% |
2% |
|
Day 3-8 |
10% |
50% |
20% |
10% |
|
Day 9-10 |
5% |
40% |
35% |
20% |
There are several things we can use this historical trending for. First, we can place some risk triggers in place for subsequent iterations. For example:
- If we’re not below 30% in Analysis & View Active Time by iteration day #3, we may have a problem. In this case, we’re lagging behind in understanding the work technically (research time) or getting sufficient story (requirement) clarity. In either case, it indicates a progress problem that the team needs to be aware of.
- If debugging time exceeds 35% at any time during an iteration, check with the team at a daily meeting as to what might be the root cause. Between us, it might indicate:
- Inexperience on the part of members of the team – struggling to implement difficult or complex features
- Many incoming defects from testing (unit, acceptance, and others)
- It might indicate tools or technology inexperience within the team
- If testing ever gets below 20% of team time, check with the team at a daily meeting to ensure they're not compromising product quality for speed. This might become particularly evident during the last few days of each iteration.
Of course there are other risk triggers that could be set, but you get the idea. You shouldn’t set too many though, just ones you consider significant for a particular iteration, then adjust as you move forward.
I should mention that you’ll need to modify your interpretation of the data in a paired programming environment. In this case, only one of the pair will be tracked at a time – so the recorded Active Time may represent the effort of two.
Part of your adjustment reaction should be correlated to the amount of historical data you have from the team. If you’ve only stored a few iterations worth of data, then clearly you don’t want to overreact to the trending. You instead want to observe and learn the general tendencies. However, if you have many iterations and truly have consistent trending, then your adjustments become nearly self evident.
Next topic discussion:
I want to switch gears a bit and discuss piloting with 6th Sense analytics…
Previous Post:
Learning to Adjust
Next Post:
Fun stuff like timesheets and…
