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.
Do you want to get this article in your inbox? You can sign up here and join 24k other subscribers.
Background
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.
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.
Examples
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.
Conclusion
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:
- Hands-on Agile Webinar #1 on product discovery anti-patterns.
- Hands-on Agile Webinar #3 on agile failure patterns.
- Hands-on Agile Webinar #5 on sprint planning anti-patterns.
✋ 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.
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:
See all upcoming classes here.
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.