Fixed Scope, Time & Cost
When I transitioned from being a Project Manager in a digital agency to becoming a Scrum Master at a non-client-facing Fintech company, the change was much larger than I ever expected. The guys at Crunch worked in a completely different way to how I was used to, and at first, I was wondering whether I would be able to do anything to help them improve, as it already seemed awesome here.
That was two years ago now, and since then I’ve worked with my teams and the organisation to create something that I now feel is a huge step forward. When I look back at when I started, the teams here were completely different, whilst most of the original team members remain. It makes me laugh when I think about my mindset when I first arrived.
At the digital agency, we very much worked in a faux Agile fashion, ultimately much closer-aligned with the Waterfall methodology, whereas Crunch were definitely on the journey to becoming an organisation that embraced an Agile mindset. This was my first true exposure to this way of working.
The learning curve has been steep, but far from insurmountable. One of the most significant learnings was how to approach a project without falling into some of the traps I had previously. The biggest one was avoiding having a fixed scope, timeframe, and cost associated with a project.
The big trap
One of the biggest shortcomings of many companies is that every project they undertake has a fixed scope, timeframe and cost. This is fine in a “simple” environment, but rarely does it turn out to be this way. Ultimately, a majority of projects turn out to be “complex”. I could go into more details here but I’d just be doing a shoddy job at explaining the Cynefin framework.
A large majority of the time, having these three things fixed will lead to hard decisions to be made later down the line, whilst a lot of heated and frank discussions take place. It very rarely turns out well. This can be for hundreds of reasons, but a few include:
- The deadline has to be moved
- The scope has to be reduced
- Additional developers have to be acquired
- Developers have to work at an unsustainable pace to deliver it in time
- Quality is compromised.
All of these things lead to team members and stakeholders becoming dissatisfied and demoralised, which can result in significant long-term consequences. For example, if the quality is compromised, this can lead to a product that doesn’t hold together very well and needs a lot of post-launch support just to keep it standing. This is very frustrating for everyone, since more money has to be spent just making sure it works, rather than being able to continually improve it.
When I was a Project Manager, we often had all three of these fixed, which led to me moaning at the developers when things were taking longer than expected (if any of my ex-colleagues are reading this, I apologise), whilst having to break the bad news to the client — usually by giving them another optimistic delivery date.
The amazing yet rare feeling of achieving all three was always short-lived, as we soon came to terms with the fact that a significant amount of time was required to address the compromised quality. In hindsight, I’d have rather told the clients that we weren’t going to deliver their project on time, but instead reassured them it was going to be of high quality.
Nowadays I spend a great deal of my time educating our stakeholders and scrum teams about why we need to avoid being in a scenario where all three are fixed, and the issues this causes. Of course, occasionally we fall into the same trap and make the same mistakes, but we learn from them and become better as a company in the process.
We have addressed this in a variety of ways at Crunch. This includes us being more transparent to our stakeholders and providing more realistic metrics. Using burnup charts and probabilistic forecasting helps with this.
Another is by promoting incremental delivery to the Product Managers and stakeholders. This ensures that for everything we deliver we’re improving the experience for our end-users, which means that we don’t follow an all-or-nothing approach. On multiple occasions, we haven’t completed everything that was initially planned/scoped out because we felt it was more beneficial to our users and/or the business to move on to another workstream.
Doesn’t Agile say you can’t have a fixed scope?
It’s a bit of an urban legend that in an Agile environment you cannot have a fixed scope. You can even have a fixed deadline. But in this situation, it has to be accepted that either the cost (this carries several risks though) or the quality needs to remain flexible, with the latter always the last resort.
Most importantly, however, it’s important to be open to change. Almost always throughout a project, a new great feature is thought of, or a feature is no longer required. It would be a massive shame to be unable to respond to this.
Consider a fast food burger restaurant. They have to give you a burger (which always has to be the same and of good quality) within a certain amount of time to meet their targets. They are able to achieve this because they have invested a lot of money in their infrastructure and staff to allow this to happen. Saying “Sorry, you haven’t got a bun because we were running late” wouldn’t sit well with anyone.
“But surely a fast food burger restaurant is a simple environment?” Yes, that is true, but when they first started out it was complex and they had to keep experimenting to find a solution that worked. All of the experiments they undertook contributed to making it a simple environment, so now they make it look really easy and deliver consistent results.
Conclusion
Overall, when working in a complex environment, the organisation has to understand that not everything can be predicted ahead of time. By forming solid relationships and being trusting of your teams can allow change in a non-destructive way.
Transparency is always key. By being transparent, whether through conversations or useful metrics, understanding develops and allows for healthy discussions on progress to allow change to happen.
Change can include working towards making a complex environment more simple. This can be done in a multitude of ways but ultimately can make things more predictable. Making an environment too simple can remove the opportunities to innovate, though, and can lead to a lack of motivation within a team.
Hopefully, from reading this, you can take away something and apply it to the environment you are in. We would be interested to hear about how you do things, so please let us know in the comments.
If you have enjoyed reading this, feel free to give this a round of applause and follow us, so you will be the first to know about any future posts that we publish.
Written by Samuel Catt, Scrum Master at Crunch. In his spare time Samuel is a competitive English Pool player taking part in a number of competitions.
Find out more about the Technology team at Crunch and our current opportunities here.
📝 Read this story later in Journal.
👩💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.
