Scrum: the Model-T of Agile?

Several years ago during a break in a scrum training class, a student approached me and asked “what do you think will come after scrum?”. At the time, I had no answer for this question. The several teams that I had worked with that had used scrum had gotten so much benefit from it, and the rest of the organization needed scrum so badly (in my opinion), that I couldn’t imagine the need for anything different for product development.

Our organization, its environment, and my understanding of scrum have all evolved quite a bit since that day. If asked the same question now, I would have several possible ideas to discuss, depending on the team and the situation. Scrum would probably be the starting point for all of those conversations, but in many cases it would be augmented by something else, or a modified version of scrum, or some other agile approach like Kanban might be the right answer. There are still many parts of our organization that will benefit from adopting scrum, and teams that have been using it for years have all evolved their own implementation of scrum that suits them well. I don’t see scrum going away in organization any time soon. But if it did not evolve it would seem a failure to me.

Scrum was invented in the early 90s. We’re approaching its 20 year anniversary. In software terms, that is ancient. That it has survived and in many ways thrives is a testament to its broad applicability.  Most successful scrum adopters will augment the framework with other technical and business practices like XP, Innovation Games, and Lean Startup. Particularly with teams that are taking a Lean Startup approach, I’m beginning to see the need for the way we understand the Product Owner role to evolve. I’m not sure how that evolution will happen, but I wouldn’t be surprised if on such teams, the PO role gets absorbed into the cross-functional team, doing both the idea validation with customers as well as development of the software that results from those discussions. I wouldn’t be surprised to see Product Backlog Items sorted into categories like “working software”, “idea validation”, and “technical validation”, rather than having a single Definition of Done for all product backlog items. While this could be a slippery slope for an org that is not agile in its culture, experienced agile teams can gain significant advantages from such an approach since the learning we need most doesn’t always require us to build working software to get an answer (check out the link to Lean Startup above for more on this idea).

With these thoughts in mind, I started wondering: “Is scrum too much of a sacred cow to evolve?” I’m not sure the answer to that question, but while thinking about it, the idea came to me that Scrum is not a sacred cow as much as  it is the Model-T of agile.

Ford didn’t invent the automobile, that honor goes to Nicolas-Joseph Cugnot, Gottlieb Daimler, Carl Benz, or Wilhelm Maybach, depending on the book you’re reading. What Ford did was figure out a way to mass produce the automobile and sell it to the public at an affordable price such that it became an integral part of the lives of nearly everyone on the planet today.

 

 

Similarly, Jeff Sutherland and Ken Schwaber didn’t invent agile. The ideas of agile go back to at least the 1950s and probably before that, and are part of a family of new approaches to doing business that also includes movements like Lean, Theory of Constraints, and Six Sigma in manufacturing, Leadership Agility and Radical Management in management theory, and Lean Startup and Innovation Games for learning about customer needs. What Jeff and Ken did was figure out a way to mass produce Agile and sell it to the software industry in a way that has put agile on the map all the way up the C level of nearly every organization where software is important. Gartner famously predicted that by this 2012, 80% of software development will be done with an agile approach. The focusing of agile principles into a broadly applicable framework like scrum was a major innovation, just as the development of the Model-T assembly line was a major innovation in manufacturing.

The Ford assembly line was the exact innovation needed in its day. It persisted as the primary innovation in the auto industry until the 1970s when companies like Toyota evolved a newer approach that was more fit to customer’s evolving needs and provided higher quality products. It took decades for Ford to adopt similar approaches to catch up to Toyota. The question for me is this: at 20 years old, will Scrum see the need to evolve, and if so, how?

2 Responses to Scrum: the Model-T of Agile?

  1. Dana says:

    I like the idea of moving the PO more into the team. My group has been making games for about 12 years and we became agile by intuition. That’s in part because we were the live team supporting a MMO so building working software while adding from the wish list and tackling the bug list was our daily chore.

    When I started to learn about SCRUM I often had the problem of defining my role. Was I the SM or the PO. I manage the backlog and deal with the stakeholders (company principles and community players) but I’m also part of the team (QA, documentation, data mangement, feature design, etc.).

    But SCRUM would say that I’m not supposed to be both. I’m not supposed to have managerial oversight on the self managed team. And while I did, I didn’t. The team met regularly to decide what we should do and how best to do it. I helped facilitate the process as well as guided the direction.

    So I tend to think you’re right about the evolving of the PO into the team might be good on some teams. SCRUM seems to me to be a great framework for building working teams on and not a set of rules that must be adhered to. After all, the Model T came only in black while the frame itself brought us some of the most beautiful Hot Rods ever created.

    I want to be in the business of creating beautiful things not adhering to rules.

  2. Problems are bound to surface during the development process; however, the team, not the Product Owner should come up with the viable solutions to such problems. This is because the team is well versed with the technical aspects of the software under development.Presence of the Product Owner in Daily Scrums and Retrospectives is essential as he is the bridge between the technical team and the stakeholders. Since feedback given during the Retrospectives is important in planning the succeeding sprints, the Product Owner’s presence is vital.

    http://scrumstudy.com/blog/?p=145