« October 2004 | Main | December 2004 »
November 19, 2004
Ahhh... but does it come with a trophy?
This is a blatant self-promoting advertisment for a workshop I'm giving at XP Day 2004 on Friday, November 26th. I don't normally take the P.T Barnum approach with these things, but they started it :-).
p.s. The aforementioned trophy is here. Jealous much?
Posted by Andy Marks at 02:34 PM | Comments (0)
November 16, 2004
The Parable of the (Two) Blind Men and the Elephant
I was pair on a story with my collegue Pat yesterday and we were trying to design a solution to a fairly tricky problem. Basically, the story was to develop a page allowing the user to make a number of updates to values displayed as cells in a table.
The complexity revealed itself in the validation rules for the changes. In short, for any given set of updates, the state of the cells both to the right and left of each pending update determined whether the update was to be considered successful.
The number of cells to look ahead and behind varied from submission to submission.
Note: The specifics of these rules are not really the focus of this post, so I wont go into any further details here.
The updates also had to happen atomically (i.e., any validation problems would reject the entire batch of changes). In the end, this requirement made things considerably simpler from an implementation perspective.
We spent a good hour or so yesterday morning using decision trees and diagrams to develop an algorithm for determining whether a particular updates was valid or not. In the end, we weren't really any closer to something simple enough to implement. For each rule we had, enough subtle variations existed to make the solution overly complex.
Then, at almost the exactly the same time, we both had a classic Warner Bros. "lightbulb" moment and came up with a relatively straightforward solution:
- Apply all the updates as though there was no validation (without committing anything visible to the user), then check the final result for patterns indicating invalid updates.
So whilst we couldn't easily devise a way to detect a single erroneous update within a set of updates, the end result of an invalid set of updates was easy to detect.
By slightly changing the perspective we were using to address the problem, we'd sidestepped what would have been an 'orribly nasty set of validation rules in favour of a single check of moderate complexity.
I'm not sure either of us would ever have come up with that solution in non-pair mode; it needed the presence of the pair as a sounding board and someone to talk over design.
Posted by Andy Marks at 02:14 PM | Comments (0)
November 05, 2004
Be careful of what you measure
It's often been stated that people optimize workplace performance to suit how they're being evaluated. In other words, if a Project Manager get awarded a bonus for the number of stories completed in an iteration, then that PM will probably leave no stone unturned to cram as many stories into each iteration as possible, including needlessly splitting stories into smaller components.
Examples like this emphasise the importance of taking great care in choosing what variables to track and reward.
So what then do people think of using these two theoretical KPIs for an Agile development team:
- Time, in the form of variance between original estimates versus completed actuals
- Code quality in the form of the number of bugs produced by the team
"What's wrong with this picture?", I hear you say:
- The first criterium implies that the project values "estimate accuracy over code quality". After all, if you're stuck finishing a story in time and are under pressure not to exceed estimates, then you're not going to be developing at an optimal level and code quality will suffer. This drop in quality might be merely a side-effect of the project culture, but it could also be a conscious decision to not test as thoroughly as you want to, thereby saving some previous hours. Of course, we know that "saved time" is spent elsewhere, but we'll get to that later...
- Unfortunately, the quality debt we've built to ensure we never exceed our estimates will have to be demanding payment in the form of the number of bugs escaping the clutches of the team and into the wild. But wait, we're also being measured by the number of bugs we produce! Whatever is the solution?
So what other parameters do we have to play with when quality and time have been locked down in this fashion? Well, the two remaining project variables thus far unconstrained are cost and scope. As it turns out, neither option is particularly pleasant:
- Dropping scope just to ensure accurate estimates, while possible, doesn't seem like a good tradeoff. Do we really want to deliver less business value just to ensure we're able to estimate stories accurately against thin requirements? Is maximizing estimate accuracy really more important than maximizing business value?
Moreover, the sort of intellect that would form KPI's as stated above is probably unlikely to accept such cavalier scope reduction.
- Unfortunately, a more likely solution lies across the cost axis. Specifically, the development team is likely to artificially pad their estimates to ensure they have enough time to build in sufficient quality to satisfy both their internal quality barometer and prevent large numbers of bugs running free.
I seriously doubt most PMs run through these scenarios in their heads before deciding how to measure a team's performance. The result of such negligence is a development team that is coerced into creating a communication barrier in the form of inflated estimates when they're working within an environment where transparency and honesty in such things should be valued above anything else.
Just like when you first learn basic physics in school, project physics using the four control variables can take a little getting used to, but the underlying principles are sound and proven over the ages. The more people who understand the interaction between these variables, the better.
Posted by Andy Marks at 08:00 PM | Comments (0)