Celebrating 25 years of Scrum, the new guide was presented on November 18, 2020 at an event held jointly by Scrum Inc. and Scrum.org; the companies of Jeff Sutherland and Ken Schwaber respectively, co-creators of Scrum. Since that time, The Scrum Guide (November 2020) can be read and downloaded (in several languages, even) at: scrumguides.org

The first thing that attracts attention is its smaller size. In just 10 pages, the authors distill this framework from the “Definition of Scrum” to the description of the “Commitment: Definition of Fact”, the last artifact described in the new guide. But let’s not be fooled, a smaller guide makes Scrum even larger, a framework agnostic to the definition of the value you will build with it, a line of work that its authors have been developing with every evolution of the framework.

“A smaller guide makes Scrum even larger, a framework that is agnostic to the definition of the value you are going to build with it.”

Another aspect that is generating more commotion is related to the old Scrum Roles, which have become known as “Responsibilities”. In this way, the concept of Scrum Team gains importance (as opposed to the old roles), and is now described as a self-managed team, and it is the responsibility of the Scrum Team itself to define who does what, when and how. In this way, new implementations of Scrum are possible, without failing to comply with the specifications of the Scrum Guide:

A Scrum Team formed by one person permanently occupying the responsibilities of PO, one person permanently occupying the responsibilities of SM, and several people permanently occupying the responsibilities of Developer.

A Scrum Team formed by one person occupying the responsibilities of PO, with several people occupying the responsibilities of Developer, which also turn the responsibilities of SM in order, randomly or as / when they consider.

A Scrum Team formed by several people occupying the responsibilities of Developer, and rotating between them the responsibilities of PO and SM.

“New Scrum implementations are possible without missing the Scrum Guide”

There is also a subtle, but no less important, change that you may not have noticed: the duration of the Sprint has changed from a maximum duration (timeboxed) to a fixed length. This, just as before, allows a Sprint not to get longer, the change comes in that now also prevents a Sprint from getting shorter, and thus further promotes the concept of sustained rhythm.

“The duration of the Sprint has changed from a maximum duration (timeboxed) to a fixed length”

Another important change is the reappearance of “commitments”. And although this is a change that is causing discussions in different areas, let me ask you a question: did nobody notice that the 2017 guide included the value of the Commitment, but then did not specify commitments throughout the guide? Well, in the new guide, the Scrum Team commits to the Product Goal, the Sprint Goal, and the Definition of Fact to ensure improved transparency and to be able to measure progress in delivering value from the Product Backlog, the Sprint Backlog, and the Increment respectively.

“No one was surprised that the 2017 guide included the value of Commitment, but then did not specify commitments throughout the guide”

The aspects presented in this article are a small summary of some of the changes incorporated in The Scrum Guide (November 2020). Some others remain unremarked, such as the elimination (finally!) of the three questions in the Daily Scrum, the incorporation of the Sprint Goal development in the Sprint Planning by the Scrum Team, or other changes that in my opinion will continue to contribute to Scrum being the most extended agile framework, not only in Software Development initiatives, but in any initiative of any department, industry or even in any aspect of our lives, that aims to generate value through adaptable solutions for complex problems.

Publication of the new Scrum Guide (November 2020)

Note: This post is part of series exploring the structures and patterns of Agile Organizations. We have been working on a new training and toolkit, and the idea behind this series of posts was to share some of the insights and perspectives that we developed while working on our new Agile Organizations training. 

Over the past few years, as organizations looked to scale their ongoing Agile initiatives beyond the team level, scaling frameworks were all the rage. And as people discussed at length the merits of Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe), Nexus, or the “Spotify Model”, something got lost along the way. Agile scaling conversations started to resemble football fans at a sports bar:

“SAFe is the death of Agile! It’s the worst!”

“Scrum @ Scale is just ripping off LeSS!”

“LeSS is for startups, it’s pure fantasy in the real world!”

“Messi is so much better than Ronaldo!”

The ongoing joke became that Agile Scaling was like teenage sex – everybody talks about it, nobody knows how to do it, everybody thinks everyone else is doing it, so everybody says they’re doing it too.

Recently, there has been a collective realization that a more holistic view of the challenge was required. Scaling Agile across an organization is more than implementing a framework (processes). It is principally a change on how we view work – a new mindset. The limited results obtained by many process-driven Agile transformations made it painfully obvious that simply trying to insert Agile processes in a traditional, silo-based organization, just generated more of the same (Forrester described this pattern as “Water-Scrum-Fall”). 

An understanding has grown that to truly transform an organization, there are multiple areas that must be addressed, including:

How do we speed up decisions? (empowerment)

The challenge these big questions poses for people working on Agile transformations is clear – the answers in some cases keep changing. Partly because of the speed of change in the market, but mainly because as we experiment, we learn more about ourselves and who we want to be.

If the answers keep changing, shouldn’t our processes also keep changing?

And there you have the basic issue with process-driven Agile transformations – you’re putting the cart before the horses. Whether you decide to use LeSS, SAFe, Scrum @ Scale, or some expensive custom-made framework, the hard truth is that your framework of choice will not guarantee success. In an Agile world, your processes should not be static, but rather ever changing. Adapting to the emerging needs of motivated, purposeful people.

In these circumstances, understanding the patterns underpinning organizational agility becomes more important than the scaling framework itself. If you understand the building blocks – their purpose, their strengths and weaknesses, and their conditions – you can more easily adapt your processes along the way. You don’t need to implement SAFe to benefit from mid-term planning. You don’t need to implement LeSS to benefit from feature teams.

All of these patterns can be used as organizational structure building blocks. When teams and leaders understand them, they can continue to re-arrange them as part of their continuous improvement activities – tinkering with their organizational structure to help create an environment where people can do their best work.

Agile scaling frameworks have proven useful on two counts:

defining many Agile scaling patterns (and grouping them together into a coherent whole)

providing teams and organizations with a starting point for their Agile transformation

So the point here is not that Agile scaling frameworks are bad or irrelevant. Providing a starting point for teams to continuously improve from is extremely valuable. Similarly to team-level frameworks such as Scrum, that starting point prevents teams from having to completely re-invent the wheel.

However, we should not lose sight that Agile transformations are about changing the mindset of an organization. Processes and structure exist as a supporting role, enabling people to put that new mindset into practice. It is therefore key for any organization thinking about transforming towards Agile ways of working to not focus on which framework to use, but rather focus on answering the bigger questions. And as we find more answers about who we need/want to be as an organization, continuously review our structure to simplify, empower, and catalyse.

To accomplish this (continuously adapting structure), we need to understand more than just the scaling framework itself – we need to understand the building blocks (patterns) underpinning organizational Agility.

Beyond Agile scaling frameworks – continuously adapting structures

Think about yourself as the Scrum Master of a development team. Think about the last time you coached somebody on your team. They came to you with a problem or an impediment. You did the right thing and you took the coaching stance, you didn’t advise them, but only asked questions as to coach them to a solution they would come up with on their own.

Now think of those questions… were your questions leading or not? Were you really asking an open coaching question, letting all your own ideas and view of the world behind? Or were you in fact just disguising a solution inside your question hoping the other person would somehow pick up the advice and work from there?

Don’t feel bad if you did. One so easily falls into that trap. But now that you are aware of it start restraining yourself. Because every time we use leading questions, we keep people, we keep our teams just that little step away from become just that little bit more self-organized and we keep them away from getting just that little bit closer at excelling.

Once we understand that even a small leading question is a way of control that can nip self-organization in the bud, we’ll be ready to let go and that smallest step will lead us to become better coaches, better Scrum Masters and better change agents towards the organization.

The Scrum Masters’ responsibilities lie in supporting the Development team, the Product Owner and the Organisation as a whole. To do so knowledge of what is being Agile and what is Scrum is a must. He supports and brings change through coaching and facilitation and this with a servant or catalyst leadership attitude.

So indeed, one of the things the Scrum Master is supposed to do is help the Development team become self-organized.

For a development team, to have self-organization means taking responsibility and choosing HOW to accomplish and manage their own work without relying on anybody to manage them.

It has been proven that the people closest to the work know best what to do and given the right team conditions and the right work environment they will deliver the best quality results at the highest speed.

The best conditions for teams to be self-organized are the following:

The team should be cross functional in skills, abilities and knowledge. the Scrum Master can work with the Development team to build a skill, abilities and knowledge matrix, searching for gaps and opportunities for growth towards the right competencies so that the team might be in the ability to finish work independently.

The development team should be small, from three to nine people, to allow for optimal communication and collaboration.

Longstanding teams gain a higher performance over time. In fact changes in teams amongst others caused by decisions in the organization are one of the biggest challenges facing self organizing teams.

The Scrum Master should be the change agent in the organisation to create these different team conditions for self organizing teams to exist.

If you are lucky enough, your organization will be ready to make an overall change. Or maybe you could start small with a pilot? Or maybe you are working from the trenches? Either way, you will probably not have the perfect cross-functional, small, longstanding team from the start, it will be a continuous work to create the support and mold the right conditions.

And then there is the right work environment. This is an environment where the team is not told what to do.

As nobody is telling the team members what to do, the development team will have to come up with and try things themselves. They might fail and so they will learn and have to search for a new approach starting a loop of continuous adjustments. Environments in which teams are trusted to learn from failure are environments set up for constant learning, experimenting and ultimately for innovation and excellence.

Having the ownership of the approach, adjustments, and the results, will motivate the team and make them more focused and interested and committed to the work, eventually leading to higher morale and with-it higher productivity. The Scrum Master must make sure that the Development team is empowered to manage their own work (the HOW).

The Scrum Master is responsible to abolish a command and control culture and to grow the ultimate learning organization. Needless to say, that this cultural change will not be established overnight and that the Scrum Master should set the example by understanding to the fullest the impact of their own behavior. 

How the wrong question can nip self-organization in the bud

Front line employees are often overlooked in an agile transformation – but they can be the key to a truly successful approach.

When leading the second phase of an agile transformation, we put focus on transforming the business to an agile approach – which usually means introducing collaborative, design-thinking driven ways of working in our product development and innovation lifecycles. We introduce techniques such as Customer Journeys, Empathy Maps, and we train our Product Managers to be effective Product Owners. We might even go all the way to bringing some real life customers into our workshops – but this is rare, and even when it is done, these customers carry a lot of weight on their shoulders. They are -effectively- living “personas”, tasked with representing faithfully the desires of entire customer segments.

While these ideas and tecniques work well, nothing can replace the raw, unfiltered feedback your real customers give you on a regular basis – and no Product Owner can capture that like front line workers can.

Front Line employees are the people in your organization having direct contact with your customers on a daily basis, often for very short and standardized interactions. It can be a customer service rep, a salesperson, or a support technician. In many organizations these employees are not taken into account by “the business” when thinking about innovation and product development.

Learn to listen to your customers – constantly. Formal customer feedback methods (customer satisfaction surveys, focus groups, design thinking workshops, etc.) are great – but even better is when you combine it with a steady stream of informal feedback. Agile organizations capture detailed customer feedback constantly. In an agile organization, front line employees are encouraged to regularly establish close, unmonitored and healthy relationships with end customers in order to serve them better, but also to capture their thoughts and comments. This closeness supplies a steady stream of unstructured, informal feedback which is much better at capturing changing customer moods than formal methods. 

Imagine your company’s products and services were all sold on Amazon.com – think about the quantity and quality of feedback you would get from the reviews. That’s what we’re looking for here. It’s not that easy if what you sell is insurance, or automobiles, or education. You need the involvement of your front line.

Empower your front line employees. One of the strongest characteristics of an innovative, agile organization is the empowerment and self-organization front line employees exhibit on a daily basis. They act on the feedback they receive from customers without being blocked by bureaucracy or having to ask for permission. They take risks on behalf of the customer, going out of their way to deliver what the customer needs (as long as it’s reasonable). This can mean anything from providing extraordinary customer service to passing along important feature requests directly to a Product Owner.

Autonomy and empowerment do not mean “do whatever you want”. A common mistake is to create a culture of autonomy, without putting in place the internal feedback loops necessary to capture such critical feedback. Nothing is more demotivating than knowing what your customer needs, but not being able to pass this information along to the right person. This is why successful agile organizations have a disciplined approach to sharing the precious feedback front line workers gather with the right Product Owners. And Product Owners communicate new features, roadmaps and product backlogs with openness and transparency. Make sure these mechanisms are in place before you go all-out and empower your front line workers!

Front Line Agility – the missing link to true innovation and customer centricity

Are you looking to become a better Scrum Master or Agile Coach? Here’s where you need to focus on! We give you 5 essential skills for a Scrum Master or Agile Coach.

So, you already know Scrum. Ok, what’s next?

Before you start – Assess yourself honestly. Do you really know Scrum well?

This article assumes you have achieved a basic level of proficiency as a Scrum Master / Agile Coach. But have you, really? How do you assess yourself? Ideally, you are being mentored by someone more senior with proven credentials. But it takes years of experience and practice to reach the level of mastery required to mentor people professionally, and you might not have a suitable mentor within your reach. If you lack a mentor or have doubts about their experience, don’t go at it alone. Join an Advanced Certified Scrum Master coaching and mentoring program from Agilar and get professional, accredited validation of your skills from some of the world’s top agile experts.

As a Scrum Master, your team looks up to you for advice on how to be effective at self-organization. The most important practice you can offer your team is good Visual Management techniques. Teach them to visualize their work in a way that works – for them and for you. Experiment with different taskboard or digital tool configurations – there is no one best way. How many columns do we want to visualize? What levels of granularity do we need to represent our work? (epics, stories, tasks, etc…). How do we visualize interruptions or other unplanned work? How do we see who is working on what? Your goal as a Scrum Master is to help your team use Visual Management effectively to be able to easily answer  questions such as “what are we working on” and “who is doing what”. As extras, add information radiators that answer questions such as “are we going fast enough” or “what is blocking our progress”.

2. Advanced meeting, workshop and training facilitation

As a Scrum Master, you have achieved a basic proficiency in workshop facilitation. Now it’s time to take it to the next level. Continue to practice and invest in your facilitation skills. Try new techniques, experiment, practice. A great facilitator will create experience and outcomes that delight workshop attendees and leave them wanting to come back. Have you ever heard of people who want the meeting to last longer? Because it is interesting, relevant and they are having fun? This is your goal. Great facilitators regularly obtain NPS scores of 50% or higher in their workshops and ROTI scores of 4 or higher in their meetings. Some good books to read on the topic: Facilitator’s guide to participatory decision making; Gamestorming; and research Liberating Structures. To improve your training skills, develop your game with Sharon Bowman’s Training from the Back of the Room series.

You might have heard “you don’t need to be a technical expert to be a good Scrum Master”, and it’s true. But it certainly helps. If you want to be a great Scrum Master, you need to build deep rapport with your team and if you understand the work they do, this will be a lot easier. Besides, there are a lot of ideas the team might be missing, and you might be able to contribute more than just coaching. Concrete advice on this topic depends on your area of specialization, but if you are working in the software development space you should definitively study XP (Extreme Programming) and Devops (read Continuous Delivery and The Phoenix Project) for inspiration.

No Agile coaching practice is complete without a solid understanding of the fundamentals of Lean Thinking and the Toyota Production System. While adaptability to change and customer centricity get all the headlines, Agile is a direct descendant of Lean and you cannot coach a team to high performance if you are ignorant of the fundamentals of operational excellence, total quality management and continuous improvement frameworks. Invest in learning and practicing the basics of Lean to increase your game. There are a vast amount of resources you can explore, but we like to recommend the basics: Taiichi Ohno, Lean Thinking, The Toyota Way. While kanban with small “k” is part of classic Lean, the Kanban method is a modern agile framework that is also a good entry point to this area of knowledge. A certified Kanban training offered by a reputable trainer is also an option. Finally, the LeSS (Large Scale Scrum) agile method relies heavily on Lean & Systems Thinking as its foundations so a LeSS training or book can also be a good entry point to Lean, besides teaching you one of the most important approaches to approaching large initiatives and large organizations.

5. Creating rapport with leadership and “the business”

Anybody who has introduced Agile practices within the IT department of a classic (large) organization has heard that one of the easiest, fastest wins is “increased collaboration between business and IT”. But there is a big difference between the initial quick wins you see in a sprint review and the transformational impact creating true rapport with leadership can bring. The next frontier of Agile is coaching the agile organization and creating agile leaders, and to achieve this ambitious goal we need stronger, more mature Agile Coaches. A modern coach needs to be not only a good coach, but also a good trainer and a great consultant. You need to master talking to any actor at any level and delivering clear, crisp explanations of what Agile really means (hint: it’s not a process, or a methodology, or a bag of tricks), what are the benefits, what are the risks, why this is urgent, and what we need to do to start our Agile transformation today. This is no easy task: leaders have little time and patience and “the business” (colleagues from different operational or functional areas of the company) are up to the brim with day to day “BAU” work, besides tending to think that this doesn’t really apply to them. It takes a really good Scrum Master to be the champion for change in such an environment. A good book you can slip into a leader’s briefcase to tempt their interest is Doing Agile Right by our friends at Bain & Co.

5 top skills to develop for a Scrum Master or Agile Coach

Publication of the new Scrum Guide (November 2020)

Beyond Agile scaling frameworks – continuously adapting structures

How the wrong question can nip self-organization in the bud

Front Line Agility – the missing link to true innovation and customer centricity

5 top skills to develop for a Scrum Master or Agile Coach

Information about the use of cookies