There seems to be a lot of discussion these days about whether or not Agile still works, and whether or not Scrum in particular is “dead” or at the very least dying.  The common thread that I see in these discussions is usually something to the effect of “why do we need set iterations” or “user stories suck as requirements documents” or comments in a similar vein about some fundamental part of the Scrum methodology.  But, what many of these people forget — on both sides of the coin — is that if we are to truly embrace Scrum as an Agile methodology, it requires us to focus on one measure of success — actual, demonstrable results.

“Individuals and Interactions over Processes and Tools”

This is the very first and most important statement in the Agile Manifesto, as it sets the tone and goal of all the others.  If we’re really Agile, then we shouldn’t be religious zealots about any specific methodology, tool, or process.  We should view those things as means to an end, and as ways to focus our interactions with individuals within the Scrum teams.  Many Scum implementations fail this philosophy from the word go, for the following reasons:

• Scrum focuses on teams, not individuals;
• Scrum prescribes certain specific ceremonies that “must” happen; and
• Scrum prescribes a certain process that requires short iterations and small efforts.

There are many ways in which Scrum appears to be inherently anti-agile — and by refusing to deviate in any way from what the Scrum “gods” have delivered from on high is to reject entirely this fundamental principle of Agile development.

“Working software is the primary measure of progress.”

Hidden amongst the Twelve Principles of Agile is this gem — which provides us with the touchstone from which we should approach any Agile work.  If we’re not delivering something of value, and we’re not ensuring that what we’re delivering is actually working and meeting customer needs then we’re simply plodding along in a “death march” that makes some people feel good at the cost of delivering actual business value to the organization.  Scrum attempts to achieve this by:

• Setting a short-term commitment that delivers some value at the end of the sprint;
• Putting a “Product Owner” in place whose job it is to ensure that work is useful, usable, and meets the customer’s needs; and
• Requiring regular review of the actual work done with the stakeholders who can provide the most useful feedback.

Thus, we can see that the focus on small iterations isn’t necessarily anti-Agile, so long as it is focused on ensuring that the team is delivering working software that actually meets the needs of the business and the stakeholders (and, presumably, through them the customer).

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.”

The last principle in the Twelve Principles of Agile is perhaps one of the most important ways in which Scrum actually enables us to be more Agile.  It’s important to remember that Agile software development has its origins in the concepts and principles of lean manufacturing and the Toyota Production system — in which the two goals are to (1) deliver value with every step in the process, and (2) ensure that the processes are constantly under review and subject to efforts to improve in any way at any time.  Scrum actually helps us achieve this by:

• Establishing a daily regimen of identifying any blocking issues, impediments, or slowdowns that can be acted on immediately by the Scrum Master; and
• Setting up a regular system of retrospective reviews that require the team to reflect critically on what they’re doing, how they’re doing, and to identify new things to try every single iteration in order to improve.

While there certainly is some process prescribed by Scrum, the end goal of it is to enable people to deliver working software and to reflect on how to be more effective.

“Responding to Change over Following a Plan”

The last statement of the Agile Manifesto brings us to a logical conclusion where Scrum is concerned.  Following textbook Scrum as it’s described and espoused by people with no concept or understanding of your particular culture, business, or fundamental needs is “Following a Plan.” Instead, we should choose to “Respond to Change” by using Scrum’s own prescribed systems against it.  We should use our retrospectives within the Scrum framework to identify how we need to adapt the process to ensure that we’re delivering working software as quickly and effectively as possible.  We shouldn’t blindly follow Scrum if it’s blocking us from actually doing the work that we need to do.

Focus on results — if Scrum is getting in the way of those results, change it so that it’s no longer blocking you.

Make Scrum your own.