Dissecting the Agile Manifesto
How Agile is Your Team? It’s About Time You Found Out
We recently shared an article about how you might think you’re working Agile, but in fact, you’re probably not! We thought it would be beneficial to actually go through the Agile Manifesto in more detail so you can see where you might be going wrong.
The Agile Manifesto begins with four values, followed by 12 principles that break these values down further. The four values 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
It’s important to note that the manifesto also stated that while true Agile values the items on the left more, that doesn’t mean that the items on the right should be ignored or are not valued at all.
Four Main Values of Agile
Individuals and interactions over processes and tools
A common mistake in most companies is when people say things like “Hey, we want to do Agile, so we’re implementing Scrum, Jira or Kanban boards.” First off, Scrum, Jira, and Kanban are just tools. Second, just implementing these tools doesn’t mean you’re working Agile! This is a company just following some kind of roadmap of what they need to complete and deliver from a checklist and then calling themselves Agile.
Alternatively, you’ll hear “We’re not implementing full scrum, so we’re not Agile.” This couldn’t be further from the truth! If your team members are happy and are communicating with each other, you’re already practicing a key element of being Agile. It’s not that you aren’t Agile because you haven’t fully implemented a process or methodology.
There’s a good chance that if you aren’t discussing what is or isn’t working with your team, you may be focusing too much on processes and tools. Both are important, of course, but to be truly Agile, you should be putting extra effort into individuals and team members. This is where we see a lot of people “Doing Agile”, rather than “Being Agile.”
Working software over comprehensive documentation
This value is most often mistaken as, “We don’t need to write documentation.” But as I mentioned earlier, although the items on the left are valued more, that doesn’t mean we should be negating the items on the right. You need some kind of documentation!
Just thinking about the ‘here and now’ will come back to bite you later. You need to think ahead, at least a year or so, from today. Without documentation, your future team will have no idea what this particular project or feature is all about and won’t know how to move forward. This could cause serious problems for your deliveries as well as hinder your ability to provide value for your customers.
We’ll get into delivering valuable and working software later on when we dig deeper into the 12 principles.
Customer collaboration over contract negotiation
The first thing you need to understand is who your customer is. In an Agile team, everyone should know who the customer is, and how they are contributing to the value being delivered to that customer.
QAs think that engineers are their customers, and engineers think that project managers are their customers – this is a MISTAKE! Team members are bringing their capabilities to each project, but are often unclear as to who their customer really is.
Part of the issue here is that there is usually an intermediary between the client and team members. While this is helpful for organizational purposes, the team should also be communicating with the customer, to ensure that they understand their needs and priorities, as much as the intermediary.
In terms of contracts, sometimes they’re necessary. But first, everyone involved in the project should sit and discuss it. If a contract is no longer valid because it was written earlier and things have changed, it can be beneficial to re-write it to fit new needs.
Responding to change over following a plan
When it comes to this principle there tend to be two ineffective and definitely not-Agile extremes; very detailed planning or no planning at all.
Teams calling themselves Agile will plan ahead for a half year, working on the things already expected, while forgetting whether this work is something they’d like to do or if it’s even important. The risk here is that they will not be providing value.
Other teams have no plan at all and are just rushing forward. With no real direction, they are jumping left and right, without delivering anything of real importance. In this case, they can’t even be sure they are providing value.
The ideal situation would be to find a middle ground. It’s important to plan, but it’s equally important to iterate on your plan as you go, to make sure that you’re still providing value and working on what’s important. (See the first of the 12 principles.)
12 Principles of the Agile Manifesto
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
If you plan too far ahead, then something will likely go wrong and the plan will continue to be delayed. Priorities will change and some of your plans will not be valid anymore. You’ll no longer be providing value to the customer because, in this case, there won’t be working software. Too much focus on following a plan means that no one is looking at what’s right in front of them.
Sometimes you need to stop and ask yourself these questions to ensure that you are keeping customer satisfaction and continuous delivery of valuable software as your highest priority.
- “How quickly can I provide value and what is the actual value?”
- “Is what we’re working on still valuable for our customers?”
- “Will this delivery to the customer be quick?”
- “What else can we do, rather than what we’re currently working on?
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
In Scrum teams, it’s not uncommon to hear, “This is the sprint, and this is what we’ll deliver.” But what happens if, in the middle of the sprint, one of the requirements is no longer needed, but you still need to provide something?
Two possibilities that can arise from this scenario:
1. “We’re going to ship the feature anyways because we spent so much time on it. Worst case, no one will use it.”
The problem with this thinking is that it, in fact, breaches the first principal.
2. “Let’s just drop it.”
The problem here is that the team will feel like they wasted time and this will lower morale. It can leave your team with negative feelings over wasted time on developing something that will never be delivered
Any change is reasonable and needs to be considered. Especially in software development, It’s important to constantly understand what the value is of what we’re developing, where that value comes from and how it changes over time. We need to communicate that these changes can happen, and work with our team to maintain flexibility in our planning.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
A lot of companies have monthly release schedules, and some even have quarterly release schedules. Most of these companies likely believe that it’s their consistency and predictability that adds additional value, but it’s actually quite the opposite. The issue with these longer release times is they don’t provide value immediately or don’t provide value to customers as early as possible.
The longer you wait to release a feature, the longer it will take to fix any bugs or make necessary changes. Continuous delivery is extremely important when providing value to customers, but also in developing working software.
4. Business people and developers must work together daily throughout the project.
Here we have another commonly misinterpreted Agile principle. Developers and business people are usually speaking a totally different language, have different priorities, and different ideas on how things should be done. The misconception here is that these priorities can’t work together and it will be impossible to find common ground.
What we need is to create a unified language, bringing business people and developers into one team and force them to work together. This will ensure that they understand each other and create one set of priorities.
If you don’t have features, then your software isn’t fit for purpose, but if you don’t have fast well-developed software then it’s not fit for use either! The ideal situation is having cross-functional teams, each responsible for parts of a system, ensuring there is accountability. Without accountability, there are no priorities.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
We’ve all seen the job ads out there looking for software superstars or software ninjas – searching for that top 1% of the best developers for their project.
The thing is, people who are at the top of their game are also, usually, the same people who have the largest egos. In most cases, these people are not team players. It’s more important to have a team of people who want to solve problems together, work together and are motivated to create solutions.
If you have two or three rockstars, with high tech skills, but low interpersonal skills, they won’t be able to provide real value in a project. People with better interpersonal skills can actually provide more value because of their ability to communicate rather than these developers with huge egos. It should be more about problem-solving and brainstorming when you’re looking to provide real value.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
A face-to-face conversation is considered to be the most effective way of problem-solving and communicating in general. Two things to consider with this principle are team sizes that are considered to be most effective, as well as the growing number of distributed teams.
Smaller teams tend to be able to solve problems quicker and more efficiently. It’s also much easier to build a team dynamic with fewer people. Larger groups have more opinions, so finding solutions can be more challenging. We recommend a group size of 8 teammates maximum.
Also, with more teams becoming distributed, this part of the Agile manifesto is becoming challenged. Video calling is available and is seen as an effective alternative to face-to-face meetings, but it can be argued that it isn’t quite the same as having a small group of people seated in the same room.
There is a huge impact on what kind of values and motivation team members are bringing to their team, and there isn’t any alternative that beats face-to-face interaction for these important meetings.
7. Working software is the primary measure of progress.
If you don’t have any working software, nothing else matters. This principle is clearly connected to continuous delivery. The later you provide value, assuming you are still providing value, means you aren’t really providing value at all. Even if you say you’re testing, it isn’t providing value until it’s delivered.
As mentioned earlier, if you deliver every quarter, how do you know that what you’ve developed is still valid? You don’t! You’re basically robbing your customers of the possibility to obtain value from your product, which is obviously just bad business.
Working software is all that matters to achieve this, continuous delivery is paramount.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Many companies have an idea and want to ship it out ASAP, but then there is literally nothing to ship because they’ve since had another big and wonderful idea, which they want to be shipped immediately, again.
We need to plan, but not too far ahead. Planning means creating a culture where you have a consistent pace at which you’re delivering predictably. This means there aren’t any surprised customers waiting for value and nor are there surprised people making these products without value. Unpredictability doesn’t serve anyone. If you say it’ll be ready, it should be ready.
This is when we see how important estimations are. Estimations are not there to judge people but to be able to track progress and make sure there are no hidden issues that haven’t been spotted yet. They are used for measuring velocity, and rewarding/reprimanding developers – but at the end of the day, it’s about knowing what’s going right and what’s going wrong. Otherwise, you can end up in a situation where you have spikes of delivery and spikes of nothing and no one will be able to figure out what’s happening.
9. Continuous attention to technical excellence and good design enhances agility.
It’s really easy to forget that without the reasonable quality of the code, you can end up in a spiral of paying out technical debt and bug fixing. Technical excellence comes from understanding everyone in the team and taking time to focus on quality. Making sure that everything delivered is at the highest possible quality. This can sometimes mean we are delivering a little bit slower or getting rid of a feature, but as long as the delivered aren’t so delayed, the quality takes precedence.
Your product will slowly but steadily be pushed in the grave if you forget why quality and technical excellence is so important. The point here is to maintain consistent quality – consistent high quality.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
The more work in progress you have, the more difficult your bigger picture will become. If you’re working on multiple tasks at the same time, and the team is spread thin, it can easily lead to lack of focus. Lack of focus can quickly make it impossible to ensure that what you’re working on is actually important.
If work in progress is building up, then that probably means there is a bottleneck somewhere in the line that needs to be dealt with. Handing what comes before this bottleneck or after it can slow down your progress and make things more challenging. Your first step should be to determine where the bottleneck is and how to solve it.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
Well, we think this principle should be obvious. People who understand a problem best are the people who are actually having the problems and working with them on a day to day basis.
If you create priorities from the top of a company to the bottom, chances are pretty good that the person higher up in the hierarchy is more disconnected from the issues they are trying to resolve.
The best working teams are empowered to determine the problems they’re having and solve them themselves, not those who are told what they need to work on. This type of critical thinking is extremely valuable and found primarily in self-organized teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
When using Scrum you hold retrospectives, but these meetings can turn into blame fests. If done properly it’s possible to see the real value of team reflection. One thing that seems to be neglected in these retros is the emotional part – talking about what team members like and don’t like about the work process.
Sprint reviews, or the like in any given methodology, should be about 4 basic tenets:
- Did we deliver what we planned?
- What changed since we planned last time?
- How does the team feel about the process and delivery?
- What could be improved in what we delivered, based on lessons we learned?
If we don’t talk about why we changed direction in the middle of the sprint, why our sprint went haywire and we didn’t deliver, how can we improve on what we’ve been doing? Without asking these tough questions, we stop ourselves from learning from them.
The first main value of the Agile Manifesto is about individuals and interactions. If people aren’t happy, they won’t do as well in a project. If team members don’t know where they fell short, they won’t know where to improve. Of course, if everything is going perfectly, there is no harm in holding these retros because there is always room to improve!
Do a step, check if it’s improved. If it has improved, reinforce it. If not, then you can experiment with something else. The whole idea with this principle is to keep iterating. Just because a process was perfect once doesn’t mean that it will stay perfect forever. Your team needs to be able to reflect on the work they’re doing and the processes in which they are working, to keep things fresh, up-to-date and relevant.
How Agile are you?
After reading the Agile Manifesto, with more details and examples, how Agile do you think you are? What about your team? Maybe now is the time to do a retrospective!
Remember, it’s not about creating strict plans and following through line by line. It’s also not about negating to make any plans at all and just running into the wind. Being Agile is about flexibility. It’s about the value of people, reflection, iteration – always working to improve the tasks and processes we use in our day-to-day activities to optimize them.
Article written by Sona Kerim
