On February 11-13, 2001 in Snowbird, Utah, seventeen individuals met and changed our perception of Software Development. They represented different methods – from Extreme Programming, through Scrum and DSDM up to Crystal Methods and so on. Agile Alliance – a unique group, to be honest. They had one goal – to stand against the current way of delivering good products to customers in general. Future was unclear for them. They just wanted to change it.
Manifesto of Agile Software Development
Agile Manifesto is turning 19 this month. It is the main reason why I would like to focus on it and the impact which it has caused. Because this is true – Agile Manifesto is a cornerstone for all Agile methods that exist. It is the main connection between all these methods. The way, how they can be described, without focusing on specific methods of work. But do you know what is in it?
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.
Do you know that?Manifesto of Agile Software Development
This is the part of the Manifesto for Agile Software Development which everyone knows (the Google search returns 133.000 results regards only one part of the above Manifesto). The Agile movement started from smaller companies, where the implementation of these methods was easier, but right now, the biggest corporations see value from its usage. Netflix, Spotify, Uber built their success on early value delivery and quick response to change. Right now, the biggest corporations are implementing Agile methods to some degree. Therefore, they present themselves as “Agile companies” where these four sentences are valued and lived in their flesh.
Problems it has caused
“We are working in Agile”Noises of doubt – heard in the city
“Agile doesn’t work”
“Agile didn’t change anything in my work”
These are examples of testimonials that I heard during my work. Now more than ever, we are facing an Agile degradation process. We have a wide selection of Agile methods, for example, SAFe, LeSS, Scrum XP, Crystal, FDD, BDD, Scrumban, etc. All of them should implement Agile Manifesto’s rules.
It is hard to convince people to Agile. In the vast majority, they tried them and failed (or Agile methods failed them!). They tried to work with “Agile Manifesto rules” and saw no change or even worse – blame for revealing these problems was put on them.
When I discuss the Agile related topics with them, I try to find the root cause of that state. They work for different organisations, using different methods and have different role’s description. Maybe Agile is no longer valid, and we should move back to more traditional ways of working? They have one thing in common – a misunderstanding of Agile Manifesto’s principles.
What is it? Try to turn the page and read again…
Principles behind the Agile Manifesto
We follow these principles:Principles behind the Agile Manifesto
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.
It is a big issue with Agile implementations – most of them do not take into account these principles. Lack of understanding of those may result in smaller or bigger holes, for example:
- No access to end-users feedback,
- No value created within the iteration,
- “Almost done”,
- Performing actions which do not have any value (“I always have done it that way!”),
- Mails are sent without any real results (“right now it is his problem, not mine because I’ve sent him an email” – oh so true!).
They may look silly, but they result in less and less value delivered by any Agile implementation. It does not matter if you use SAFe, LeSS, Scrum, XP or none of the common Agile approaches. If you do not understand these 12 principles, you are likely to be in danger of not getting proper results from Agile.
At start try to go through these 12 principles and to answer the question “Are we doing that?”. Simple “yes” or “no” question. Ask the whole team. If the answer is “no”, then try to swallow it: “we are not doing Agile”. Try to do that exercise frequently. Agility is not something given once and for all. You need to foster and nurse it.
The next step should be to create an action plan, define how can you improve the current state and move to the point, where you follow all 12 principles which stay behind Agile Manifesto. It is hard for me to give you any more hints because all situations are different. You have to find that answer on your own.
The Agile Manifesto was created by software developers for software development. All principles eventually have an impact on other parts of an organisation. It is the main reason why Agile started to flow outside of the IT department and why Agile Transformations take so much time and effort. Proper understanding of all Agile principles may help on that path by raising awareness on value delivery.
In the end, no one reads terms and conditions.