Part 3 - The Untapped Potential of the Agile Manifesto
In my previous blogs (part 1 and part 2) I covered the first 8 principles of the "Twelve Principles of Agile Software" as listed on the agilemanifesto.org website. Here I will continue with an explanation of the remaining principles.
We had just completed principle 7, so next up is principle
8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
The pace at which a team can deliver functioning software is determined by the team and is therefore a measured result, not a demand!
Many planning approaches in classical development use expert estimations to determine the duration of the work in order to identify a delivery date. Often these are combined with scientific approaches to incorporate average values and buffers. If during the project it transpires that the initial estimates and assumptions were not correct, stress becomes a factor, since the promised delivery date is still expected to be met (estimates quickly turn into commitments). In order to meet the date, compromises are made with quality - it is the least visible in the short term. These compromises then lead to software which becomes difficult to change — see principle 2.
Agile teams develop sustainably. This means the quality is never compromised and the speed at which the team can develop high-quality software is regarded as a fact. This can only be changed in the medium term through improvements in the development process. Therefore the planning of a development project must be adapted to the reality of speed, and not vice versa!
Everyone, meaning developers, clients and sponsors must agree to maintain a sustainable pace of development. A quick indicator as to whether you and your team are working at a sustainable pace - as yourselves if you could maintain the current pace that you have experienced over, say the last 3-4 weeks, indefinitely. If not, you should consider this principle more closely.
9. Continuous attention to technical excellence
and good design enhances agility.
With this principle there is an emphasis on two things equally; on the one hand it’s about people's ability ("Technical Excellence") and secondly it's about the product being kept in "good shape").
The former demands that there is continuous attention to the team's technical and technological abilities. With "technical", software engineering is meant techniques that are particularly helpful in an agile environment, and their expertise in the technology they use. These include techniques such as test-driven development, continuous integration, collective code ownership, pair programming, but also the correct treatment of versioning, and code repositories etc.
This principle speaks of continuous learning as a fundamental part of Agile. What do athletes do to stay "excellent"? Ongoing training! Agile teams and organisations need to do the same. They live the principle by seeing learning and training as part of their daily life. Some good ways of doing this are, for example, "Coding Katas" or "Coding Dojos" and agile organisations treat this as part their normal daily work.
The second part of the principle is about the ongoing focus on "good design" — which means constant transparency to the quality of the product design — including the architecture and internal quality, and ultimately, the changeability. Agile teams not only have technical tools to understand the basis of continuously measured indicators to determine the state of the product, but they also understand that measured data is only one perspective of the product — therefore it is necessary but not solely sufficient. Agile teams have established ways to inspect their product from the inside (e.g. through joint code reviews) on a regular basis, and whenever they determine that something is not correct they take appropriate action.
10. Simplicity--the art of maximising the amount
of work not done--is essential.
These words caused much confusion amongst developers and were repeatedly thought to be wrong. It’s not just about simplicity, which Albert Einstein considered essential; "Everything should be made as simple as possible, but not simpler." Developers in particular have a strong desire to strive for the perfect solution, thereby optimising at an early stage. And it is exactly this behaviour pattern that can be fatal, since the desire for perfection leads us to implement more complex things than necessary.
Using the pattern of "Re-Use" we have learned to solve problems in code so that we can reuse a solution to solve a similar problem. Unfortunately we are not able to adequately anticipate future problems precisely; hence the production of software for future re-use does not work effectively. This results in more complex code, which is even more difficult to understand and adapt, paradoxically, making it even more difficult to re-use. By contrast, simpler code created only for today's use, can be refactored as needed and therefore make it significantly more suitable for future re-use.
Further, the same applies to features which we implement or even better, to the extent to which a feature is implemented. Does every feature of our software really need to be "a perfect solution", or is there a simpler possible alternative? This principle therefore tells us to consider the code and features as simple as possible, but not simpler! Developers know this under the KISS principle ("Keep It Simple, Stupid!") and the YAGNI principle ("You aint gonna need it").
11. The best architectures, requirements, and designs
emerge from self-organising teams.
Even with this principle I often see many misunderstandings in teams. The emphasis is on the word "emerge". The principle tells us that the best architectures "arise", and the best requirements and designs also "arise" — meaning they grow over time from self-organizing teams. Maybe not after the first time or the second time, but after some time the best solution will emerge, and changeable software supports this paradigm. Many organisations still believe in the old fad, that the software architecture is created by a computer science genius, upfront, handed over to the teams which they then have to implement.
Typically the requirements for software only build up over time, and contain more and more precise details as we go, or as we like to say "just-in-time". Research has shown that, when asked, what portion of features were known upfront in detail and what portion of the features emerged over time, around 60 - 80% of requirements emerged over time.
12. At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behaviour accordingly.
In the twelfth and final principle, the importance of regular inspection and adaption is stressed. Successful agile teams regularly reflect on their behaviour and make adjustments accordingly. This also means the process of software development is adjusted too. In Scrum, this principle is manifested with the retrospective meeting held at the end of a sprint. But in other forms it is simply stated that we should implement feedback loops at regular intervals.
So that is all 12 principles and an explanation of each. So why is this an untapped potential, you may be wondering. Well that is going to take some time to explain, so I will put it in the next blog post - the last one on this topic, I promise!!