Formula One – Agile To Survive

As we approach the revised start of the 2021 season, Netflix has released the latest Formula One: Drive to Survive. Aside from me being a huge F1 fan, why do I mention it here? Because I think there’s a lot we can learn from the pinnacle of motorsport, whether they call themselves agile or not.

Teamwork One thing people often point to are the pit stops because they are a great example of team coordination. When a car stop in the pits, about 16 people pounce and change all four tyres in under three seconds. (Click on the image to watch Mercedes do back-to-back pit stops.) That takes a lot of practice as well as a lot of trust in the rest of your team, not least that the driver will stop exactly on their mark. It might feel like dev teams are always working on something different, so how can you practice, but think a little more abstractly and you’ll see there are many common activities e.g. how do you react when a critical bug is detected? The F1 teams start by practising pit stops with a stationary car and work up to full speed rehearsals; your team could do dry-runs to exercise their mental muscles so they are prepared for performing under pressure.

Plan then adapt It’s good to make a plan but you should expect to have to adapt as situations change. There have been so many examples over the past year, but one big one from F1 was the 2020 calendar: on March 11th all the teams, cars, marshals, safety crews, track workers, vendors and everyone else needed to make a Grand Prix happen (and the fans, of course) were in Melbourne for the Australian GP. The next day a member of the McLaren team tested positive for COVID-19 and they decided to withdraw from the race weekend. On Friday 13th, the sport’s governing body (the FIA) announced the race weekend was cancelled and the fate of the rest of the 22-race season was unclear. A lot of effort must go into planning the huge, international events (with about 300,000 fans attending each) and all the logistics of moving hundreds of team members and many millions of dollars of equipment from one race to the next… but then all of a sudden the plan has to be scrapped! Trying to create a new schedule whilst balancing various COVID restrictions, track suitability, media constraints… well, if you think sprint planning is hard, spare a thought for the F1 organisers πŸ™‚

Never give up Sergio Perez had to pit after an incident on lap 1 of his penultimate Grand Prix (having been effectively fired by Racing Point for the next season) and rejoined in last place. He fought back and managed to get a midfield car up into the points, then other teams had problems, and suddenly he’s leading the race. He won his first F1 Grand Prix and subsequently gets signed by Red Bull (which is a step up from where he was). F1 is very strange because sometimes teams will announce the drivers for next season in the middle of this season, so some drivers have to compete in maybe a dozen races for a team that has already decided to replace them – weird! Fortunately companies rarely act this way, but there may be times when a team member (or maybe even the whole team) feels demoralised; it’s important to remember your goals & objectives, to think about why you chose to do this job. It’s unrealistic to expect everyone to be at their best every day (especially given the current COVID challenges) so it’s important to support each other through the tough times.

There are probably many other ways in which F1 demonstrates agile traits, or maybe your favourite sport has agile elements – please leave a comment with your observations.

WFH+365

It’s been a year since we were told we had to work from home, thanks to COVID-19. WFH has always been an option for us, and it can be useful for the odd day or maybe two, but a year of it is way too much if you ask me! (I do appreciate that I’m fortunate to still be working and that my company has been very helpful in making WFH sustainable, but I miss the face to face chats even more than I miss the free snacks!)

Let’s go back to March 2020 and start at the beginning. COVID was hitting the news and there was talk of us doing a few days “test” to see if our various systems could handle hundreds of people working remotely. I remember that was announced on Wednesday, and so my coaching team decided to do a pre-test on the Friday… but before we could start the test it became the real thing, and we’ve been working from home ever since.

Why do I mention this on my agile blog? Because there’s lots to learn from it: agility is the ability to react and change rapidly; working from home requires a lot of adaptation; and of course “The best-laid schemes o’ mice an’ men gang aft agley” or, if you’re not fluent in Robert Burns, no matter how good your plan is something will go wrong πŸ™‚

If we didn’t already have some degree of agility throughout the company then some parts would probably have broken or at least been very taxed to cope with the sudden changes. Our IT teams quickly dealt with issues as they were reported, but then most IT teams are used to reacting to waves of tickets – kanban (or more often some process based on aspects of kanban) supports the flexibility and unpredictability that they face. Dev teams were empowered to experiment and find tools that worked for them; for example, we had a preferred video conferencing tool but teams are used to chatting with the people around them, so some used Discord and others tried Sococo – the emphasis was to focus on the outcomes (e.g. ad hoc conversations).

One adaptation that I had to make was due to the lack of (or at least greatly reduced) visual cues that I observe when sitting in a room with the people that I’m coaching. Combine that with physical interruptions, internet connections that drop every third syllable, the increased possibility of multi-tasking (e.g. having a conversation on Slack in another window) and general fatigue, and unsurprisingly it’s a challenge to have deep conversations. Shorter, more focused discussions followed up by text chats seem to be working, but it does seem to mean slower progress… but at least it’s progress!

I also find that I am using whiteboards even more than I did BC (Before Covid) and after trying a few websites Mural.co is a firm favourite – it’s simple enough that anyone can contribute with a moment’s introduction, but powerful enough that we can build templates for a variety of purposes (retrospectives, story mapping, roadmaps, popcorn improvement boards, etc.).

What adapting to COVID restrictions has shown me is that flexibility, empowerment, experiments, and adaptation are key – now if only we had a word to encapsulate all that. πŸ˜‰

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.

Focus

One of the challenges I often hear from developers is about focus – there are good reasons to avoid multitasking (a big one being that people can’t multitask – it’s actually time-slicing and incredibly inefficient) but at the other extreme working on a single problem for a whole day is also ineffective, so what’s the ideal amount of time? [Drum roll] It depends! πŸ˜‰

My personal preference is based on the Pomodoro technique – I like 25 minute timeboxes of focused work interspersed with 5 minute breaks. It fits well with breaking work into small chunks, which means I need to understand the problem I’m tackling and think about a path towards the goal. The other benefit I find is that it’s a good reminder to switch between sitting and standing at my adjustable desk.

There’s a perception that longer timeboxes equate to more focus, but people’s concentration tends to wane after about 45 minutes hence the “ideal” could be using an approach like Pomodoro and allocating multiple timeboxes to the same problem: 25 minutes working on a problem, a 5 minute break, and then another 25 minute timebox will (for most people) be more effective than 45 minutes without a break. The focus-and-break cycle should be sustainable throughout the day, so every so often the technique recommends a longer break; it’s also good to give your eyes (as well as your brain) a break, and even do some stretches.

But, of course, it’s not that simple! If one person is “in the zone” and focused solely on their work for an entire day then they haven’t been collaborating with their teammates or getting feedback from their customer. That may feel good for the developer but agile is a team sport – “the needs of the many outweigh the needs of the few”. The sprint commitment is made by the whole team. Having only one team member understand a problem or the design of a solution is fragile – if that person is unavailable (e.g. on vacation for two weeks) then the rest of the team is blocked from making progress.

The other reason to break that focus into smaller chunks is to demonstrate the work in progress and seek feedback. If you only get feedback every other day, then the potential exists for a lot of rework and wasted effort – the longer the interval, the bigger the risk.

One additional thing to consider: it is important to look ahead, not just focus on the work at hand, so there is a need to fit refinement or replenishment into the schedule, as well as the daily stand up or other team coordination meetings. Without looking ahead all that focused effort could be for nothing if it doesn’t fit into the larger vision.