Author: Marc Greis

Two Types of Leaders

Marc GreisLeave a comment

Type 1: “Someone in my leadership sphere made a mistake. They are obviously stupid.”

Type 2: “Someone in my leadership sphere made a mistake. What could I have done to support them better? Which tools could I have given them to get the job done? How could I have motivated them better? How could I have communicated expectations more effectively? How could we have collaborated to recognize earlier that something was going wrong? And was that „mistake“ even a mistake, or is that a problem with my own perception? How can I collect honest and open feedback about my actions as a leader from them? How can I help them to see this as an opportunity to improve? Which lessons do I take away from this, and how will I improve as a leader in the future? Which tools do I use to improve and whose advice and coaching support can help me?”

The behaviour of type 2 is often referred to as „Agile Management“, „Management 3.0“ or „Modern Management“. I personally like to call it „Successful Management“.

(Sidenote: In my opinion, the same comment also applies to parenting.)

Agilists in Foxholes

Marc GreisLeave a comment

There is an aphorism claiming that „There are no atheists in foxholes“. It implies that there are no „real“ atheists, but that anyone will turn into a believer when facing near-certain death.

I am not planning to argue whether or not this statement makes any sense. However, I do wonder whether it could be applied to many self-professed agilists. I have dealt with many people who claimed to have an agile mindset (including scrum masters and agile coaches). However, as soon as they had to deal with a stressful situation, with customer and/or deadline pressure or with results that appeared to be subpar, they transformed into waterfallish management 1.0 manage-by-fear-and-pressure micromanagers who tried to motivate their team members by using some version of: „Succeed, or else!“

I believe that being agile is easy when everything is going fine. But there are many fair-weather agilists. The real test of how much your agile mindset is worth comes when you have to deal with a truly tough situation. The weird thing is that many people seem to think it is normal to give up whatever positive principles they claimed to have as soon as the project goes downhill. So sometimes it seems like there are indeed very few agilists in foxholes.

A Sprint is not a Ticking Stopwatch

Marc GreisLeave a comment

Often, people seem to have the impression that the purpose of a Sprint in Scrum is to pressure them into finishing tasks within a given timeframe. In that regard, it would be a replacement for the stereotypical crazy project manager who is standing next to the developers, pushing them to finish their assigned tasks on time – no matter what.

This results in various problems:

  • Developers scramble to finish tasks they had understimated in the last one or two days of the sprint.
  • We end up with a fixed scope/fixed time situation, so quality is sacrificed
  • The teams accumulate technical debt that “will be fixed in the next sprint” (or not… most likely not)
  • People get stressed out

So a lot of the problems that we have in a waterfall project with arbitrary deadlines is carried over into an agile environment, because the end of the Sprint becomes just another arbitrary deadline. The result is that people want longer sprints, because: “Then we are not pressured into delivering something so frequently.”

The mindset should be exactly the opposite though: “The sprint gives us the opportunity to deliver something frequently!” But this does not work if the sprint is seen as a ticking stopwatch.

How do you achieve this mindset? How do you steer people away from “We MUST finish everything!”? There are several points that need to come together:

  • It should not be seen as a major failure if a story is not finished within a sprint. It should rather be seen as an opportunity to improve the planning for the next sprint.
  • Estimates should be realistic. A major antipattern would be a statement like: “Let’s estimate this as a 5, or else we will not get it into the sprint!”.
  • Estimates should account for high quality. The team should always estimate the size of a story when executed with high quality (including the necessary tests and documentation).
  • The decision to consciously consider a story “Done” with technical debt should be an absolute exception, and it should not happen just because the time in the Sprint is running out.
  • The Product Owner must understand how important it is to empower the team to not finish a story if it cannot be done well. It is not in the Product Owner’s best interest to get code that is finished with low quality only to fulfil the sprint deadline.
  • The team needs to understand why we work in sprints. The purpose of the sprint is not to apply pressure to the teams. The purpose of the sprint is to plan and re-plan the work often, to get frequent feedback on completed work, to allow for emergent designs and architectures and to limit the concurrently active tasks.

So the solution is a mix of empowering the team, ensuring that the team understands the background of Scrum and asking the development team to take pride in their work.

My Definition of “Leadership”

Marc GreisLeave a comment

I previously offered the recursive definition “True leadership is about enabling others to lead.” I believe that this definition of leadership can also serve as one explanation of what Agile in general and Scrum in particular are all about.

Often, people have a hard time reconciling the word “leader” with the word “servant” and they have a hard time reconciling the role description of a Scrum Master with the word “leadership”. The reason is that an old-fashioned definition of the word “leadership” is ingrained in their minds. They assume that leadership means that one person leads and other people follow, and that the leader/follower relationship is immutable.

A Scrum Master however is not a leader who expects others to follow. The Scrum Master’s goal is to enable the team to stop following. The Scrum Master leads the team into self-organization and into collective leadership. This is where my definition of leadership comes from, and I believe that Scrum Masters should measure their own performance based on whether or not their team is (or is becoming) a team of leaders, who then – following the recursive definition – collectively empower each other.

Is Scrum a Process?

Marc GreisLeave a comment

Many agile coaches are strongly allergic to the term “process” when applied to Scrum, and you should be very careful not to refer to Scrum as a “process” in their presence.

But is Scrum a process or not?

The Scrum Guide refers to Scrum as a “process framework”, which I assume is meant to imply that a process can be built upon and within this framework but that Scrum itself is not a process. The Scrum Guide then goes on to refer to the “Scrum process” or “the process” several times. So I believe that this invalidates the strict “Scrum is not a process” rule already.

I believe that many people hate the word “process”, because it is a word that is heavily used in a waterfall context, where every little step of the development path from first product vision to final product delivery is described in painstaking detail. Practically every action that needs to be taken before, during and after each milestone is clearly described in process descriptions, and huge amounts of documentation are generated to satisfy these process descriptions. Obviously, Scrum does not do this, so Scrum is not a process in this classical sense. I think this has lead Jeff Sutherland and Ken Schwaber to call Scrum a “framework” rather than a “process” – because Scrum is hardly as prescriptive as typical waterfall processes. The prescriptive content of the Scrum Guide is 16 pages long. I have seen process descriptions where the table of abbreviations already took up more than 16 pages.

So no, Scrum is not a process in this old highly prescriptive command-and-control sense of the word.

But nevertheless, Scrum is a process. A “process” in its dictionary definition is simply a series of actions. Scrum clearly is a series of actions. You start with a Sprint Planning. Then you hold Daily Scrums during the Sprint. At the end of the Sprint, you have a Sprint Review, and then you conclude with a Retrospective before starting again with another Sprint Planning. This is clearly a series of actions, i.e. a process.

I believe that is where for many people the confusion comes from and why both sides of the argument have a point. Perhaps it is simply a “Know your audience” kind of situation. When speaking to a project manager who spent the last 20 years managing waterfall projects, it might be a mistake to refer to Scrum as a “process”. But I trust a Scrum Master to know what they are talking about when they call Scrum a “process” and that there is no problem with the Scrum Guide referring to the “Scrum Process”.

Process Diversity

Marc GreisLeave a comment

When people speak about diversity in the workplace, they usually refer to building teams from people of diverse backgrounds. However, I would like to write about a different kind of diversity that can be highly beneficial: Having a diverse set of approaches for how to organize the work within an organization – or to use a shorter term: process diversity.

To illustrate the meaning of this term, I would like to describe two different fictional companies going through an agile transition:

Company A took a very structured approach to their agile transition. They spent several months thinking about how to organize the teams, how to distribute the work, how the teams should interact with each other and with the various stakeholders. Their project handbook clearly describes how teams are expected to conduct their Scrum ceremonies and what kind of output is desired from them. It also contains a template for a task board that the teams should use and explains how to use the chosen software tool to make the task board available in digital form.

Company B did not care quite that much about coming up with such a detailed process description. There is great variation between how the teams organize their work in Company B. Some use Scrum, while some use Kanban. The task boards in each team look completely different. Some teams use burndown charts, others use burnup charts, while others use neither. Some decided to transfer their task board 1:1 into the software tool, while others track only the higher-level user stories there. Some teams do their dailies in the usual “Everyone answers three questions” fashion. Other teams decided to use other less presciptive formats. One team decided that they want their Product Owner to take an active role in their daily, but other teams have clearly decided against that.

So which approach do I prefer? Personally, I strongly lean towards Company B’s approach.

I like to explain my reasoning by pointing to biological evolution. The only way how species could develop new useful traits is through a diverse gene pool which is caused by mutations. If all members of a species were identical, there would not be any kind of evolution, and the whole species would either succeed in its given environment, or the whole species would fail.

I believe it is the same for companies. Evolution of positive ideas, practices and frameworks is more likely to come from a diverse process landscape. For example if every team structures their task board differently, then the teams can learn from each other, adapt good ideas from other teams and avoid making the same mistakes as other teams. I strongly feel that Company B will have huge advantages over Company A in the long run, even if the differences between the teams might lead to problems every now and then.

Obviously, wanting to benefit from process diversity implies that teams are willing to learn from each other, and you will have phases where teams converge towards common approaches. But the teams should always be encouraged to diverge again by running various experiments to enable another round of process diversity followed by collective learning and process convergence.

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.