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.