Part 2 - The Untapped Potential of the Agile Manifesto
In my previous blog I covered the first 3 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 3, so next up is principle 4;
4. Business people and developers must work
together daily throughout the project.
This principle speaks of the close cooperation between members of the development team and the people for whom the software is developed. This may seem obvious initially, but frequently the exact opposite is observed in practice. The relationship is usually adversarial rather than cooperative — and that is why the manifesto provides a clear instruction — "daily cooperation throughout the project". Working closely with the customer is also the 3rd value in the agile manifesto value statement.
And, with this principle "daily" is also explicit. In Scrum, for example, this is addressed with the Product Owner role. A close cooperation between the demand side and the implementing side must extend throughout the entire duration of the product being developed. This also means the team should be involved from the very outset, when the ideas for the product are being considered.
5. Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
This principle represents a central point of Agility, one that also creates great difficulties in almost all organisations. That is, the demand for self-organising teams, and getting beyond the actions of "Command & Control" management (sometimes referred to as "micro management"). For many companies this means a complete change in their way of working, which ultimately requires a cultural shift.
Dan Pink, in his book "Drive: The Surprising Truth About What Motivates Us" identifies the motivation of knowledge workers (which, of course includes software developers) dependent on three main factors: Autonomy, Mastery and Purpose.
Providing self-organisation (autonomy) and trust to employees is in stark contrast to the management standards that were established in the last centuries. Those came from the industrial production era and ultimately manufacturing. These standards have become invalid in the age of knowledge work. Frequently you will encounter, even with software developers, mistrust followed by checks and control, which in turn leads to demotivation. Facilitate rather than manage is the interpretation of this principle for managers and leaders, which includes includes increasing transparency and self-regulation.
This requirement is not without consequences, because self-organising teams need less external management leading to more freedom and taking on tasks previously accomplished by managers. Establishing such an environment as required by this principle can be a large hurdle and could take months, sometimes years. Hence it is often recognised that many organisations need to undergo an "Agile Transformation".
6. The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Today, it is generally not understood as a fact that the most effective and efficient way to communicate is a face-to-face conversation. A large portion of our communication is none verbal, and only with face-to-face communication is the entire bandwidth utilised. This enables us to validate immediately whether what was said has been understood.
As a result many people tend to say, "ok then, Agile will not work with us because we have distributed teams...". The interesting point here is that this principle applies regardless of whether agile is adopted or not. The principle tells us that agile teams are aware of the efficiency in communication and try everything possible to speak directly with each other. When there is a necessity for telecommunications infrastructure to be used, one should at least ensure to have the highest possible bandwidth (HD video, HD audio) in place. Nothing is worse than a bad connection!! Moreover, establishing and maintaining a personal connection is still essential in building effective and engaging teams.
The challenges associated with knowledge work is, of course, more complex than the working world of the 20th century. Historically many processes were standardised. Their focus was not to utilise the collective intelligence of the individuals, but to maximise their manual labour. This type of work has been largely replaced by machines and robots at the end of the last century thereby providing human beings more freedom to explore the things that require more creativity and innovation.
In this age of knowledge work the focus now is to utilise collective brain power of everyone involved more effectively. This requires ideas and concepts to be transferred from one brain to another, but unfortunately we are unable to download the contents of the mind to one another!!.
This means we need to talk to each other and make sure people understand. As software development typically is so complex and we have to deal with so many ambiguities, it requires even more communication. Software development is frequently described as 50% communication! Or as Alistair Cockburn describes it, a collaborative game.
So rather than focusing on optimising the time it takes to write code, we should strive to ensure the code for the right thing is written.
An additional point worth mentioning here is a common misunderstanding of value statement 2 in the Agile Manifesto.
Working software over comprehensive documentation
The typical response to this value is "developing in an agile way means no more documentation!".
This is perhaps due to the confusion between documentation and communication. It is often thought that is something has been documented then it has been communicated - which is obviously not the case. Similarly, if something is [verbally] communicated it is not protected from being forgotten. Therefore, it is necessary to document, but the question is more around what to document and how much. Generally it is good to, first communicate and then document, but only as much as you don't want to loose or forget important information or decisions.
7. Working software is the primary measure of progress.
It may sound obvious that the primary measure of progress is working [functioning] software. However, what is important here is what we mean by progress. When working software, as mentioned in principle 3, is made available, then, and only then, can we call this progress. So progress is less about how many tasks have been achieved or how much time has been consumed, but what has actually been achieved. That is, "Working" vs. "Delivering".
Therein lies the significant difference to a more classical approach, where development progress is defined as how much of the original scheduled or budgeted time has been consumed. Further to this, and in the "agile world" there is a clear definition of what "Done" means and it is defined as a boolean value — a work package either done or not, there is no "almost done" or 90% done.
Documentation which describe how the software would be functioning if all assumptions which have already been made come true, are excluded from this definition of progress. Agile teams are only really interested in real artefacts which can be used for receiving feedback from a user or customer.
Still 5 more principles to go. I will cover them in my next blog.