Blog: Background of Scrum and Agile – Schwaber and Sutherland

The recent story about Scrum and Agile began in the 1990s when  – the Fathers – collaborated and started experimenting with and using Scrum in their respective companies. According to legend, in 1995 they presented a formal codified version of Scrum at the OOPSLA conference in Austin Texas. The most widely circulated version of the conference paper only bears Ken Schwaber’s name (see link in the comments). Later on, they participated in and co-signed The Agile Manifesto.

In 2001 Ken Schwaber and Mike Beedle wrote the book “Agile Software Development with Scrum.” Although the book was somewhat primitive, especially the illustrations, its content was easily accessible. The Scrum framework was presented in ordinary terms, enabling simple-minded folks like myself to understand it without further ado.

This book was my gateway to this new way of thinking, developing, and managing. I stumbled upon it in a bookstore in Denver Colorado in 2005; I didn’t even know what the word Scrum meant. Until then I had always been told that as a manager you should plan-delegate-monitor-control, and if it didn’t work it was because you executed one of those steps poorly. Scrum was totally different, it resonated with all my experiences. I committed more or less on the spot to the Scrum and Agile way and made that my future.

Later, in 2010, the Fathers developed the Scrum Guide and are still maintaining this document. It is regarded as the foundation of Scrum and holy writ for some. It is, of course, the prerogative of the Fathers to define what they mean by Scrum, however, in my humble opinion the document is quite shallow in some areas, for example in clarifying the role of the Product Owner. The various versions of the document have also meandered somewhat haphazardly over the landscape. This has led to much splintering, including the Fathers leaving the Scrum Alliance and running their own show. Add to that a host of other interpretations of Scrum, and you can now find all sorts of things in the market called Scrum.

I have never met the Fathers and learned from them directly. Therefore, I have precious little to say about their contribution apart from what I can find in publications and hear from people with first-hand knowledge. I will say though, that I attribute the simplicity of Scrum to the work of the Fathers. The simple rules – what Dave Snowden would call “enabling constraints” – are elegant from a systems design point. The framework of Sprints, Definition of Done, Roles, Events, and Artifacts are simple enough for anyone to remember. They give just enough structure to get started and enter the continuous cycles of improvement and learning. It will work for you, it has been tried enough times to say that confidently. It is not bloated with roles, events, and artifacts like the heavy-weight processes such as SAFe, where you have to be lucky to find two people in an organization who have the same understanding of all the process details.

The concept of the three roles provides a near-perfect balance of one-ness and three-ness, by having the three epicenters of responsibility and authority the traditional tendency to power focus is dampened, especially the Product Owner and Scrum Master provide checks and balances for each other.

Once you are in the flow of constant learning with good feedback you may find that you can do even better by changing some of the constraints, removing some, or adding new ones. That is OK, Scrum is not a religion, but an excellent starting point for your ever-adapting journey in unfolding circumstances.

Finally, I will add one more observation. The concept of the time-boxed Sprint or Iteration is brilliant. If you can stick to the Sprint of 2-4 weeks, it provides a container, a greenhouse where the Team’s creative resources can sprout and flourish optimally. It gives the Team members an enabling constraint and enough freedom to be their own self-organizing masters. I know there are situations where the concept of a Sprint can be impractical, especially if the work requires constant reprioritization. Still, if you can stay with the Sprint it can release so much energy.

All of this would not have been here without the effort of Ken Schwaber and Jeff Sutherland.

Kurt B. Nielsen, Scrum Trainer
Print Friendly, PDF & Email