New Year’s Resolutions

I’m sure most people will be happy to see the end of 2021 but also trying not to build up too much expectation for 2022. There won’t be a sudden end to COVID – it’s going to take a continued effort from everyone. It won’t go away just because we’re all tired of dealing with it. Stay strong; hang in there; support each other; and keep safe, please.

The New Year is a time when many people set Resolutions – things they want to improve, e.g. eating better, getting more exercise. It’s a handy reminder to review how happy we are with various things, but is doing it once a year really enough? It often leads to huge goals because it’s going to be so long until the new review… and, of course, huge goals aren’t usually achievable. That’s why most resolutions are abandoned within a few weeks. It probably helps to have a vision of how you would like things to be in a few months (even a year), but set smaller goals – what are the steps that you think will take you towards that vision?

Hopefully that sounds familiar: regular retrospection, identifying where you want to improve, deciding on small steps to go in that direction; take a step, then go back to retrospection, rinse and repeat.

Engineers and product owners should be well practised in this – retrospectives to look at how we work, and experiments to probe what to build. So how do we convince HR that annual appraisals should be replaced with frequent feedback, and Finance that regular (e.g. monthly) planning trumps attempting to predict six or even twelve months ahead? That’s a challenge I’d like to add to my backlog for next year. Suggestions are welcome!

2014: Didn’t jog
2015: Didn’t jog
2016: Didn’t jog
2017: Didn’t jog
2018: Didn’t jog
2019: Didn’t jog
2020: Didn’t jog
2021: Still haven’t jogged
This is a running joke! 🙂

Too busy to improve

I’m starting with an assumption: that we believe there is always the need for improvement (in what you produce and/or how you make it). If your product/team/system is perfect then you can stop reading now and go feed your unicorns instead. 😉

The next group I’ll invite to stop reading are those who believe it’s everyone else who needs to change but not themselves. I have worked for organisations where senior/middle managers want the coaches to “fix” the teams. Unfortunately, there can be no significant improvement until those people realise they’re not just part of the solution, there’s a good chance they’re actually part of the problem.

Hopefully, we are agreed on the need to continuously improve, and to be part of those changes. So how are you demonstrating that? Do you make sure there’s time for experiments or do you constantly push for more output? Do you encourage the team to discuss frustrations even when that might lead to questions about the organisation’s structure or decisions that have been made higher up the org chart? Do you help the team look deeply at themselves too, because effective retrospection and root cause analysis is not easy?

One unfortunate anti-pattern I’ve seen is “we’re too busy to improve”. This may be understandable for a week or two, but when this persists then it’s a red flag. I’ve encountered variations of “the Product team want us to focus solely on delivery”, or “leave the teams to get their work done”, or even “if it doesn’t help us get stuff done then we don’t have time to look at it”.

This is a very short-sighted approach; I’ve seen it paired with cancelling vacation or requiring overtime. The focus becomes the quantity of output, often at the expense of quality, sustainability, and the team’s health. Sadly the eventual outcome is often the realisation that what was produced wasn’t even all that important or urgent.

Returning to the presumed assumption that time spent on improvements will not contribute to helping the team deliver more, it’s important to ask why. If the time spent on retrospectives each sprint (commonly that’s 1 hour every 2 weeks) cannot be spared, then your plan is already incredibly fragile and very likely will fail – how will you cope if a team member is sick for a day, for example.

So rather than focus on the cost of improvement, think about the potential benefits. What if that one-hour retro resulted in an improvement that saves the team a few hours? What if the retro highlighted a concern about the quality or design of the work they’re producing? What if the conversation resulted in the discovery that a critical element had been skipped due to cutting corners because they are under pressure?

Saying “we’re too busy to improve” is a step back towards waterfall; it sends the message that “we know everything we need to know” and that nothing can be learned from the work the team are doing. More damagingly, if that is believed to be true when under pressure, when it’s finally lifted why would the team return to doing retrospectives and looking for improvements?

Scrum doesn’t work for us

Hearing a team say “Scrum doesn’t work for us” can trigger a negative reaction, based on an assumption that the team doesn’t understand Scrum or isn’t doing it right, but it could be a positive sign – maybe the team is growing and needs to move beyond “Scrum by the book”.

Scrum can be a good starting point because it provides structure and guidelines on how to “do” Agile – the Scrum Guide specifies roles, artifacts, and events. It specifies pillars (transparency, inspection, and adaptation) and values (commitment, focus, openness, respect, and courage), so it also tries to instil a mindset of “being” Agile. Scrum’s definition states “Scrum is simple” and “purposefully incomplete”; it is not intended as an endpoint but as a stepping stone on an Agile journey.

But rather than say “we’ve outgrown Scrum” and throw it away, this could be an opportunity for the team to inspect the way they work, consider which aspects they would like to change, and then run experiments to try to move towards where they want to be. That might sound like a retrospective, and that’s not an accident – effective retrospection is, I believe, the engine that powers change. If, for example, a team identifies the way that they collaborate during a sprint as something they could improve then they may decide to try pairing for the next couple of sprints. After those two sprints, they should ensure they discuss collaboration in their retro and whether pairing is helping – it could be they decide to extend the experiment, try something different, and adopt it permanently as part of how they work.

Another example could be to move towards kaizen (continuous improvement); maybe the team decide it’s working so well that they decide to drop scheduled retrospectives from their calendar. A purist might ask if you are still doing Scrum if you aren’t doing everything in the Scrum Guide; as a pragmatist, I would be pleased to see the team grow and wouldn’t care what they call it.

Finding value

As part of the warm-up for a retrospective this week we were asked to share an article of clothing which represented the previous sprint. I picked a photo of a jumble sale because I felt we had been trying to find the value in a pile of possibilities – there are many things we could do, but which is the “best”? At a jumble sale, you really shouldn’t try something on then put it back and repeat until you find the thing you want; however, we have the benefit of being able to conduct small experiments to see if we’re doing the right thing.

By taking a small step and inspecting the outcome we can decide whether to continue going in that direction, make a small tweak based on what we’ve learned, or maybe go back and try something different.
To avoid any cognitive bias we should be clear beforehand what criteria we will use to analyse the outcomes; stating those criteria also helps identify any metrics we should collect.
For me, this is the heart of agility – short feedback loops that enable us to learn and react. That reaction helps us deliver what our customers need, and stop working on something as soon as it stops providing value.