Chapter 22. You’re Not Done Yet

We’ve come a long way together. My hope is that you have been implementing many of the recommended practices and “things to try” throughout the book. If so, you’ve hopefully made a lot of progress. You’ve established an Enterprise Transition Community (ETC) to introduce Scrum into your organization. The ETC, in turn, has created an environment that encourages improvement communities to form and flourish. Some of these improvement communities have disbanded already, after accomplishing what they sought to improve; other improvement communities have expanded their focus or are still hard at work at more persistent improvement opportunities.

By now Scrum has become the default way of working for at least some teams in your organization. It started with individuals on those teams becoming aware of the need to change how they developed software. As the awareness grew, it turned into a desire to develop software differently. In response, individuals acquired the ability to work in an agile manner. This led to early success with Scrum, which was promoted to others so that they could begin their own cycles of awareness, desire, and ability. Finally, the implications of doing Scrum were transferred to other parts of the organization so that organizational gravity did not pull everyone and every team back to where it started.

Along the way you have changed not only people’s job descriptions but also how they view their roles on the team. Teams are now structured around the delivery of features rather than around the technologies or layers of the architecture. And although given the opportunity to self-organize, teams are subtly influenced by leaders who have themselves learned how to work on self-organizing teams. Team members have incorporated new technical practices that help them write higher-quality code. The team understands the importance of its product backlog, how to work effectivity within Scrum’s strictly timeboxed sprints, and how to plan with incomplete information. Quality has probably improved—not only are testers integrated into the development process, but programmers are helping with automated tests as well.

By now, you might also have scaled Scrum onto larger projects or projects spread across multiple cities or continents. You’ve learned how to overcome some of the bigger challenges created by those projects. Scrum is now more deeply integrated into the organization and might even coexist with other corporate mandates, such as CMMI or ISO 9001 compliance. Employees in human resources, facilities, and the project management office are now your allies in creating sustainable change. The organization has made tremendous progress.

Don’t stop.

I don’t care how agile you have become or how well you do Scrum. It doesn’t matter how good you are today; if you’re not better next month, you’re no longer agile. You must always, always, always try to improve.

Wait, you say, I have a final objection. Being agile isn’t my goal, delivering great products is. If I’m good enough, why can’t I stop? To that I say, of course being agile is not your goal. Your primary goal is to develop amazing products, quickly and cheaply, that thrill your customers and users. To do that, though, I believe you will need to be agile. And to be agile, you must continuously improve.

Continuous improvement is easier than it might sound. You’ve planted all the seeds already. Your improvement communities will play a key role inside the risk-tolerant, idea-generating, nurturing culture fostered by the ETC. Through trial-and-error experimentation, these communities will lead the organization toward better and better ways of working. Beyond that, though, they will engage employees’ passion. The organization will shift from seeing problems to seeing possibilities.

And with that, you are on your way to succeeding with agile.