Scrum Is Hard and Disruptive

People sometimes come to our classes expecting us to be some kind of snake oil salesmen pushing the latest quick fix to all their problems. Scrum is not that. Despite articles like this one, I’ve never met any of these people who are supposedly claiming Agile is a silver bullet — even amongst our competitors.

Others come with the expectation that Scrum is just a nice practice they can layer on top of their existing hidebound bureaucratic messes to use “resources” (human beings) more efficiently. Scrum is not that either.

Scrum, a simple framework with no redundant or optional parts, is hard to do. It disrupts the organization to be the best it can be, and it puts facts you’d prefer not to know right in your face. Scrum is hard and disruptive. If it’s not hard and disruptive, you’re not doing Scrum!

A person at a large company forcing its unwilling employees into Scrum training proudly told me “We’re doing a MODIFIED version of Scrum,” as if it had never occurred to anyone before to modify the framework and avoid confronting organizational impediments. It’s OK with me if people want to experiment with diluted, compromised versions of Scrum. I just wish they’d stop calling that “Scrum.”

Here’s a clue: if you’re shoving Scrum down people’s throats with a top-down, command and control “rollout,” you’re probably not doing Scrum.

Ken Schwaber recently gave the Scrum Trainers the following text:

1. Scrum is a framework for iterative, incremental development using cross-functional, self-managing teams. It is built on industry best practices, lean thinking, and empirical process control.

2. Scrum is optimized for high yield product management and product development. Scrum is particularly appropriate for high risk, complex, large projects and can be used when other parts of the endeavor are hardware or even waterfall development.

3. If waterfall suits current needs, continue using it.

4. An enterprise can use Scrum as a tool to become the best product development and management organization in its market. Scrum will highlight every deficiency and impediment that the enterprise has so the enterprise can fix them and change into such an organization.

5. Whenever an enterprise modifies or only partially implements Scrum, it is hiding or obscuring one or more dysfunctionalities that restrict its competence in product development and management.

6. The iterative, incremental nature of Scrum puts stress on the product development organization to improve its engineering skills and on the product management organization to optimize the return on investment of every release and project. The phrase, “That can’t be done here” really means that it will be very difficult to do so. The gap between current practices and target practices is a measure of incompetence and competitive risk.

7. The use of Scrum to become an optimized product development and management organization is a change process that must be led from the top and requires change by everyone within the enterprise. Change is extremely difficult and fraught with conflict, and may take many years of sustained effort. Turnover of staff and management can be expected.

8. The most serious impediments to using Scrum are habits of waterfall, predictive thinking over the last twenty to thirty years; these have spawned command and control management, belief that demanding something will make it happen, and the willingness of development to cut quality to meet dates. These are inbred habits that we aren’t even aware of anymore.

9. The focus of using Scrum is the change from old habits to new ways of doing business. Scrum is not implemented or rolled-out as a process; it is used to foment change.

10. Scrum is not a methodology that needs enhancing. That is how we got into trouble in the first place, thinking that the problem was not having a perfect methodology. Effort centers on the necessary changes to the enterprise.

11. Iterative, incremental development is much harder than waterfall development; everything that was hard in waterfall engineering practices now has to be done every iteration, and this is incredibly hard. It is not impossible, but has to be worked toward over time.

12. Managing a release or project to deliver only the highest value functionality and not deliver the rest optimizes value and is the job of product management and customers.

13. Self-managing teams are extremely productive. When they work closely with the customer to derive the best solution to a need, they and the customer are even more productive.

14. A team consists of people trying to do their best. Conflict is natural and the team needs to know how to deal with the conflict and have resources to draw on when needed.

15. The role of an enterprise’s management changes from telling people what to do to leading and helping everyone do their best to achieve goals. People aren’t resources and managers aren’t bosses.

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *

*