I had been to
Netobjective’s seminar “Transition to Agile” about two years ago, so I knew this month’s talk on “
Use Case Driven Agile Development” (August 15, at De Anza College) was likely to be good. It was very good. Dan Rawsthorne is a good coach.
During his two hour talk, Dan gave what he calls a “low precision, sunny day-version of the truth”. Here are some brief notes on the first part, the Essence of Agile.
First, for whom do we (or should we) develop:
- Ultimate end users
- Maintainers
- Whoever pays for it
Agility is about paying attention and reacting. You can’t not make mistakes. What you can do is figure out you made a mistake quickly and react accordingly.
According to studies by The Standish Group, an average of 45 percent of any given product will never be used. It’s complete waste. With agile development you are trying to avoid that kind of waste. The magic of project management then, according to Dan, is to redirect the resources used to build the stuff that’s not needed towards the useful things that we don’t know about (yet).
Here’s what you should aim for in an interative product development cycle:
- 1. iteration: build the 7 percent that’s always used.
- 2. iteration: build the 13 percent that are often used.
- 3. iteration: build the 16 percent that are sometimes used.
- 4. iteration: build the 19 percent that are rarely used.
- 5. iteration: no development here, just avoid the 45 percent that are never used!
Of course, one can never fully achieve this, but keep it in mind while you’re trying.
A brief summary view of project management:
- Goal: provide a suitable solution for users that consists of quailty code and doesn’t cost too much.
- Ideal: convert effort you would spend unwisely into developing things you don’t know about yet.
- Common strategy: get your money, then spend it wisely.
- Implementation: we claim this requires an agile process.
The essence of agility:
- iteration
- validation
- feedback
The important thing about agility is doing everything in small, easily validated chunks. Validate that the chunks are the right ones and that we have accomplished them. So, a process is amenable to agility if it can be decomposed into small chunks, each of which can be validated.
Interesting note about the half life of requirements. We all know requirements go stale after a while. At a rate of 3 percent per month, that means a 100 percent change over a 3 year project period (or maybe one third of the requirements change three times over the course of the project). Why? The universe changes around your product. Even if you knew your requirments perfectly they’d be wrong after a while.
One of the “good” team philosphies leading to agile is validation centricity (validation is any activity that lets you know you’re doing the right thing and you’re doing it right). Activities of validation, verification and test are more important than those of analysis, design, and construction (some agile teams validate as often as twice a day!).
And finally, let the product lead: decisions must be based on the product, not documented plans, anlyses, requirements, or designs.
Download the seminar notes (PDF).
