There was a recent thread on the Yahoo egroup ScrumDevelopment asking about the contents of the next release of Scrum. In particular, people wanted a new release that would address the architectural failings of Scrum regarding the product owner. The general consensus was that many product owners had trouble understanding and then fulfilling their obligations within the Scrum framework.

I understand these failings. The product owner job is incredibly difficult. Almost all people fulfilling the product owner role are surprised by how much work it is. Historically, product owners were questioned by the development organizations about their requirements. After extensive grilling, these requirements were deemed complete and bound in a requirements document, a product requirements document, or a marketing requirements document. The development organization then went off to build the software to satisfy these requirements. The person known as the project manager was responsible for making sure that this happened on time, and on schedule.

Now, however, the product owner is responsible for an emerging set of requirements on something called the product backlog. They are responsible for elucidating these requirements as needed, decomposing these requirements on an ongoing basis, changing them to optimize return on investment, and even meeting with development teams frequently to tell them what is needed and to review what they have done. The product owner has gone from someone who could blame development if a project failed to someone who is responsible for the success or failure of the project. At Yahoo, this person is called the “single wringable neck.”

No wonder people want this problem solved. A number of people are offering product owner courses to address this problem area. Books such as Agile Planning and Estimating and User Stories Explained have been written by Mike Cohn to help. Still, this remains a difficult area.

However, there will be no Scrum Release 2.0 to explain the product owner role in more detail, or to address other problems areas, such as:

• How do waterfall and Scrum projects integrate their work to create a single product?
• How do engineering organizations improve the quality of each increment?
• How do ScrumMasters become more effective in helping teams resolve conflicts?
• How are complex system architectures decomposed to allow work in the first sprint on both functionality and the architecture?

Why not? Because the point of Scrum is not to solve these issues. The context, players, and dynamics of each organization's situation is unique, and the solutions must be unique, too. Even when the problem is solved, the problem evolves so that the organization must once again find a solution to keep the productivity and value maximized. In short, there is no one answer to problems within an organization, and certainly no one answer for all organizations.

The underlying premise of Scrum is that the people, technology, and requirements of most development projects are too complex for single solutions. Scrum unearths the problems caused by the complexity and lets the organization solve them, one by one, over and over again. Traditional methodologies provide answers to all problems, and this is why they don't work—they assume a simplistic rather than a complex problem. They proceduralize answers; Scrum calls on the participants to use hard work and common sense.

The desire for a more formal, regular, advanced Scrum is normal. That is what our profession is all about and why we were drawn to it. We take complexity and normalize it into computer programs. Resisting doing the same to Scrum is extremely hard, but necessary, because the further development of Scrum to address individual or organizational difficulties is the death of Scrum and the birth of still another useless methodology.

AUTHOR BIO: Ken Schwaber codeveloped the Scrum process with Jeff Sutherland in the early 1990s to help organizations struggling with complex development projects. One of the signatories to the Agile Manifesto in 2001, he subsequently founded the Agile Alliance, a nonprofit organization dedicated to the creation of agile software. A thirty-year veteran of the software development industry, he teaches and speaks at numerous conferences, including OOPSLA and Software Development.