Zupa adopted the Agile model early and shares the benefits of developing under Incremental structures with our clients.
We’ve previously described the opportunity our Agile scrums and stand ups bring, from business analysis through to pair programming, test cycles and deployment. This time, we’ve asked Guest Author James Privett, Software Developer at Zupa back to the blog to describe the true value of Incremental frameworks.
“With career experience of various development models, I’ve found that companies opting into the Agile way – principally, being flexible to change – fair better than those that don’t. In my opinion this maintains a continual source of ‘truth’. At Zupa, we also choose to work incrementally. This was an entirely new way of working for me and now, a year later, its become the best software creation process I’ve experienced.
What does it mean to be incremental?
Simply put, a vertical slice of functionality (and where required, UI) can be produced, tested and demonstrated to stakeholders in a short space of time. This work can be critiqued, scrutinised and reviewed to produce vital feedback. A pragmatic approach allows us to develop components whilst being confident that we are heading in the right direction – without wasting time to perfect elements that suffer from mission creep.
Let’s make something…
Taking a real-world engineering process example, let’s say we are given the requirements to;
‘Build a vehicle that can take the user from destination A to destination B whilst having enough space for four additional seats’.
This sounds like a car – not exactly mind blowing; however if we were to develop this product using the non-incremental Waterfall method, this would be working under the assumption that the requirements are perfect. In this case, the engineers and the stakeholders are all working under the same assumption, and that nothing can change in the process. The result? poor communication and planning with only the deadline in mind; and when that deadline is met, we shall have a car. Subsequently, the stakeholders would be confused (and probably not happy) when, due to limited and misunderstood requirements, a van with enough room to carry four chairs in the back is produced instead.
In all the ways to explain structure, perhaps the best and widely accepted illustration is from Agile & Lean coach, Henrik Kniberg;
This is my tweet pic.twitter.com/8fK3goa5ge— Henrik Kniberg (@henrikkniberg) January 26, 2016
A small advance on citation – a link to the Author’s tweet. Thank you Henrik Kniberg!
Let’s make something better…
We could approach this in a way whereby we make small incremental steps, so that modular parts of functionality can be demonstrated to stakeholders and conversation can take place. Perhaps it is decided that the vehicle should be able to have the roof down if it’s a nice day. We can welcome this change as part of the way we work, however, to achieve that we would have to take time out of doing something else – such as having seatbelts or being able to use its brakes. We can demonstrate that this can be a ‘nice-to-have’ feature that can be made in the future.
So, we have gathered further requirements in our planning stage that has allowed us to ascertain that we are building a car (and not a van).
We agree with stakeholders to demonstrate small parts of our car’s systems as it is being made, keeping us on the right track whilst further developing solutions as a team.
We develop our (massively simplified) car in these logical steps:
- We have a Car! With seats!
We can show these steps to stakeholders once completed, for approval and/or scrutiny until the car is complete, and it can be tested. This immediately presents some problems. Each step provides little value in that the stakeholders must imagine the completed step within the sum of the whole, incomplete car. Showing them four wheels for example won’t really demonstrate anything, it is not until the very end of the process when the car works that value is achieved. This would probably become frustrating for the stakeholders very quickly, which in turn would only have a detrimental effect on the team.
This way of working is not as stoic or open to failure as The Waterfall Method, but it is brittle as it will inadvertently encourage assumptions and guesses, allowing simple mistakes to fall through the cracks.
Let’s make something well…
We aim to provide value at every step, incrementing functionality and complexity, and maintaining testability as we go. So we could say that our two main goals are;
(A) ‘We want to build a vehicle that can take the user from destination A to destination B’.
(B) ‘We want to have enough space for four additional seats’
In prioritising development we can say we are going to concentrate on requirement (A) first. Instead of building the constituent parts of the end goal we could build simpler solutions that achieve requirement (A) but build upon themselves in functionality at each iteration. So, our development cycle output could look like:
- Build a skateboard
- Develop into a scooter
- Morph into a bicycle
- Then into a motorcycle
- Then into a car
- Finally, into a car – with four additional seats.
The point here is that developing something incrementally means adopting the right mindset that allows each step to produce value to the stakeholders. The analogy with steps 1-4 is that although none of them are the end goal – that is okay because they are developing in complexity whilst going in the right direction, testable at each step – they are ‘fit-for-purpose’.
I have found that developing in this way has, over time, created an additional benefit of deep understanding between developers and stakeholders. This is especially evident when developing functionality within niche system domains. I have recently been working to make finance based software components and interacting with stakeholders that know how finance truly works at a technical level is key to team understanding. Presenting the work in progress at each step enables considerations to go both ways, enabling conversation as well as room for making and unmaking mistakes. This ultimately leads to happier developers, happier stakeholders and better quality work.”