Topic: Mindset and culture
It seems to be a common pattern that a team will adopt more-effective development practices and achieve a certain level of improvement and then settle back into old habits, or at least stop moving forward. Ron Jeffries recently commented on the phenomenon on the Extreme Programming list, following up on an editorial by Steve McConnell on "Cargo Cult Software Engineering." Others have added good insights as comments to Ron's message.
I've observed the same pattern, as well. In an earlier post here, I wondered why people are satisfied with just a small portion of the improvement they could achieve, if only they tried. I thought it might have something to do with maintaining focus on continuous improvement. Maybe there is something to that. At XP Day London 2006, Joseph Pelrine and Ben Fuchs gave a very interesting presentation entitled "Turning up the Heat (Without Getting Burnt)" in which they suggested shaking things up a bit when a team was slipping into a rut, to make them take a fresh look at themselves and how they're working.
I think it's a compelling idea. We tend to think of the process facilitator / team coach / ScrumMaster role as a protector whose task is to keep problems away from the team so they can work unimpeded. I wonder if the role is more properly a sort of "team sifu" whose task is to help the team realize its full potential. If your stance is off, your sifu may well kick your feet out from under you. It's for your own good, you know.
I'm not suggesting you allow a team to crash and burn. There's no useful lesson in that. On the other hand, if a team is in a rut you can kick their feet out from under them. The difference is that the team has to agree to it. If you feel they're in a rut, bring it up in a retrospective. Get a consensus from the team that things aren't going as well as they might, and that it's time to change something. It could be something really simple, like rearranging the layout of the team room, or changing the time of day of the daily stand-up. Sometimes that's all it takes to refresh the mind.
When a team reaches a plateau of performance, it may not be solely because of their focus on continuous improvement. There may also be a management problem. Consider the reasons why companies try alternative software development methods in the first place, and how management responds to the results of the initial projects. I like to ask managers why their organizations decided to give agile development a try. The only answer I have ever gotten is that the company's IT department had been delivering nothing at all for years on end. Of course, those IT departments were delivering software. Why did management think they had been delivering nothing at all? Because they delivered the wrong solutions too late and at too high a cost to do the company any good. Management was willing to try something different because it "couldn't be any worse" than the status quo.
The point here is that companies don't decide to try agile methods because they think they are already really, really good at what they do and they'd like to see some incremental improvement. They decide to try agile methods out of sheer desperation. When the new approach yields value, they are thrilled. Management wants to institutionalize the process their prototype agile teams used and replicate it across the organization. In these cases, management "locks" the agile process at an early stage of its evolution. From that point forward, continuous improvement is all but impossible. Ron suggests a team vary its practices so they can discover changes that might improve their effectiveness. How can a team do that when management dictates a fixed process? In effect, management has built a hard ceiling over their development teams.
Many agilists claim that their approach can deliver as much as 10x the business value of traditional processes. I've seen that level of improvement on occasion, myself. More typically, I've seen improvement in the range of 2x to 3x. The problem is that most people stop there. They are so excited about a 3x improvement that they want to celebrate and lock it in. Who can blame them? They don't really believe they can take improvement farther than that, because in their careers they've seen many "magic bullet" processes come and go, and none has ever delivered anything like 10x improvement.
It's hard to keep the process flexible enough to enable continuous improvement over the long term while simultaneously institutionalizing it throughout a large organization. I think this will be one of our main challenges in the next few years. Introducing agile at the level of individual teams has been quite successful since the manifesto was published. We won't get much farther until we address the problem of large-scale organizational change, so that agile teams can stop working around their own organizational cultures and start working with a supportive culture.
