Sunday, 8 March 2015

Good, Cheap, Quick - Pick 2

In any production endeavour you can pick 2 of the following 3 aims:

           

If it’s Good and Quick it won’t be Cheap.If it’s Quick and Cheap it won’t be Good.
If it’s Cheap and Good it won’t be Quick.


One of the aims of scrum is to square the Good-Quick-Cheap circle as much as possible by ensuring that the delivery of software is always Good, by de-scoping a sprint if Quick and Cheap (read: resource costs) are a concern. 

This means that in Scrum the overall solution requirements are not fixed at the start of the process but rather become a variable to be managed through the life of the project.  The 2 fixed points of Scrum are the increment delivery date - the end of each sprint - and the quality of the increment.  The de-scoping allows quality to be prioritised and the commitment from a mature team with a known velocity allows the Definition of Done to be met at the end of each sprint and thus meet the increment delivery date.  As more increments are delivered, the overall solution requirements can change as much as is necessary to meet changing customer demands.  So rather than Good-Cheap-Quick referring to the total deliverable at the end of the project, it relates to each individual sprint.

Contrast this with a Waterfall process, where the overall solution requirements are a fixed point around which quality rotates. Nominally the time to delivery is also fixed, but it might (and often does) change as technical debt is accumulated, requirements change, staffing issues arise, etc. In Waterfall the increment is the entire solution, and over that time period there are much more likely to be changes which affect the time to delivery; in Scrum, because the increment is only 2 - 4 weeks any changes which occur will only affect the next increment, not the current one.

This all means that the Good-Cheap-Quick conundrum is somewhat less of a burden in Scrum, because the ability to de-scope covers Good, the ability to re-prioritise for each sprint enables efficiency, and therefore covers to a certain extent Cheap, and the short length of the increments covers Quick.  Scrum isn't a panacea for these ills, because any methodology can be implemented poorly or inappropriately, but implemented well, and with appropriate input from those people working around but not in the scrum team (PO, BAs, Customer reps, etc), Scrum can certainly help.

As always though: Development is a process, and some things simply have to be done in order. Agile helps with that, but it doesn’t change it.  



UPDATE: Since writing this, I've discovered that the Waterfall situation that I described is actually a formal model called the Project Management Triangle (aka Triple Constraint or Iron Triangle).  On the one hand, it's a bit annoying to think I might have reinvented the wheel (yay! I've thought of something new! Oh.....hang on.....dammit....) but on the other hand it's nice to get a bit of validation that my thinking makes sense in a broader context.  Perhaps I should investigate this Project Management malarkey a bit more.....