Secondly, in more recent times, we have seen many companies start to favor an ‘Agile’ way of working. This is an altogether more collaborative approach, where a project team is empowered to test different ideas and exercise creativity. It is about trying things, breaking things, and learning from your mistakes. Often, you end up with a solution that is very different from the original brief, but that shouldn’t matter because you have reached your destination iteratively through intensive testing.
Both ways of working have their merits, but I think it is fair to say that in recent years, more companies are favouring Agile. The problem is that many companies think they are being Agile – when really what they are suggesting is just Waterfall by another name.
I’ve seen many stakeholders say: ‘I want to work in an Agile way, but, here are the deliverables…’ That is counter-intuitive. Actually, truly Agile software development is about reverse engineering the product:
‘Here is an idea of what we want. Now go and do the testing, gather the data, review the user experience – then you tell me how we deliver the final product!’
For Agile to work well, the original brief should be something to draw inspiration from, rather than follow to the letter.
You don’t have to use all the pieces
One school of thought around Agile is the idea of a ‘Scrum’. It is a way of working that I have always enjoyed. It gets you closer to all the different angles in a particular project, and can help you get the most out of your development team. It brings out different skill-sets and specialisms, and enables true collaboration. It creates a space where ideas can be shared easily, without the restraints of the waterfall structure.
A Scrum can also help smash the common misconception that you have to use all the resources and component parts available to you. In software development, that approach can be chaotic and overcomplicated. I like to compare it toWhat LEGO: You don’t have to use all the pieces to build something great. Likewise, a recipe can be adapted, refined – even fundamentally changed – but the result might still be delicious.
This way of thinking represents a fundamental change from the linear approach of Waterfall. Crucially it is about utilising the people in the team – their skill-sets, experience and creativity – rather than just the hardware and software tools at your disposal.
In this environment, the role of the Scrum Master is key. They are the bridge between a collaborative project team and the main stakeholders. They are responsible for building trust on both sides: Sometimes the team might need shielding from the stakeholders or they will lose focus. Likewise, stakeholders might need a gentle nudge to a new point of view.
At Mpya Digital, we often use Scrum Masters to help the client understand what they need. It can be a delicate conversation! The outcome isn’t always obvious at the beginning – and that can be frustrating for stakeholders who are investing significant money in the project. But, with software development, you cannot just ‘order’ a product and create it like a production line. There has to be an element of testing, and following the data.
And that is why I find the role of Scrum Master so rewarding. If I can successfully get a stakeholder to change their mindset, I can help them deliver the right solution, even if it is different from the one they first envisaged. That is better for the project team, better for the end users – and, ultimately, better for their whole organization.
Article by our consultant Olof Markstedt, working as a fullstack developer. He is loves working with people and improving processes.