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.

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

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

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

Beyond Agile scaling frameworks – continuously adapting structures

How to become a credible Agile Coach today

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

Information about the use of cookies