The 12 Agile Manifesto Principles Explained
Do you want to get more out of your Agile team?
Do you want to better understand how to manage an Agile team?
Do you want to contribute more as a member of an Agile team?
… then this is the blog for you.
Prior to the Agile Manifesto and the Agile principles, software was delivered using the waterfall project management approach which led to a large number of project failures and software teams having a bad name. Due to the this fundamental flaw in how software project were delivered, a few smart and frustrated software engineers gathered together to revolutionize how software projects should be delivered. It cannot be overstated, what an impact the Agile Manifesto and the 12 Agile Principles have made to the software development industry and the world at large. Agile is not only being used for software development. It’s principles have been adopted in other industries like manufacturing, marketing, and building new businesses just to name a few. If you’re in business, you’re a technology company whether you like it or not. If you’re a technology company you’ll need to adapt and innovate at a rate faster than your competition. For your business to be able to do this, it’s not just your IT or software teams that need to understand Agile but your entire business. Below, I’ve listed the 12 principles and extrapolated their meaning.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
With an adaptive methodology, a product is delivered incrementally and iteratively with a deliberate cadence. Here, software can be delivered throughout the project so the team can gather feedback and insight to then be used to develop the next increment of software. In addition, when continually delivering small increments of software, it allows the customer to generate value consistently throughout the project.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
With an adaptive methodology, it is much easier to accept continual data, insight, feedback into the product lifecycle to meet the changing needs to the customers, users and market. This is in direct contrast to the prescriptive methodology whereby much of the documentation and specifications are completed at the beginning of the project and any subsequent changes usually incur a significant cost.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
In this Agile principle, it states that software delivery can be from a couple of weeks to a couple of months e.g. two months. Scrum is one of the most popular Agile frameworks and prescribes that Sprints can be no longer than one calendar month. So, eight-week sprints will be Agile but not Scrum compliant.
4. Business people and developers must work together daily throughout the project.
Regardless of whether you’re developing using Agile or a different project methodology, the idea of business people and developers collaborating throughout the project is always a good idea. Having said that, nobody likes half their week taken up with meetings. Scum prescribes specific meetings at specific times and locations. Scrum also prescribes who should and should not be at each meeting which delivers a cadence to the team’s communication and collaboration without hindering progress. Further to this point, an adaptive methodology like Agile and Scrum cannot work without the constant collaboration between the business, customers, users and the development team. How the business and development team communicate to deliver the next increment is critical to the success of the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Due to the fast pace and constant changes within an Agile environment, management need to be able to trust the product and development team to make the right decisions based on the project vision and mission. It’s simply not possible to escalate issues to management and wait for a decision. Further to this, employees who are given the ability to make decisions and feel like they are contributing to the greater whole are generally happier and more productive.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Having the whole project team in the same physical location allows them to learn about everything by osmosis. If they here a discussion and know the answer, they can simply turn around and answer it instead of sending an email, having a ticket raised, or creating an unnecessary Issue in Jira.
7. Working software is the primary measure of progress.
A team’s velocity is not a measure of success. The number of Jira Issues a team completes is not a measure of a team’s success. The number of lines of code is not a measure of success. The number of people hours spent on a project is not a measure of success. Working software is what it’s all about. What is the piece of working software that delivers the highest value to the business and its customers?
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
There is a temptation for management to push a product and development team to increase the output of each Sprint, work longer hours, etc. The reality is things break, including teams if pushed too hard and too fast. Productivity decreases while bugs and errors increase. It’s more beneficial to keep the product and development team happy and healthy working at a constant pace and delivering high quality potentially releasable software.
9. Continuous attention to technical excellence and good design enhances agility.
One of the perceived risks in Agile is that because there is less upfront planning than in traditional waterfall style projects, the project is more likely to fail. This, however is addresses with developing the Agile team themselves to mitigate this risk and being adaptable enough to address any issues that arise.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
I love simplicity. I love minimalism. I love doing what is required and nothing more to achieve the desired outcome. From a product perspective, this principal suggests that an Agile team should build exactly what is necessary so the product provides a solution to the customers pains, gains, jobs to be done (jtbd). Adding unnecessary features increase build time and cost while also increasing support and maintenance costs.
11. The best architectures, requirements, and designs emerge from self-organising teams.
Agile is all about empowering the product and development team to find solutions to the problems presented and supporting them in the process. Agile works well when teams self organise and are not micromanaged within a strict hierarchical structure.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Within Scrum, there is a meeting called a Retrospective that occurs at the end of every Sprint. Think of it like a lessons learned document that occurs at the end of every waterfall project. The difference here is that a) the Retrospective occurs at regular intervals and the lessons learned are immediately applied to the next Sprint.
I hope you found this helpful.
As always, if you have any questions, feel free to reach out or leave a comment below.