The 12 Agile Principles

Kevin Pedersen, Growing Agile, https://www.growingagile.co.za/

Much is said and written about the Agile Manifesto that if I were to write about it, I am sure it wouldn’t be anything that hasn’t been said before. There is less material out there around the 12 agile principles that go along with the manifesto though, so I had thought I could put out there my own thoughts around these 12 sentences that help us understand how to apply the agile manifesto in our daily work.

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

There is a reason that this is the first principle, it is fundamentally describing why we should be agile. Satisfying the customer is our highest priority, it is what we care about most, and how do we do that? By delivering valuable software as soon as possible, and then inspecting and adapting based on feedback to continue to deliver valuable software.

It sounds so simple, yet is fairly difficult to do, especially if you are a team that is used to working from long Business Requirement Documents that have the detail of everything that the stakeholders could ever wish for written in a nice long list. Fortunately over the years there have been many tools, tricks and techniques developed in order to figure out what we should deliver first that is actually valuable to the customer.

My favorite tool of choice for breaking down a large idea into smaller deliverables is Jeff Pattons User Story Mapping. With this practice you map out a user journey and break it down so that you can understand how to deliver a valuable slice of a product to the customer without having to develop all those nice to have bells and whistles that slow a release to production down.

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

This is the one that all the Product Owners and people coming up with ideas love the most. It is great, this gives them permission to change their mind whenever they want and the team delivering just has to suck it up and do it!

Well, maybe not so much. Whilst we want to encourage any change of direction that will make the product better for it, there is always a cost involved. Usually when we change a requirement that the team has already discussed and refined there is an amount of waste generated.

A better way would be to try and change requirements early in development by collaborating on the plans early with the team. The more people you have looking at a solution, the better the solution will normally be.

Changing requirements late should not be the default, but the exception.

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

Some teams that are advanced in their agile practices will laugh at this now, as they deliver a lot more often than once every couple of weeks! However if you think about it, those teams are not who this particular principle is aimed at.

Most teams starting on their journey will not have Continuous Integration / Continuous Delivery (CI/CD) pipelines, or even automated testing in place for them to be able to release on demand. Many teams are still having to abide by a quarterly release plan that has to go through some kind of Change Management process in order for another team to move their code through the phases into production for them. These are the teams that should pay particular attention to this principle.

It can almost seem impossible to be able to deliver software every couple of weeks, so start by just reducing it a little. How do you go from your current quarterly releases to once a month? Maybe at first you cannot go to production once a month, but can get to integration phase once a month. Then figure out how to make the releases a little easier, is there something you can automate a little bit? One small step at a time, and over a period of several releases you will make gradual baby steps to reducing the amount you release at any one point. The aim is to release in smaller and smaller batches, more and more often.

The smaller releases the easier they are, the less risk is involved, and generally the smoother the process. It takes concentrated effort and focus on the release process in order to make a difference.

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

I recently attended a workshop with Woody Zuill around Mob Programming and it really opened my eyes up to just how powerful it can be for a whole team to be working on the same computer at the same time in the same place. The whole team! That included the Product Owner who is the representative of the business and customer needs for the team.

Now the Product Owner did not sit all day every day with the team, that would be unrealistic, how would they ever learn more about the customer and business requirements if they spent all their time with the team? What they did do is ensure that they spend some part of their day, every day, with the team.

This kind of access to the person that makes decisions around the product they are working on is vital. It gives them real guidance and focus on what is important. The more time the Product Owner can spend with the team on a daily basis, the less time is needed in rigorous planning meetings.

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

This principle seems to be more aimed at the management structure around the team than the team itself. Step 1, ensure you have motivated people, step 2 give them what they need, step 3 leave them alone to work their magic.

How do you ensure you have motivated people? Dan Pink in his book “Drive” shows us there are 3 main facets to motivation in knowledge workers: Autonomy, Mastery and Purpose. That is, give them the Autonomy to have some say in how they do their work, don’t micromanage them. Let them have Mastery over their craft, pay for them to go on courses or conferences, let them play with new tech when the opportunity arises. Sometimes the hardest to help the team with is the Purpose, so try to explain to the team how they are going to change peoples lives by working on this product, what a difference it is going to make.

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

In this day and age face to face isn’t often possible. Agile people have for years been preaching the need for teams to be co-located, and whilst it definitely does have its benefits, technology has enabled us to work remotely, and a certain virus has forced us to at least give it a try. If you want to learn more about remote facilitation I can highly recommend visiting the Remote Coaches for tips and tricks.

When it comes to this principle I always think of the communication effectiveness graph which can be found here:

Often we find the team will start with an email conversation and escalate up towards face to face as the need arises. Maybe an email isn’t responded to in time, so they make a phone call, maybe the phone call didn’t give them the info they need so they book a meeting. What we actually want to encourage is to start with face to face first, and if that isn’t possible then work your way backwards to a form of communication that is possible, so use this model as a decision tool rather than an escalation tool

7. “Working software is the primary measure of progress.“

Early in my agile career, when I was still a project manager with agile tendencies, I took over a project that was ‘60% done’. When I probed a little I found out that the 60% done meant that 60% of the budget had been spent, the project was far from done. In fact the only progress made on the project was a requirements document, and even that wasn’t complete.

The first thing I did was take was to take what requirements had been gathered and break it down into a story map so that we could get an idea of where we could start developing some working software. Story maps are a great way to figure out how to slice up an idea into chunks of work that deliver end to end value rather than working component by component.

If we can break our work down in such a way where we can deliver features to the customer, and start gathering feedback so that we can tune and adjust, then we can say we are starting to make progress, measurable progress. Whilst a large requirements document is work, and some of it valuable, the amount of waste generated by trying to figure out everything up front is incredible.

Working Software isn’t the only measure of progress, but it is the most important one. Nothing else matters if your software doesn’t work.

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

Sustainable development pace by the delivery team is an obvious thing that jumps out with this principle. If your people are working lots of long hours, eventually it gonna hit you in the quality of work being delivered.

How often do you think about the sustainable pace of your sponsors and ‘users’ (I dislike using the term user in this context). If sponsors are constantly chasing the new shiny thing and pushing more and more work to the team, then the team will be overloaded and it will be difficult to maintain a sustainable pace. If your sponsors can work at a sustainable pace, and have focus, then it makes it easier for the team to also have a sustainable pace. One way of doing this is to introduce a Kanban system where limiting the Work in Progress (WIP) at the early stages of the process, creating an artificial bottleneck early, helps keep a sustainable pace throughout the process.

If the end customer, or user, is receiving new updates on a daily basis, then they can be overloaded with the amount of changes happening and be turned off. There is a fine balance between releasing to end customers in small batch sizes often, and delivering value that they can consume regularly without feeling overwhelmed.

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

I find that this principle goes almost hand in hand with the previous principle around sustainable pace. Most teams want to give attention to technical excellence, but pressures put upon them mean they generally aren’t given the time they would like.

Building good products takes time. Building quick dirty throw away solutions in order to learn are quite quick. Problems occur when the quick and dirty are then taken on face value as a good product, put into production and then asked to be built upon. This leads to spaghetti code and the demise of maintainability. Eventually you have to give up and re-write the thing from scratch.

Another example of where this is a problem is down to affording the team the time to put together a proper infrastructure around automation, of tests and deployment. Again this takes a little time, but saves an exponential amount of time in the long run, so it depends on the lifecycle of the product.

These things are hard to do, and it is difficult to find the right balance between ‘building the thing right’ and ‘building it fast’. Both are important factors to take into consideration for your unique context, and it is all too easy to slip into the mindset of ‘get it out quick’ and not grasp the consequences until it is too late.

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

When I was an Analyst back in the day before I discovered Scrum, or even knew what agile was, I would write down the findings of my analysis in a document called a Business Requirements Specification. This was often a fairly chunky piece of work that usually took many weeks, depending on the size of project at hand obviously.

When I think back to those days, and talking to the people from business who wanted ‘the thing’ then I would do my best to wring out of them every possible wish and desire they had. The more I knew, the easier it would be to satisfy them, at least that was my thinking.

The problem with that approach is that we end up listing every single wish and desire that we can think up. All the bells and whistles, nice to haves, call them what you will, without really understanding if they give value to the customer for the time spent in development. We try to make all the decisions up front when we know the least about what we are trying to achieve.

Using methods relating to an agile way of work we can easily see that the backlog should be emergent, not fixed up front. Gather enough information to get going, and then start. As we develop the product we gain feedback and the backlog is regularly refined and adjusted as we learn.

If we commit to doing everything up front, by signing off on an analysis document early, then we will likely ask the team to develop a lot of features that don’t really add much value. By trusting in the process and letting the requirements emerge as you develop, you will start to maximize the amount of work not done, and will have a simpler more effective product because of that.

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

Building on the previous principle, we can see that gathering all the requirements up front can cause problems with what we are trying to accomplish, especially when it is left to a single poor lonely analyst to pull everything together.

The more brains and eyes you have on something, the better the quality for it. Well I guess you could get all philosophic about that, as for sure there is a problem in making all decisions by committee also, but the basic premise I think is fairly true. If we involve our teams in figuring out what we are going to build, then not only will the team have valuable input into the direction, but they will also likely be more invested into the product and care about it more. If you have a team that cares about what they are building, the quality of the product will definitely be better than if they are just doing a day job to pay the wages.

In a large corporate environment it is generally not feasible to have an architect in every team. If that is the case then see if you can find ways to change the role of the architect away from the command and control tick box culture to a way of work where they can mentor teams to make architectural decisions themselves. Give the teams some guidelines and boundaries within which they have to work, and then help them be as self sufficient as possible. The team can then start calling on the architects for advice and guidance at regular intervals to ensure they are delivering a quality solution.

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

If you only take one thing away from the agile values and principles, it should be this one statement. Inspect and adapt. It is at the heart of everything we are trying to accomplish. There is little benefit to doing a lessons learnt, a post mortem, at the end of a project when it is too late to change anything. We should be aiming to introduce feedback loops as often as possible where it makes sense.

Scrum is built upon empiricism. Kanban encourages the idea of inspect and adapt. For both you need to be gathering data and then working on improvements based upon what you are measuring. As Deming once said “without data you’re just another person with an opinion”.

Conclusion

So on that note, I would like to leave you with a thought for introspection. What are you measuring? For your team, your organization, maybe even in your personal life? Deming also said, “In God we trust; all others bring data.”, and then ensure that you tune and adjust your behavior according to what the data is presenting.

This article is based on blog posts that were originally published on https://www.growingagile.co.za/2020/06/the-12-agile-principles-part-one/, https://www.growingagile.co.za/2020/07/the-12-agile-principles-part-two/, https://www.growingagile.co.za/2020/07/the-12-agile-principles-part-three/, https://www.growingagile.co.za/2020/07/the-12-agile-principles-part-four/.

---

Related Agile and Scrum articles

Making Your Culture Work with Agile, Kanban & Software Craftsmanship

More Agile and Project Management Knowledge

Scrum Expert

Project Management Planet

---

Click here to view the complete list of Methods & Tools articles

This article was published in January 2022