One of the most misinterpreted and misapplied terms in our Industry is the term ‘empowered’. I hear it used over and over from organizations that are new to Agile concepts and have usually know just enough to be dangerous – and dangerous they become. Although I’ve seen this term misapplied in many different roles, it is usually my experience teams that are the biggest culprits, and that’s who I’ll focus on in this blog. Using it more like the term ‘anarchy’, the term ‘empowered’ misused as a reason to get away with everything from reprioritizing the Product Backlog to missing iteration goals. This behavior is one of the most disruptive forces in an Agile transformation.
I thought I’d shed some light on that term and where the term ‘empowered’ does and does not apply.
Let’s start with the definition of empowerment:
em•pow•er•ment (ɪmˈpaʊəmənt)
n.
1. the giving or delegation of power or authority; authorization
When it is said that “teams are empowered”, they are given certain authorities where management approval is no longer necessary. This authority is over HOW they work, which includes (but isn’t limited to):
- Own the delivery of an integrated, high quality vertical slice
- Creating, owning and managing the Iteration Backlog – the list of tasks the team collectively needs to complete in the current iteration toward the iteration goals
- Owing their own work-processes – how members of the team work together within the team. This includes, but isn’t limited to, setting up their own meetings, rules of conduct, team norms, etc. – basically those processes that are needed to work effectively as a team
- Being able to create and own their architecture (this may be limited to architecture of a particular section for large-scale development)
- Own their technical practices – be able to practice paired programming, Test-Driven Development, Continuous Integration, Refactoring, etc. without Product Owners or managers telling them not to
However, there are bounds to that empowerment and teams that exceed those bounds are teetering on the edge of:
an•ar•chy ( n r-k )
n.
1. Absence of any form of political authority.
Empowerment turns into anarchy when we here statements like the following thrown around by team members – “We are empowered to…”
- “Change the features in the Product Backlog because we didn’t like what’s there”
- “Change the order of the Product Backlog because the high priority items are boring”
- “Not help our managers, other teams or other colleagues outside the team because we are empowered not to be interrupted” Aside: I actually knew of a team that enclosed themselves behind locked doors so they wouldn’t have to speak to anyone between iterations. I understand empowered not to accept scope creep but not letting anyone even ask a simple question is ridiculous.
- “Deliver nothing!” I knew of several teams that delivered 0, nothing, nada, zip, zilch, you get the picture, for multiple iterations because they told the Product Owners (who weren’t trained, btw) that “the teams were now empowered to choose their own work.” Ummm, no.
So what’s the line between genius and madness – between empowerment and anarchy? Two simple mental models that will act as your litmus test:
- Product Owners are empowered to decide WHAT features the teams will work on and in which order
- Teams are empowered to decide HOW they will work on delivering those features.
Two notes to keep in mind:
- I don’t mean to imply that there is no collaboration but rather final authority on both sides. Teams are welcome and encouraged to give input on priorities but the final decision is the Product Owners and the teams are NOT empowered to override that priority. Product Owners, etc. are welcome to give input and best practices on task breakdown, max. number of hours per task, technical norms, technical practices, etc. but the final decision is up to the team.
- When you have multiple teams, there may be organizational norms and best practices that the team may have no authority over. It is up to management and ScrumMasters to collectively determine on a case-by-case basis if those are helpful or barriers.
The whole point of these particular empowerments are to create the most innovative and effective organization. It also focuses the different roles to accomplish their goals efficiently. Be wise and watch out for words that are thrown around without making sense.
