Too Many Options

Teams collaborate to create high-quality products, and in order to collaborate they need many discussions… but how much discussion is too much?

Why do teams need to have discussions at all? Wouldn’t it be quicker if someone created a series of tasks and then the team just implement them? Well, it may be quicker to release something if everyone just did as they were told, but there are so many problems with this approach that I don’t have time to list them all! Some of the biggest issues are that it’s a single person’s understanding of the problem and the rest of the team probably don’t understand what they’re doing or why, which leads to a sub-optimal solution which the team can’t support without that one person’s involvement… but the “hero” of that project has no doubt been moved on to something new, set to repeat the “success” of that rapid release.

Instead of relying on a single person (who I’m trying to refrain from calling a single point of failure) Agile teams collaborate on all aspects of their work, sharing their knowledge. User stories focus on the Who, What and Why, leaving the team to work out How. The Product Owner sets the scene, explaining the business aspects; the development team should seek to understand their customer, how this story will impact them and what benefits it is expected to deliver. This discussion may take a while, but it’s usually the next step that takes the most time: deciding how to produce that deliverable.

Before starting a sprint, the dev team need to have a reasonable idea of what they will deliver. They need to have enough understanding of their approach that they can have discussions with the Product Owner about the size and scope of the work, i.e. the Negotiable part of INVEST. Teams can go overboard and spend too much time upfront; there will always be surprises during a sprint, so it’s better to limit the pre-work and put that effort into the sprint work. But if teams go too far the other way and do no preparation, then they miss the opportunity to discuss how much is “just enough” to meet the customers’ needs.

What happens if the team cannot agree on how to approach a story? The team could keep discussing their options ad infinitum, often called analysis paralysis, but at some point the team have to recognise that they are not converging so continuing to talk will not help. They could invite others to join the discussion, but that can lead to problems around impartiality; it also doesn’t help the team learn how to react the next time they reach an impasse. One helpful step could be for the team to conduct a spike, building a small proof of concept so they could compare a key difference. Perhaps a few spikes are needed in order to extract the best pieces of each approach – it’s rarely as simple as A or B, and more often is a hybrid.

One last thought: don’t just discuss ideas – draw them! Not everyone can draw (I’m terrible!) but a tool like mural.co makes it easy to use their built-in images or import graphics found online, so there’s no excuse to skip this important step. It’s too easy for team members to think they all agree on the approach, but making it visible will help bring any misunderstandings to light.

Inspiration

I’m suffering from blogger’s block this weekend – I can’t think of a topic for a new post. I’ve jotted down lots of small things but nothing that I could write more than a paragraph on. But if I dig a bit deeper, I don’t think the topics are the problem – I just can’t conjure up enough excitement to give any of them enough attention. It’s a good thing I’m not getting paid to update this blog – a job comes with expectations and timelines, and trying to be creative under pressure is just not conducive to producing something worthwhile.

So how do developers cope when faced with a deadline? I remember when I was a developer that I often needed to leave a problem overnight before I could start to find potential solutions. But that was back in the bad old days of waterfall or plan-driven development – someone sets a deadline (usually an artificial one) and then we had to meet it.

How is an agile approach better? Here are a few things which spring to mind:

Deadlines are rare, but when there really is a deadline then the scope is variable. It ought to be obvious but I’ll spell it out because this should have been true in waterfall too but rarely was – if you fix all three sides of the iron triangle (time, cost & scope) then the only variable left is quality. Time is fixed because of the deadline; cost is the equivalent to the number of people working on it; so if you don’t allow scope to change then you’re basically forcing developers to cut corners. [I’m ignoring the argument for adding more people when the deadline looms – Fred Brooks covered this many years ago.]

Rather than adding people when it’s too late, why not start with two (or more) people working together from the beginning? Most companies require code changes be reviewed because they know having a second person look at a problem helps improve the quality … but collaborating on the design (when you’re tackling the problem) rather than reviewing the code (when you’ve picked a solution and gone down that route) results in an even better outcome. Having someone to discuss ideas with is so valuable that solo developers often use “rubber ducking” (yes, talking to a rubber duck!) as a way to clarify their thinking.

I find visualisation to be incredibly useful, for myself and when I’m sharing a concept with someone I’m coaching. When a team is discussing their confidence in meeting their sprint commitment, I find a burndown chart can challenge the overly-optimistic (“We’ll get it all done on the last day”) and lead to conversations with the product owner about relative priorities, expectations, etc. When discussing a new feature and how it will benefit the end-users, sketching the user interface may help build a common understanding, and story mapping can build empathy with the customer.

Frequent feedback can help too. Sometimes the enormity of a problem can be daunting, so break it down into more manageable pieces and take smaller steps towards the goal. Getting feedback on a small part of the challenge can be stimulating and provide inspiration for the next steps.

Please leave a comment: how do you cope when you hit a creative block?

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.

Happy Birthday Agile

It’s twenty years since the Agile Manifesto was created in Snowbird, Utah. There’s obviously been lots of people posting about whether it’s still relevant, whether it should be revised, and so on, but I think it’s still important and applicable.

It starts with: “We are uncovering better ways of developing software by doing it and helping others do it.”
It doesn’t claim to be definitive; “We are uncovering” means we still have room to learn and improve how we do this. There are many “flavours” of agile, including Heart of Agile and Modern Agile, and some organisations develop their own take on agile (but “hybrid” agile-waterfall monstrosities don’t count in my book).

The next few lines (i.e. the rest of the manifesto) seem to be problematic for some people because they don’t fully understand “we value the items on the left more” – the manifesto’s authors even spell it out by saying “while there is value in the items on the right” and yet some people still think “Agile means we don’t do documentation”.

The first of these, “we have come to value: Individuals and interactions over processes and tools” is one I’ve see many organisations fail to grasp. It’s a long-running joke in the community that “installing Jira” equals “adopting agile”. I’ll refrain from ranting about Jira because the point is that any tool is not the way to become agile – it’s about people. I remember another coach saying “If a company doesn’t understand that it’s all about people then they don’t deserve agile”! 🙂

The next line, “we have come to value: Working software over comprehensive documentation“, is the one I see people misunderstand most – I wonder if that’s because so many people hate writing documentation? If you think about the two extremes, neither is ideal: documentation without software is clearly not a useful product, but also software with no documentation is rarely desirable (a simple tool with no user interaction might just about be ok, but even then anyone trying to fix/enhance the code is likely to benefit from some docs). That’s why we value working software more than documentation but not instead of.

I think the third line is easier to appreciate if you’ve ever worked on a waterfall project where we’re expected to blindly follow the documented specifications and hit deadlines, even if it means delivering something we know to be wrong. By valuing “Customer collaboration over contract negotiation” it means we would rather work with our customer, e.g. show them demos (or better yet give them something they can use) and get feedback early and often. If you don’t work with your customer and respect them, then how can you expect to keep them as a customer? (Ignoring monopolies/cartels, obviously; add banks to the list of rants I’m avoiding in this post!)

The final line, “Responding to change over following a plan” is closely linked with the previous one – in an ever-changing environment like software development there is always going to be change, whether that’s feedback from the customer “course-correcting” the direction of the product, or how the team works together (e.g. coming out of a retrospective), or the tools/technology that we’re working with. To ignore those changes is to say that we can’t learn anything during a project; I can’t think of a single instance where that’s been true, even working on tightly constrained legislation/standards-based projects – there’s always something discovered along the way. However, just like documentation, that doesn’t mean we work without plans – we need to understand where we’re heading and how we think we can get there… but we also need to revise the plan when things change. We need a roadmap (i.e. a destination and options for getting there) rather than a single route set in stone … but that feels like a future post 🙂