I have been part of 3 teams using Agile so far. None of them gave the benefits claimed for Agile, but then none of the projects were really full Scrum (or full anything.) One did not do burndowns or reviews, one did not have a real product backlog, one had a project manager/team leader apart from the Scrum Master and Product Owner. In that last team, finally management was persuaded to sack the project manager on the grounds that the new autonomous team would get everything done when it was 100% Scrum: that didn’t work either. Many of the tools and disciplines that the semi-scrum Agile approach introduced did good: but it didn’t help keep the the deadlines under control.
So my limited experience is that half-assed Scrum does not give the benefits claimed for full Scrum.
My habitual framework for looking at development organizations is the CMM Capability Maturity Model, and Scrum kinda looks wrong against what CMM says. (The replacement to CMM, CMMI, has many improvements and corrections, but the big picture has not changed.) CMMI gives five grades of software development maturity: initial, managed (“repeatable”), defined, quantitatively managed, optimizing. CMM is not really a framework or an exact checklist, but it does provide a way for technical and non-technical management to ask “do we have the right things in place”?
So can CMMI help me figure out about Scrum and semi-Scrum better?
The proponents of CMMI for Development have put out a document to discuss whether CMMI and Agile can be reconciled. They propose that the CMMI culture grew out of larger, low-trust and high assurance contexts like fighter software, while Agile grew out of smaller, high-trust and flexible contexts. (You do not want to learn from your mistakes when the mistake means crashing the zillion dollar jet seems to be the summary, with all the contradictions that entails.) But they think there can be a CMMI that works with the Agile culture, too.
But their main tack is that Agile can be the concrete mechanism for achieving the capability improvements that CMMI proposes. For example, if you adopt full Scrum, you are implementing important aspects of Level 1 Managed (roles and responsibilities), Level 2 Defined (project monitoring, Timeboxes, and the 3:5:3 inputs, ceremonies and deliverables, product reviews), Level 3 Quantitatively Managed (Velocity), and Level 4 Optimizing (Daily Scrum, Scrum Retrospective, etc). It doesn’t tick all the boxes for CMMI of course (and of course Scrum is not the complete Agile story either, you still need to combine it with practical technologies such as Kanban tools, continuous integration tools, and whatever.) But it gives a good head start.
So here is my problem: I have thought of CMMI as a waterfall. You cannot skip levels, it is impractical for an organization to go from Level 0 to Level 5 in one go. So you progressively get more capability one by one. (Of course, each different process area may be in a different state of capability/maturity. But it is still basically a waterfall.) You see where you are, then figure out how to improve your process to the next level.
So from this POV, Scrum does not have a hope of working: it involves jumping multiple levels at once, not going from one to the next. Jeff Sutherland’s videos are very insistent that doing Scrum without velocity estimation is not Scrum, and material spruiking Scrum always mention the process improvement angle. (From the Scrum POV, I guess I have been thinking that the CMM maturity levels are components, while Scrum is a feature (cross-cutting many levels), and Agile says you are sometimes better off implementing features rather than components for all sorts of reasons.) So in adopting Scum you are not trying to move the whole organization from Level 0 to Level 5 in one step: you are implementing a cohesive selection of items from multiple process areas to provide something that works as a unit. (So the adoption of Scrum is itself an example of what you try to do with software development using Scrum!)
OK, that makes more sense: Scrum is like a non-waterfall CMMI.
But I wonder if I am still getting it all upside down—
Perhaps it is not that a Level 0, 1, 2 Maturity organization could not use Scrum to jump to a much higher capability level, perhaps it is that a Level 0,1,2 Maturity organization cannot make the leap to adopt full Scrum or Agile. That an organization implements a semi-scrum solution (unless it is a familiarization exercise for the tools) is a sign that it is actually not ready to solve its problems. Such organizations won’t even get to the stage of development team autonomy, let alone going beyond demanding fixed delivery-times before the velocity has been actually measured. I think this theory makes more sense of my experiences with semi-Scrum.
So the first issue with Agile is to get stakeholder buy-in.