It takes a great deal of practice to safely say we are doing Agile on a project, but what if we don’t put enough thought into being Agile? Agile methods often leave room for interpretation and acknowledge that you may have to go off-script. It’s at these times that teams are likely to revert to non-Agile habits – that is unless they truly embrace the ideology that’s behind Agile. By following the 12 Principles of Agile in your projects you’ll be able to keep things on track even when it’s not clear what steps you need to take. In this article, we will dissect these 12 principles and explain how employing them can benefit your team, and in doing so, we’ll see the true flexibility and power that Agile can bring to a project.
What are the 12 Principles of Agile?
The 12 Agile Principles are a set of rules created to unite our understanding of different Agile methodologies. They were drafted up in the “Agile Manifesto,” a document collaboratively written in 2001 by the leaders in the world of Agile and SDLC practices at the time. These principles are shared regardless of what Agile framework you may be using, be it Scrum, Kanban, or something else. Following them helps guide your project and ensures that no matter what your process is, you’re being truly Agile along the way.
1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”
In short, this means we should release early and often to benefit our customers. Iteration and feedback are at the core of what it means to be Agile, referred to here as “early and continuous delivery.” Early delivery is important because the longer it takes a customer to see the direction of a project the more likely it is to diverge from their expectations and requirements. Meanwhile, continuous (and consistent) delivery helps the project maintain a rhythm while allowing for iterative review along the way. As we’ll see in the other principles, sustainable development is key to being Agile!
Another core feature of Agile is the ability to adapt to change which is shown here by describing this method of delivery as “our highest priority.” Despite being written like 12 commandments, Agile is not set in stone, so instead of saying “Thou shalt deliver continuously,” this principle urges you to prioritize this wherever possible. Phrasing and semantics aside, this principle also highlights that we should aim to “satisfy the customer” with “valuable software” by proactively meeting their needs, which goes without saying but is all the more important to not lose sight of.
2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage”
This second principle means that we should be willing to make changes to stay competitive, and it outlines a common fear to address when becoming Agile. Chances are high that when someone studies Agile they’ll wince when they get to the part about “changing requirements,” but it’s absolutely necessary and one of Agile’s core strengths. Adapting requirements as more information is gathered ultimately leads to the production of an effective and competitive product which is important in the long term.
As with the first principle, saying “Welcome” doesn’t dictate the action you should take, just that you should allow and assess changing requirements at every stage of development instead of dismissing it outright. To address concerns, this principle highlights that allowing for change gives the customer a competitive advantage which is necessary for a successful business and by extension the software team it hires. Being Agile means providing this benefit to your customer, so if you’re queasy about late development requirements changes ask yourself if dismissing the change will affect your customer’s competitive advantage, and then recommend what is best for them.
3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”
The third principle of Agile is likely known even by fringe Agile users, and it boils down to trying to release on a shorter frequency. If you’re familiar with Scrum, this would refer to “sprints” where work is planned for one or two weeks after which working code is presented to the team. This shorter delivery time allows teams to get earlier engagement from clients and stakeholders, which Agile uses to adapt to changing requirements (callback to principle 2!). Like the other suggestive principles, this one allows for the idea of month-long time periods but puts priority towards smaller intervals when possible.
The operative word in this principle is “frequently,” which implies both consistency and regularity. In principle 1 we talk about delivery being continuous because it needs to be sustainable, and here we add on that it needs to be consistent and have an end time – like a pay period. Agility is more about moving correctly than moving fast, so stepping through your project with short, even, and calculated steps is key to being Agile. Even if your project doesn’t easily lend itself to a sprint structure, see if you can still have some shorter, more frequent deliveries.
4. “Business people and developers must work together daily throughout the project”
Number four can be a major hurdle for becoming Agile, but in essence, it asks that you include both the business and tech groups in daily work. In this case, daily work is considered anything your team does on most days like status updates and the internal discussions that happen between scheduled meetings. By looping in both sides throughout the process – like when making a notable on-the-spot design decision – the communication channels will be open so everyone is on the same page and immediate feedback can be given if necessary. The added perspectives help to makes sure that important details receive adequate attention before they get baked into a part of the project.
A common rebuttal is that doing this will cost more time, but this should ideally optimize those long checkpoint meetings by dedicating less time to getting up-to-date and more time towards planning the next phase. I am also confident that anyone reading this article has recognized disconnects between their tech and business teams in the past, it’s not only common, but it gets worse when projects get faster or more complex. Recognizing gaps early and often is a cornerstone of being Agile, and with how large gaps can grow between business and tech teams it’s imperative to stay on top of things.
5. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Principle 5 focuses on giving passionate teams room to work. It’s easy for a team to lose motivation – we’ve all been there – but building that passion is great for the project and the people. Using motivated individuals to build a product and giving them the tools to really shine is a great way to turn a project into a work of art as opposed to just another task – this is where principle 5 comes in.
You can start by finding ways to plan the project with the team, like adding some leeway to the structure so a team member can show their ideas or section out work based on individual interests. As the project starts to build momentum, follow up with your team to see what they need in order to be successful. This is what most teams do when trying to build motivation, and the closer this is to the project building step the easier it is to do. Notice how this principle doesn’t mention speed or efficiency? This is because being Agile is also about doing things well – why make software quickly if it’s not good?
If you are having difficulty finding the right people, you can always hire on-demand talent; professionals who will be uniquely suited to and interested in your project!
6. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Truly a principle not written in 2020, number 6 tells us that information is easiest to convey with personal communication. Email, texting, and other messaging platforms all have their own benefits, but it is usually at the expense of overall effectiveness for relaying information. Effective and efficient conversation comes from hearing someone’s voice and seeing each other’s expressions. This of course relates to face-to-face communication, but in today’s world companies have noticed (or have been forced to notice) that this can be translated to video calls for remote work. The expressions are there, you can be heard, and you can even record the conversation giving it every advantage for effective communication – unless of course you think smelling someone is important. Communicating clearly is important to Agile and non-Agile teams alike, but given Agile’s frequent engagements this principle warrants special consideration.
7. “Working software is the primary measure of progress”
Principle 7 – my personal favorite – is the often incorrectly done task of measuring software in working features. You may have heard of the Ninety-Ninety rule that says when a software task is ninety percent done, the final ten percent takes just as much time to complete as the previous ninety. This makes light of the common pitfall of measuring a task by what’s been developed so far without accounting for testing, things breaking, revisions, refactoring, and all the other reasons we’ve attached to timeline extensions.
By measuring the progress of what has been completed, you plant your feet and say “this feature works, and the client accepts it” indicating that your team is now ready to focus on something else. As you can guess, working software doesn’t just refer to the final product, it also refers to the deliverables in principles 1 and 3 in which every iteration should have a working feature to show the client. Tracking outputs is a key way to validate that your Agile process is functioning effectively.
8. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
The bane of any crunch-time enthusiast, principle 8 specifies that an Agile process can be done indefinitely – without the development team combusting. Having to regularly put in extra time to meet deadlines can quickly wear down a team. This kind of pace is sporadic and unsustainable and by definition not Agile. This does not mean you have to work slowly, it just means you have to work at a pace that’s sustainable – be it slow but deliberate refactors, or fast but calculated deliveries.
Though a good project manager would never think of a project’s timeline as indefinite, it’s almost guaranteed that there will be post-production work that can build up over time. Chances are that if you crunched to deliver a project, you’ll be under pressure to crunch to address the issues afterwards to stay in line with that precedent of speedy delivery. Specific processes aside, if you want to be Agile you need to organize your process so that it can maintain its pace. If you don’t think your team can follow your processes consistently, changes should be made.
9. “Continuous attention to technical excellence and good design enhances agility.”
The 9th principle is hard to commit to for any corner-cutters as it specifies that agility is improved by doing best-practice work. During a software project, it’s enticing to save time by doing something less-than-excellent, despite the fact that it could save time in the future if good design choices were made now. Making your attention to excellence continuous (there’s that word again) improves how you handle complexity in the project, which as we’ve mentioned, is part and parcel with Agile. Committing to good design makes the code require less upkeep and reduces the technical debt which can slow down projects later on. Part of being Agile is making it easier to move fluidly through the entire lifespan of a project, so if doing something now would make development easier going forward, consider doing it.
10. “Simplicity – the art of maximizing the amount of work not done – is essential.”
Principle 10, the most likely to be on a LinkedIn post, talks about simplifying the scope by identifying what we don’t need to do. This is about working smart, not hard. By recognizing what adds value and what doesn’t, you can choose how to allocate your resources to best serve your project. Aim to identify what is and isn’t necessary, and use that to focus your efforts. Early on in a project, this often takes the shape of a Minimum Viable Product (MVP) – working software that meets the primary use-cases of its audience while leaving out the bells and whistles.
This is another hugely important principle, and one that doesn’t leave any ambiguity. Too often projects get bogged down by doing more than is necessary while important features are neglected; instead we should look at the work that doesn’t need to be done and maximize it. Being Agile never really means coding faster, but you get your speed boost by coding more efficiently.
11. “The best architectures, requirements, and designs emerge from self-organizing teams.”
In addition to being passionate, principle 10 asks that your team is also self-organizing for the best product. A self-organizing team is a group that can plan, estimate, and complete work by themselves while proactively engaging stakeholders as needed. This is a tenant that could fill an entire article, so for now let’s focus on the heart of the principle.
Letting a team organize themselves can be a hard sell for management but it’s all about saving time over the duration of the project. Managing a team is a lot of work and usually requires sizable meetings to give direction and understanding, but a self-organizing team is simply given a high-level primer and then allowed to run from there. Add this together with Agile’s iterative nature and regular engagements and control comes back because even though the team is managing themselves, you get to jump in more often to redirect the project as needed. This principle is hard to fully commit to right away as it involves trust, but if you want to be Agile you’ll want to give your team some leeway to organize themselves, even if it’s only a little bit to start.
12. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Finally, at principle 12, we talk about the heart of Agile: ensuring teams inspect their process and adapt frequently. None of this will be executed perfectly on the first try, even if you get a professional to implement Agile for every team they’ll adapt it to your unique team and business using reviews and retrospectives. Throughout this article we’ve called back to previous principles, but this one can be referenced in every instance of Agile because no matter what you’re implementing, you should make time to inspect what you’re doing and adjust how it works until you’re comfortable. Thankfully this is also one of the easiest principles to perform, simply set aside some time for your team to really look at what they’ve done and then give their own insight on how it can be adjusted to work out better – easy as that! As always this is a principle meant to be done frequently because just like we engage early and often to satisfy the client, we can do the same for our process to satisfy the team. When it comes to being Agile, I wouldn’t recommend trying any principle until you are comfortable with this one as it is important to all aspects of the ideology.
Summary
It is through these principles that we can truly be Agile, something that simply following a framework can’t replicate. Though it is more likely these will stick on your cubicle wall instead of in your memory, understanding their application and how everything ties together makes it easier to embody. Knowing the 12 principles strengthens your understanding of any Agile framework and gives you much-needed direction when there isn’t a script to fix an issue with your project. Simply read them over once in a while, understand the benefits each has, and keep in mind how you can react to opportunities. So next time the Agile thing to do is not clear, remember the 12 principles and be Agile!
Are you looking to hire a software developer? You’ve come to the right place, every Scalable Path developer has been carefully handpicked by our technical talent team. Contact us to start the hiring process.