Agile Transformation: Mastery, Autonomy & Purpose

Mastery Autonomy Purpose — Synopsis

Master autonomy purpose — in this article, I present a slightly different way of viewing agile maturity, through Dan Pink’s lens of Mastery, Autonomy, and Purpose; as a simple and useful way of fostering conversations and ensuring all relevant perspectives are considered.

Mastery Autonomy Purpose — Age-of-Product

Do you want to get this article in your inbox? You can sign up here and join 24k other subscribers.


Let me start by saying that if you haven’t seen Dan Pink’s video on ‘Drive; the surprising truth about what motivates us,’ then check it out STRAIGHT AWAY. The concepts are very relevant to the agile space; and, for me, it’s up there with David Marquet’s video on ‘greatness.’

Anyway, Dan talks about:

  • Mastery: i.e. being great at what you do / achieving excellence in your field
  • Autonomy: i.e. being self-directing / the master of your own destiny
  • Purpose: understanding the ‘why’ behind your work and the value it delivers.

Even though Dan discusses these concepts in relation to the individual, as key drivers/motivators; I also like to think about how these 3 dimensions can be applied in the agile context. Straight away you can see how the above relates to specific agile principles. And it seems to me that just about any agile value/principle you can think of can roll up under one of these.

Upcoming Scrum and Liberating Stuctures training classes and workshops — Berlin Product People GmbH

M.A.P. as a Simple Framework

But why should I start thinking about my agile world this way? Well, these 3 concepts can act as a great, simple framework for thinking about how to create great agile teams — i.e. to consider how we can make each of our teams achieve mastery, become autonomous and to have a purpose.

Let’s examine each one:

  • Mastery: each agile team typically wants to undertake their work to a high standard – delivering maximum value and avoiding crippling technical debt – they also want to be supported by the types of processes and tools that help them be agile (and ensure tight delivery & feedback loops), not hinder them (check out Spotify’s ‘engineering culture’ stuff for an idea of what I’m talking about here and here).
  • Autonomy: we also know that successful agile teams are self-directing and possess the necessary skills to deliver their work – with as few dependencies as possible.
  • Purpose: perhaps we can consider this from the alternate perspective – i.e. what happens when teams do not well understand the value they provide to customers and/or the reason for their existence. Teams without a purpose often spend their time on value-less work, thereby failing to deliver maximum value.

Cannot see the subscription form?
Please click here

Key Agile Roles

And, depending on the specific method/framework you’ve adopted, some key agile roles translate very well to this way of thinking – especially when considering the notions of how ‘servant leadership’ focuses on 2 main things; enabling teams and providing them with direction/purpose :

  • Mastery: Chapter Leads (and the chapter members more broadly) fulfil much of this agenda
  • Autonomy: Agile coach / scrum master can help the team achieve this through understanding agile principles & practices
  • Purpose: your Product Owners can provide squads with the context they need to see how they add value to customers and the organisation.

You may even use this construct when conducting health checks, both at the team level and for the scaled agile organization (i.e. not specifically SAFe, but any method of scaling agile).

Before I thought about things this way I used to utilize the traditional split of People, Systems/Tools, and Processes – which is still useful, but not nearly as much as M.A.P.

Leveraging this construct can save you time also – when talking to people about certain continuous improvement initiatives, you can simply say some like ‘This will help our squad achieve Autonomy’ – which folks can simply accept without much more explanation.

Pragmatic Application

But how does it work in the pragmatic sense? Well, as with most things agile related, you need to build something into your cadence. Many of you may have heard of a ceremony called POCLAC that commonly operates in agile organizations – well, POCLAC stands for Product Owner, Chapter Lead and Agile Coach – and is a squad level ceremony that, in the case of Spotify, bills itself as a ‘support structure for the squad’ (i.e. in the model of servant leadership) and focuses on overall squad performance and health from the perspectives of People, Process & Product – which is a fairly close match to Mastery, Autonomy & Purpose.

So, given I prefer the Mastery, Autonomy & Purpose terminology over People, Process & Product, I’m going to opt for calling this ceremony SquadMAP instead of POCLAC.

Note that with somewhat of a cross-over of purpose many often ask how SquadMAP and squad retrospectives align. i.e. why do you need SquadMAP when retros serve the purpose of continually improving squads. Well, typically Chapter Leads don’t attend squad retrospectives, which means that their perspective is often overlooked. A dedicated ceremony for Product Owners, Chapter Leads, and Agile Coaches means that we’re covering off all the important bases.

Applying to the Scaled Agile Scenario

And those of you who are thinking ahead are surely asking yourself about how this applies when scaling agile – well, you guessed it, there’s also room for a TribeMAP, where the collective tribe leadership, Product Owners, Chapter leads and Agile Coaches gather according to a regular cadence to consider all things tribe health-related — and similarly thinking along the lines of Mastery, Autonomy & Purpose. Agenda items are typically things that are being escalated from SquadMAP or squad retrospectives.

But beware – do not assume or treat this group as a typical, old-fashioned leadership team. It is a leadership group, but only in the context of servant leadership – TribeMAP exemplifies servant leadership by ‘enabling’ squads to succeed.


I’ll illustrate further via a couple of examples:

Scenario 1

The nature of the work our tribe is committing to (in alignment with its mission) doesn’t happen to logically fit with any of our current squad missions, and we’re tempted to artificially split the Epic into 2 separate ones – shoehorning each into separate squads.

How SquadMAP and TribeMAP can help: in this scenario some senior squad members recognized this as a potential problem when reviewing the tribe backlog, and while considering which future work their squad might pull down. They’d noticed that a certain Epic didn’t fit nicely into any of the squad’s current missions – nor did any squad seem to possess the necessary skills to deliver that work. In this case, knowing that their squad couldn’t resolve this issue themselves, those individuals raised this issue for consideration by TribeMAP directly. During the next TribeMAP session the group sought to better understand the problem and decided on some actions – which included confirming that the work should sit with that tribe and not another, and then reviewing the squad structure/skills mix to ensure it could deliver the work. Primarily, it’s the Autonomy and Mastery agenda that drives these actions.

Scenario 2

During several recent retrospectives, a relatively new squad has considered the reasons why they haven’t been delivering value to customers. They identified ongoing, systemic issues with their workflow that inherently involves dependencies on other squads within other tribes. And given the nature of this problem, the squad is not able to resolve this issue themselves. How SquadMAP and TribeMAP can help: In this case, the squad escalates this issue to TribeMAP for consideration. This group makes decisions based on what’s best for the tribe’s ability to successfully achieve its goals — autonomously. Which in this case involves acquiring new skills within the tribe and negotiating for, and taking ownership of those activities formerly performed by the other tribe. Again, it’s the Autonomy and Mastery agenda that drives these actions.

Culture Change

I also believe that this lens will help us with the cultural change that’s so important to any agile journey. Exploring your world through this lens can help you identify the values and principles that are important to you, as well as the types of behaviors that you’d like to encourage or avoid. Perhaps the obvious example is to focus on the need to drive greater Autonomy within teams, which aligns well with existing agile principles and practices, but Mastery and Purpose are sometimes neglected. A focus on improving Mastery can help progress the way in which team members do their work; and the tools, systems, and processes they use which will speed up their cycle times and shorten feedback loops.


I find Mastery, Autonomy and Purpose a useful lens through which to view our agile environment; it helps us gain a more holistic perspective on our agile journey, ensuring we consider a wide range of success factors. What I’ve covered above is only a small sample; I’d encourage you to consider how else it might help you through your agile journey – especially with respect to any cultural/behavioral challenges you may face.

📺 Subscribe to Age of Product’s Brand-New Youtube Channel

Now available on the Age of Product Youtube channel:

✋ Do Not Miss Out: Join the 3,500-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

Join the Hands-on Agile Slack Group

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Agile Transformation: Mastery, Autonomy & Purpose — Related Articles

Download the ’Scrum Anti-Patterns Guide’ for Free

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

Date Class and Language City Price
🖥 💯 🇬🇧 December 7, 2022 GUARANTEED: Hands-on Agile 48: How Elon Musk Would Run YOUR Business with Joe Justice (English; Live Virtual Meetup) Live Virtual Meetup FREE
🖥 💯 🇬🇧 December 12-13, 2022 GUARANTEED: Professional Scrum Master (Advanced) Training (PSM II; English; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 💯 🇩🇪 December 14-15, 2022 GUARANTEED: Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 💯 🇩🇪 December 19-20, 2022 GUARANTEED: Professional Scrum Master Training (PSM I; German; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 🇺🇸 January 23-26, 2023 — US Timezone Professional Scrum Product Owner Training (PSPO I; English; Live Virtual Class) Live Virtual Class $1,045-$1,245
🖥 🇬🇧 January 24-27, 2023 Professional Scrum Master (Advanced) Training (PSM II; English; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 🇩🇪 January 31-February 3, 2023 Professional Scrum Master Training (PSM I; German; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 🇬🇧 February 7-10, 2023 Professional Scrum Master Training (PSM I; English; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 🇺🇸 February 13-16, 2023 — US Timezone Professional Scrum Master (Advanced) Training (PSM II; English; Live Virtual Class) Live Virtual Class $1,195-$1,395
🖥 🇩🇪 February 28-March 3, 2023 Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT

See all upcoming classes here.

Professional Scrum Trainer Stefan Wolpers

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.