You work in a system.
You do. Even if you don’t aknowledge that fact, you can’t escape it. The process you use to produce whatever it is you produce, is inherently systematic. If you don’t admit it, that doesn’t change. It just means that your system is out of your control, and probably a bit shit.
It’s a long time since Ken Schwaber and Mike Beedle turned me onto something that blew my mind.
Their book, Agile Software Development with Scrum, was like nothing I’d ever read for professional reasons. Until then, I’d followed the lead of teachers and trainers, reading mainly from the curriculum text, and things that I thought might help me learn “how things were done”. I was looking for a set of instructions on how to be a manager, or a project manager, or a Microsoft Certified software developer (!) – whatever. If I’m honest, I saw Agile Software Development with Scrum that way as well, that’s exactly what it is. Scrum is a way of doing things that you can learn “by the book”.
It was one word in the book though that really flipped the switch in me.
The word wasn’t totally foreign to me, but I’ll admit to looking it up.
1. based on, concerned with, or verifiable by observation or experience rather than theory or pure logic.
What empiricism means in terms of an agile mindset, is the acknowledgement of what we do every day as a system. We can choose to observe/improve it or ignore it, let it evolve untrained. You need to really watch what you’re up to, embrace it and own it. If you don’t, you’ll never find the parts that work and those that don’t. Improvement will be left to chance.
Prior to finding Scrum, if I tried to enact an idea or practice from a book and it didn’t work, I would assume that I just wasn’t doing it right. Go back to the book and check. Where am I going wrong? The idea that “inspection and adaption” (page 100) is built into Scrum turned that on it’s head. If it’s not working, maybe you’re doing it exactly like the book says, it’s just not working! . . . and you should change it.
Read through the comments in the posts of just a few agile blogs and you’ll know that there are differing levels of comfort surrounding that. How much change and in what areas should be “allowed”. For the record, I’m in the “extreme change is OK” camp. I’m not a Scrum purist (or even an enthusiast particularly). No brands for me. If what you’re doing in 12 months resembles too closely what you’re doing now, then you’re not standing still, you’re going backwards.
Have you ever worked somewhere that had a “continuous improvement” focus? Good. I also like to think of that (call that) “continuous adaptation”. In an industry where long-term survival is success in itself, Darwinism stands alongside Kaizen.
It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.
Sadly, we often see teams that miss the opportunity to adapt; even though the vehicle for doing so is in place. The Retrospective.
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
Scrum guide – Ken Schwaber and Jeff Sutherland
Iterative development is great. We understand that making small, measured alterations to a product will improve it more effectively than arduous planning and big-bang releases. Often though, teams fail to apply the same thinking to the adaptation of their “system”. Sure, they’ll go through the motions of a retrospective, but too frequently, we see failure to enact real positive, iterative change. Retros become a ceremony without value.
Get your Retro right
There are enough resources online that will tell you how to run a retrospective. Rather than bore you with my version, I’ll just point you at two good texts.
Firstly, the essential retro book, Agile Retrospectives Making Good Teams Great, by Esther & Derby Diana Larsen. Their staged approach (1. Set the Stage, 2. Gather Data, 3. Generate Insights, 4. Decide What to Do, 5. Close the Retrospective) allows you the freedom to develop your own activities. Secondly, if you’re stuck for those activities, hit this little beauty – Getting Value out of Agile Retrospectives by Luis Gonçalves and Ben Linders. It’s a really quick read full of ideas to mix it up in your retrospectives.
No matter what you do, no matter how you run them, the one personal point-of-view that I would hope to impress upon you, is that if you want effective retrospectives, you need two things, without question . . . so that’s two points. Sorry.
1. Make list of action items from every retro
Not a long list, no more than two or three things. Change just one thing a week and you’ll have close to 50 positive mutations a year! They’ll be items that the team agrees to work on for improvement. They should be focused on improving the way the team works together toward one of their own objectives (better quality, interactions, sprint goal success).
2. A solid process for enacting the changes
(Really, super, especially, over-the-top, f@#$ing important)
The retrospective is all well and good, but it’s what happens between them that really matters. How are the action items turned into real improvements? Add them to the sprint backlog, or simply make the action list visible and prominent in the team area, with a commitment to discuss it every day. Those things are simple and they’re what make a retrospective a valuable ceremony.
How often have you not seen either, or a seen list of actions that is never discussed between retros? Never allow yourself to go through the motions. If you’re discussing, but not genuinely enacting change for the better, stop pretending. Spend that retro time doing something else. If you’re wise though, you’ll shape those retros up, act in between and make them the most powerful agile tool you have in improving your system.