This is the third part of the blog series were we discuss the 12 Agile Principles. In this post we will focus on principles 7-9.
7. “Working software is the primary measure of progress.“
Early in my agile career, when I was still a project manager with agile tendencies, I took over a project that was ‘60% done’. When I probed a little I found out that the 60% done meant that 60% of the budget had been spent, the project was far from done. In fact the only progress made on the project was a requirements document, and even that wasn’t complete.
The first thing I did was take was to take what requirements had been gathered and break it down into a story map so that we could get an idea of where we could start developing some working software. Story maps are a great way to figure out how to slice up an idea into chunks of work that deliver end to end value rather than working component by component.
If we can break our work down in such a way where we can deliver features to the customer, and start gathering feedback so that we can tune and adjust, then we can say we are starting to make progress, measurable progress. Whilst a large requirements document is work, and some of it valuable, the amount of waste generated by trying to figure out everything up front is incredible.
Working Software isn’t the only measure of progress, but it is the most important one. Nothing else matters if your software doesn’t work.
8. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely..”
Sustainable development pace by the delivery team is an obvious thing that jumps out with this principle. If your people are working lots of long hours, eventually its gonna hit you in the quality of work being delivered.
how often do you think about the sustainable pace of your sponsors and ‘users’ (I dislike using the term user in this context). If sponsors are constantly chasing the new shiny thing and pushing more and more work to the team, then the team will be overloaded and it will be difficult to maintain a sustainable pace. If your sponsors can work at a sustainable pace, and have focus, then it makes it easier for the team to also have a sustainable pace. One way of doing this is to introduce a kanban system where limiting the WIP at the early stages of the process, creating an artificial bottleneck early, helps keep a sustainable pace throughout the process.
If the end customer, or user, is receiving new updates on a daily basis, then they can be overloaded with the amount of changes happening and be turned off. There is a fine balance between releasing to end customers in small batch sizes often, and delivering value that they can consume regularly without feeling overwhelmed.
9. “Continuous attention to technical excellence and good design enhances agility.”
I find that this principle goes almost hand in hand with the previous principle around sustainable pace. Most teams want to give attention to technical excellence, but pressures put upon them mean they generally aren’t given the time they would like.
Building good products takes time. Building quick dirty throw away solutions in order to learn are quite quick. Problems occur when the quick and dirty are then taken on face value as a good product, put into production and then asked to be built upon. This leads to spaghetti code and the demise of maintainability. Eventually you have to give up and re-write the thing from scratch.
Another example of where this is a problem is down to affording the team the time to put together a proper infrastructure around automation, of tests and deployment. Again this takes a little time, but saves an exponential amount of time in the long run, so it depends on the lifecycle of the product.
These things are hard to do, and it’s difficult to find the right balance between ‘building the thing right’ and ‘building it fast’. Both are important factors to take into consideration for your unique context, and it’s all too easy to slip into the mindset of ‘get it out quick’ and not grasp the consequences until it’s too late.
Thats the end of this blog post, as always we look forward to your comments below as we muse over the final 3 principles in the next blog post coming soon.