I have trained thousands of project managers, program managers, and development managers to use Scrum. I teach them Scrum practices. Once these practices are introduced, the managers re-experience their validity in exercises and discuss their impact with their peers. This poses a conundrum for these managers, however. Scrum practices aren’t the prescribed practices for getting something done in most organizations. In fact, they are often the exact opposite of traditional practices for organizing and directing those who build products.
All of the managers will have to go back to their organizations and do what they are paid for: deliver projects on schedule and budget. To do that, many will fall back on the traditional practices that they have always used and that are “the way things are done” in their organizations. So what use are these new techniques? What use is Scrum? They still have to get things done! At the end of the day, the organization looks to them to deliver the project on schedule.
I respect their problem. It’s one thing to know something and another thing altogether to do it. Through ScrumMaster training, all of the managers learn that people in teams of nine or less are more productive than nine individuals. They realize that people are most productive when they manage themselves. They understand that teams are most creative when they are cross-functional. They discover that teams and people are best able to work within short horizons, or timeboxes, and that teams and people do their best work when they aren’t interrupted. They learn that people take their commitment more seriously than other people’s commitment for them, that people always do their best, and that teams improve the most when they solve their own problems. They get it when I show them that team members are most productive when dedicated to a team, and that changes in team composition ruin productivity. They know that broadband face-to-face communication is significantly better and less error prone than any alternative method;
They also learn not to build an unnecessary inventory of requirements or architecture, since 35 percent of requirements will change and 65 percent of requirements are of such low value that their delivery is questionable. They discover that frequent course corrections are often better than staying the course or persisting. They remember that the greater the transparency, the more effective the inspection and adaptation, and that flaws and errors compound with time so they should catch and correct them as soon as possible. They find out that reducing quality to hit dates can ruin your company; and that, under pressure to “work harder,” developers automatically reduce quality.
When they leave knowing all that they know, I tell them that they are now ready to be a ScrumMaster. And that, just like managers everywhere, ScrumMasters are responsible for getting things done. There is one key difference: the ScrumMaster has to use these Scrum practices to do it. Since the managers have just spent two days affirming to themselves that these practices are in fact better, they are left with two choices: Ignore everything that they have just re-remembered and re-experienced and re-validated or try to do their job in a new way.
If they have the courage of their convictions, they (and their teams and organizations) will be more productive, produce higher quality products, and have a better work environment. But shifting to these new practices will feel awkward, risky, and uncomfortable. Will the practices really work? Intuitively, they know so, but actually doing it for real is a different thing. This transition is the path of the ScrumMaster—and even if you know the path is the right one, it’s difficult to walk.
