Posted by andy in : Agile,Business Value on January 31, 2005. There are no responses »Here are some tips I picked up this week from a friend. He has just started at a new company. His new company has lots of projects without any clear indication of their business value. So he got them to draw a matrix like this (an evil 2×2 consultancy as it’s known in the trade):
|
High RiskÂ
|
|
|
|
Low RiskÂ
|
|
|
| Â |
Low Value To Customer
|
High Value To Customer
|
He then asked everyone to place their project in the appropriate box!
This really helped people think about the business value. Just trying to justify the position in the box, makes you think about the value of the project. We’re not just doing projects for doing them sake (hopefully).
It was surprising how many high-risk, low value projects appeared on the grid! You can now ask “Why are we doing these?”, followed by, “Shouldn’t we be investing our energy elsewhere?”
The best bit of advice came at the end. I asked him, “But won’t they simply do the chart to humour you, and then return to their old ways?”
“Don’t be silly, I’ll just keep giving people more work until they stop working on non-important stuff!”
Still, I thought it was an interesting technique that was worth sharing.
Posted by andy in : Agile on January 27, 2005. There are no responses »Check out http://www.waterfall2006.com. I particularly like the registration page:
We’re sorry but registration is not yet ready. Our software developers have a really wonderful design. They’re almost done entering it into it a UML tool. They’ve told us not to worry and that finishing it will be “trivial” because “all that’s left is the coding.”
Posted by andy in : Agile,Coaching on January 12, 2005. There are no responses »I have noticed a couple of common problems when the team meet the business to estimate what they are going to do next:
- There is too much talking and the estimating takes far too long.
- It does not involve the whole team. Some people don’t feel confident to participate while others dominate the proceedings.
Here is a little technique that is worth trying if you find yourself in this situation:
- Get someone to read out and quickly explain the task that needs estimating.
- On a count of three (as if playing Rock, Paper, Scissors!), each developer presents a hand showing their estimate with a finger representing a unit of work. If you feel that the task is too big for 5 units of work, simply break the task down and repeat for the smaller tasks.
- We take an average of the team estimates.
The nice thing about this is that it is quick, fun and appears to provides reasonably accurate estimates (probably because it involves everyone).
