From its humble beginnings in software development, Agile has spread to nearly every function within a typical business. In the process, its core ideas have been adapted time and time again. Various Agile manifestos each take their own approach to Agile principles.
It’s no surprise how easy it can be to get stuck in the weeds as you try and figure out how to adapt a specific manifesto to your needs. For example, if Agile focuses on stakeholder value, who is the stakeholder in HR? If you have multiple stakeholders, like in creating contracts, do you just ignore this?
Ultimately knowing how to adapt Agile comes down to understanding its core principles. So let’s run through how several major Agile manifestos each approach principles to appreciate what connects them all and what you can learn from them.
Agile, as we know it today, got its start at the beginning of the millennium when 17 software developers got together to develop a new way to address the grinding inefficiencies of their work processes. They were tired of working on projects for months (or years) only to deliver something that no longer met customer requirements.
That’s how the original Agile framework focused on shortening the time needed to deliver benefits to users and to quickly gather feedback. By combining improved speed to market, more rapid feedback, and continuous improvement, Agile could overcome the frustrations developers experienced in the early days.
Based on that Agile manifesto, its creators also developed 12 Agile principles to further clarify the goals, methods, and ideas behind Agile. All of this was designed to avoid one thing: fake Agile.
The Agile world is full of misconceptions. They often result in “Fake Agile”, which is essentially when you think you are being Agile but are not. For example, you may start using daily standups or tracking your work on a visual board. However, at the same time, you may be spending months working on something before ever showing it to a stakeholder.
In other words, you’re working more or less the same way as before, just with a few tweaks. This often results in people thinking they are Agile but wondering why they’re not getting the benefits. In other words, teams end up with the worst of both worlds. The best way to avoid this is by understanding the underlying principles behind Agile ways of working.
Even within the world of software development, the originators of Agile knew that it could be approached in many different ways. That’s why they began with a manifesto designed to guide teams in using it. This resulted in 12 Agile software principles.
What’s interesting is that the majority of these 12 principles can, and will, be applied to areas outside of software development. Only a few are really specific to software development. For example, principle seven states that “Working software is the primary measure of progress.” While that’s obviously specific, it also reflects the general principle that Agile is about delivering value to shareholders, not excuses, documentation, or anything else.
The other more specific Agile principle to be found here is number nine, “Continuous attention to technical excellence and good design enhances agility.” Again this is somewhat specific to software, but the focus on quality also reflects the broader Agile focus on stakeholder value. Delivering something subpar just to be able to say it’s delivered is not Agile.
Now let’s look at how Agile principles evolved and adapted to meet the needs of other functions.
Looking at the 10 principles of Agile marketing, it’s clear that they closely match the 12 originals from software development. The single standout is principle nine, “Continuous attention to marketing fundamentals and good design enhances agility,” which discusses focusing on marketing fundamentals.
This is a version of the technical excellence principle but instead focuses on the fact that being Agile and experimenting often should not come at the expense of marketing fundamentals. In other words, don’t do things differently just for the sake of doing things differently and think you’re being Agile.
In a way, this reflects good experimental design. When designing any kind of experiment, whether in science or marketing, your hypothesis shouldn’t be random. Any experiment you want to try should be based on an educated guess regarding what might improve performance.
Because Agile sales is still relatively new, you can find many different versions of Agile principles applied to the sector. That said, most examples of Agile sales principles out there closely follow the precedent set by other Agile principles.
For example, they emphasize the value of face-to-face meetings, frequent collaboration, focus on customer value, etc. One interesting difference is an emphasis on “responsible and ethical sales practices.” Another mentions “close alignment, transparency, and quality interactions with internal and external customers.” However, this mostly reflects the same attention to quality and providing real value that we mentioned previously.
Looking at how Agile principles have been adapted to contracts shows how you can create principles that are quite different from those mentioned previously while sticking to the same core ideas.
For example, instead of focusing on stakeholder value, the first principle here states that “highest priority is to create a positive outcome for the ultimate customers and for all contracting parties.” This reflects the reality that contracts don’t have a single stakeholder while still giving those using these principles a focus on creating real value for those involved.
Principle 3 mentions consistent rules for the sake of transparency, integrity, empowerment, autonomy, etc. on the part of the contracting parties. You won’t find anything similar in the other lists mentioned here, but the ultimate goals this principle seeks to promote are precisely what all the Agile approaches mentioned here aim for.
Throughout the list, you find principles that initially sound totally unique, but on further inspection actually promote common Agile values. This is an excellent illustration of how Agile can be modified substantially while not succumbing to “fake Agile”.
Much like the Agile contract principles, Agile HR’s list of principles looks substantially different at first glance. This reflects the reality that, unlike all of the other functions mentioned here, HR isn’t usually working to produce a kind of product. Instead, this example shows how Agile can be adjusted to better manage and empower people.
Principles like “Invest in human connections and build strong relationships; and care about the happiness, health and welfare of your people” look very different from the other lists of Agile principles we’ve mentioned. But the reality that Agile is built on a foundation of trust, transparency, accountability, and empowerment means that from an Agile HR perspective, this is just as important as something like continuous improvement.
Put another way, HR’s Agile principles are designed as much to enable Agile working with others as they are to use Agile in HR itself.
If there’s a single takeaway from comparing these six different approaches to Agile principles it’s that they are remarkably similar. For the most part, each one simply adjusts language to reflect the specifics of their function while keeping the general idea exactly the same.
Only functions like procurement or HR in which the basic style of work, in which a team produces something for a single stakeholder, is different do the Agile principles vary significantly.
This shows just how adaptable Agile principles are in practice. But it also shows that what makes Agile work in all of these contexts is the fact that these dozens of principles all relate back to core ideas found in the original Agile manifesto.
Much in the same way an engineer can apply the same principles towards building a bridge or designing a car, an understanding of Agile fundamentals is what empowers practitioners to freely apply Agile in a huge variety of ways. The trick is getting that foundation.
Here at AgileSherpas, we’ve recently launched a new platform specifically designed to make it easier to learn Agile theory. Whether you want to learn as an individual or bring your entire team up to speed, we make it easy to use self-paced, instructor-led, and social learning to get those key fundamentals down.