The Agile Manifesto is a collection of 12 principles that were defined to address the challenges faced by software developers. I expand on principles 9 to 12 in this final post.
9. Continuous attention to technical excellence and good design enhances agility.
It is always easier to develop on top of well designed and structured code. Low quality code contains problems such as bugs, logic workarounds and a lack of good structure. This only increases the technical debt when more work is done.
It is important to start on day one with great code and then refactor as necessary to keep it good. Agile promotes constant small iterations to functionality. This means that it is vital that refactoring is given an important place in the product roadmap.
It is also a good idea to enforce coding styles. Creating a full style guide to describe how code should be structured and presented is something to aim for.
10. Simplicity – the art of maximising the amount of work not done – is essential.
This principle is the key to making sure that you obey the idea of constant iteration and delivery in Agile. There is a tendency for software teams to want to deliver everything to the user. This is particularly true of designers and UI experts.
With this principle we are encouraging the idea that ‘less is more’. We are making sure that we only deliver the bare minimum. This includes features, lines of code and dependencies.
Sometimes, at the start of a project, this is fairly easy. There is a requirement to get something released, so the bare bones is all that can be achieved. As the project advances it is important to continue asking the question “Am I adding value?”
11. The best architectures, requirements, and designs emerge from self-organising teams.
This is probably the scariest and most controversial of the principles. It suggests that a team consists of no real experts or specialists. It allows the members to experiment and learn from its mistakes.
Those who do not totally understand Agile probably believe that this is a recipe for chaos and disaster. It is important to remember however, that these team members are high level professionals who have to deliver often. The Agile methodology will not let them disappear down untested paths for months on end, making huge mistakes. They will not deliver and that is not Agile.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Looking back at how you have worked and what successes and failures you have had is vital to the continuous improvement of your team. Having a fully Agile team, where the members have respect, commitment and buy-in makes retrospectives easier and very rewarding.
I love our demonstrations and retrospective ceremonies. They are honest, forthright and often great fun. I am constantly surprised and enlightened by the points that emerge from our discussions.
The key point in this principle is that you act on the points that are raised. A team will become disillusioned if you encourage their feedback and then do nothing about it.
The idea of a retrospective is to figure out what you can do to make your development processes more agile, and that can only be a good thing.