In web and software development we all know what it’s like to finish a project and have it leave a bad taste with either your team or your stakeholders. Often left with thoughts of “if we’d just had time to slip that last feature in”, “I wish we’d understood that requirement earlier. or even worse “I wish we’d given that more testing time”. The problem is that as humans we’re incredibly good at this kind of thinking, but by using Agile processes to change this thinking both your development team and stakeholders alike will be a much happier bunch.
The Olympic games is different from most other types of sporting event in that there isn’t just a single winner, there are Bronze, Silver and Gold medal winners. Gold medalists have won the competition, Silver medalists have achieved a slightly lower achievement and Bronze medalists slightly lower still. Yet the psychology that affects these 3 athletes is totally different.
The athlete who won Gold is obviously elated. They’ve reached the top.
The Bronze medal winner is often just as happy, if not more so. They beat everyone but 2 in the world, and achieved a medal (They could have missed out!).
Silver medal winners have a totally different outlook though. You’d be forgiven for assuming that they may be as happy as their level of achievement – they did win a silver medal at the Olympics after all. Although the reality is nearly always different and is viewed more in the light of “they beat everyone in the world except one” . They strove to be the best and came off second.
This is called Counterfactual thinking and is something that often affects how a project is viewed in hindsight;
… Counterfactual thinking is a concept in psychology that involves the human tendency to create possible alternatives to life events that have already occurred.... These thoughts consist of the "What if?" and the "If I had only..." that occur when thinking of how things could have turned out differently …
This is subtly documented in the media every time the Olympics comes around every 4 years – more recently in social media in the form of a meme based on the US gymnast McKayla Moroney’s response to only bringing home silver.
If you take a look at her body language in this youtube video it speaks for itself. Unimpressed.
Why is this relevant to Software Development?
As Software Developers we often fall on one of two sides of the industry. We’re either writing software for a client or writing software for our company.
If you are working for a client, you usually give them a quote or an hourly rate and estimate on delivery. The client has a price they are willing to pay (this commonly has a high conscious weighting) and if your estimate falls within this they agree to your estimate, you go off and build something, often changing things 10 times along the way, and in the end the client is either happy or not. Their perception hinges on a number of things, but assuming that the project went quite well their happiness may still come down to whether they perceived that they had achieved what they wanted in the time/money they’d agreed upfront – regardless of whether something unforseen occurred.
The feeling of whether they had obtained the value they were looking for in the project often drives their feelings towards it, even though cash was weighted highly going in the project in the beginning other subconscious factors are at play.
In an internal product team things are slightly different, your business stakeholders or product manager also want to gain the same value, but they set out wanting to achieve a goal with the cash coming in with a lower weighting. Maybe their goal is to ship Feature X. Depending on whether you’re using Scrum/Waterfall/etc and how strictly you’re adhering to this, you may sit down and try and work out how long Feature X will take your team to complete, you may/may not have to convert this time into a dollar value.
At the end of the project they still use the same way of gauging the success of the project – whether they perceive they obtained the value they set out to and achieved their goal.
Regardless of the psychology behind it all, sadly the exchange of Goods/Services nearly always uses the common currency of money, but software development is about delivering value to a business, and guess what?
The Exchange rate between Money => Value can be quite subjective.
Couple this with the dark art of developer estimation and you can see why people sometimes feel negative about a project. The second money and time come into it things get complicated.
Why product teams and Agile practices help a lot
I’m not about to suggest that we should all throw away thinking about the cost or time to deliver software. With the proper use of Agile methodologies, there are still ways that a team with a normally positive and successful result can work better to achieve a perceived positive outcome in the eyes of stakeholders/clients.
What I think helps are three things Agile brings along for the ride:
- The frequency and amount of involvement Agile suggests stakeholders should have (frequent low latency feedback).
- The way Agile development teams deliver iteratively, showing progress.
- The way they think about their progress and the future.
Agile teams aim to deploy early and often, something I am extremely passionate about.
By deploying often, your stakeholders get a feel for progress and delivery constantly and this lets them see it take shape – and also allows them to both make course corrections and create scope creep change priorities. The former raises the chance of a positive outcome as they dodge having to make any last minute emergency phone calls up your company hierarchy because for some reason the brief has been totally misunderstood. The latter also allows stakeholders to feel like the project played into their needs even if their needs were changing, which if done successfully can make a project almost feel like it had a “free bonus” even if it took longer or cost more cash.
Another way that Agile processes affect team/business/stakeholders is how it subtly changes how they measure progress. Often progress is measured in small chunks that have their expectation of success reset regularly at the end of every sprint or deployment. This means that not only are you and your team winning an Olympic medal every 2 weeks with only your last Olympic performance to compare to, this also means that the project doesn’t get negatively bogged down by a few bad weeks.
More importantly though, by using iterations you are always looking forward.
You don’t get so caught up with the “what could have been” and more about “what are we going to rock out next”. This is incredibly powerful as its infectious and spreads internally within an organisation and also over to a client as they see that you have total buy in to their project’s success.
Teams that deal with external clients can also look to take advantage of Agile practices by treating their clients as partners rather than customers. Be clearer about your costs and release iteratively, updating them on project spend more regularly.
By using not only Agile practices, but almost more importantly the shift in thinking that Agile can bring to a development team, you’re able to be more productive and positive in your delivery, giving everyone a Bronze medalists feeling about the project’s results – You could have failed, but instead you nailed it and made it to the podium.