Insurgent Scrum

Just watching Everton take Manchester City apart. Nice to see the Toffees in full recovery from their awful start to the Premier League season. The snow is also finally beginning to melt off after over a month of cold weather and continuous snow cover. North-central Colorado isn't Minnesota after all and we're not used to snow cover for weeks on end.

Thinking about the ways in which Scrum can get started in an organization, one possibility is an insurgent movement on the ground. I have experienced Insurgent Scrum on a couple of occasions. The driving force is usually the total desperation of a development group in the face of an organization in chaos that is unwilling to change its ways. In my experience, the development manager and some or all of his charges decide that they are going to work as a team, deliver working increments of software, and use as much of Scrum as they possibly can. As a team, they convert requirements into user stories, prioritize the stories with or without direct input from the business/PMO, plan their Sprints, commit to the plan, and get on with it day-by-day. On one occasion, the development manager was able to bring the QA manager on board as well, resulting in good automated testing practices being put into place and the formation of something very closely resembling a cross-functional team.

The development of a team dynamic and the sense -- and reality -- of accomplishment that came from delivering working product increments every two weeks brought about great improvements in product quality, staff morale, and productivity. Everyone involved wanted nothing to do with going back to the old command-and-control, isolated individual style of work. The QA staff realized the biggest improvement in their working lives, the result of the emphasis on automated testing and the distribution of testing throughout the course of each Sprint, instead of the usual over-the-wall at the last minute testing push.

That was the end of the positive results, unfortunately. The business and PMO, once they figured out what was going on, applied massive pressure to return things to the way they had been before the Insurgent Scrum movement started. In both of my experiences, it turned out that vastly improved quality, increased productivity, and empirically derived planning were not sufficient to overcome the perceived loss of control. Allowing developers to chose their own daily work, and even worse, to determine their own Sprint commitments, constituted a threatening degree of freedom. The universal expectation in the business and the PMO was that they would give the orders, down to the level of specific design solutions and that development and QA were there simply to type in the code and test the results. Wow. Ultimately, control was more important than the success of the product and indeed the success of the company. Double wow.

In neither case that I experienced personally was Insurgent Scrum successful. It did lift product quality, improve planning, and, most importantly, improve the daily working lives of the people doing the work. In one instance, the front-line managers dug in their heels and refused to stop using Scrum. The only way the business could find to squash the insurgency was to lay off the entire development and QA staffs, including the managers. Triple wow. Strangely enough, I have seen similar outcomes, minus the layoffs, when coaching organizations that brought me in specifically to help them in their move to Agile/Scrum.

So what's the lesson here? Well, first of all, I am convinced that Insurgent Scrum is worth the risk. Improving the working lives of the people on the ground is worthwhile regardless of the ultimate outcome. There is also always the very distinct possibility that an organization will see the benefits of Scrum and adopt it on a grander scale, using the original insurgency as the example of success and the source of practical knowledge which could then be spread throughout the organization. Companies that are focused on winning, instead of on control and corporate politics, will clearly follow the model that leads to successful adoption of Scrum.

Is your organization focused on success? How will you know? It may be impossible to tell until you start, which is where courage comes into play. Be courageous, but always remember that discretion is truly the better part of valor. Get going with Scrum, but avoid open provocation. Demonstrate the benefits of Scrum: delivery of working product increments, fully tested, ready for release, and with much greater predictability than is possible under traditional defined process management; vastly improved staff morale and therefore productivity; innovation as a matter of course; and on and on. Build trust Sprint-by-Sprint. If your company is unable to recognize the benefits of Scrum, it's an unmistakable sign of where the organization's priorities lie.

All for now....

...-.-