The Rule of No Rules

Is Scrum all about anarchy? Well, yes and no.

Yes, because Scrum is not about forcing rules and creating enforcers of this rules. There's no hierarchy and authority representatives, no one is entitled in a controlling role.

One common misunderstanding is believing that the Scrum Master is like a police officer that has to make team member follow the rules of the "true Scrum".

No, because Scrum has values and principles that one should understand and follow. Working agreements reach consensus in the team and are applied on discretion. The team auto manages itself and decides what to do and how to do it.

Scrum is all about negotiation, inspection and adaption. No imposing something and making it work by force.

Telling the Tale Using a Task board

What a taskboard is?

• A communication vehicle
• A wall or a whiteboard where the team post their kanban cards
• A visual indicator -a.k.a. information radiator- that provides a quick status check

Who should build it?

• The Product Owner should build the first version
• The team can increment it's content in each Sprint

Who should maintain it?

• The main responsible is the Product Owner
• But this doesn't excludes the team in participating
• The ultimate goal is that the taskboard accourately reflex tasks -kanbans- progress
• The rule of thumb is having always updated status of tasks completion

Who should prioritize it?

• In kanban the taskboard is not prioritized but in Scrum it is, so the main responsible for this is the Product Owner

Does it has to be online?

• Yes, if you want to save the kanbans for later analysis
• Yes, if your team is distributed
• Yes, if you have way to many kanbans to put in a single wall (smells: problem indicator)
• Yes, if you have found an electronic taskboard that is not complicated to use and fill your needs
• Otherwise you should be using the old and simplified version: post-its and a whiteboard

Management by Sight

To world famous Toyota Way, based on the Toyota Production System success, has a very interesting concept that always caught my attention: Management by Sight


So what this all about? Let me try to explain the need for this:

• Manager, and why not engineers, are busy people who don't have time to crunch numbers to see how they're progressing in the project
• Everybody cares about measuring progress, but managers are just big fans of it
• So, we need something that people can look and instantaneously, and why not magically, can tell them whether they're on track or falling behind schedule

Once we all realize that we need some light here, we're ready to look into what Toyota discovered years ago: a simple chart that shows progress


But some conditions for the magic to work:

1. It has to be visual (obviously!)
2. It has to be public
3. It has to be periodically updated
4. It has to be easy to read
5. It has to be easy to understand
6. It's interpretation has to be clear
7. Only a few indicators should be considered per graph, don't try to show everything in just one chart
8. It has to be a communication vehicle for the team
9. It has to have real data, not massaging information should be allowed
10. It's a tool for the team, not just for managers

The Mythical Scrum Master

Once upon the time there was an all powerful individual full of charm and personality, his energy and intelligence what nothing from this world. His voice was like a thunder and he has this magic thing for solving everybody's problems: his name was The Scrum Master

Unfortunately this is just a myth, no such thing exist or at least can be easily found in just one individual. But let's go one step back, why people created a myth around this character? There are some reason that I can think about:

1. From a management perspective it's easier to concentrate all responsibilities -and powers- in just one individual
2. From a team perspective it's times easier to expect that somebody leads the team and solve problems
3. Concentration of responsibilities in one individual is the worst enemy of team empowerment and the great ally of micromanagement
4. Blaming only one individual in case of failure is less harmful to morale than blaming the whole team

So what can we do to kill the myth? Several things I guess:

1. People believes in myths because they try to avoid reality, so let's start there recognizing that there's no Super Scrum Master
2. Like it happened in old towns, myths will be erased via education -so let's start by educating managers and teams
3. But education people on what? Short answer: Scrum
4. Micromanagement is good as long as the team is in charge of it: micromanagement of the team by the team is what we're looking for

When the Product Owner Has to Say No

Saying no to the team, to the client or the Scrum Master, is one of the PO's more important tasks, but let's think in some situations when this might happen:

1. When the team wants to force the client to use a technology, platform, architecture or design that it believes that is "technically suitable" but has no value for the client -I know what is best for you syndrome-
2. When the client wants something that is clearly unfeasible with the given schedule and resources -the dreamer syndrome-
3. When the Scrum Master representing the team wants to change the scope for the project -two captains one boat syndrome-
4. When the team voted and decided what should be excluded from the product -technical decision without business support syndrome-
5. When developers want to work on an overkill solution for a problem -super engineer syndrome-
6. When the team wants to investigate during several sprints without guarantying practical results -researcher syndrome-
7. When the team and Scrum Master want to skip demos -ostrich syndrome-
8. When the team want to exclude the PO from all meetings because they believe they already understand the product well enough -come back when it'll be ready syndrome-
9. When the client want to communicate directly with the team bypassing the PO -serve yourself syndrome-

Syndromes Origin

Even though these syndromes are very common, their origins are still fuzzy, some might be:

1. The PO is not making a good job gathering requirements
2. The PO is not making a good job communicating requirements to the team
3. The PO is not making a good job tracking Sprint progress and backlog evolution
4. The PO is not making a good job interfacing with the Scrum Master
5. The PO is not making a good job buffering the team from external influences
6. The PO is not making a good job setting priorities
7. The PO is not making a good job using her charisma to lead/influence the team/client in the right direction

Whatever reason that is forcing the PO to says no to the team, these seems to indicate a disruption in the PO role an performance. After all a NO is not required if everybody is clear in what should be done.

Many NOs accumulated in the course of a project are a symptom of a failure in the PO performance. But in any case is times better that the PO says no and correct her course than letting things flow in a direction that will take the project to a failure.

Another of my Articles Published by the Agile Alliance

Another article written by me, Definition of Done and the Quest for the Potentially Shippable Product, has been recently published by the Agile Alliance: see this link http://www.agilealliance.org/articles_by_category?id=17

The Illusion of Control

Buddhists believe that the control is just an illusion, people fond to control things suffer to much when they realize that they can't control everything.

Buddhists recipe for happiness (and please don't take this literally) is not creating tight bonds to anything or to anybody, just let things flow and interact without forcing control.

What I found interesting in this philosophy is that managers tend to devote much of their time and effort to craft complex control devices, dashboards, and metrics loosing perspective that in Scrum everything is about micromanagement, but not micromanagement of the team by the manager. Micromanagement of the team by the team itself is times more efficient.

If a team learns how to manage itself, the illusion of control won't be necessary any more, managers will become coaches, and will sleep better at night.