12 Principles of the Agile Manifesto – What Do They Really Mean to Practitioners?

Eugene LaiMon, 03/11/2019 - 16:49
Subject

If you have been practicing Agile or are considering it, chances are you have read the Agile Manifesto at least once. Most of the principles described in this artifact seem fairly common-sense, but some could be somewhat mysterious if you have not personally experienced them in practice yet.

I would like to try to dispel some of the mystique regarding the 12 principles and hopefully help you make sense of this. Afterall, our chances of successfully applying the practices will improve if we actually understand the underlying ideals, right?

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

This one is relatively simple, or is it? We should focus on delivering working product to the customers early but also “continuously”. [node:summary]what does that mean? Do we need t[node:summary]If you have been practicing Agile or are considering it, chances are you have read the Agile Manifesto at least onceo deploy automated builds to the Production system every 12 seconds like Amazon? Maybe not. What this is suggesting is that we try to consistently and incrementally provide working solutions, because that’s what the customers want.

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

This principle is saying that we should encourage change instead of trying to minimize change as most traditional waterfall projects tend to do. Does this mean that we should allow last-minute requirements to be added to the scope? Not necessarily. If the team is confident that they can absorb the change without sacrificing quality, perhaps that is an acceptable strategy. The key words here are “welcome” and “harness”; take advantage of the ability to pivot and adapt if the situation enables you to exploit an opportunity to exceed expectations.

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

Consistent and incremental delivery of working software/system is central to the key advantage Agile brings to the table. Don’t wait months/years to deliver all of the features; iteratively share viable products and get it to market sooner rather than later so that we can understand whether the solution meets the customers’ needs.

Principle #4: “Business people and developers must work together daily throughout the project.”

This one may surprise many people who come from a traditional way of managing projects, where business sponsors and solution developers only talk to each other at the very beginning and the very end of the project. This collaboration strategy has proven to be generally risky and ineffective, especially for software projects. Daily collaboration allows both business and technology workers to stay aligned and enable them to expedite decision-making and issue resolution.

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

Give the people the right tools and autonomy, and let them do their best work!

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

Translation: Don’t send emails! Have a discussion if something needs to be figured out!

Principle #7: “Working software is the primary measure of progress.”

Reams of documentation is not good enough. We need to show that the product is doing what the customer wants and needs!

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

Let’s play the “long-game”; don’t make people work weekends and holidays. Give them a chance to do their best work over a long period of time so we can establish positive momentum and build on our success.

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

Just because we don’t have a “Design phase” in the project plan does not mean we no longer need to follow best practices for engineering!

Principle #10: “Simplicity--the art of maximizing the amount of work not done--is essential.”

This is one of the more confusing items on this list. How do we “maximize the amount of work NOT done”? What this is telling us is that we should consciously think about what we will NOT do, similar to traditional project charters that state what work is “out of scope”. Deciding on what we will not do can be as important or more important than choosing what work we will do, because this enables us to clearly understand the priorities and focus on getting those done.

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

“Emerging design” is often a difficult concept to understand. This item is encouraging teams to innovate and come up with creative solutions without being confined by a written contract or an outdated document that was created months or years ago.

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

Reflection is an important part of Agile practice because of the empirical nature of this approach. For Agile to be effective, we need to learn from real-world experiences and gleam something useful from them so we can adapt how we do work. This is a critical step to ensure the team builds a continuous-learning mindset.

So, there you have it. It’s not so bad after all, right?