Tag: agile coach

Why do Agile Coaches Love Post-Its?

Marc GreisLeave a comment

Often, people joke about an agile coach’s affinity for post-it notes. And it’s true – it is difficult for me to imagine how I would do my job without post-its. It hardly ever happens that I do not have a pack of post-it notes within an arm’s reach, and it hardly ever happens that I moderate a meeting without using any post-its.

However, I believe there is a deeper meaning behind this:

Once, I was told that the meeting moderator’s pen is like a modern scepter. Whoever holds the pen in a meeting also holds the power over the meeting. Whoever holds the pen is the primary decider when it comes to what will be written down and how it will be written down. There are many ways in which a moderator can (more or less) subtly manipulate a meeting to elicit a preferred result, simply by presenting the results in a certain way.

This changes completely when the moderator hands post-it notes and pens to the meeting’s participants. This is effectively a handover of power, and the moderator fully retreats into a facilitator role. And this is a deeply agile concept – to not hold on to power but to give it to the team.

So I actually believe that the heavy use of post-its is just another expression of an agile mindset.

The Agile Burden of Proof

Marc Greis1 Comment

In my opinion, the worst thing agile coaches can do is to introduce practices they cannot motivate. And by “motivate” I do not mean that they can recite the relevant passage from the Scrum Guide or from some book. By “motivate” I mean that they actually reach and convince the people they are dealing with.

The burden of proof that a specific practice is useful is always on the agile coach.

Saying “It’s done like this, because we do Agile/Scrum/Kanban/Whatever” is only marginally better than saying “It’s done like this, because I say so.” If we accept these as valid arguments, then we also have to accept “It’s done like this, because we always did it this way” as a valid argument – and it is a common argument of people who oppose Agile, because they want to hold on to their old processes.

If someone asks “What is a retrospective good for”, we should have a meaningful answer and not just something pre-packaged from the Scrum Guide, such as “It’s an important inspect-and-adapt meeting”. That is like saying “It’s important, because we do Agile”, because after all, Agile is the reason why we run frequent inspect-and-adapt meetings. But why do we run frequent inspect-and-adapt meetings in Agile? We need to be willing and able to dig quite a bit deeper here. I would recommend using the 5 Whys method here before you even go into the discussion with your team.

Yes, that makes life more difficult for agile coaches, because there will often be some resistance, and often, we cannot even conclusively prove that something works until it has been tried. But the important word here is “try”. I do not see a problem with introducing a practice explicitly as an experiment, stating right from the start that it is a time-limited experiment while encouraging feedback and making sure that the experiment is properly documented and monitored. That is the agile way for handling this: If we emphasize the importance of empirical product development, then we also need to practice empirical process development by running our “great” ideas as experiments and not as decrees that are not open for discussion.