Scrum -- the practice in which development work is carried out in fast-paced and frequent iterations by closely connected teams --should be easy, fast and fun. But old-style organizational thinking tends to seep back into the process, and Scrum-inspired projects end up like every other overbearing project -- late, over budget, and a slog for all.
Jeff Sutherland, creator of Scrum and author of a new book, Scrum: The Art of Doing Twice the Work in Half the Time, wants to set the record straight on Scrum, and provides guidance on this often misunderstood approach to product development.
As explained at Scrum.org, Scrum "is a way for teams to work together to develop a product. Product development, using Scrum, occurs in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed."
The bottom line is that Scrum is a very straightforward and simple methodology, Sutherland says. "At its root, Scrum is based on a simple idea," he writes in his book. "Whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want? And question whether there are any ways to improve how you’re doing what you’re doing, any ways of doing it better and faster, and what might be keeping you from doing that."
Unfortunately, while Scrum-inspired projects start out with great hopes and commitment to moving through projects in a fast and furious way, they often end up bogged down in inertia. In a recent InfoQ interview with Ben Linders, Sutherland recounts his experiences with a number of Silicon Valley firms, all of which had at least 200 Scrum teams within their facilities:
"Unfortunately, over 80 percent of these teams do not have tested, working software at the end of a sprint. This creates huge delays and many problems. Scrum becomes slow, hard, and painful. It is a gross violation of the second value in the Agile Manifesto. [Working software over comprehensive documentation.] Therefore, it is 'Bad Agile.' The product owners and customers cannot count on anything except being late."
Sutherland says there are four basic tenets of Scrum that guide efforts to achieve quick turnaround of product development with high participation and quality assurance. He outlines these four tenets in his book:
Planning Is Useful. Blindly Following Plans Is Stupid. "It’s just so tempting to draw up endless charts," Sutherland writes. "All the work needed to be done on a massive project laid out for everyone to see—but when detailed plans meet reality, they fall apart. Build into your working method the assumption of change, discovery, and new ideas."
Inspect and Adapt. "Every little while, stop doing what you’re doing, review what you’ve done, and see if it’s still what you should be doing and if you can do it better."
Change or Die. "Clinging to the old way of doing things, of command and control and rigid predictability, will bring only failure. In the meantime, the competition that is willing to change will leave you in the dust."
Fail Fast So You Can Fix Early. "Corporate culture often puts more weight on forms, procedures, and meetings than on visible value creation that can be inspected at short intervals by users. Work that does not produce real value is madness. Working product in short cycles allows early user feedback and you can immediately eliminate what is obviously wasteful effort."