How to slowly destroy your organisation

  How to slowly destroy your organisation Here is a tip if you want to destroy your organisation: keep adding roles! I’ve seen it in many companies, and it is a typical slippery slope! Let’s discuss why and what the alternatives are. Back to the “beginning”: the agile team Think of a small company. Just … Read more

Transformation “energy”

One interesting observation I made several times during “agile transformation initiatives” is that they seem to be activated by a sort of “organisational energy” that drives the change. This lasts for a certain amount of time, but then it usually fades and is eventually gone. Here is how it works prototypically: Phase 1: “Recognise Incompetence” … Read more

Laws, Sausages and Sprints

Update: I got some comments regarding this post that made me realise I was a victim of bias when writing it. It might seem I am arguing for an isolation of the developers. Absolutely not: anybody who heard me on the topic knows I am an advocate of direct communication between developers and stakeholders. This … Read more

For agile at scale, use actionable principles instead

It seems the battleground where agile consulting companies are trying to win something has moved to the “scaling” domain: what methods/frameworks/tools/… could we use to bring agility to larger organisations. The topic is fascinating and important, but the answers we’re getting from the market are, in most cases, pretty disappointing, as many “solutions” seem designed … Read more

Retrospectives: “Tunes and adjusts its behaviour accordingly”…

This is the third article in a mini-retrospectives series. In the previous ones I wrote about how retrospectives should be done at regular intervals, but also in other occasions and how the retrospective could be done in different groups than just the team. In this post I will continue to challenge the 12th principle of … Read more

Retrospectives: “At regular intervals”… or not?

This is the first in a series of posts about how to moderate retrospectives creatively. Traditionally the retrospective in agile software development is the reflection done at the end of the iteration. Principle twelve of the Agile Manifesto says “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts … Read more

“Scaling” the team – part one

No, this post is not about increasing the size of your development team, but about how to establish some measurements in your team – typically during the retrospectives, but not only – to support continuous improvement: let’s talk about Solution Focused Scales. I already discussed this technique in my Solution Focus presentation, but listening to … Read more