After diving into the Agile Manifesto and discussing the Agile Values here, this post is entirely dedicated to the accompanying principles.
Originally, the 12 principles of Agile software development were split in three categories: customer, managers, teams (see below a copy of the original manifesto), each category having four principles.
I. Slanted towards Customers:
The first four principles refer to behaviours and practices that the development team and the customers alike should adopt, to deliver the highest value to the customer.
Principle 1: customer satisfaction and early delivery
From the first line, the Manifesto positions the customer first. The most important thing to consider when you build software is the person(s) you’re doing it for.
Delivering software early creates rapid value for the customer (they have a working system they can already test, use, give feedback on, that partially solves their problem), while continuously delivery ensures the customer feedback is incorporated into every version of the product and the iterations are creating incremental value, with each delivery.
Principle 2: change
Changing requirements are the only constant in product development. The product assumptions you start with change as you deliver frequent and continuous value to the customer and receive feedback.
In a traditional software development environment, changing requirements late into the product life-cycle is very costly (as the customer won’t see any version of the product but the complete one).
The agile way of creating software works with short iterations (maximum 30 days long), so changing requirements won’t create a big risk for the product nor a high cost, at the same time ensuring that customer value is delivered and customer needs are met.
It’s also essential that you make decisions into the customer’s competitive advantage, not yours, so you must listen to your customer and serve them, not the other way around. Sometimes that might include helping the customer figure out what they really need, which is part of serving the customer.
Principle 3: frequent delivery
As mentioned above, frequent delivery ensures (1) delivering value to the customer as fast as possible and (2) incorporating customer feedback as you build the product.
This is one of the Agile principles that I think should be updated; the current industry norm is of 2 weeks iterations, from corporations to startups. Some companies go even lower, e.g Amazon deploys to production every ~16 seconds.
Principle 4: collaboration with business
Traditional software development (or waterfall) had absolutely no contact between the developers of a system and the end users. The discussions, creating specifications or changes, clarifications were made between assigned Project Managers on both sides. It’s obvious why there would be quite a few misunderstandings from not having clear specs to misunderstanding the entire system and customer needs.
This is why the fourth Agile principle ensures that the customers have direct contact with the team that builds the product, on a daily basis, throughout the entire project. Ideally a customer representative will be in the same office with the product team, and become part of the team itself.
II. Slanted towards managers:
The second category addresses how managers can help the team deliver excellent products. The Agile Manager’s role is to make sure the team has a supportive environment, autonomy and the right tools to build the software. I’ve written in detail about the role of the manager in an agile team here.
Principle 5: motivated individuals
The key to project success is motivated individuals that are given the freedom to get the job done, without external interferences (e.g. manager / project manager to tell them what to do, or how to do their job) , to implement solutions that they created, and create their own working process.
In this context, management’s role is to create the right environment (tools, processes, autonomy, proper rewards , etc.) for the team to work at the height of their abilities.
For this to happen, trust is essential: trust that the team of experts hired to do the job can and will do it, as long as the manager gets out-of-the-way.
Principle 6: face-to-face conversation
Face-to-face conversation is the most efficient way to communicate, and the fastest way to solve problems and misunderstandings. I consider this is another principle that needs re-thinking, with the rise of remote teams supported by successful tech companies, like WordPress, Basecamp, Auth0, Atlassian, GitHub, Aha!, InVision, Trello, etc.
The communication technology enables almost a face-to-face experience, that allows teams to work efficiently even remotely. I’m going to look into research on this topic and will work on making a separate post about it.
Principle 7: working software
In Agile software development, progress is seen only from the point of view of delivering value to the customer. The only way to create value to the customer is to deliver working software for them to use and give feedback on. Thus progress equals valuable software delivered to the customer.
Does that exclude the usage of metrics in general (as some of my devs are asking me every time I inquire about their lead time or I point to the fact that defects number went up during a sprint)? Definitely not, you can use whatever metrics benefit your team and are of use for your team to measure their learning, as long their primary purpose is continuous improvement and you don’t use those metrics to measure individual performance, or as a basis for rewards, promotion, salary raises and so on.
Principle 8: sustainable development
One of my teams has been working weekends, public holidays and all their free time to meet a deadline. They’ve been doing it for about a month and one of them was telling me they were exhausted, but: the deadline was set by them, they are highly motivated by the product and want to deliver as fast as possible, and – most importantly – after they deliver, they will slow down their pace, collect customer feedback, and look into code maintenance, to make sure we didn’t create technical debt with our desire to move fast.
It’s not the ideal approach, but it is what works for the team. They overall keep a sustainable pace, and they define what that means for them as a team, without any management imposing these deadlines on them.
Our CEO is a great supporter of work-life balance, we don’t have a fixed working schedule and we are trusted we can manage our work so that we deliver with a sustainable pace. Recently he communicated to the team that he wants us to “work smarter, not harder“, as in deliver the right products, rather than work constantly do deliver little value.
All the research shows that overworked teams make more mistakes and overall deliver less value and less work than rested, motivated individuals. Long working hours backfire for people, and companies, says HBR, while The New Yorker shows how even the Wall Street is giving up the cult of working overtime:
“The perplexing thing about the cult of overwork is that, as we’ve known for a while, long hours diminish both productivity and quality. Among industrial workers, overtime raises the rate of mistakes and safety mishaps; likewise, for knowledge workers fatigue and sleep-deprivation make it hard to perform at a high cognitive level.”
III. Slanted towards the team:
The last category of the Principles is addressed to team behaviours. Agile teams are given trust, autonomy and freedom to create their best work, but with great freedom comes great responsibilities. While the Principles don’t get into software engineering practices, they point towards them and there’s a lot of supporting literature (including by the Agile Manifesto signatories themselves) on what technical excellence and good design are.
Principle 9: technical excellence and good design
As the Agile way of delivering software focused on delivering early and maximum value to the customers, technical excellence and great design should be a constant objective for the teams.
Principle 10: simplicity
Simplicity – delivering the simplest and fastest solution that solves the customer’s problem, and then building on it based on customer feedback – is the most underestimated Agile principle (at least in the context I am working in). Sometimes developers get carried away with delivering features that are not necessarily required by the users, but they consider useful or valuable, or they overcomplicate the solution (e.g. if group interaction is needed, use Facebook, don’t build an entire new platform), creating waste and extra cost for the customer.
“Best code is no code“, told me once one of the Senior Developer I work with. If you can solve a customer’s problems without writing any code, it’s the best and most cost-efficient solution you can give. As this is not the case most of the times (otherwise there would be no software built 🙂 ), building the simplest solution that covers the customer’s needs comes the closest.
One question that I got my teams used with is but “What should we NOT build next?“. There should be a constant attention and focus on what doesn’t need to be done, as much as on what needs to be done to deliver value to the customer.
Principle 11: self-organising teams
As mentioned, in order for product development teams to deliver their best work, they need trust, and a certain degree on autonomy to build the best solution for the customer.
That implies an entire rethinking of the role of the manager (see above, and my posts on the topic here).
Principle 12: continuous improvement
This is the most important of the 12 principles from my point of view. All of the above become obsolete if the team is not continuously learning and growing. If the teams are to adopt a single principle, I would recommend this one, as it is the most likely to bring them closely to agility.
Reflection, inspect/adapt should be behaviours that become part of the culture of the team, that happen ad-hoc any time there’s an opportunity for improvement for the team, or they figure out a better way to build software (faster, higher quality, higher motivation, higher value, etc.).
Conclusions
The Agile Manifesto is the game-changer in software development and is the only guide that should show you if your teams are agile.
Unfortunately, agile software development frameworks (such as Scrum, that soared in popularity in the last five years) don’t make a direct reference to the Manifesto and its values and principles (despite the fact that the Scrum creators are also part of the Manifesto creators), and many teams get stuck into following a specific framework, without being really agile.
The best advice I can give to any team that wants to build products in an agile way is to go back to basis: read, understand, and follow the values and principles, as they are your main indicators that you’re on your path towards agility.
One of the signatories of the Agile Manifesto, Alistair Cockburn, posted a few photos from creation of the manifesto on this Facebook post here. I copied them with his permission. Find below the copy of the original Manifesto and the accompanying principles, split in the three categories discussed.
Agents of Awareness 