Scrum is like 20th Century Politics (Part 3 of 3)


In Part 1 and Part 2, we saw the forces of extreme right and extreme left savage two organizations in the name of scrum. One company goose stepped about in Luftwaffe jumpsuits. Another built a gulag for stakeholders who would question its developers-only central planning meetings.

In both cases, malevolent propagandists diverted the team’s purpose, and product progress all but ceased. The right was called wrong. The in progress was called done.  The 1 was called 0. User stories were enigmatic and undecipherable.

In isolation, these two examples find one doubting the utility of agile as a strategy for product governance.

Is the answer devolution, a stepping back? Should process be foregone entirely? Shall we place our faith in the anarchic code of the 19th century cowboy coder, or in a justice league future of caped super geeks?

For a company to survive, products must be built. The company needs a social contract, one that helps developers and product managers to find common purpose.

In other words, a third way.

Scrum, when used properly, can provide balance between the extremes of oppression. Best of all, it promises super stable neat innovative stuff made real quick.

Effective scrum starts with a division of power, so that (for example) the legislators of user stories are not the same individuals as those responsible for commanding the code. While code commanders in chief and the user story legislators often resolve conflicts on their own, gridlock can arise. In these cases, a judicious VP of product or the like can be brought in to arbitrate.

Summary of Roles:

  •     Development Team (Executive) with Scrum master (president) facilitating
  •     Product Owner (Legislative) representing the stakeholders (citizenry)
  •     Senior Product Manager (Judicial) to arbitrate disputes


Members of the judiciary serve for life unless deposed by a natural disaster (board member or CEO). Product Owners can be replaced preriodically by popular demand of the stakeholders. The development team needs to deliver results at the end of every sprint cycle, or risks losing stakeholder support.

While extremists might threaten this balance from time to time, corrections are inevitable so long as everyone understands the process and keeps watch on the others. When working, the system results in frequent releases and giddy, smiling stakeholders.

Companies that follow this third way are more likely to emerge as winners in a market conflict. They are also more like to feel good about work, have more satisfactory love lives, and sleep more soundly.

Happy product building!


Leave a Reply

Your email address will not be published. Required fields are marked