House of cards

The beast is unleashed

I try to follow Mike Cohn's posts and tips reasonably regularly. His most recent post caused a furore in the community – not entirely unexpectedly. The premise of the post is that under certain circumstances a separate dedicated PO may not be required for a team (deep breath). This goes against the basic construct of the Scrum Guide and most of the reaction has been strongly negative. As you can imagine, when you question the basis of an empire, the empire strikes back. I admire him for the courage in addressing this topic. Mike puts in some interesting arguments and I strongly recommend you read them, before you make up your mind one way or another.

What he wrote made me think and here is my explanation for why the Scrum Guide is the way it is and why the strong reactions to Mike. 

Enlightenment

Traditionally, you have had two sides of software development (as for any transaction). There is one side who needs something and is ready to pay for it (i.e. the business defines what) and the other side who can make it if paid suitably (the IT-Dev decides how). Also, Scrum Guide is written from the perspective of the Development team (hence you see it as a team – the others are just roles). It is all about how the team should be and what the other roles should do to ensure success. The Scrum Guide is a contract structure between the Product Owner and his army of minions (aka the development team). Someone should oversee and enforce this contract – enter the Scrum Master. The whole structure assumed us (development team) vs them (they could not come so they sent the PO) and the referee (Scrum Master). It may not have been the way it was intended, it is the way it has been widely interpreted and used. The idea was that “we” will manage the work between ourselves - we are collectively a community of nerds. But we need someone from “them” (the geeks) to tell us “what is the work” (story) and “when to do it” (priority) – enter the PO.

Now what we are doing is truly trying to break down the us-vs-them, making “them” one of “us”. This is already evident in the move to DevOps. In philosophy, it is an attempt to get the people who build the system and the people who operate the system closer together. Now when people of two disciplines work closely together, they pick up parts of each other’s skills – sometimes more, sometimes less. Like doctors and nurses. You can depend on nurses to read and interpret your charts but probably not operate on you. Will you let your team run without the single wringable neck of a PO?

The big question

Can a team collectively take product decisions? What about architectural decisions?

Is it possible that in certain context, product decisions can taken by a team collectively? Mike puts forward logical perspectives on why it should not be impossible. I think it absolutely can work, because I have worked in such a team. As Mike put it, the person with the most knowledge “sells” a feature rather than “tell” the rest of the team what to do. Equally well, they don’t stop at selling, they work intimately closely in seeing their vision through. When I say "work", I don't mean it in the euphemistic terms. I mean it in the literal sense of software development.

The person with the most knowledge “sells” a feature rather than “tell” the rest of the team what to do - Mike Cohn

And the answer ...

We already got rid of a separate identified Scrum Master few months back. While we were busy building stuff, almost silently the PO has become one of "us". There's no separate "Development team" - just "the team". Customer collaboration over contract negotiation - anyone? Here’s to a great team (#EMMI) and the man (MikeCohn) who saw it coming.