The other day was discussing with Anthony Murphy and other colleagues about key roles & responsibilities emphasising on the Project Management role in Agile approaches when some pointed that any project manager interested in Agile should read Lissa Adkins‘ book on Agile Coaching because, exactly as she says, it’s a great companion for ScrumMasters, Agile Coaches, and Project Managers in Transition.
And yes, I fully agree! But part of the problem with Agile roles is the promise of cost reduction, or at least time reduction, and normally this responsibility relies on Project Managers ‘supporting’ PO roles, or in the Product Owner role itself. But why this obsession on cost reduction? In my experience, slogans like Jeff Sutherland‘s one promising to deliver TWICE the work in HALF the time with Scrum is part of the problem. Even the amazing video from Henrik Kniberg on Product Ownership states the responsibility of the coach to build it FAST.
Yesterday was working with a group of Project Managers about Agile and better Ways of Working to succeed in our challenges. Was really great opening the topic of the role of Project Managers in Agile approaches. My question was, and is, what are the responsibilities of ANY role when we choose an Agile approach?
I normally use a tweaked version of Henrik’s 3-roles model to tackle, explain and work on roles and responsibilities (and Henrik liked it 😉
This simplified model (image bellow) is the perfect tool to understand where everyone is and where each responsibility better fits. Business, Technology, and People & Process are the unique dimensions that we need. The 1st one, Business or Product Ownership, with the main responsibility to deliver the RIGHT product or service. The 2nd, Development Team, with the main responsibility of building and delivering the product or service RIGHT, with high quality. And the 3rd one, Coach or Agile support, to create a high performance ecosystem where products and services are delivered fast enough to learn and adjust our roadmap properly.
With this exercise, throwing into these circles any of our key tasks and responsibilities, is when we can discuss and agree on which role is better to manage certain decisions: Should the Team decide their annual leave or should this come, or be approved, by the Business. Does the Coach decide their next improvements or experiments or should be the Team themselves? Who decides our next Release date? The length of our iterations? The Definition of Done at story level? And on and on, till all key responsibilities are clear (enough).
Yesterday was not possible but, when I have time I love to complement this exercise with the Delegation Poker practice from Management3.0. Decision making is not boolean. It’s not black or white. And there’s a lot of beauty and benefits when we navigate the grey areas in between.
Ideally, we should do our best to move our responsibilities as close to the intersection of the 3 roles as possible. As a business representative I’m keen to understand the technology the Team is working with and the methodology that better support our work. As development team I see the benefits of understanding the business perspective and the benefits they expect from our work. And as a coach, even I recognise I prefer to work with low context, I’ll do my best to understand the business goals and pain points, and the technology benefits and challenges.
So, It doesn’t matter if you are a Project Manager, an Engineer or a Life Coach. The problem is that we are mixing a roles discussion with a job description problem. The solution is not to convert Project managers into Product Owners. The approach should be to move from Project Manage-MENT to Product or Service Owner-SHIP. This, the product owner-SHIP, is the additional beautiful detail of Henrick Kniberg’s video on this topic (in a nutshell). We need to stop describing people as Product Owners or Agile Masters because this is another huge problem of the founders of Scrum. Product Owners and Scrum Masters, WTHell!!?? I always imagined them in a meeting room smoking big cigars, drinking good whisky, and laughing while having a conversation like this:
- How can we call the business representative, Jeff?
- Hmm… We don’t want to refer to them as managers so we need a fancy name, right?
- Yeah, what about Product Owner?
- Yeah, I dare you to call them Product Owners!
- Hahaha, Done, then we’ll call the Agile expert as Agile Guru, no, wait wait, Agile Master!
- Hahaha, yeah let’s do it. This way we’ll spend the rest of our lives explaining to people what these roles are meant to be.
So, what about looking for true Product Ownership and Agile Mastery? Where everyone is required and welcome to support both sides of the game?
Anyway, this is just based on my experience and my sometimes crazy thoughts. What do you think? Is this model fit for purpose in our organisation?