This is the first of a number of reported lunch-time dialogues, which may or may not have happened at the 2005 Agile Business Conference. The topics will be the most controversial aspects of DSDM, which will be considered and addressed from a pragmatic DSDM perspective.
If you have any controversial questions you would like to ask, you are warmly invited to dress up as a delegate and join the discussion in future editions of the newsletter.
| The Question | “SHOULD HAVES BEFORE MUST HAVES? ARE YOU MAD?” |
|---|---|
| The Scene | Agile Business Conference 2005. Lunch is being served in the spacious Queen Elizabeth II Conference centre. The panoramic view from the 5th Floor window showcases the Palace of Westminster and Big Ben. Delegates are emerging from the conference auditorium, to a beautifully-prepared hot buffet. The air is a buzz of conversation. Two earnest-looking people arrive at a table, locked in fierce debate. |
| DSDMer | (Hangs anorak on back of chair and sits at table) Timeboxing is a really powerful aspect of DSDM for keeping the project under control and ensuring on-time delivery. If you use an overall timebox of, say, six months for the project, but then break this down into smaller timeboxes of, say two or three weeks, and define a business-focussed deliverable for each, you will be able to see progress clearly and get warning of any problems early enough to take action to address them. |
| Conference Delegate | Seems reasonable (munches on chicken leg) |
| DSDMer | It would look a bit like this (draws incredibly neatly on napkin) |
| Conference Delegate | (Almost choking on the chicken leg) Well, that’s just stupid! The shoulds and coulds in the first timebox are being done before the must-haves in the second. Any fool knows you have to do all your musts first! |
| DSDMer | Well, not really if you think about it. You are trying to build something useful and complete within each timebox. A sensible set of features to deliver together will usually include some musts, shoulds and coulds. In the first timebox, for example, you might be creating the screens for adding a new customer account. Must-haves would include capturing the right data, doing the credit checks and so on. A should-have might be the adding of a photograph of the customer on-screen – useful but we could manage without it. |
| Conference Delegate | Well, why not leave the photograph until the last timebox? |
| DSDMer | Because it sensibly goes with the development of the customer data entry screen. You’d end up with a “rag bag” of unconnected bits of development if you left all shoulds and coulds to the end. And you’d have to “re-open” lots of unconnected pieces of code. The testing would be harder… |
| Conference Delegate | Hmmmm (mouth full, so unable to interrupt) |
| DSDMer | And if you left all the shoulds and coulds to the end you couldn’t have the possibility of delivering key features early. |
| Conference Delegate | No, I still don’t like it. To give me confidence that you’d deliver on time, I would need all the musts to be done first. |
| DSDMer | And what would happen then, if you’re estimating was wrong? You’d have nowhere to go to get back on track.![drop_must[1]](/blog/../content/wp-content/uploads/drop-must-have.jpg) …but if you have shoulds and coulds, you can leave these out and get back on track immediately at the end of the timebox. |
| Conference Delegate | Excuse me, but that banoffee pie over there looks delicious. I’m off to get a piece before it’s all gone. |
| DSDMer | …but I haven’t finished explaining yet… |
Well, do you have more staying power than banoffee-man? If so, put your questions on this and any other DSDM issues to the DSDMer. We look forward to hearing from you.
Recent Comments