Challenging Why (Not If) Scrum Works

to go up? Of course! Even if they still did development in the same old way, they would still do better because:

• The team would be able to work together as a unit, eliminating significant communication delays and challenges.
• You would have direction from someone who could tell you what was important to the customer.
• You would be working on only one project at a time.
• You would not waste time following procedures that were not useful.

You almost cannot fail to see some positive results quickly, but it will only take you so far. When you actually implement Scrum, you'll get additional benefits because:

• The iterative natureof Scrum development (including the re-assessment of priorities between iterations) enables you to build code that is of value to the customer.
• Thefocus on defining acceptance tests concurrent with requirements improves both the quality of the code and the clarity of the requirements.
• The ability of the team to determine how to remove impediments as they arise allows them to improve efficiency.

Phase 1 produced significant improvements by changing the organization of the team: eliminating delays in communication and unproductive procedural overhead. The additional improvements in Phase 2 come from using a better process. Note that the first two benefits of Phase 2 (iteration, test-early) come more from the team's general approach than from the team figuring out how to solve things.

Structure and Process
Over the last eight years, I have worked with dozens of companies, helping them lay out roadmaps for adopting Agile practices. Sometimes, I encounter teams who have show dramatically greater productivity than their counterparts, even though they otherwise follow the same development process. These more effective teams always have the following elements:

• They are organized as work-cells.
• They are co-located.
• They work on only one or two projects at a time.
• They have access to people who can tell them what needs to built.

It is improved structure, rather than process, that accounts for their superior productivity. These are the same structural elements that take place in the first phase of adopting Scrum. I have seen this so often that I can conclude that first dramatic improvements from Scrum are more likely due to structural improvements rather than iterative process or self-managed teams.

Why is this important? Because I suspect many teams who cannot adopt Scrum processes are missing out on the chance to improve effectiveness simply by adopting the same Phase 1 structures that Scrum teams employ. They can enjoy these benefits even if they cannot go to Phase 2.Lacking the knowledge of what drives Scrum, they fail to gain the experience.

Where to Go Next
Where do teams look to see what works? It sounds great, as some Agilists advocate, to "let the team decide." But what happens when what is needed is beyond the team's capability to change? Or what if the team does not want to follow good procedures? How do we decide when practices are good and must be followed and when practices are not clear and the team should decide? Our industry is very far from having an established set of best practices even though thought leaders align fairly strongly on them.

In the past, this has been done through mandates by management which led to wasteful procedures and bureaucracy; however, this does not mean that going the opposite way, giving teams full freedom to do whatever they want, is the right way to go. This is fraught with its own set of problems. What is needed is a combination of best-practices across an enterprise implemented in a way that supports the