Sunday, 1 April 2012

Are Agile Retrospectives a Must?

Originally when I finished University and took my first step in the big wide world of work, taking on the role of a junior software engineer, we would perform some form of a retrospective after each release cycle. Thinking of ourselves as being agile, practising Scrum, amongst other things we would be working on 2 week sprints, releasing to the business at the end of each sprint, morning stand-ups, planning poker, retrospectives and all the other tools and practices available to an agile team. This wasn't always the case but when time permitted and resource allowed, we would get together in a room, usually lead by my boss, and come up with a list of "What went well?", "What went wrong?" and "How can we make it better?", voting on each point, prioritising a list and if we get chance trying to elevate some of the points noted.

That was four years ago, I have no doubt that I have changed in those 4 years. Becoming a more proficient and confident engineer, become more confident with the business and with others and having changing opinions about the agile movement. I think it’s worth noting that agile rocks, or what I think agile is all about rocks and I love the software craftsmanship movement, probably as I am a true geek at heart, feeling very passionate about the software I write. I also like to think the craftsmanship movement relates to myself a little, always striving to produce high quality software which will add value to my users, always trying to write clean code, always trying to practice TDD etc. Software Engineering being such a broad subject there are obviously things which I don't do so well and obviously things which I should change, this could cover an entire blog post itself so I will miss those bits out and focus on the question "Are Agile Retrospectives a Must?".

As far as retrospective go, I haven't been on any courses and defiantly don't have a certification in it. On the other hand, I have read several books, attempted to lead several retrospectives and attended a lot. I will put forward my foundations for asking this questions and my reasoning's behind it.

So retrospectives are primarily a forum to reflect on the last iterations set of work and highlight issues or problems people are having. These problems could relate to any topic e.g. technology, the business, fellow team members, 3rd parties or maybe just the general feeling for the ongoing project by the team. Below are some of the good and bad points about Agile Retrospectives:

  • Points get raises
  • People get issues of their chest
  • Issues can be resolved
  • Blockers come out
  • Team disagreements come to the surface
  • People don’t remember on long projects
  • Difficult for people to get involved
  • Difficult when people work on different projects
  • People take things to personally
  • Actually dealing with the issues after, who, how, when?
  • Doesn't fit a Kanban approach.
  • What if you don't have sprints but are constantly developing and releasing?
Now obviously there needs to be some sort of forum where team feedback and conflict resolution can occur and my main point is that with all the good will in the world having a de-facto agile retrospective doesn't always work? As companies move to a more continuous and lean approach to software development, sprints go out the window. You tend to work on projects which may span months, weeks, days or hours but you’re putting out software daily, easing the impact on the user, reducing the risk on every release, little and often is the game we play (or try at least). So how does this practice work with the agile retrospectives I have read about and practised in myself? It doesn't, when we would release every 2 weeks without failure it was great, every 2nd Friday afternoon we would have a retro, trying lots of ideas (usually from here) and usually it was productive. But even when you have set release cycles likes this I find two weeks can be long time and things which have caused issues can be missed.

Alternatives to retrospectives in my mind are purely dependant on how well communication in your team is. In my opinion a short weekly get together combined with good daily communication will solve most if not all of your problems. Spread the knowledge, get some sort of forum in place like campfire, and post issues you’re having to the whole team. Get a wiki so complex process can be documented (briefly); make sure everyone in the team is in the know. Simply by sharing as much knowledge as you can you will find that tension drops, people are more confident in taking on any task, code ownership is spread amongst the team and people are not solely responsible. Business issues which you are having report them up the chain but ensure everyone is aware you’re having issues and then they won’t be so frustrated if they hit them to. Internal team issues can be brought up in a short weekly meeting, put the issue on the table, let everyone know and see what people say. People should already know if things haven't gone well as they have heard it, read it on the forum, or witnessed it during the week. 

Now the above approach won’t always fit your team and I may be completely mistaken as to what I think best practice is and what is the best solution to solving conflict and issues which are preventing software from being delivered. What I do feel strongly is that once you have moved away from a scrum based development style to a more Kanban based development style, dropping the set release cycles and moving to a more on demand approach, the usefulness of a set retrospective won’t fit your need. You can obviously elbow the practice into your process but thinking again about this approach you may find taking a different angle on the subject you may find it will yield better results.