“A kind of Scrum”

When I talk to different companies in the software industry about how they work I often hear the expression that we use “a sort of scrum” or “we have our own version of scrum”. I hear a warning bell from those kind of statements. Agile and Scrum are buzzwords that most companies like to boast that they use, especially since many system developers prefer to work that way. But how much can you tweak Scrum and still get the benefit out of it that we proponents promise?

It is true that “agile” means easy to change and that agile development is based largely on changing the approach from the feedback you receive. In all agile methods, the aim is to have frequent and short feedback loops. But it is a common misunderstanding that Agile is so lightweight that you easily can change the methods as you like. It is not the frameworks that are agile, they make you agile if applied properly.

It is easy to introduce scrum meetings each morning. It’s easy to have planning and retrospective meetings. It is easy to put up a Scrum board for all to see. But it’s hard to get all the pieces to work together as a whole, and to get the entire organization to be permeated by the agile values:

  • Deliver often
  • Respect people
  • Responding quickly to changes

Scrum is often implemented in isolation in a development department and the change is often driven by the developers on the floor. It is perhaps not surprising because the movement has been built by developers and there is an inherent power shift from traditional managers downward in the organization to the developers.

Such initiatives from below often encounter obstacles and resistance when trying to fit the agile way of working into an organization that is not prepared for it. That’s when you easily begin to stretch the agile values and create ”our own variant of scrum”. What happens is that the transparency of scrum exposes dysfunctions in the organization, but instead of resolving the root causes, you change the process and make workarounds and thus continues to hide the root causes. This pattern is so common that it has a name, scrumbut and the effect is often that the team doesn’t deliver a “potentially deliverable product” each sprint.

To less mature organizations, the best advice is to adhere strictly to a methodology such as Scrum to have something to hold on to and the result can be relatively good anyway. Scrum as it is described in The Scrum Guide is a very mature approach that has evolved and adapted over two decades. More mature organizations knows what effects changes to the processes will cause and therefore will have more freedom to stretch the methods to their own advantage.

Change can be costly, not least in the form of altered balance of power, but there is a lot to gain by getting everybody involved and pull together. A good agile organization is like a Formula 1 car driving fast and responds to the slightest input pulse from the driver, but also has a trimmed team in the pits that are willing to fix anything that might happen during a race.

If you intend to introduce Scrum in your organization and unless you’re really mature, you would do well to stick to Scrum by the book and be responsive to all the temptations of deviation. Take them as a signal that there are some things in the organization that are not working optimally and try to fix the root causes. We are all children at the beginning and to mimic can be an effective way at the beginning of a change.

Circle of Consensus

When I work as a scrum master, one of my bibles is “Agile Retrospectives – Making Good Teams Great”. It describes a number of patterns and exercises that one can use during retrospectives. When you work iteratively, especially when you have short iterations, it can easily go routine in the retrospective. It gets boring and does not give that much input into the continuous improvement that you’re after. But the book gives many tips on different exercises you can use to access information and make decisions or simply just to get a change.
The most common exercise I’m experiencing is a kind of brainstorm where everyone in the team writes down things that have been good and bad during the iteration on post-it notes and then group, prioritize and decide actions to take. It is an exercise that I feel is worn out and has some flaws. It is of course not nice to say that something has been bad so many teams mask to call it delta, i.e. what can be improved. But I think that is nonsense and prefer to call things by their right names. If you have good teamwork and an open discussion climate, you can also discuss what has gone bad. But as I said, I think there is a flaw in the exercise and that is that most of the subjects that come up have both positive and negative aspects. It often happens that the same piece ends up in both columns or is put up in between. So I have developed an exercise I call “The Circle of Consensus” which I have used at St. Jude Medical and at Mawell. I will follow the pattern from the book of how an exercise is done.

Activity: Circle of Consensus
Use in small teams (2–5 people) to analyze what the team thinks is important at depth.

Analyze important issues and decide measures to take in consensus.

Time needed
20–60 minutes depending on team size, the depth of the discussion and how consistent the team is.

Each member choose 1–3 topics that are important to them and discuss one subject a time until you have enough understanding and can reach consensus on what should be done.


  1. Introduce the activity by explaining that a regular brainstorm rarely penetrates a subject in depth and many subjects have both positive and negative aspects. Ask everyone to write 1–3 topics they want to discuss. Ask them to formulate themselves compact and to the point so that it is easy to stick to the topic. Participate yourself in the exercise if you are part of the team. “We will discuss one subject a time and I will record what we come up with.”
  2. Give the group a few minutes to come up with topics. You will usually notice when they are done.
  3. Ask them one at a time to formulate his or her subject. It is best if the same person leads the discussion which will develop leadership skills within the whole group.
  4. Encourage the group to discuss the topic from many different perspectives. Intervene if someone dominates too much or if someone is oppressed or censored. Be prepared to fill in with more aspects if the group is locked to one perspective.
  5. Usually the group reaches consensus on the subject and on what should be done. Note the topic and what actions the group decides to take.
  6. If you can not reach consensus you can either leave the topic or you can use the contradictions to analyze the group dynamics to obtain a better teamwork in the future.

Materials and preparation
Post-it notes for topics. Small patches helps to make compact and pithy formulations. Notebook or whiteboard to summarize the discussions.

This exercise often makes everyone on the team to speak and to discuss topics that are important in depth.

A team of three people has had problems with stress and have different views on how much work you should put down to write clean code. One topic discussed was what creates stress. There were many different things that created stress. One team member was stressed out just by knowing the team was behind schedule and another became frustrated by being forced to write smelly code. The third thought the client showed little interest in the work and was not told clearly what was expected of them. It was decided by consensus to talk more with the client and to work more actively to make a clear and prioritized sprint backlog.


When Software Talks


It begins as a feeling in the abdomen, something that gnaws and feels quite uncomfortable. They did not know how right they were, Martin Fowler and Kent Beck who coined the phrase code smell or perhaps they did.
Well, I have identified some place in the code that gnaws and smells and begin to refactor. Sometimes the refactoring is easy and quick. Sometimes there are so many nested dependencies so there is no simple way to refactor. There is a refactoring method called Mikado I have started to use which is a structured way to unravel and refactor tangled dependencies. If my employer lets me be and I continue to follow my intuition, then things starts to happen. For me, refactoring is a way to get to know the code and make it mine. And finally the code starts to talk. It is a deeply creative process that is very satisfying and personal.
In my earlier life I took a course in film studies and wrote an essay on the film Metropolis and then the same thing happened. It can also happen when I am studying a music piece with my choir, Boo Cantabile. The score on the paper begins to talk, or rather sing. When I lay a jigsaw puzzle the same thing happens. In the beginning everything is chaos. Gradually, you can begin to see patterns and sort the pieces by some system. Then subdivisions appears and at a certain point the puzzle begins to talk and more or less resolves itself. Programming is a craft more than anything else.
Unfortunately there is seldom understanding of this creative process among principals, project managers and product owners. There is such a focus on the short-term; delivering functionality for the next sprint or a deadline. This incurs technical debt and is difficult to avoid. The heroes of salable functionality is software development’s response to quarterly capitalism. I have been and remain a strong proponent of agile development, but also see the risk of “short-termism”. How can that come to be and how should you respond?
Sometimes a development team is under the pressure of deadlines and can not muster the strength to dive deep into the code, but are forced to continued accumulation of technical debt. I know what should be done and it would be beneficial to the client in the long term, but I cannot do anything about it. It’s similar to when you’re stressed and are forced to breath with your chest instead of breathing with your stomach, a breathing that is better except in extreme emergencies.
Often the pressure is from the developers themselves as Henrik Kniberg so aptly expresses. We are an impatient species and often the press is a chimera. But sometimes the ignorance simply is due to lack of competence of those in charge. They do not know what separates good from bad software and has no understanding of what technical debt means. It requires skilled programmers which can also spread their insights to the entire team. A good leader has either the knowledge or has sufficient trust in the developers in the team and let them spend their time as they choose. On the occasions when I have seen really good software been created or created it myself it has unfortunately often been thanks to some ingenious programmers “flying under the radar” and programs secretly without the management knowing. Why is it that? It’s something that at best is appreciated in retrospect but rarely rewarded while it is happening.
And this is one of the truly great risks of agile development. It is easy to sub-optimize. Or is it something that affects immature organizations? Agile development is, in many respects, a powerful tool that perhaps too many embrace uncritically and throw the baby out with the bathwater.