
Havana, Cuba
Agile & life
Fine tuning the power dynamics in an Agile team - The case for democracy and power abuse
On how to avoid the common pitfalls of a team that tries to achieve Agile yet fails all the same.
- For the most part Agile frameworks promote a collegial decision making
- But when it's misunderstood it tends to favor the few that either know how to use it or stand in a position of corporate power
- What can we learn from identifying the sources of power?
One of the hardest part of being a Scrum Master is to exert proper action when fitted and well gauged influence when it's enough to fix problems. The optics of using too much power affect the trust your team has on the legitimacy of Agile, it weakens the belief that transparency, inclusion and the pursuit of the team's happiness are the priority.
Everything in the Agile Manifesto is geared towards a better inclusion of the team in both the product and the process decision making. No democratic power stands up to its name without the doubt of being dismissed by the people that enforced it in the first place. Let's explore the difference between feedbacks and votes. Power dynamics in an organization refers to the relationships between people, both formal and informal.
Democracy Holocracy in Agile
A holocracy is a form of organizational governance in which (as opposed to a hierarchy) there are no leaders or subordinates. Terms like "position" or "employee" are replaced with the term "role". Each role has a defined purpose, its domains of influence, and accountabilities. When acting out a specific role, an employee is authorized to make independent decisions that ensure and improve how that role is fulfilled.
Pushing towards a horizontal decision making is a continuous goal of an Agile inspired team. The era where a sole source of power was accepted is long gone; most of the organizations I've got to be a part of tend to favor a more communal type of consensus, and for good reasons:
- Increased complexity: it has become almost impossible for a sole person to have both a deep and up to date domain and technical knowledge on a project. The rate at which innovation has been racing for the past decade made it hard for any architect, engineering manager, tech lead or product manager to have the exact insight at any subject at any moment.
- Exploded responsibility: accountability has changed, and for the good. In a Spotify organization responsibilities for technical expertise is clearly for the iOS, Android or Backend tribe lead, the product expertise is that of the product manager, the team's organization is for the Scrum masters and the Agile Coach.
Identifying the power and the counter-powers
For all political systems have their apparent and subdued power figures, Agile teams do not escape this rule as they are capacity and vision management structures in a nutshell, politics care about the city, Agile care about the product and the team, and everything in between.
Let's take it to a small team level in a scrum configuration and let's compare where responsibilities lie and how they are distributed:
-
Product vision
Compared to a waterfall both the source the power and its delegations tend to be clearer, albeit it depends greatly from one project to another. The product owner (and by extension the product manager when the term applies) is responsible for the the product vision, yet Scrum shines by including at almost every stage of the product definition the whole team, either by providing a direct recommendation on new features, often driven by a new tech the product owner is not familiar with, or by nudging the product direction with proven indications of technical limitations.
-
Sprints
Voting instances
No democratic power stands up to its name without the doubt of being dismissed by the people that enforced it in the first place. Let's explore the difference between feedbacks and votes.
Endnote
#TODO