By 2001, the software industry was in trouble—more projects were failing than succeeding. Customers began demanding contracts with penalties and sending work offshore. Some software developers, though, had increasing success with a development process known as “lightweight.” Almost uniformly, these processes were based on the well-known iterative, incremental process.
In February 2001, these developers issued a manifesto—the Agile Manifesto. The Manifesto called for Agile software development based on four principle values and twelve underlying principles. Two of the principles were 1) to satisfy customers through early and continuous delivery of working software, and 2) to deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
By 2009, the Scrum Agile process was used predominantly. A simple framework, it provided an easily adopted iterative incremental framework for software development. It also incorporated the Agile Manifesto’s values and principles. The two authors of Scrum, Jeff Sutherland and myself, also were among the authors of the Agile Manifesto.
I had anticipated some of the difficulties organizations (and even teams) would face when they adopted Scrum. However, I believed that developers would bloom in a Scrum environment. Stifled and choked by waterfall, developers would stand tall, employing development practices, collaboration, and tooling that nobody had time to use in waterfall projects.
Much to my surprise, this was only true for perhaps 20 percent of all software developers.
In 2009, Martin Fowler characterized most Agile software development as “flaccid”:
There’s a mess I’ve heard about with quite a few projects recently. It works out like this:
■ They want to use an Agile process, and pick Scrum.
■ They adopt the Scrum practices, and maybe even the principles.
■ After a while, progress is slow because the codebase is a mess.
What’s happened is that they haven’t paid enough attention to the internal quality of their software. If you make that mistake you’ll soon find your productivity dragged down because it’s much harder to add new features than you’d like. You’ve taken on a crippling Technical Debt and your Scrum has gone weak at the knees. (And if you’ve been in a real scrum, you'll know that's a Bad Thing.)” http://martinfowler.com/bliki/FlaccidScrum.html
Martin’s description of flaccid Scrum resonated with our experience. Most developers were skilled, but not adequately skilled in the three dimensions required to rapidly build complete increments of usable functionality. These dimensions are:
■ People The ability to work in a small, cross-functional, self-managing team.
■ Practices The knowledge of and ability to apply modern engineering practices that short cycle development mandates.
■ Tooling Tools that integrate and automate these practices so that successive increments can be rapidly integrated without the drag of exponentially accruing artifacts that must be handled manually.
We put our business on hold while we worked through 2009 to create what has become known as the Professional Scrum Developer program. Offered in a three-day format, we formulated a workshop. The input was developers whose knowledge and capabilities produced flaccid increments. The output were teams of developers who had developed solid increments of software called for by the Agile Manifesto and demanded by the modern, competitive organization.
Richard has been there since the beginning. His book, Professional Scrum Development with Azure DevOps, continues his participation in the movement started by us few in 2009.
When you read Richard’s book, you can learn the three dimensions needed for Agile software development: people, practices, and tools. Just like in the course, Richard intertwines them into something you can absorb. If you are on a Scrum team, read Richard’s book. List the called-for practices. Identify which practices pose challenges to your team. Order them by their greatest impact. Then remediate them, one by one.
Many people spend money going to Agile conferences. Save the money and more by buying this book, discussing it with others, and going to meetups and code camps—the “un-conferences” for the serious.
Richard and I look forward to your increased skill. Our industry and our society need it. Software is the last great scalable resource needed by our increasingly complex society. The effective, productive teamwork of Agile teams is the basis of problem solving that our society also needs.
Scrum on!
Ken Schwaber
Co-creator of Scrum