The reason why I write a post about the agile manifesto for beginners, even though I am not a beginner anymore, is that this is the post I wish I had been told of back when I first heard of Agile.

What is the agile manifesto and why was it written

In 2001 a group of 17 software developers got together to discuss approaches to their work. The group was formed, according to the official manifesto site, of “representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes”.

In 2001 Mac OS X and Windows XP were the trending OS. iTunes and the iPod were born. Microsoft killed Clippy and launched the first XBOX. MSN had 5 million users. Google launched Google Earth, and BitTorrent was created, as did Wikipedia and Mailchimp. Nokia released the 8520, and the 3310 became a retired classic.

The world of technology was changing rapidly, and the old ways of making software, designed for the days in which software was bought out of boxes, needed a review. The result of the meeting was the Agile Manifesto, a set of 4 Statements, and 12 Principles that have been widely used in software project management ever since.

What is the original text of the Agile Manifesto?

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.

What do the four Statements of the Agile Manifesto mean?

1. Individuals and interactions over processes and tools

Teams and culture have more impact in the results than the specific technologies, tools or methodologies they use. A great team can do more with simple tools and tight budgets than a mediocre teams using flashy methodologies and tools. Focus the conversations on the humans.

2. Working software over comprehensive documentation

If your users need to read the manual, you have room for improvement. An app that works is worth more than a detailed specification, so focus on producing software that can be put in the hands of users to resolve real problems.

3. Customer collaboration over contract negotiation

The final result of software projects is often very different when compared with the initial idea of the final deliverable. Focus on building a real relationship with all the customers and stakeholders of the project and not in writing every single detail in a contract you can use to argue. Agile contracts often have a flexible scope and budget, that changes with the scope. Trust is again vital.

4. Responding to change over following a plan

In this context, organizations and teams need to be able to breath change, to accept that with every review and every interaction with a real user, the product backlog is likely to change.

The 12 Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This means you must deliver features early on, even if they don’t look great, and continue doing it often and in a predictable way. Break down your functionality in small pieces and follow MVP principles not just on the prototype phase, but as you build additional features into your product. What is the single smallest change you can make to validate a feature before you refine it? Keep this question in the back of your head at any point of the project.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Changing requirements are a sign of learning and adapting to changing information and needs. Please don’t every say “this was not part of the requirements”, that is precisely the point if we listen to the agile principles! We need to design the product so that we can easily incorporate these continuos changes. Think of Lego bricks and how they come in different shapes and colors and let you change your mind as you build your creation. I recommend you look into design systems too!

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This has been used as a justification for sprints, but remember that sprints are older than the Agile Manifesto. This does not say the cadence of these deliveries has to be the same every time, just that you shouldn’t let more than a couple of months pass between releases, and that if you can keep it down to every couple of weeks, that’s even better. As a beginner, you need to know that implementation, release and announcement are three different things, and that you can play with these and your deployment pipeline instead of committing to sprints too.

4. Business people and developers must work together daily throughout the project.

This, too, has been used to justify some SCRUM practices, like the daily standup. What this means, however, is that tech and business need to be coordinated, but you can do this with emails, a good ticketing system or sitting together all day long. I would add that designers need to be part of this combo too, and it’s perhaps a challenge that deserves a Manifesto update.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The team is vital for a project to succeed. The Manifesto talks about their most important quality, motivation, and then adds organizations should support them and let them do their thing with full trust. You need to read the “Hire managers of one” post if you want to understand this better.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

I can’t avoid adding that this was written in 2001 before Slack, Jira and Loom, remote work and before COVID too! This is another principle that may need to be revisited, I agree that face to face conversation is the best but, what is the second best, for the many situations, more frequent each year, in which this is not possible?

7. Working software is the primary measure of progress.

Amen. Developers say “show me the code”. I say “give me production credentials”. I don’t care how automated your deployment pipeline is or how short you keep your feature lead time or how large your test coverage is. How will I feel using your software? That’s what I care about.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Hello, startups! All-nighters and high burn rates are ok every once in a while, but they are not something you’ll be able to do forever so find a way to work sustainably or get ready for the imminent repetition of the .com recession we’re about to live as an industry.

9. Continuous attention to technical excellence and good design enhances agility.

MVPs don’t necessarily deliver low quality or careless design. On the contrary: making an MVP requires shining in anything you deliver, because you are delivering very little. I wrote a post about MVPs beyond the classic skateboard example I encourage you to read.

10. Simplicity, the art of maximizing the amount of work not done, is essential.

Simplicity not only on the way you implement things, but also in what you implement at all. Get rid of superficiality, accessories and things you build because you can. The best MVPs are the ones that require little or even no code. Wizards of Oz, Waitlists and Ghost features are some of my favorite ways to validate ideas.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

I am a big fan of self-organizing teams when they are formed following the point 5 of this list. When I start working with a new team, however, I like to do a capacity evaluation exercise. This helps me learn how mature a team is and what capabilities we need to build. Once ready, the team can be fully independent. I wrote about this team capacity matrix in my blog

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In SCRUM teams this is achieved through the retrospective, but there are other dynamics you can follow. Remember that the principles are guides, not prescriptions or instructions on how to run things in your digital team. Find the best way to carry these reflections with your team, and what rules you will apply to your ceremony.

What about the so called “Agile Methodologies”?

Agile is a belief rather than a methodology. The Agile Statements and Principles can be interpreted in a lot of different ways.

It’s important to understand that the Agile Mnaifesto and Principles do not propose any specific tools or dynamics. Instead, they focus exclusively on values.

Some of the methodologies that suscribe to this ideology already existed before the Agile Manifesto.

Your own methodology, if guided by these Manifesto and Principles, can be Agile too!

Even the parents of the manifesto started by stating their work was in progress.
Do not let anyone sermon you about standards, practices or manuals.
Ask them for production credentials instead!