The Pragmatic Approach to Agile Adoption
It is perhaps a little ironic and apt in relation to Agile and Scrum that LeSS is the abbreviation used for the Large Scale Scrum Framework, used for scaling Scrum for enterprise use. Many now consider Agile Scrum, or seperately, the two terms Agile and Scrum together as contradictory (especially when scaled up), with Scrum seen as a lesser form of Agile or perhaps a less extreme version of Agile.
The argument is not new, after all, Scrum is an earlier version of Agile, an earlier idea of what was once considered Agile. In fact, Scrum was originally proposed as a product development methodology. Not surprisingly, Scrum is now often considered a project management framework rather than an Agile development framework by many (and it is no longer just the Agile purists). Regardless of how Agile Scrum actually is, it is the most popular framework to adopt and as an Agile development framework it is a stepping stone on the path to Agile, from lesser Agile to greater Agile. Unfortunately for Scrum, it is not easy to scale up for large enterprise adoption.
Hostility towards Scrum is perhaps a consequence of the mass adoption of Scrum by Project Managers who make up a large part of the ranks of Scrum Masters, and who practice it from a Project Management perspective rather than a Developer perspective, thus alienating the latter. Consequently it can be argued that Scrum has become a project management framework and is an Agile development framework in name only.
By scaling up any Agile framework you are in effect making it less Agile, but does it matter?
It depends on who you ask. Scrum just works for smaller businesses, especially in terms of productivity gains that can be achieved. The Scaled Agile Framework (SAFe®) is an alternative to Scrum, with SAFe® winning the large enterprise market in part because its more flexible and easier to adopt. However this framework also has many critics who claim that it is also less than Agile, or at least less Agile. The problem is that labels have power, for good or for ill and unfortunately for Agile much of the criticism of Scrum and other frameworks is interpreted as criticism of Agile, when in reality they are very different things (Scrum is a framework whereas Agile is a methodology).
Scrum success is highly reliant on the successful implementation of Agile methodology and an Agile working culture. It’s not surprising then that Scrum and Agile are often confused, since you can’t have effective scaled Scrum teams without an enterprise Agile work culture and intelligent management.
The Blame Game
When Scrum adoption fails, it is frequently dismissed as a failure of adoption of an Agile working culture, as if you can somehow separate Scrum from Agile. Companies that fail to adopt Scrum tend to blame the training, and frequently they do have a point. Unfortunately many businesses sign up to the idea of implementing an Agile Development Model and then get a less Agile solution with Scrum. Of course the trainers blame the organisation for failing to adopt an Agile working culture.
Criticism of Scrum and other frameworks is rarely applicable to Agile and yet somehow Agile gets the blame.
A quick search on Google revealed the following criticisms of Scrum:
- Velocity estimation is only good for identifying how good a team or team member is at making estimates and therefore it is not based on productivity. Not compatible with the Agile Manifesto.
- The idea of the Sprint is not compatible with sustainable development (the primary goal of Scrum). By no definition does burnout equal sustainable.
- The Scrum Framework does not adhere to the Agile Manifesto, and therefore should not be considered an Agile development framework at all. In effect it is being incorrectly labelled.
There are plenty of examples of criticism for other Agile development frameworks, each with its own advocates and naysayers.
Enterprises looking to adopt an Agile development framework should consider the alternatives carefully. Hybrid development models such as Scrumban are considered far from ideal but are best in specific circumstances and in most cases hybrid methods are the operational reality, with processes tailored for the business in question. A process-by-process migration over time typically leads to hybrid models with positive results, or could potentially lead to Scrumbut (in the case of Scrum hybrid). These mixed methods should not be referred to as Scrum or Agile, but rather as Hybrid models.
If your business is avoiding taking the all-in Agile purist approach to adoption, and instead looking at hybrid transitional options (the reality for most businesses) then you need the right Application Lifecycle Management tool (ALM software) for the job.
Whatever the Agile path your business is on, it is critical that an ALM Software is adopted for Scaling Agile, no matter the framework used (or hybrid model). codeBeamer ALM is versatile enough to meet your organizational requirements on every level and is one of the few ALM software options available for the complete implementation of the Scaled Agile Framework (SAFe®), as well as DevOps. Your path to Agile and DevOps can begin and end with codeBeamer ALM.