AB InBev, is a multinational drink and brewing company based in Leuven, Belgium. It has approximately 630 beer brands in 150 markets, 164,000 employees based in nearly 50 countries worldwide. For 2020, AB InBev’s reported revenue was 46.9 billion USD.

AB InBev Europe started its Agile experiment in 2019 with a simple, open-ended question: "What benefits can Agile bring to us?"

Since then, Agility has brought faster, more focused deliveries across more than 70 teams and 10 business lines. It has transformed the culture of the company and customer experience, while creating momentum and tangible business results in areas as diverse as  commercial, HR, logistics, supply chain, and finance.

In this article we present the case study of ‘Sales BI’,  one of the most successful underdog stories of ABI’s journey. 

Sales BI (short for Business Intelligence) is the key reporting tool for all operational and tactical sales KPIs. Pulling in data from various sales and distribution sources across the org, it then massages it into actionable insights leveraged by salespeople across Europe.

Sales BI's net promoter score in 2019 - when the Agile pilot started - showed that its users hated the software. Its NPS started out at -73 in 2019. Since shifting to an agile way of working, NPS has reached highs of +71 in 2020 and stabilized around +48 in mid 2021. At the same time both the number of users and average session duration grew.

Diverging from Existing Program Governance

Before 2018, business intelligence in the Sales sector was an ad-hoc, manual process based on spreadsheets. Initiatives were started to build a robust tool that would support Sales. Based on the existing program governance of the time, it was approached as a fixed scope, fixed budget project and outsourced to third party preferred suppliers.

The result was an all round failure, classic of traditional approaches. Missed deadlines, non-working features, angry users. The project was canceled and restarted. Twice!

During 2018 a the 3rd attempt to deliver the tool was underway. Stakeholder pressure and apathy had grown exponentially, exposing the team to an ongoing cocktail of "We need this yesterday!" and "Yeah, right! You've failed twice, what has changed now?"

Steering committee meetings revolved around status updates, escalations, red-amber-green indicators, tasks that the team and vendor were working on, and planning spreadsheets. Months had gone by and there was nothing to show, pressure was high, and their backs were against the wall.

While the traditional project was underway, a couple of people from Business got fed up and decided to try something different on their own - in parallel to the main project. In practice, they forked or branched the project from a business perspective. They called their initiative “Plan B”.

A common pitfall in IT projects is to start building architectures and solutions before having validated business assumptions. Clear requirements don’t guarantee business success. The requirements could be guiding you towards building the wrong thing. Plan B decided to focus first on the business problem, then on the technical solution.

Using off-the-shelf, "no code" tools, a team of non-technical business people went directly to talk to end users. “What are the issues you're facing currently? What reports or BI would you like to have?” The goal was to build a skeleton or prototype as quickly as possible without getting bogged down by project management governance or technology.

A few weeks later, the first prototype was ready to show.

The team handed it over to willing ‘beta tester’ end users. It was a raging success. The simple delivery provided enough functionality to enable end users to get work done faster and better than before.

A few months later, the prototype had grown to become a massive spreadsheet connected to multiple databases and dozens of users! Plan B team started panicking. They were a victim of their own success. Agility had enabled them to go too far, too fast. They had ignored the technical side for too long and the solution was no longer scalable. The team could barely go on holidays.

It was time for a pivot. The moment had come to turn that prototype into a technically sound product that could be scaled and maintained sustainably. 

Recognizing that the practice of outsourcing everything could be improved, the Director of Zone - the central hub that provides tools and services to the countries - tasked one of his direct reports to investigate the possibility of building an internal software development department. The hypothesis was that bringing software development in-house and applying Scrum - the world-class project management framework - would produce higher quality software, respond quicker to customer requests, and lead to better customer satisfaction. 

It was decided to launch 2 experiments to test this hypothesis. The first candidate project was called Central Planning. Plan B was the ideal 2nd candidate. Sales BI decided to cancel Plan A and pour the remaining budget into Plan B.

The projects had similarities and a few differences.

6 months after both teams started, the differences in output and outcomes was stark. Central Planning had delivered working software multiple times, users were becoming happier, and the team was collaborating well. On the other hand, Sales BI kept running into various organizational challenges and was unable to produce usable working software.

Violating Agile Manifesto's 12 Principles

Sales BI was not following key principles of the Agile Manifesto:

4th principle: Business people and developers must work together daily throughout the project.

The Developers had never met their users nor saw those users use Sales BI.

6th: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The team organized themselves into expertise silos, communicated actively inside those silos, but not enough outside of those silos.

During the kickoff weeks the team had the luxury of being physically together. Being co-located has the added benefit of serendipity, of bumping into a colleague and striking a conversation without needing to schedule it. Afterwards however - before and during COVID lockdowns - , the team was distributed throughout Ukraine and they didn't make space for having unstructured conversations.

7th: Working software is the primary measure of progress.

Instead of reviewing a working product and engaging in conversation with the audience, the Sprint Reviews were plagued by conversations about status of tasks and red-amber-green indicators.

In order to remedy those issues, at the beginning of 2020 the Developers were brought over to Leuven HQ to experience the AB InBev reality. It was a mix of functional workshops - refining backlog items, working agreements, etc. - and some intangible, team-building activities.

Experiment: Get in the backseat of your users' car

Sales people go around the country, visiting bars, restaurants, and supermarkets to sell their beer brands. Which establishments they visit, which brands they attempt to sell is data that comes directly from Sales BI. What better way for the Developers to understand the challenges of using the Sales BI or to experience its shortcomings than actually hop in the backseat of cars of those salespeople? 

In early January of 2020 the team did exactly that. The Developers split up in pairs and each went out with one salesperson. At the end of that day, during the debrief, it became clear that the Developers empathized with their key users.

The positive effect of this experiment was evident immediately. Previously, when encountering a decision point during development, the Developers would stop and seek clarification from the Product Owner. This was a slow and low-quality process. Now, with this new and fuller understanding of their end-users, the team was able to make decisions on their behalf which led to faster and better resolution of those questions.

Another impediment that disappeared after the week of bonding was the team's way of working. 

In the beginning, the team focused on developer “efficiency”, focusing on their own technical skills which led them to organize themselves in silos of expertise - database, middleware, and front-end. It proved to be a flawed strategy. Each silo built things that the others couldn't use, all of it was dumped onto the teammates responsible for testing, and no working software was created.

They decided to try a different approach focusing not on development efficiency but on solving the customers problem. 

Instead of organizing themselves as a single team of 9 people, they assembled in 3 cross-functional sub-teams. They call these sub-teams "pods". The members are tightly integrated within each pod, yet each pod is loosely independent from the others. Rather than working on a technical part, each pod works on a complete user-facing feature from beginning to end. The positive impact was measurable: velocity increased, releases followed suit. 

The pods also improved requirements. Previously, requirements were written with the technical phase in mind and it had to be "translated" so that anyone outside the team could understand.

Now, with the team focusing on solving a customer's problem, the requirements are written from the user's perspective which requires no translation and the team is constantly reminded of the problem they are trying to solve.

Previously, when the team was not delivering a usable increment, the discussion at the Sprint Reviews - or as it is officially named internally: Management Committees, "ManCom" for short - revolved around status updates and escalations. Stakeholder attendance was understandably low.

With the team's new-found productivity, ManComs changed entirely. The team focuses on showing the working product and listening to feedback. It is an informal conversation which users and stakeholders eagerly attend. It is not unusual for the PO to invite 20 people and 40 actually show up. In the past, the PO would lead the entire meeting. Now, different team members take turns presenting, increasing the team's engagement, and improving their understanding of stakeholder feedback.

The positive impact of this experiment is even measurable in the slides presented in the Sprint Review. Before, the team could have 14 slides where 0% related to the working product. Now 80% of the 'non-agenda' slides present new features.

A secondary benefit is that the recordings of the Sprint Review become product documentation. Those recordings capture the team explaining a newly developed feature and the stakeholders reaction and questions to them. Which turns out to be similar questions to other users.

"The backlog was filling itself", said Ryan, the manager of the Sales BI program. "Stakeholder collaboration ended up turning Sales BI into a different animal", he continued, admitting that his original vision for Sales BI didn't materialize. And the organization was better for it.

"When the team was not delivering, the stakeholders focused on deadlines. When they started delivering, the conversations shifted to 'what's next?' ", further reflected Ryan on the impact of Agile.

Sales BI success has both proven the hypothesis that software development is a core competency and clarified what benefits Agile could bring to AB InBev. Its learnings seeded a new way of working that now encompasses most of the departments of the company. On average, Agile ways of working have proven to increase a product's NPS / customer satisfaction by 50 points, reduce the time-to-market by ⅔ , and team members are & remain engaged.

Key insight: a new approach to business application development

Traditionally in large organizations business people have had two options when faced with a need to develop a new tool:

Deal with IT, with all their bureaucratic budgeting and project management processes, and associated costs, delays and failures 
-or-

Go rogue and hire an agency “on the side” to deliver their solution, which is typically low quality, not fitting into the overall architecture, and gets them into fights with IT.

The new approach teams up key people from IT with business teams to develop rapid prototypes that focus on fulfilling end user needs using off the shelf lightweight tools and components that integrate directly with production data sources in a secure way. Under the careful watch of IT security and data experts, business people are encouraged to explore together with their end users in a contained way, developing fast and valuable solutions.

One of the principles of the Agile Manifesto is “Simplicity”.

Plan B was able to park all the scaling conversations. Scaling technology, scaling features, scaling contracts, and scaling stakeholders & users,. 

Do seek the advice and alignment of your architecture team to ensure that experiments as Plan B don't cause havoc within the ecosystem.

The Plan B team began as 2 people bouncing ideas off each other. They had a shared goal, desire to solve a problem, and eagerness to learn new technologies. Only when the product was in wide usage did they consider creating a larger team around the product.

Scrum Master must be equipped with habit-changing skills.

Culture is the shared beliefs and behaviors of a team. The Scrum Master of Sales BI understood that changing it required them to start with atomic habits and build on each little success.

The Scrum Team must observe the users using the product / service.

You have to make it a habit for the Scrum Team to observe the user experiencing the product / service. The team will better understand the context and empathize with the users. Which will increase the quality of their decisions.

Teams might dismiss it at first, but you must keep coming back to it. Look at the organizational structure and processes for incentives that are prohibiting the Scrum Team from becoming cross-functional.

The Sprint Review is the most important interaction that the team will have with users and stakeholders. Prepare it ahead of time to have to project that "laid back yet in control" confidence.

Prepare a couple of days before the review. Which PBIs can be presented, how, and who will present them.

Start the Review by reminding the stakeholders of the Product Goal, the goal of the release, what's been done previously. A user story map is a great tool for that.

Present - not demo yet - each item. A great formula is the "before and after".

Let someone from the team demo the new features.

Turn your Sprint Review recordings into documentation.

Don't let your preparation go to waste. Use it to build your documentation for your documentation. It has a polished and "fresh off the oven" explanation of how the feature works, why it exists, and might even have a couple of questions from the audience.

A case study of how a team went from -70 NPS to +70 in less than 1 year.

This article is written for current and aspiring Agile Coaches and for those looking to hire an Agile Coach to support their organization's agile journey.

One of the most frequently asked questions in the Agile community is about career path orientation. Demand for Scrum Masters and Agile coaches continues to rise, and with it, there is a plethora of definitions and qualifications that make it difficult to figure out what are the right skills, experience level and credentials that give you the right to call yourself an “Agile Coach” and be taken seriously. 

I built my first Agile team in 1999. In 2006, I started working as an Agile Coach and have never stopped. In 2009, I became one of the first Scrum Alliance Certified Agile Coaches. I have been heavily involved in the international agile community for almost 15 years, and as the founder and co-CEO of Agilar, a leading agile consulting, training and coaching company, I have good insights into the market - both from the perspective of customers, of coaches, and of the certification bodies. I am also one of the longest-serving volunteers of the Scrum Alliance Trainer Approval Community, the toughest agile certification body in the world that grants the most prestigious, most valuable and hardest to get Agile certification - the CST. 

Before discussing how to become a credible Agile Coach, let’s align on what we mean by “Agile” today.

The term comes from the “Manifesto for Agile Software Development”, but the word "Agile" on its own has never been officially defined by the authors. The Manifesto that was crafted 20 years ago was intended specifically for the context of developing software, mostly within a single team, product or project. The Manifesto has been wildly successful and has given birth to the Agile movement, creating the momentum we live in now. 

But if today you would consider "Agile" only as a way of working with software, or a way to manage product development or projects, you would be severely limiting yourself. 

We have grown way beyond that. In 2021, we need to broaden our definition and set a new baseline to be able to properly discuss the role of the modern Agile Coach.

Today, when we talk about "Agile", we need to be talking about "Agile Organizations" and "business agility". Today’s advanced agile coaching challenges lie less in the coaching of teams, software products and individuals and more in the coaching of leadership, the broader business and organizational transformation. 

Let's extract the essence of the Agile Manifesto -the type of teams, culture and ways of working the authors were proposing. Let’s extrapolate that to the business reality we face today. 

Today, what we call an “Agile organization" is a place that stands out by exhibiting a unique culture and approach to work. Agility is not about methodologies, specific practices or tools, but about integrating and exhibiting certain coherent behaviors and mindset that deliver tangible and measurable results.

We can describe an organization as “Agile” if they achieve many of the following:

Being significantly more responsive and adaptive to changing market conditions and consumer needs than before. 

Innovating and outpacing their less agile competitors by delivering products and integrating feedback quickly and frequently - typically by implementing customer-centric, iterative-incremental, team-based, inspect-and-adapt approaches to new product development.

Building and delivering high quality products and services, working at a sustainable pace while demonstrating respect for their employees, customers, stakeholders and the broader environment & community.

Remaining competitive not only through innovation but also through high standards of operational excellence and continuous learning and improvement.

Very few organizations can honestly claim they meet all these criteria, but that should not deter us. We should take these as a set of guidelines or characteristics to aspire to, in a quest to improve our organizational culture, effectiveness and way of working. The Agile movement brings us guidelines for building organizations that are healthy, successful, and fit for the future.

What is an "Agile Coach" today? How has the role evolved?

Historically, the best description of the role of an Agile Coach comes from Lyssa Adkins’ book “Coaching Agile Teams”. This was a landmark book when it came out and is still the authoritative book on the subject today - go and read it if you haven’t. But it is from 10 years ago, and these were simpler times. There were no scaling frameworks, no big talk of agile beyond software or business agility back then. Based on our definition of agility, a modern Agile Coach retains all that Lyssa taught us and extends it, as you become more senior, to focus more on the challenges of coaching leadership and guiding entire organizations that want to become “more Agile”. 

Besides the focus on organizational transformation, another trend from the last 10 years is the addition of stronger classic coaching skills to the Agile Coach profile. Nobody was talking about ICF or ORSC certifications 10 years ago. Chapter 5 of Lyssa's book might have started this trend.

Finally, while 10 years ago practically every Agile Coach had a software development background, today it has become widely accepted that this is not required.

Another name for the role of Agile Coach is Scrum Master, by the way. A Scrum Master is exactly the same as an Agile Coach. Scrum Master is the specific terminology for Agile Coach used in Scrum. Since most Agile implementations include at least some amounts of Scrum, and Scrum is the most popular agile method in the world, the two terms are almost synonymous.

What does an Agile Coach do on a daily basis?

Depending on your level of seniority, skills, interests, and the general organizational context, as a modern Agile Coach you do one or more of the following:

Training, teaching and mentoring on a variety of Agile topics (both mindset and practices) to a team or a broader audience.

Implementing new processes related to adopting an agile approach.

Protecting teams from interruptions and distractions.

Chasing or resolving blockers and general problem-solving within the context of an Agile team.

Facilitating workshops and meetings with a professional facilitator approach.

“Real” business, leadership and personal coaching (ICF style).

Internal consulting (advising) on topics related to Agile (mostly to leadership).

Designing, documenting and communicating new processes and methodologies related to Agile; Agile organizational design.

Leading change & communication in the context of an agile transformation.

Co-creating operating models & scaled/de-scaled approaches fit for the organization.

Proposing experiments and driving continuous improvement in the ways of working of the organization.

Continuously learning and staying ahead of new trends and ideas that might be useful to your organization in the future within the context of ways of working and organizational design.

Plus many other compatible things I’m forgetting...

All these activities fit nicely together in a coherent way. You are the expert, you have the mindset, and your responsibilities are all related to informing, guiding, implementing and sustaining this new way of working.

In summary, an Agile Coach is a teacher, a mentor, a guide, a coach, a facilitator, a problem solver, a consultant, an eternal learner and a servant leader - all within the context of an organization that wants to become more Agile or sustain its agility.

Can I rightfully call myself an Agile Coach? How do I obtain credibility?

One of the most problematic and confusing situations in the market today for employers, customers and coaches alike is that many people are calling themselves “Agile Coach” on LinkedIn without being able to justify the title credibly. 

This is an unregulated market, so there are no barriers to entry. There are no legally binding certifications or accreditations. There is no common, agreed understanding and definition of the job or the levels of seniority.

Even having validated experience, there is no simple way to assess the results an Agile Coach obtained in a past engagement or the relative difficulty of the challenges they faced.

Unfortunately, we must confront the possibility that many Agile Coaches might be overselling themselves. Agile demand has grown exponentially in recent years, and the needs of organizations serious about change surpass the skill and experience of most coaches in the market.

We are lacking granularity and standardization of the profession. The universal title “Agile Coach” is not giving us enough useful information on what the actual level of seniority of the coach is, what impact they can have, or what challenges they can successfully tackle. 

Case study: a scale of Agile Coaching levels of seniority

Within Agilar, in an attempt to create some clarity for ourselves and for our customers, we have come up with a seniority scale based on our 15 years of experience doing this job ourselves and the natural progression we feel we have gone through.

These are the levels of seniority in our Agile Coach career path, and some examples of what impact you could typically expect from a coach at each level.

Working in an agile team as a non-coaching member (Developer or Product Owner) is for many people the first recommended step. It is uncommon to start coaching a team if you have never actually worked in an agile environment yourself.

Minimum recommended time in role: 6 months

Recommended Scrum Alliance certification: obtain the CSM

Level 1 - Scrum Master or Junior Agile Coach

Basic coaching of one team, getting them to an “MVP” level of agile maturity (we call this "Basecamp 1" in our Agile Maturity Assessment)

Coaching a Product Owner from “business”

Participating in internal CoP and public community events

Recommended Scrum Alliance certification transition: CSM to A-CSM

Getting one team to really high performance levels

Coaching multiple teams (with Scrum Masters) simultaneously

Coaching and training of a broader range of business & stakeholders

Coaching at product level for medium sized products

Presenting at or organizing community events

Minimum recommended time in role: 2 years

Recommended Scrum Alliance certification transition:  A-CSM to CSP-SM

How to become a credible Agile Coach today

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

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)

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

Note: This post is part of a 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.

Case Study - ABInBev's Sales BI Team

How to become a credible Agile Coach today

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

Publication of the new Scrum Guide (November 2020)

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

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

Beyond Agile scaling frameworks – continuously adapting structures