The Agile Manifesto gives us four statements which form the underlying ideas behind all the Agile methodologies. It also gives us 12 principles behind the Manifesto which go to further help us understand what it means to be Agile and guide us in our decision making processes.
Agile has become a noun and a verb. To be agile is to embrace, live and let your lives be guided by these agile principles. It can be taken a lot further than just software development. HR and accounting departments are also embracing agile practices and even whole companies from the CEO down are being run in an agile way (Travis Perkins, Nokia, BA Terminal 5).
We will discuss Agile from first principles using my own experience with developing software for our examples.
The Agile Manifesto
The four statements in the Agile Manifesto are:
- Individuals and Interactions OVER processes and tools
- Working software OVER comprehensive documentation
- Customer collaboration OVER contract negotiation
- Responding to change OVER following a plan
The balancing statement
It is very important to note the following line in the Manifesto:
That is, while we value the things on the right, we value the things on the left more.
That last statement clarifies and balances Agile and becomes the scales on which each decision can be weighed against. Time and time again we will come back to that last statement.
The principles behind the Agile Manifesto
The 12 principles behind the Manifesto are:
- Early and continuous delivery of valuable software
- Welcome changing requirements for customer advantage
- Deliver working software frequently
- Business people and developers must work together
- Build teams around motivation with support and trust
- Face to face conversation is most effective
- Working software is primary measure
- Maintain a sustainable pace of development
- Continual focus on technical excellence
- Simplicity to minimise wasted work
- Self-organising teams deliver the best results
- Reflect regularly, tune and adjust to become more effective
These 4 statements and 12 principles form the building blocks that go into XP, Scrum, Kanban, LEAN and SAFe (Scaled Agile Framework).
The four statements
Individuals and Interactions OVER processes and tools
The first statement says that the people and the interactions between people are more important than any process or tools we might use to achieve our goals.
Coaching teams has shown me that people can achieve anything and overcome any obstacle if the dynamics in the team are right. Conversely, a team whose members are in a negative state of mind and complain about their workplace find the simplest of challenges almost impossible and a state of despair quickly develops.
Simon Powers
Therefore, coaching the team to be a better team and fostering an environment where the team members can speak freely without fear and with the courage to try new things improves interactions and creates inspiration, motivation, self-organisation and encourages the team to strive for excellence.
Putting people first
This principle appears throughout all Agile practices in some form or another and sums up why agile is so special in the world of business. Putting people first is something we have heard from HR departments for years but never seen delivered. Agile puts people first. How cool is that?! It is the first statement in the Manifesto. Everything that follows in the Agile world comes from this. This is why I believe agile has the ability to change our working world far beyond I.T.
Behind this statement is the 5th and 6th principles:
- Build teams around motivation with support and trust
- Face to face conversation is most effective
It is far harder to fall out with someone when talking face to face than by email or phone and much easier to read their tone and intention from body language.
What about tools and processes?
The balancing sentence comes into play because we also need tools and process. We don’t want anarchy. Process makes repeatable boring tasks easier to complete with less risk of mistakes. Process and tools are therefore important and vital to success.
A process is defined as:
“A method, or process, is a way of working. Whenever you do something, you’re following a process. Some processes are written, as when assembling a piece of furniture; others are ad hoc and informal, as when I clean my house.”
James Shore & Shane Warden The art of Agile Development
So we can see that a process is really just a way of doing something.
How can a balance be found to favour interactions and people over tools and process? The answer is simple. Let the team (the people) find the right tools and the right process as part of their iterative learning. And don’t use process to hide or disempower people. The people lead the process.
It is fine to start with a framework. Most companies now have tools and process in place for development. And often we don’t have much choice than to start with what is already there. Through the teams inspect and adapt cycle, let the process evolve. Never allow the tools and process to stifle the team. Team excellence must come first. The tools and process should be there to support this. The retrospective in Scrum is a good place to address process impediments and how to change them.
The Four Statements – an example from my experience
I recently used this Manifesto statement to improve a situation working with a remote team from India.
The problem
The previous manager had put in place a rigid and strict process for the Indian team to follow. Developers were given small tasks via Jira and they completed these in isolation of other tasks. This reduced the risk of developers doing too much damage with larger pieces of work. Communication between team members was not needed as each task was isolated from other work.
This showed a complete lack of trust in the remote team and put the process OVER the people and interactions.
The result was that the team members completed their tasks exactly to their understanding of the spec which was quite often incorrect as they had not had the benefit of interactions with other team members or a higher level view of what was being developed. The coding styles changed for each piece of work depending on who completed the task and the resulting units of work were often hard to read and to integrate together.
The problem increased over each iteration, forming a cycle of worse and worse code being delivered that was not what the UK team expected. Misunderstandings increased rather than decreased. This resulted in less trust in the Indian team and a more rigid process was enforced by the UK team and the circle repeated itself again.
This was compounded by cultural differences where the Indian team like to say yes even though they didn’t understand and the UK team assumed an air of arrogance and explained their intentions less and less.
The solution
In this instance, the problem was solved by coaching the UK and the Indian team. And by setting up a series of open sessions where each team could put down good and bad things about working with the other team in a retrospective style approach.
The assumption was set that ‘everyone does their best with the knowledge and tools they have’. This often called the retrospective Prime Directive and more can be learnt about this in ‘Agile Retrospectives: Making Good Teams Great’ by Esther Derby and Diana Larsen.
Putting people first, fostered an environment of courage, trust and knowledge. Since people came first, developers knew they would not be criticised for their feelings. The team was able to unwind the cycle.
Brown bags were set up to share and invite comments on the overall architecture. And open sessions were set up to share ideas and best practices.
Interactions became the key element in this transformation with video conference sessions and the default communication becoming face-to-face via Skype.
The old divide and conquer process was completely dropped and a new one evolved that promoted an equal team.
This entire transformation can be summed up by putting people and interactions above process and tools.
Working software OVER comprehensive documentation
Quite often in agile processes we define success as delivering working software. At the end of each iteration the software should be in a demonstrable and optionally deployable state.
In waterfall processes, working software only happened at the end of the project if at all. Customer value can only be realised when software is delivered. We see here the first, third and seventh principle condensed into this statement.
1. Early and continuous delivery of valuable software
3. Deliver working software frequently
7. Working software is primary measure
These principles form the basis of the iterative development cycle of the Scrum framework. Delivering software frequently gives the customer the option to:
- review frequently
- build trust in the development team
- start making money earlier
Working software – an example from my experience
In 2012, I was asked to advise on a project at NYSE to mediate between a waterfall team and agile suppliers and get the internal development teams to deliver. The waterfall team was based at NYSE and the suppliers were from other companies.
The situation
When I arrived, the project was already 18 months in and not a single piece of code had been written!
Vast books of documentation had been created and a team of 20 authors of various skill sets sat there day in and out writing more.
Management were getting nervous that nothing had started yet and there were problems with the contract negotiation with the third party suppliers. The suppliers were Agile houses and NYSE wanted huge documents of requirements to be drawn up that the suppliers would be contracted to with fixed time and cost. They were understandably unhappy.
What happened next?
I started with the internal teams. I found the developers ready to start developing. However they were unable to because the documentation phase had not be signed off. I encouraged the teams to start anyway and to use the requirements documents to compile a list of backlog items that could be prioritised.
Within a single month more working code had been completed than in the previous 18 months and the development was underway.
We used documentation generators to document the code from the tests as they were written. Creating living documentation in this way means the documentation is always current and shows what the software does now. And not what the designer hoped it might do.
Within 6 months we had our first working components ready for the third party teams to integrate with.
Unfortunately the culture outside of our teams at NYSE was unable to adapt. It refused to relax its rigid documentation process for third parties. Subsequently the project was cancelled, since the money ran out before common ground could be found.
This is a case of putting comprehensive documentation OVER working software.
It was widely felt in the development team that the entire project could have been built using agile in the duration.
I hope NYSE can reflect on this and adapt to a more agile approach in the future.
Customer collaboration OVER contract negotiation
Working with the customer to produce value for them is at the very heart of agile. This statement firmly puts the people developing the software on the same side of the table as the people paying for the software.
The word collaboration brings a sense of working together and not working for. This changes the whole dynamic of the relationship. It fosters a drive for value in the development teams and a deep trust in the customer.
Communication points, built into Scrum, emphasise this. The product owner has discussions with the customer and helps them to write and prioritise the stories. The team commits to delivering a set of the stories and then demonstrates back to the customer. The customer then feeds back and any changes are prioritised for future work. This is collaboration.
The opposite of this is when the customer gives a detailed spec to the people developing the software. They quote a price and then start developing. The customer wants to change their mind and they have to go through a change management process to renegotiate the cost. Arguments can arise due to unexpected costs on the development side and who should pay for them. Each change has to be negotiated and this can be a time consuming and expensive process. This usually results in deteriorating relationships and less trust.
Customer collaboration – an example from my experience
As a Director of a development company, I once had a client who insisted on a fixed price contract for some work. During the work a technical issue arose which would take an additional 2 weeks to resolve. The question arose, who should pay for this?
If development pay for it, then the project would be at a loss, if the client pays for it, they are paying far more than was agreed.
Should the development team build in a huge contingency for each project? This would be uncompetitive.
The answer comes from a deeper understanding of software development and the nature of complex problems. Complex problems are better solved with an empirical method. This means trial and error. Trial and error does not work with a fixed price and fixed scope and fixed time line.
In this example, we were lucky enough to have an understanding customer and we split the cost. It was the last waterfall project I ever worked on and all further projects have been time and materials. Time and materials is only possible with the trust that agile brings.
Responding to change OVER following a plan
This statement is the one that most people think of when trying to sum up the benefits of agile. Building software can be a lengthy process. Business requirements change at a much faster pace than completing a whole software application. Agile gives us a way to meet this fast-changing world and still deliver software.
This is mostly achieved through the iterative development cycle. The iterative nature of agile potentially gives the business working software at the end of every cycle. The business can:
- change the priority of requirements
- add new ones
- remove old ones from the backlog
- direct the development team at every single iteration
This statement and the previous one work well together. Responding to a customers request as part of the process (and not having to negotiate over every change) hugely improves relationships.
Agile doesn’t react to change as an event. Agile expects change as part of the usual business flow. This is a fundamental change from software methodologies that went before it.
Responding to change – an example from my experience
At Loot, a UK paper that was owned by the Daily Mail group, I was asked to prepare the company for sale by streamlining the applications and business process.
After some initial review, the teams defined their backlog and started work. The priority was the translation from web adverts to print. The system that did this was cumbersome, required a large amount of technical input and often crashed.
After several weeks the teams had made good progress. Changes were already being felt within the business. Research was going on in parallel by the business teams on other improvements we could make.
Then, one idle Tuesday morning, the results from one of the UX experts was presented to the senior management. It showed that 80% of potential customers were dropping out of the sales process at the same 2 points. Fixing this would be far more valuable to the business than streamlining the printing process.
So, of course, we responded to that change.
Learn more and get certified!
Finally, you can learn more about being agile and the agile mindset on our highly-impactful and certified agile training courses in London and online.