Scrum has been around for a while, they say. The Scrum Guide holds the definition of Scrum, they say. The first, official version of the Scrum Guide was released in February 2010. So, how was Scrum defined before 2010 then? How did its definition evolve before and after 2010 and become the framework that we know today? What else happened along the road to the way that Scrum is defined and represented?
In the paper “Scrum: A Brief History of a Long-Lived Hype” I have described what changed to the definition and representation of Scrum over time, before and after the creation of the Scrum Guide. It shows how Scrum evolved into the framework that we know today since its first formal introduction in 1995. Because a touch of historical awareness is more than helpful in understanding Scrum and caring for the future of Scrum.
I looked for sources that are not just credible in terms of authorship but also offer regular enough check points. In the end, the sources I used for describing the evolutions of the definition of Scrum are:
The paper “SCRUM Software Development Process” by Ken Schwaber (1995, 1996)
The paper “SCRUM: An extension pattern language for hyperproductive software development” by Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber and Jeff Sutherland (1999)
The book “Agile Software Development with Scrum” by Ken Schwaber and Mike Beedle (2002)
The book “Agile Project Management with Scrum” by Ken Schwaber (2004)
The book “The Enterprise and Scrum” by Ken Schwaber (2007)
“The Scrum Guide” by Ken Schwaber and Jeff Sutherland (2009, 2010)
“The Scrum Guide” by Ken Schwaber and Jeff Sutherland (2011, 2013, 2016, 2017)
“The Scrum Guide” by Ken Schwaber and Jeff Sutherland (2020)
For every source I have described the same three topics to show what Scrum consisted of at the time (regardless the different terms used), what the ‘definition’ of Scrum was at the time:
Roles, responsibilities, accountabilities
Controls, deliverables, artifacts
Phases, meetings, time-boxes, events
For every source I have included a graphical representation of Scrum or of a Sprint that was either taken from the source directly, either from an alternative source of the same period.
Finally, I have shared my thoughts and observations on the changes to the definition of Scrum for every source. Obviously, they represent what I deem noticeable. They hold no judgement, directly nor indirectly.
To complete the paper I have listed some important landmarks in the history of Scrum and included some personal musings on the topic of “Scrum and the Desire for Universal Truths” (and what the Scrum Guide was not created for).
I hope you will enjoy reading the paper. I hope it will help you grow a deeper understanding of Scrum. I hope it will help you shape your Scrum to get the most from it. I hope it will help you create better products with Scrum while humanizing your workplace.
Take care Gunther Verheyen independent Scrum Caretaker
April 2016, two years ago. Letting go of exclusively partnering with Ken Schwaber and working for Scrum.org was, if not just an even bigger step, certainly a more frightening one.
April 2018, today. Reflecting, looking back, those were decisions I ‚had‘ to take. For they were the most honorable decisions to take.
Looking back, I regret none of my job changes, despite the losses, the pain, the regret to find we were not in it together after all. They turned out very revealing experiences in many regards, not only professionally but certainly at a personal and human level (if ever those aspects can be separated). Looking back, those were the best decisions possible. Looking back, it leaves the misleading impression that it was all part of some bigger plan.
Looking back even further, I wonder. Quite some of my many job changes actually happened in springtime. More importantly probably, every single one was based on principles and values and was a forward-looking decision, in search of a different, if not better, future.
Over time, certainly, I started recognizing, appreciating and ultimately embracing that I am good at searching, not at finding, that I am good at travelling, not at arriving. Really good at not belonging too, an outsider. Wholeheartedly however. Walking the difficult path, facing the challenge to achieve what I may find I need to achieve without being part of formal, corporate or commercial structures anymore.
There are plenty of challenges, more than I ever will be able to handle, and probably even more deciding to be on my own 2 feet. Some challenges are known, most are not. What life is all about, right?
Allow me to thrive on deliberately emerging opportunities to bring value; to the individuals, the communities, the teams, the organizations I am grateful to work with.
With ‘Professional Scrum‘ we promote the use of Scrum beyond the mere following of the formal ceremonies (‘mechanical Scrum’), but employing Scrum from an understanding of the underlying values and principles. In our Professional Scrum workshops we follow the difficult path of helping people explore how to build on the empiricism of Scrum, the intelligence of people and the Scrum Values, to tackle difficult and complex challenges. The easy path would be to be instructors, treat attendants as mindless robots and give people easy black/white solutions.
In March 2012, Ken Schwaber and I agreed to organize a new Scrum event in the Netherlands. We wanted it to be a platform for the attendants, not for the speakers, for the organizers, or for sponsors. We wanted to crave space for people to talk, connect, share ideas, experiences and challenges on Scrum.
On 11 July 2012 the first Scrum Day Europe event happened. 130 People, one day, no booths, no sponsors, no vendors, a few keynotes and lots of small high-energy, collaborative sessions. An event, not a conference. Impact, not volume.
Imagine, on 7 July 2016 the 5th edition of the Scrum Day Europe event takes place. The location is the same: the fantastic Pakhuis De Zwijger in Amsterdam. The ambition and core concept are the same: interactivity, people, Scrum. I am sure that some day we will even stop projecting the names of us, the organizing parties, Prowareness and Scrum.org.
The theme of this 2016 edition is “The next iteration“. We will not only celebrate the 5th anniversary of the event, but we want to use the occasion to be grateful that Scrum has reached the age of 20. We want to celebrate by thinking about the future of Scrum. My opening keynote, “The future present of Scrum”, will introduce some thoughts. But, much more important, during the open sessions and interactive workshops, attendees have plenty of time to interact with each other and the presenters. Therefore we need the input from Scrum practitioners that want to share viewpoints and considerations.
If YOU have ideas to share on the future of Scrum, the future that lies beyond those teenage years, please send in a proposal for the call for papers via the website. What challenges do we face with Scrum? What do you consider crucial looking forward? How can people, teams, and organizations employ Scrum for software development more and better?
Propose a session. Or get your ticket to join us on this fabulous day for high-energy interactions on Scrum. Be quick. Registration is limited!
At some occasions we stop to look back. It happens rather irregularly in my life, although regularly in Scrum. We see the trail we left behind. We notice landmarks, missed chances, forgotten events, achievements. Small or big. We cherish that we cannot undo it. And we look ahead of us, and think of the paths we might create moving forward understanding that our current actions continually determine our future.
Looking back, two fairly recent, symmetric landmarks stand out on my trail of Scrum created since 2003:
Two and a half years ago I left consulting and moved to that home of Scrum, Scrum.org, to shepherd Professional Scrum and be its face in Europe.
Looking back, I am humbled by the opportunities to travel, to speak, to think, to write, to publish a book, to collaborate with people across the globe. I thank anyone who crossed my path, regardless how they chose to interfere with me.
Just for a split second, I pride myself for having gone my ways, having made my choices. In that split second I see some impact on people, on individuals.
Looking forward, I shiver and doubt takes over again. I embrace the solitude that is often my companion and look forward to the future that, to date, is unwritten. There are many unknown futures that can unfold. In a short flash I realize that there are probably much more options than I know of. There are more paths than I can possibly identify.
Although the future will be nothing like the past, it’s fair to assume that my journey ahead will keep including Scrum. The exact directions however…
Scrum is een framework voor complexe productontwikkeling.
“Scaled Scrum” omvat elke implementatie van Scrum waarbij meer dan één team een product realiseert.
“Scaled Professional Scrum” omvat elke implementatie van scaled Scrum die bouwt op de fundamenten, principes en waardes van Scrum, met inbegrip van software development professionalisme.
Het framework voor Scaled Professional Scrum van Scrum.org biedt de ruggengraat waarop organisaties hun productontwikkeling op basis van Scrum kunnen opschalen mèt behoud van de eigenheid en de voordelen van Scrum. Het framework bundelt de practices, ervaringen en inzichten van een wereldwijd netwerk van experten, waaronder Ken Schwaber en Jeff Sutherland, co-creators van Scrum.
Het kloppend hart van Scaled Professional Scrum is een Nexus, een ‘exo-skeleton’ voor Scrum. Een Nexus implementeert het Scrum proces zodat 3-9 Scrum Teams zo efficiënt mogelijk gezamenlijk aan één product kunnen werken.
Het Scaled Professional Scrum framework bevat 40+ practices. Elk van deze practices, indien met kennis en kunde geselecteerd en geïmplementeerd, kan de werking van een Nexus optimaliseren naar een specifieke context.
On May 28 and 29 the first Scrum Days Poland were organized. A great team made it happen, gently directed by two friends of the Scrum.org trainer community, Kate Terlecka and Tomek Wlodarek. Kate and Tomek were so kind to invite me for two sessions at the event:
In the executive track I spoke about ‘Empirical Management’. Find the slide deck at SlideShare.
For the main event I was asked to do the closing keynote, which was about ‘Scaled Professional Scrum’. Find the slide deck at SlideShare.
Apart from these sessions, I was asked for some thoughts on Scrum by different people:
1/ On behalf of the organization, Paweł Feliński checked in with me on some topics with regards to Scrum, and the adoption of Scrum:
2/ Leszek Pietrzkiewicz went around asking some people, including myself, to ‘describe’ Scrum in one word:
3/ Leszek Pietrzkiewicz asked me ‘Why do Scrum?’
4/ Andy Brandt, another Polish Professional Scrum Trainer, asked me some questions about Product Ownership, questions he typically gets from the attendants of his PSPO classes:
I applaud the local organizers for setting up such a great conference. I am grateful for being at the conference, meeting people and expressing the above thoughts. Traces of Scrum.
People and organizations regularly ask us at Scrum.org (1) for our ideas on scaling Scrum. They are keen to learn from Ken Schwaber‘s and our community‘s experience in scaling product development done through Scrum.
At the same time (2) we frequently get asked for an assessment that tests a person’s ability to join a Scrum Team, often in a scaled context, and be productive in terms of having practiced Scrum.
They are satisfied with our existing Professional series, offering rigorous help and insights to adopt, implement and grow Scrum and Scrum Teams. Additionally however they look for (1) help and inspiration in their scaling efforts and (2) courses and assessments for Professional Scrum Practitioners. As part of our on-going mission to improve the profession of software development and guide the maturing of Scrum, we have taken action. We are in the process of (1) launching a practitioner course to scale Professional Scrum and (2) we are revisiting our assessments accordingly:
The “Scaled Professional Scrum for Practitioners” workshop introduces our framework for scaled Scrum. It introduces techniques and practices for horizontal scaling, amongst which defining and growing a Nexus, a networked structure of 3-9 Scrum Teams developing a product. Find the next planned session here.
We have also created and made the “Scrum Practitioner Open” assessment available, free to anyone taking it. The Scrum Practitioner Open assessment provides anyone with the ability to assess their skill to productively participate in a Scrum Team that is developing increments of software. This assessment is particularly useful for people on one of multiple teams engaged in a scaled development initiative.
Try the Scrum Practitioner Open assessment. Our industry will benefit from an assessment testing the ability to develop software effectively in a Scrum Team, in a scaled context, and optimize common development issues based on the values of Scrum and the basis of empiricism and transparency.
Traditionally an individual is declared a ‘manager’ when having hierarchical control over other individuals. A traditional manager exerts power. A traditional manager commands people through the assignment of to-be-done work; expressed as tasks or work packages, given on a daily base or via to-be-followed plans. Subsequently a traditional manager follows up on the execution of the assigned work. The traditional manager does not wait for the results of the work but wants to see how the work is being carried out, who is doing it, when the tasks are being performed and how much time it is taking. The time it takes is in general compared to the time that was instructed the task should take.
This and other performance information is recorded and stored, mostly in reports and other forms of documents. The traditional manager (in)frequently uses the stored information to evaluate a subordinate in order to steer that person’s career; via carrots like education, promotion, incentives, bonuses, salary. The traditional manager acts as the one who knows it all, and is supposed to act in the best interest of the company and its shareholders, even if that interest is obscured from the people assigned with the actual productive work.
Not limited to, but certainly in a context of agile, there is not only no need for a ‘manager’ behaving according to this authoritarian pattern and traditional expectation, it is even highly counterproductive and extremely discouraging. It undermines enthusiasm, disregards intrinsic motivation by focusing solely on extrinsic motivators, kills job satisfaction, is an open door for politics and bribery and is therefore catastrophic for an organization depending on people. It is without doubt disrespectful and inhumane.
Is the notion of ‘manager’ therefore forever corrupted? Evil by default? A lost case?
Management – Actually
Scrum, like all things agile, has a very different viewpoint on working with people and on the aspect of management, but it does not the disregard that the activity of managing is required.
Let’s explore this different perspective upon the statement that “Scrum Master is a ‘management’ position”.
A Scrum Master is a manager. Contrary to the traditional idea of a ‘manager’, a Scrum Master has no formal power over the people in the Development Team, not deciding over their careers, incentives, etc. A Scrum Master does not manage the people or their tasks. But a Scrum Master does manage (via) the Scrum process. Within an organization a Scrum Master is accountable for the maximization of Scrum, for ensuring that people, teams, departments and the organization realize the highest benefits possible from using Scrum. A Scrum Master is accountable for the way Scrum is understood and enacted. This requires management skills, traits and insights.
A manager is a Scrum Master is a manager. A Scrum Master is explicitly responsible for removing Impediments. Impediments are elements that limit the efficiency and progress of a Development Team in areas that are beyond the reach of self-organization of a Development Team. Impediments are most often found in the wider organization, in company processes, procedures, and structures. Removal of Impediments works better if the Scrum Master is a manager turned Scrum Master, thereby adopting facilitation as the primary management tool and seeing the workfloor as the primary habitat.
A Scrum Master indeed is a manager, albeit not in the traditional sense. It is clear that a Scrum Master does not manage budget, people, work and tasks. Product Owners manage investments. Teams manage themselves. However, self-organization as promoted through Scrum does require goals and boundaries. A Scrum Master manages the boundaries that Scrum provides to augment self-organization; time-boxing to limit risk, focused efforts, cross-functional collaboration, releasable results, validated learning.
The Scrum process does no more than framing the creativity of people in their joint creation of valuable software. The process of Scrum lays out a foundation for rhythm and discovery. A Scrum Master manages the Scrum process through the provision of specific services like removing Impediments, facilitating teams, educating the organization, coaching people and keeping the road open to perform, to work, to innovate, to be creative. The services that the Scrum Master provides, needs to provide or is allowed to provide become a mirror to the state of Scrum in an organization.
Scrum Master can be seen as a management position because the Scrum Master role holds what is expected from a manager in an agile context, not because it reflects what traditionally is expected from a manager. A managing Scrum Master is a wise leader that engages people through organizational purpose and vision.
Manager – A Scrum Master
A manager who acts like a Scrum Master optimizes the value of management to the organization. The optimization lies not in commanding and controlling tasks and detailed work items. The value a manager brings lies in identifying wasteful activities, eliminating waste, removing impediments, embracing complexity by assuring Scrum is understood and enacted, from its principles and roots in empiricism, building on the core Scrum Stance, propelling on opportunistic experimentation, setting goals, and maintaining purpose.
The Scrum Master-manager is strongly affiliated to the Lean idea of “Go See“. A manager turning Scrum Master is a person that does not hide in a far-away office. Not hiding is much more than merely creating an open door policy. An open door is a fake measure, as it still lays the burden with the people wanting to see and talk to the manager. The workfloor buzz does not enter through that door. The flow needs to be reversed. The Scrum Master-manager walks around, is part of the workplace with the teams, the place where the real value is created. In Lean this place is referred to as Gemba.
Even in an agile context, the act of managing remains a valuable activity. The act of managing is performed by managers.
Teams manage themselves. They organize their work autonomously. They are managers too. Product Owners manage the product’s vision and the investments in the product. Others manage boundaries, company objectives and identity, technical environments, the Scrum framework. ‘Management’ is the collection of all such activities. Management done properly thrives on servant-leadership. ‘Management’ is not a collection of people executing hierarchical powers. It is an emergent, networked structure of co-managers, people with complementary skills, focus and accountability, mutually exchanged services. All seek direction. Collaboratively. Continually. Skills and meaningful conversation prevail over title, hierarchy and position.
“What you say has priority over how you look.”
Is a manager who turned Scrum Master still a manager then?