About Scrum and Agile

Recently a client with a long established history of following the Scrum framework (not text-book but pretty close), explored a proposal to revert to a neo-Waterfall model and I responded with a fairly harsh rebuttal.

To be clear, I encourage all my clients to experiment and explore different avenues in the quest to improve their processes and deliver more value; however, when the journey appears to have perils in future, then an intervention is necessary….

The proposal was to concentrate significant effort at the kickoff of a project: spending time defining all the functional specifications, then completing all the designs and finally estimating the size and duration required. The rest of the project would only proceed once this phase was completed.

The knee-jerk for this proposal was when many the backlog refinement sessions degraded into time-consuming technical design debates. Whilst the need for an improvement was rational, the medicine was not.

To me this screamed of waste and rework : waste of the effort concentrated at the project initiation, with guaranteed rework as the team uncovered new information and the Product Owners understood the requirements organically.

My comment was that this approach could work for projects where the client was proficient and had a fair track-record, however new projects with unknown technologies or vendors would suffer from an inordinate amount of ‘analysis paralysis’ as Product Owners and Architects attempted to design and document down to the n-th amount of detail.

The antidote to the disconnect between technical and functional design should be increased high fidelity discussions, with decentralised teams having the authority to make pertinent decisions.

Granted, remote working doesn’t help – now more than ever more, creative solutions and open-minds are needed.