According to the Agile Alliance, Agile Software Development is an umbrella term for a set of methods and practices based on the values and principles expressed in the Agile Manifesto.

Therefore, we cannot succeed with Scrum, Kanban, Lean, or any other Agile framework unless we deeply understand and live by Agile’s values and principles. While many people are familiar with Agile’s values through the Agile Manifesto, the principles are less well known. I’ll share them with you, along with a couple of thoughts for each that I have discovered along the way.

So what are the Agile Principles?

• Principle #1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • One of my favorite sayings is “Waste is anything the customer doesn’t want and isn’t willing to pay for.” Planning is essential. Agile events are useful. Technical spikes to explore new technologies can give us architectural runway and new competitive advantages. But, at the end of the day, customers pay us for working software and services, not the effort that got us there.

• Principle #2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Agile embraces empiricism. It is almost a guarantee that we will be more knowledgeable once we have commenced work on a project than at the beginning. Our customers will learn more about their own needs when they see an increment of our work. Let’s not forget that our competition isn’t standing still, either. So, inevitably, you will learn something during the development cycle that clearly demonstrates that the current plan is not wise, possible, or both. Welcoming changing requirements means that we are being empirical and data-driven. This isn’t to say that we should get in the habit of constantly interrupting work-in-process: as long as whatever is being worked on now is still valuable, try give your team the time they need to finish what they’ve started before you introduce a change.

• Principle #3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • This principle frequently draws controversy. For a startup, every two weeks seems like an eternity, whereas a giant, lumbering publicly-traded corporation can take two months to get code through their bureaucratic approval and deployment process. The more frequently you deliver software, the smaller and less risky your releases… and the more likely you have good automation. The more frequently you deliver software, the more chances you have to get and incorporate feedback from your customers in real-world use of your product.
  • Not every customer base can handle very frequent releases. In these cases, it can be useful to identify a cohort of your customers who will accept or even embrace frequent releases and give them early and frequent access to new features. Worst case, you deploy frequently to a staging environment and test it internally or consume your new features internally.

• Principle #4. Business people and developers must work together daily throughout the project.
  • This principle also draws controversy, particularly from developers who have had to deal with micromanagement or harassment from project managers or other stakeholders. At the very minimum, I suggest that the product owner—who acts as a proxy for business people and customers to the team—work with the team daily to clarify requirements, accept work, and help remove impediments. It’s also effectively Scrum “table stakes” to have business people attend Sprint Review each sprint. But if business people attend the Daily Scrum, participate collaboratively, and remain available and accountable to their teams, these teams will enjoy significantly greater job satisfaction and performance.

• Principle #5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • First, In his book “Drive,” Daniel Pink explains that the three things that motivate us the most are autonomy, mastery, and purpose… not financial rewards. So, I’d suggest that your Scrum Master, Kanban Flowmaster, or whomever else is in that Agile facilitation role make it their mission to gain greater autonomy. Functional managers, senior developers, and architects can help developers gain greater mastery. And a Product Manager can create a sense of purpose by articulating a powerful “why” for the team’s product.
  • Second, our typical modern management culture is a bit like an Olympic athlete who focuses only on what it will feel like to win the gold medal rather than investing in the training that enables victory. Similarly, we must focus on developing our employees’ full potential so that they have the means to deliver the wins that we so desire.
  • Third, we must allow space for genius. For instance, we now write brief user stories that cover the essential points and invite conversations between developers, product owners, and stakeholders. This is a far cry from detailed software engineering requirement documents that attempt to control every last detail of software development, often written by the people on the team with the least software developing expertise.

• Principle #6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • I think this principle covers a few things: first, don’t let written documentation or requirements get in the way of talking to one another… this is all about customer collaboration over contract negotiation. Second, there is no substitute for collocation. Just as we travel to see friends and family so that we can see them face-to-face rather than just talk on the phone, so too can we have higher quality of interactions when we are physically together. Third, events such as Sprint Planning are valuable because they allow for a greater volume of communication to occur in a shorter period of time. Never underestimate the difference in communication quality and bandwidth between several people exchanging emails asynchronously versus standing at a good whiteboard together.

• Principle #7. Working software is the primary measure of progress.
  • This is a lot like the first principle, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” To a product manager, it can feel like a big accomplishment to get a software requirements document signed off by stakeholders. For a developer, it can feel good to turn over a feature to a quality assurance engineer. However, although these activities are frequently prerequisites to delivering working software to customers, no value can be captured by the company for these efforts until working software is in production.

• Principle #8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Developing software should be feel more like running a long marathon rather than back-to-back sprints. Excessive effort can rapidly exhaust teams, burn out employees, and even impact relationships at home. One of my favorite ways of looking at this is through the Yerkes-Dodson Law, which shows us that as physiological arousal (e.g., stress, anxiety, and panic) increases, our performance on complex tasks such as product strategy and software development becomes rapidly compromised.

• Principle #9. Continuous attention to technical excellence and good design enhances agility.
  • An absence of good code management, integration, testing, and deployment rapidly comprises a team’s performance. Poor design decisions can paint a team into a corner. And failing to address bugs and technical debt—often due to delivery pressure from stakeholders—rapidly makes a codebase unmaintainable, let alone easy to develop against.

• Principle #10. Simplicity–the art of maximizing the amount of work not done–is essential.
  • More features or poor architectural decisions make a software more complex. Highly complex code is harder to test, maintain, and develop against. Many products have features that are so rarely used that their development and maintenance likely result in a negative return on investment [clippy]. In general, it is better to have a targeted product that a does few things extraordinarily well—being everything to someone—rather than one that attempts to capture the whole market but pleases no-one.

• Principle #11. The best architectures, requirements, and designs emerge from self-organizing teams.
  • This too can be controversial, particularly for people who are used to coming up with architectures, requirements, and designs but aren’t part of the teams. The two most common arguments I hear is that a company’s teams don’t have the necessary skills to do this work and someone needs to ensure standardization between teams. To the first argument, I suggest that a company invest in its employees and that the employees invest in themselves so that they can both remain competitive. To the second argument, this standardization often does not have a positive ROI, and if it’s expected to, why not have the teams talk to one another?

• Principle #12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • To me, this is far and away the most important principle. All of these Agile values and principles—and with them all of the benefit that Agile provides—came from expert teams applying the empirical process to optimizing how they work. Perhaps your team wants to vary from an Agile framework’s default process. That’s fine! Reflect, plan a new experiment, do the experiment, check the experiment’s results, then act on what you found. Plan. Do. Check. Act. This is powerful, and if you keep it in mind you can do it at every event from the Daily Scrum to your Sprint Planning.