When an organization decides to embark on an Agile Transformation, the first question should be, “Why?” What does leadership hope to achieve? Will the chosen path lead to improved ability to deliver high-quality business value? Once the goals of the Agile Transformation are identified, leadership should consider something that Ken Schwaber, co-creator of Scrum said over five years ago:
“I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it . . . Scrum is a very simple framework within which the “game” of complex product development is played. Scrum exposes every inadequacy or dysfunction within an organization’s product and system development practices. The intention of Scrum is to make them transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them.”
If your teams are bolting on a few Scrum events such as the Daily Scrum to an iterative waterfall software development lifecycle without understanding and embracing Scrum core values, it is a safe bet that you will not achieve the business agility envisioned at the outset of your Agile Transformation.
Is the organization adopting an “Agile-ish” approach as opposed to an Agile Transformation because mid-level management does not want to trade “command and control” with servant leadership? Does middle management believe current processes have already been optimized and that there is no need for continuous improvement? Or is the failure to implement Scrum related to fear of change and transparency?
Having a team perform waterfall iterations is not a reasonable facsimile of an Agile approach.
How many of the four foundational values from the Agile Manifesto[1] does an iterative waterfall approach embody? How many of the 12 principles[2] does it employ? Few if any, as most iterative waterfall teams still apply a significant upfront design phase. An iterative waterfall-based project plan measures progress via arbitrary milestones that do not typically include delivering working software to stakeholders.
When is the last time you attended a program review meeting where everything was stated as “GREEN” though no evidence of working software or customer feedback was provided? “GREEN” is of little consequence without delivering working software. Does “GREEN” mean that you failed to identify “RED” feedback? Is this lack of transparency willful misdirection? Scrum, in contrast, would highlight the deficiencies as they are encountered while delivering a working product increment each Sprint. This real-time feedback provides information while there is still time to act on it to improve the project. An Agile-ish approach may give you some insight at the time of a post-mortem, but that doesn’t allow for any course adjustments in your current effort.
So, have you succeeded with your Agile Transformation or have you “Kind of… Not”? Have you decided not to address the organizational impediments that the Scrum framework makes visible? Now may be a good time to revisit the reasons for initiating an Agile Transformation.
[1] http://agilemanifesto.org/
[2] http://agilemanifesto.org/principles.html