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 team.
Assuming that teams can discover their own best practices assumes that teams are properly trained in many disciplines: process, technical, quality, technical. Too often, this is not the case. Most still do not understand design patterns. Too many focus on story cards as their sole analysis tool. They lack knowledge to guide their experience.
Long term success with Scrum does not come simply by having teams discover answers for themselves. Instead, it comes by discovering answers that support the team. It requires both management leadership and team involvement and a willingness to learn and improve continuously.
This requires looking both at what the team does and at what constraints are placed on the team over which they have no control. When the team and management understand the principles behind Scrum, they can work together to improve the process of the team.
Looking for Standards
How do we decide what should be standard work for teams and what should be left to the team to decide? Do we tell the team, "you must do this no matter what?" Probably not. But clearly, they must be guided and strongly encouraged. They need to be aware of practices that would be beneficial. They need to know principles to guide their practices. Where should they look?
For software development, one place to look is Lean methods. Lean is the name given for Toyota's management philosophy. Lean tells teams to look for practices that improve systems by lowering errors and making us more productive. Lean practices focus on eliminating delays, avoiding work on multiple projects, continuously improve processes, optimizing the whole, and follow a "Plan-Do-Study-Act" cycle of continuously getting feedback and adjusting to it. All this sounds a little bit like Agile/Scrum development, doesn't it?