Just make a decision! Talk at South Wales Agile Group

I was asked recently to present at the South Wales Agile Group, and I decided to talk about a topic not often discussed – making decisions. I wanted to explore why teams are often terrified of making project decisions; fearing that the consequences are worse than actually making a decision in the first place.

I wanted to talk about decision-making within projects because I felt that whilst this is a problem that goes back a long way, it is mostly thanks to the implementation of Agile shining a spotlight on real bottlenecks that the problem has become more widespread.

The hardest decision I made in the 90's - Sega or Nintendo?

The hardest decision I made in the 90’s – Sega or Nintendo?

I talked about how some decisions are easy and some decisions are hard but, ultimately, if you have empowered the right people to make these decisions you have at least a fair chance of making the right ones.

It’s important to remember that a decision should only be hard to make if the consequences of that decision carry a lot of risk. You might consider the dreaded “what do you fancy for dinner?” question to be a tough one – but is it really? The biggest problem is not what to have, but spending so long thinking about an answer that you actually get no dinner at all. And this is true of project decisions, too. Often, teams will spend far longer than they need to making a decision that has minimal impact or importance for the bigger vision. What this leads to is less production and ultimately less delivery.

The reason I believe people still worry about making project decisions is due to the fear factor of getting it wrong. You can trace this back to the waterfall projects of old where all decisions were forced up-front prior to development and there was little, if any, room to adjust or change your mind as you moved forward. You had to make your bed very early on and then lie in it for the duration of the project.

The tyranny of waterfall makes making decisions feel scary

Fast forward to a more modern Agile approach to project delivery and one of the biggest differences is obvious. We’re encouraging teams to spread their decision-making throughout the life of the project, adapting to what is most important on that day. If things don’t work out the way they were anticipated to, it’s possible to very quickly move in a different direction. This approach takes a huge percentage of risk away from making a decision and, importantly, empowers the right people to make them.

Adopting Agile doesn’t make decision-making easier – it’s not a silver bullet. In some ways it actually adds the potential for increased mistakes as you’re encouraging more decisions to be made on a regular basis. In every area, Agile keeps the pressure on to encourage regular delivery.

The very best teams will thrive on the pressure, but the very best teams will also make bad decisions from time to time. What makes them the very best teams, though, is that they learn from bad decisions and improve themselves moving forward.

You can view the slides from my presentation here:
Just make a decision. It won’t kill you.

It doesn’t always have to be Scrum

When a company considers adopting an Agile approach to software development, more often than not they settle for Scrum almost immediately. This probably due to its popularity and online presence – especially considering the most recognised Agile bodies tend to sit on the Scrum side of the fence. Whilst Scrum is an absolutely fantastic framework, it certainly isn’t the only Agile approach that you can take – neither should it be the only one you consider.

Like anything else related to software development, there really isn’t a one-size-fits-all approach to how you structure your projects, despite what some people might tell you. One of the best things about an Agile approach is that it offers you guidelines rather than hard rules, so it can be far more flexible than a Waterfall methodology. There’s only so much flex that any given approach can offer, however, which is why Scrum isn’t the only option.

In addition to Scrum, you might want to consider one of many different Agile approaches, including the following:

  • XP
  • DSDM Atern
  • Kanban
  • Lean
  • Lean Startup

When considering formal Agile training, the options are surprisingly somewhat limited. Certified Scrum Master (CSM) is probably the most common certificate you’ll find amongst Agile practitioners – or people who want to be Agile – but again, its scope is limited to Scrum; not to mention to one specific role.

If you’re considering an Agile approach to software development, I’d recommend finding out which methodology suits your needs before you dive straight into the next CSM training course.

Training courses such as BCS Foundation Agile cover a much wider area, as their syllabus demands learning objectives around many different approaches, including those listed above. It’s a great way to find out what is available and what you think will work for you. It’s also a training course that carries a BCS certificate upon successful completion.

When the dust settles, Scrum still might be right for you. But given the complexities involved in changing your approach to software development, it’s better to know what options are available to you before picking Scrum blindly based on its name and reputation alone.

Delivering maximum value means being comfortable with unknowns

It’s interesting to observe that a lot of Scrum teams put a heavy focus on what the definition of done should be. A lot of time is spent meticulously ensuring that their customer has thoroughly defined through acceptance criteria what will signify a completed user story.

One element that often gets far less attention than the definition of done, if at all, is the definition of ready. Arguably it carries more importance than defining done because after all, if we don’t know when we should start then we have no chance of knowing when we are finished.

Agreeing as a team what the necessary requirements are before you can comfortably commit to writing your first lines of code is critically important before every project starts. It can be easy, however, to get so caught up on defining what ready means that you start to lose value in what you’re producing. Or worse still, wait and wait for that “perfect moment” to start that you deliver no value at all.

Andy Hiles visualises this perfectly with his graph:

photo1 (11)

Finding the sweet spot is key for maximum value delivery

It reminded me that more often than not, you need to get to a place where you’re comfortable with the unknowns that are ahead rather than try to understand everything before you deem something ready to work on. If your knowledge is too low however, then it’s going to cost a lot for the team to discover the details as they go. Similarly, if you spend too long mitigating the unknowns before you begin, you’ll bleed cost in other ways.

The sweet spot is somewhere in the middle. Know enough to be confident in what you’re about to embark on, but keep some of the decision making for when it needs to be made. Finding a comfortable level of unknowns (and a required base of known knowns) can push creativity and importantly ensure that you’re not waiting too long or wasting valuable time before you start sprinting. A team sat doing nothing is of course delivering no value at all, but comes at a cost all the same.

As a team, it’s important that you find a level of unknowns that you’re all comfortable with – but it is important you find that level and consider any risks that might be associated. For example, if your ideal definition of ready is that a technical specification document is present, but instead you have are solid user stories and technical people who you can ask questions of, ask yourselves if you can deliver value with what you have.

The chances are that you can. The chances are also that if you don’t accept a reasonable level of unknowns, you’ll lose a tremendous amount of potential value along the way.