14%20Final%20Model%20d_edited.jpg

AGILE MOUNTAIN BLOG

Thoughts worth sharing...

Search
  • Russell Hill

Part 1 - The Untapped Potential of the Agile Manifesto

The Agile Manifesto is a great source of inspiration for anyone wanting to pursue agility in their organisation, but it is often misunderstood. If that isn't bad enough, there is an incredibly powerful part of the manifesto which is not only overlooked, it is usually ignored!


First up, in what way is the Agile Manifesto misunderstood? Well, only last week a team member said, "We are agile now, we don't need to plan. The Agile Manifesto says so...".


He was referring to 4th value statement, which reads;


"Responding to change over following a plan"


It says "...over following a plan" and not "...instead of following a plan". His interpretation of this value statement was simply that we must always respond to change, and therefore we can never do any planning!


The Agile Manifesto, or to give its correct name "Manifesto for Agile Software Development", was created in 2001. It's a simple values statement which reads as follows...


We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:


Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


That is, while there is value in the items on

the right, we value the items on the left more.


That last sentence seems to be overlooked by most people who encounter the manifesto for the first time. It re-enforces the message that we value the statement on the left more than the statement on the right. It does not state we only do the statement on the left and stop doing what is on the right!


Another way to think about the 4 values statements is to consider that we should do the things on the right, when in doing so it strengthens or enables the things on the left. So for example, creating processes and/or tools which strengthen individuals and interactions is a positive thing and should be encouraged. However, we should not create processes and/or tools which prevent or hinder individuals and interactions.


There is much more to say about this values statement, but I will save that for another time. In this blog I want to focus on the part of the agile manifesto I found to be the most powerful, but largely ignored - the untapped potential!


On the agilemanifesto.org website, under the main 4 value statements, is a list of links. Depending on the screen size, these links sometimes cannot be seen unless the viewer scrolls down. Here lies a link to the signatories of the manifesto, and an about page, plus lots of links to the manifesto in many languages. However, hidden in plain site is the link "Twelve Principles of Agile Software". Click on this and there is a comprehensive set of principles providing a guiding light to help you achieve agility. Like all good principles, they don't tell you want to do, they are not practises, but that makes them even more powerful.


Practises alone can be very limiting, because they depend on how they are interpreted. Copying them because they worked in one organisation does not mean they will work in another - the success of practises is dependant on context. Principles however, are more robust because they are not context specific and you can experiment with, or create your own practises, as long as the underlying principle is understood and followed.


With that in mind, lets take a deeper look at these 12 principles. Understanding them is key so I will split this blog into several parts covering a few principles at a time.


First, let's have a look at all of them - the Twelve Principles of Agile Software are;


1. Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.


2. Welcome changing requirements, even late in

development. Agile processes harness change for

the customer's competitive advantage.


3. Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter timescale.


4. Business people and developers must work

together daily throughout the project.


5. Build projects around motivated individuals.

Give them the environment and support they need,

and trust them to get the job done.


6. The most efficient and effective method of

conveying information to and within a development

team is face-to-face conversation.


7. Working software is the primary measure of progress.


8. Agile processes promote sustainable development.

The sponsors, developers, and users should be able

to maintain a constant pace indefinitely.


9. Continuous attention to technical excellence

and good design enhances agility.


10. Simplicity--the art of maximising the amount

of work not done--is essential.


11. The best architectures, requirements, and designs

emerge from self-organising teams.


12. At regular intervals, the team reflects on how

to become more effective, then tunes and adjusts

its behaviour accordingly.



In their original form, they are not numbered. I have added the numbers so I can reference them in this text, however the numbers do not imply an order of importance or significance.


Lets take a look at principles 1, 2 and 3.


1. Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.


Immediately, this tells us our top priority is to satisfy the customer - "Make the customer happy!". We can achieve this by delivering valuable software early and regularly, that is continuously. However, the essence lies in the word "valuable". Valuable software is software the customer can use which solves a problem, or perhaps part of a problem.


Valuable software is often confused with the delivery of working or functioning software. Valuable means more than just working. It must be useful, helpful, save time, save costs, help create revenue or solve a problem. Have you ever installed software that was "working", in the sense of it did not crash, but was not useful? You probably removed it again immediately, right?


This principle emphasises the early and frequent delivery of "valuable" software. Contrast this with a more traditional process such as waterfall, where the process will deliver value quite late, typically in large "big bang" deliveries.



2. Welcome changing requirements, even late in

development. Agile processes harness change for

the customer's competitive advantage.


"...even late in development?" How does that feel for a team? Your initial thoughts are probably not good! And mostly because late changes always result in a lot of work, or more specifically, rework, and an increase in risk and costs. In general, the later a change is worked on the more costly it becomes - but it doesn’t have to be this way!


The principle says we should welcome changes and this can mean only one thing. Keep the software changeable! And in agile development there are many practices that allow software to be changed with confidence. These include things like test automation, unit testing, continuous integration, refactoring, test driven development, etc...


This principle is also connected to value, because changeable software is a valuable long-term asset for a company. Software that is difficult or expensive to change, is no longer economically viable, every little change will cost vast amounts of money or may even be no longer possible. The only true statement we can definitely predict about the future of software, is that it will need to change! Otherwise it is already dead.



3. Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter timescale.


Here we find the word "working" in front of software and this highlights the subtle difference between the first and the third principle.


With "working software" it is meant the software must be executable, tested software, which is free of known defects. This is not necessarily software that is "valuable" in the sense of principle 1. However, when multiple [vertical] slices of working software are integrated together, at some point we will get "valuable" software that can actually be used by the customer in a productive way.


Valuable software has functionality which when used by the customer will provide something useful and of value. An example of valuable software could be part of a system which customer orders can be created and processed. The business can use this software and there is added value. However, the functionality of creating orders alone is not of value if a user can not do anything else with it. But at least it is "working" and allows us to receive feedback.


To distinguish between principle 1 and 3 we can look at it this way;

  • An iteration (or a "Sprint" in Scrum) typically delivers "working" software - principle 3.

  • Valuable software is typically the result of a release, which includes integrated pieces of "working" software. Valuable software is thus a collection of "working" software to an extent that customer or value is created. i.e. it becomes "valuable" - principle 1.

Ideally an iteration delivers both "working" and "valuable" software, but if not both then most definitely "working" software.


These are the first 3 principles. I will continue the remaining principles in the next blog.

14 views0 comments

Recent Posts

See All