The Manifesto for Agile Software Development, commonly known as the “Agile Manifesto,” is one of the most well-known artifacts in the world of Agile development. Although many of the principles are fairly common sense, some are a bit mysterious. Hence, I will make my best effort to clarify the intent behind the 12 principles of the Agile Manifesto to help teams gain a better understanding of this important doctrine.
Principle #1 – “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
What does “early and continuous” mean? This is suggesting that you try to build just a subset of the functionality that your customer is asking for so that you can show value quickly, and if possible, in a consistent manner. Don’t wait until you finish the entire product before you share the work!
Principle #2 – “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”
This is potentially a tricky one that often creates confusion. How do we handle changing requirements late in the development cycle? That doesn’t seem achievable, and sounds very costly, right? The thinking here is that you welcome changing requirements, but you do NOT necessarily change your plans to accommodate the new (or revised) requirements. You provide an avenue for customers and stakeholders to offer new ideas so that you can incorporate them into your next release (or iteration).
Principle #3 – “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
This one should be fairly simple. Show the customer a working system on a regular basis so that you can build confidence and provide a natural checkpoint to get feedback. Early feedback is an important step that gives your team the opportunity to make adjustments as needed.
Principle #4 – “Business people and developers must work together daily throughout the project.”
This fourth principle really sounds like common sense, but it may actually be very difficult for some organizations to practice. If a company is a product-based business, there should be business leads that can provide the necessary feedback and inputs to the technical engineering teams. This type of collaboration is an essential part of ensuring the right product is developed to solve the right problems.
Principle #5 – “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
This one almost seems redundant, right? Why would we not want to have motivated individuals on our project team? This almost seems like a given unless you read the words more closely. This principle states “build projects AROUND motivated individuals,” which means you bring the work to the people. The distinction is very subtle here, but giving work to your best people is actually quite different from assigning people to a project. The difference is that you are giving work to a TEAM, and not just a GROUP of people; a TEAM has demonstrated the ability to collaborate effectively and deliver results time after time!
Principle #6 – “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Effective communication is absolutely critical to a successful project. This means avoid e-mail or even phone calls if you are able to have in-person collaboration. There are many studies that have proven this to be true.
Principle #7 – “Working software is the primary measure of progress.”
To be successful in applying Agile practices, we need to have proof of working product. Hundreds of pages of documentation are not good enough; they provide limited value to the end users and customers.
Principle #8 – “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
To encourage long-term success, we should promote work-life balance and avoid pushing our teams to over-extend themselves to achieve short-term objectives. Focus on quality not quantity!
Principle #9 – “Continuous attention to technical excellence and good design enhances agility.”
This is an important one because teams quite often forget that sound engineering practice is still required even if Agile practices are being implemented. There is no replacement for good design and flexible architecture.
Principle #10 – “Simplicity--the art of maximizing the amount of work not done--is essential.”
Principle 10 is one of my personal favorites because it inspires a lot of thinking and leads to many questions in my training classes. The way that this phrase is written often creates confusion, but I actually really like this sentence. The art of maximizing the work NOT done means that we pay special attention to avoid doing things that we know do not add value for our customers. In other words, we explicitly identify and call out things that we will not expend energy and time on because we make a conscious determination that these work items will not provide meaningful benefits. This is analogous to a Project Charter that contains an “Out of Scope” section which clarifies what the project will not deliver so that ambiguity is minimized.
Principle #11 – “The best architectures, requirements, and designs emerge from self-organizing teams.”
Self-organizing teams are ideal for Agile development because they will think creatively and build a sound architecture that supports long-term project success. How do you assemble such a team? That will likely require another, more lengthy discussion, but you can start by motivating the team to make decisions on their own and provide guidance on how to adapt when things don’t go as planned.
Principle #12 – “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Continuous learning is a critical component of any healthy, productive Agile team. By practicing Retrospectives consistently and effectively, your team has a much better opportunity of learning from both its successes and failures which will provide important knowledge in the long run.
That concludes my quick overview of the 12 principles from the Agile Manifesto, and what they really mean. I hope this helps you connect with the keen knowledge that our Agile forefathers have imparted on us!