Agile Retrospective – Movie Day
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
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." 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.
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