Can you do it?
This post was originally written while I was at LShift / Oliver Wyman
You’re somewhere in the middle of an Agile project. As usual, once you’ve actually started development, the true nature and scope of the project is becoming clear and the client asks ‘Can you do <some “clarified” feature>?’.
This, of course, is a trap of linguistics. As programmers we can do anything so confidently say yes, but the question they’re really asking is “WILL you do this?” with a side order of “as well as all the other stuff”. It’s related to the other trick question “Can we bring this task/feature/bug into the sprint (as well as all the other stuff)?”
As Agile practitioners (all LShift lead developers are trained in DSDM), to stop project expectation/scope/costs/deadlines spiralling out of control the conversation needs to encompass ALL of these four questions:
- Can we do it?
- Should we do it?
- When should do it?
- What shall we displace so we have time? – or, Is there a case for more budget to be made available, or a subsequent phase (these may signify a change in business goals)?
and it’s the last step that is the hardest.
In manufacturing there is the adage: “Cheap, Quick, Good – pick two”. In Design & Manufacturing (which is what software development is) the model is “Time, Cost, Quality, Features – at most three can be fixed”.
You always want high quality, so the negotiation has to be found in at least one the other three areas. But budget is often fixed and a deadline has been promised – so the variable is usually features (if newly discovered items are important, and nothing can be displaced, then new budget must be found).
NB. This is related to the Project Management Triangle though there’s a subtle difference: clients tend to think in terms of budget and deadline whereas implementation teams think in terms of features, velocity (related to team size) and deadline.
In a related post:
“reaching the very end edges of our ability to anticipate how we are going to want things to be and coping with the unknowns we encounter is part of the fundamental nature of developing software.”
True Agile is not just “morning standups and you’re done”, it’s a constant conversation between the client and developers about the relative priority of features. As the project progresses new ideas come to mind, or it’s apparent a feature implies more requirements than you thought (or occasionally less), and this is perfectly natural. An agile project team can respond to the changing requirements, but an agile project manager needs to lead the client through all four of the replanning questions.
