Agile Scrum development.
It all makes perfect sense in a textbook or following an inspirational seminar talk.
It is a revolution, so simple and easy that software almost writes itself.
We have all been there, only to come back to the office and become disillusioned with reality due to hard deadlines and project managers pressing you for estimates on how long something is going to take.
While most companies aspire to be Agile, or even claim to be Agile, very few of them are in the purest sense of the twelve principles of the Agile manifesto. As a developer this reality can be frustrating and distracting.
The aim of this blog is to try and demonstrate that right now, as others become acquainted with the principles of Agile, this reality is “normal” and will be for some time in most businesses.
The primary aims of any company are to make money and build a loyal customer base through tangible value in the products they sell. It is very often the money part that is the source of conflict between the pure Agile world and reality because the conception is that Agile teaches us to forget about the money bit.
In reality developers cannot disassociate themselves completely from money or time. We can however take steps to avoid this conflict as much as possible.
To do this we need to take a step back away from software development.
I like to think of Agile as an ideology rather than just a process to follow for developing software. A way of working that logically breaks a problem down into granular pieces of real value for the benefactor of the solution – the customer.
It promotes feedback and engagement, a close working customer relationship, flexibility and speed whilst providing a team with clear attainable objectives – this is a brilliant way of working in general, not just for developing software, and it is something everybody within a business can get behind.
By coordinating as a team with the customer at a high level a fixed scope and hence fixed budget and fixed time can mostly be achieved through a feature roadmap.
When producing this roadmap, it is important to be honest with estimations. Don’t be too optimistic. Talk through the requirements in detail to make sure you understand the complexity of what is required. Aim to under deliver rather than over deliver, you can always pull functionality forward if there is capacity (and doing things early really impresses customers).
Once the feature roadmap is produced it constitutes the high-level objectives for each release. The team should then set about breaking the work down further to create a release backlog that can be tackled in the more traditional Agile scrum fashion without the distraction of dates and cost – instead working in sprints, story points and goals or commitments.
Burn down should be closely tracked to ensure the team remain on target to achieve the release constraints and provide management with early warning should things not be going to plan. The period between releases should not be too long, if this period is too long the feedback is too late and the customer becomes disengaged.
Whilst it is inevitable that there will be last minute crunches to meet a commitment or the functionality delivered may not always live up to expectations, in my experience working in the way I have described will go a long way towards helping build trust within the business and with your customer.
It is this trust that is a direct output of working in an Agile manner as the customer receives frequent and relevant value and the development team deliver on their commitments.
Ultimately as trust becomes stronger the money aspect becomes less significant and less of a source of conflict and a step is taken in the direction of Agile utopia.
About the speaker
Robert Talintyre is a Senior Systems Engineer at Cubic Corporation based in Stockton.
He's worked in software development since graduating from university in 2003.