A strong Agile practice is a three-legged stool comprised of the Product Owner (the What), the Team (the How), and the Scrum Master (the Process). These roles are equal to and independent of one another.
In other words, there is no hierarchy in an Agile team; there are workstreams, and workstream owners. No workstream is above or below more significant or more important than another. Each has its own purpose, its own outputs, and its own responsibilities.
In a high-performing Agile team, there are no bosses – there are only teammates.
If your three-legged Agile stool is wobbling, consider these most common root-causes of poor performing Agile teams:
The Tyrant or Timid Scrum Master
No position is as misunderstood in the Agile practice as the scrum master. I often ask prospective clients why they’re hiring a scrum master (as opposed to a project manager or business analyst), and I’m no longer surprised that most cannot tell me why, or what, exactly, the role is responsible for (except for the events) or what the differences are among the PM, BA, and scrum master roles.
The most common answer is, “A scrum master is a project manager, except for Agile.” Dead wrong.
The scrum master owns the PROCESS. He does not determine what is built (that is the role of the PO), nor how to build it (that is the role of the team). The scrum master ensures a consistent, transparent process (timekeeping, utilization, governance, metrics.) He ensures accountability, keeping people honest (in other words, calling them out on their shit.) He demonstrates leadership through questions, coaching, by defining workstreams, R&Rs, working agreements, DOD, DOR, and using the word, “No.” It’s less about servant and more about leadership.
The scrum master is the “Servant Leader” of the team. Unfortunately, too many people stop at the word “servant,” especially if the scrum master is female or an immigrant.
As a scrum master, it’s not my role to “whip” the team. I’m an advocate and a coach. In some ways, I’m unconcerned about the project’s “success” or “value.” That’s not my lane. I trust that the PO has determined/documented the value of the effort, the success criteria, and KPIs. If that’s not done, I’ll ensure it is done, or I’ll escalate it as a risk. I might think the project is a huge waste of money. That’s not my call as scrum master.
The leadership of the scrum master is easily corrupted if the scrum master has a direct report relationship to any of the other parties in the team. It’s also corrupted if the organization hires a scrum master when it really needs a product owner, an analyst, or an architect — this is all too common with “Purple Squirrel” hiring managers in many tech organizations.
The Faux PO
While letting the team continuously iterate some BPOs “mind dump,” is a common ailment, even more debilitating is the old-school, top-down manager posing as a Faux PO.
The Faux PO is common in the Ghost Ship Agile practice, which means that from a distance the Agile Ship seems like it’s sailing along, but when you look a more closely, you see no one is on board.
The Faux PO tells you that the jury is still out on this Agile fad. He’s not convinced it works because the team is too incompetent to complete anything on time, which is why they need to be managed closely. Meanwhile: No metrics. No Dashboards, No backlog. No working agreements. No Definition of Ready (DOR). No Definition of Done (DOD). No separation of development from analysis. No Requirements. The Faux PO isn’t going to sully himself documenting requirements in JIRA. Plueeze….clerical tasks are for women and subordinates who can take notes while they hold court.
The Faux PO’s unwillingness to actually DO the work of being a bona fide product owner doesn’t mean that work goes away. Instead, like a house without front steps, everyone has to find a way around the Faux POs lack of output. What choice is there? Calling your boss out for being lazy AF isn’t really an option…
The Faux PO excuse is that he is much too important for events and deadlines. Because of this, there’s no cadence to the work. The Scrum Master/ Servant arranges a ton of last-minute, ad hoc brain storming or demo sessions to accommodate the Faux PO and other people with titles and opinions. At these meetings, the Faux PO talks at, past, and through the team, (who sit on mute, and stopped offering opinions long ago). No need for backlog refinement or DOR. The Faux PO tells the team exactly what to do, who to call, what to say. If they have questions, they can email the Faux PO for more detailed direction on how to accomplish their work.
But, I Like Being the Boss!
When I’ve suggested to Faux POs that the direct report relationship they have with the team is corrupting their Agile Practice, the Faux PO is incredulous! Don’t be ridiculous! They are natural leaders and visionaries! Their leadership is what is keeping this boat afloat. The team would be rudderless without them.
If everyone on your Agile team reports to you – you’re not an Agile team!
I’ve asked Faux POs if they would give up their direct reports and move their “vision” to another team as a loose-matrix product owner. They won’t. I’ve also asked if they would hire a bona fide product owner, who doesn’t report to them, and can make decisions independently. They won’t do that either.
So, I think we know what the deal is here – it’s called control – and if managers and executives are dictating the manner and methods by which work is accomplished by the team, then you’re not an Agile Shop – you’re old-school, command-control, boss-helper, my-way-or-the-highway shop, and it’s probably not going to change. Why? Maintaining a status quo (especially when you’re benefiting from it) is easier than change. Being a boss is easier than being a teammate. Hierarchy is easier than egalitarianism.
Bosses like being the boss. It’s awesome having people do what they’re told, when they’re told, without pushback or question. If only their wife and kids were like that…..
The Faux PO is a very common root-cause of Agile failure. In a risk report, it would fall under “executive-level support.” or “Unwillingness to adopt new systems and processes.” If there is an unwillingness to acknowledge these entitled behaviors or modify organizational structures, no Agile transformation can be had.
Architect as King
The Architect as King organization is really the worst of all possible Agile worlds. The team builds whatever it wants – the business can take it or leave it. There are no repercussions for crappy work, technical debt, or missed deadlines. UAT? What’s that? Open a ticket with the service desk….
The entire team, scrum master included, reports to an invincible lead, architect, or engineer, who doesn’t GAF about your process or product or metrics. You don’t like it? Do it yourself! Oh, you can’t? Oh, well. Scrum Master? Product Owner? Plueeze, The team reports to me, and your name is NOT on my performance review. Don’t piss me off, or I’ll quit, and then you’ll really be screwed….
From a product, user, and process perspective, the Architect as King organization is DOA for an Agile practice. Hire a technical writer to document the build. Anything else is a waste of money.
As amazing as this sounds, Architect as King is pretty common – especially in private or mid-cap companies. And, when I encounter a dev lead or principal architect who has been with one of these organizations since Christ was a baby, I know that this will be dev-driven development, an inelegant user experience, a shit-ton of technical debt, and I also know that nothing going to change until the king is deposed and replaced.
Final Thoughts….
It’s called an Agile practice, not an Agile perfect, and just like anything that requires practice, you’re going to suck at it the first 1000x you try to do it. But, you WILL get better. Things are never perfect, there’s always more to do. That’s why we have retros. Over time, you’ll begin to see how and why one team is better than another, why a coach is different from an owner, and how having a player in the wrong position or a hot-shot who hogs the ball can kill the team and ruin the game.
If you’re in software or tech, you’re going to have to learn to play the Agile game. Learn everything you can about it, and keep practicing. Agile is part of good project management, and good project management is Agile!
###
I hope you enjoyed this article, please check out some of my other posts and podcasts on Agile and the contingent job market. Thanks for reading!
###
Copyright 2021 Pierce/Wharton Research, LLC. All rights reserved. No part of this post shall be reproduced without permission.
When I'm Not at Work.... 
Leave a comment