High-Performing Teams Debrief. They Do NOT play Retrospective Games.

A little while ago I read an article by Doug Sundheim - https://hbr.org/2015/07/debriefing-a-simple-tool-to-help-your-team-tackle-tough-problems which discusses how high performing teams don’t do retrospectives, they debrief. The link to the article was titled ‘High-Performing Teams Debrief. They Don’t Play Games’, i.e. using retrospectives is wrong we should be all grown up and use the term debrief – while you’re at you’re not allowed to enjoy yourself. My first thought was ‘why?, what’s wrong with a good retro?’ . 

Read more: High-Performing Teams Debrief. They Do NOT play Retrospective Games.

The Movie Retro

Agile Retrospective – Movie Day

 

Introduction

This is my take on the movie retrospective that a little bit of googling will find. The first site I found it at was http://tastycupcakes.org/2015/03/a-day-at-the-movies/ feel free to go and read the original, I haven’t adapted it a great deal.

I tend to target all my retrospectives to be complete within an hour, occasionally longer or shorter is good, but an hour is a good target for keeping the team engaged for the complete retro

Read more: The Movie Retro

When is a Defect a Defect?

So I was having a quick look through my CodeProject emails, and amongst the articles I opened to browse was one titled “It’s Not a Bug, It’s…” by Dalip Mahal. Now this article has some good content, but I felt that there were some areas where a response was worthy – and I decided (for once) to create a blog post with a bit more depth than I usually do…

So, where to start? Dalip starts by discussing what makes a defect a defect, and as Dalip mentions it, defect is a better term than bug. Although sometimes defects appear to gather a life of their own, defect has a more professional and clearer context compared to bug.

Read more: When is a Defect a Defect?

The Bloom is Off the Agile Rose.

"The Bloom is Off the Agile Rose." You could call this a water-cooler comment, it was one that I heard a little while ago and it has been lurking in the back of my mind since. I will admit my first thought was ’how do they know?’ the team that this comment came from never succeeding in getting anywhere near to agile – they had a few teams doing iterative work, but the rest of the over-all team viewed agile as an R&D only thing – it doesn’t impact them and it was never really rolled out. Then when I read this article on CIO.com -Why_Agile_Isn’t_Working_Bringing_Common_Sense_to_Agile_Principles  I found myself pondering the current wave of ‘agile bashing’ that is perceived as happening by many in the agile world. I’m not going to respond directly to the points made in the CIO article, as there is a simple summary – what they were doing wasn’t agile – not sure what it was, but it wasn’t agile. There is a great dissection of the article and the agile viewpoint here: Conquering the Chaos CTO Blog .  So what is it that struck me about both of these – that although some people may view both the rose statement and the article  as being anti-agile and containing a lot of agile anti-patterns, to me they both represent something that any coach will have come across, the anti-change pattern. I’ve been through other business transformation exercises as well as agile adoption and familiarity with transformation makes me think that neither of these is so much about agile, but are more a representation of resistance to change.

Read more: The Bloom is Off the Agile Rose.

Risk Based Development

When we look at quite a few ideas that we use in agile, if we rub a little bit to get under the surface we find that the driving reason for why we want to behave in a particular way is down to risk – or more importantly managing risk. However before accepting that statement blindly we probably need to understand what is risk and how does it manifests itself. Then we can talk about some of the parts in our agile tool kit that enable us to manage or balance our risk

So let’s think about some risks

Read more: Risk Based Development