The Hitchhiker’s Guide to Killing Agile (5/?)

Sadly, […] a terribly stupid catastrophe occurred. […] it is the story of that terrible stupid catastrophe and some of its consequences. 

It is also the story of a book, a book called The Hitchhiker’s Guide to Killing Agile, not an Agile book, never published on Agile website, and until the terrible catastrophe occurred, never seen or heard of by any Agile team members.

Nevertheless, a wholly remarkable book. […]

It begins with a manifesto…

After having been working with so-called Agile methodologies for one year and a half, even though under no circumstances can I consider myself an Agile expert, as an Agile enthusiast professional instead, I feel brave enough to suggest adding another principle to the well-known Agile manifesto.

It would sound something like “continuous improvement over continuous delivery“.

I’m saying that because, even though nowadays most SW teams are able to provide continuous delivery, I’m not sure that all their development activities are improving at the same pace.

For example, I guess some teams (the lucky ones) spend some time at the end of every sprint in a retrospective session, but I wonder if they are really able to take advantage of it.

Let me clarify that I am a retrospective meeting enthusiast. Actually, I strongly believe that it’s very useful to point out what was well and what was wrong in the past, and what should be improved in the (short-term) future.

But I would also remark that the overall success of the meeting depends on how you approach it.

At the end of this kind of meeting, for instance, some teams may pick up the most relevant items to be improved as soon as possible. So, after choosing these items —something which, on the other hand, may conceal a challenge or even an issue in itself (who chooses them? according to which criteria?)—, in the best scenario someone (again, who?) will take care of them, and then there will be some more or less exciting follow-up activities.

In this case, I wonder about what happens with all the other items. Does the team just ignore them? Do they forget them? Do they eventually think “we can live with it”? Maybe these problems are experiencing an unexpected and unlikely “autofix”? I’m afraid not.

Whatever your approach is, you should make sure your team know in advance what is the expected goal/result of a retrospecting session. You can even decide that it is kind of a group therapy (an absolutely valid approach), but again, everybody should know what is the real purpose of the meeting and what will happen with all the issues discussed.

On the other hand, another problem may arise when, instead of making the team responsible of the required actions for improvement, nobody takes care of them or, even worse, nobody knows if someone does.

What’s the point in maintaining a long list of items if you don’t do anything with them, except collecting the list —and probably paling at how much it has grown— in a beautiful and meaningless spreadsheet to show in the next meeting?

Again, if you want to take advantage of a retrospective session, its purpose, resulting actions and responsibilities should be clear for everybody, as well as before as after it.

So, once taken into account the huge effort required to get the most out of the retrospective meeting, someone might start thinking of… just getting rid of it. After all, it just seems to be a waste of time… Please, don’t do that!

If you think your retrospective sessions are just a waste of time, what is probably wrong is not the meeting itself but your approach.

As I said before, the retrospective meeting can provide the team with very useful information. The point is that everybody within the team should take into acount this information and should feel responsible for using it. Only in this way they can really start improving themselves and the development process.

Don’t forget that learning from past experience and mistakes is one of the most useful and cost-effective ways of learning. After all, even though you cannot cancel a mistake (nor its cost), you can always learn from it and make it effective in order to improve your team and your development process.

Before concluding, let me add that you may also take into account the wonderful and often overlooked power of “spotlighting the right”.

As explained by the positive psychology expert Michelle Gielan in an interview conducted (and published on LinkedIn) by Kathy Caprino, “too often we believe we need to focus on all that’s broken and fix it before we can thrive, but now we’re seeing that is not necessarily the strongest path.”

So, paraphrasing just a little her advice to make it fit in our retrospective meeting context: “Instead of helping your team see all the things they need to work on to improve their situation or achieve their goals, just simply spend some time spotlighting all that they are already doing right. […] Call them out for the little things they’ve done great. […] They will fulfill their new self-image.”

To sum up, if your team is not that good at something, instead of emphasizing how good they should be, you can always decide to start praising their effort and their little steps towards the desired result. Over a period of time, they will probably redefine themselves as very good at that something.

So, what about giving it a try? After all, the proof of the pudding is in the eating!