While it’s common these days for companies to claim that they follow an Agile development lifecycle, it is uncommon for companies to measure and evaluate the efficacy of their Agile implementations. What’s the point of performing all the Agile methodology ceremonies (e.g., SCRUM) if they don’t deliver the promised benefits? How do you know what things you can or should change in your Agile implementation if you aren’t evaluating your adherence to Agile principles and evaluating their results?

We at AKF don’t believe there is a single right methodology for achieving product development agility. Rather, we evaluate Agile implementations based on the twelve principles of Agile development. This series of blog posts evaluates the twelve principles and attempts to:

  • Explain why each is valuable and what it is meant to do
  • Give examples as to how ceremonies or metrics should be constructed around the principle.
  • Explain some of the pitfalls that are common with addressing the principle.

This first post covers the principles of customer satisfaction priority, welcoming changing requirements, high delivery frequency, and business team interaction.

Principle 1 – Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.

Reason it exists: The creators of the Agile Manifesto emphasized that too many teams lose focus on delivering valuable software quickly. Our job is to create value, and software is the tool we employ. Delivering that value faster and more often benefits everyone.

Examples: The concepts of flow and cadence within Kanban are meant to help focus teams on this. Short sprint durations and velocity metrics are meant to do this within Scrum.

Potential Pitfalls: The most common failure here is in not identifying a metric of value creation. Velocity, for instance, is not a measurement of value; it’s a measurement of throughput. As such, we need a way to help teams understand the value of what they are creating. Value creation, after all, is the whole reason why we develop software. Why do we not measure that creation more frequently?

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

Reason it exists: For at least 50 years, most engineering teams fought against changing requirements. An extreme example of this resistance is companies like Motorola in the 1990s that would actively catalogue changing requirements as a defect in the requirements phase of their lifecycles. The reason behind these activities were simple – changing requirements increase the cost and time to market for a product. That perspective, while partially correct, is also fatally flawed.

Requirements change because our understanding of a market or customer needs changes. The idea that any person or team’s first idea or approach to a problem is the most effective approach ignores the facts that we are both imperfect and that the world is not static; we rarely get things right the first time and things change over time. Therefore, the best products are ones that adapt, even in development, to changing needs and new information.

Being dynamic, agile, and recognizing and embracing change can absolutely create a competitive advantage relative to companies that practice static development and believe their first ideas are always the best.

Examples: The way the most adopted Agile methodologies address this principle is by time-bounding development cycles. In the case of Scrum, short development iterations give an opportunity for changing requirements (stories) to be modified in a backlog before they are begun. If a story changes after a development cycle, the waste of the prior effort is minimized through the short development cycles.

Potential Pitfalls: The polar extremes of being too dynamic and too static are both pitfalls relative to this principle.

Too Dynamic: You can allow too much change. Allowing every change without question may result in teams stuck in development cycles with very little to show for their efforts. Ensuring that there is governance regarding the cost and time of development helps fight against this. Make sure the decision makers for changes are also being held accountable for the cost and impact of their requested changes.

Too Static: This is essentially the problem the principle attempts to fight. Change should be welcomed and embraced, but also properly vetted and understood.

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

Reason it exists: The purpose of this principle is multi-fold:

  1. Reduces the cost of changing requirements through short intervals that help isolate the effect of change to total development cost.
  2. Reduces the false precision bias associated with very large estimates; people are better at making precise measurements on small-scale initiatives.
  3. Reduces time to market by forcing teams to focus on small incremental additions to capabilities that result in massive changes over time.
  4. Reduces risk and cost of failure through small incremental efforts.

Examples: While Kanban doesn’t force short iterations, it does recommend release cycles of less than 1 week. In most implementations, when combined with the continuous process improvement focus of Kanban, efforts for most initiatives are short. Scrum enforces short, predefined iteration cycles.

Potential Pitfalls:

  • Kanban implementations may be advised to include iteration boundaries or maximum effort sizes to help enforce this principle.
  • Cycles of 1 week or shorter may be too small for valuable progress.
  • Cycles of 1 month or longer start to suffer from false precision bias and higher cost for changing requirements.

Principle 4 – Business people and developers must work together daily throughout the project.

Reason it exists: Waterfall methodologies separated teams critical to producing a solution from each other. This separation:

  • Creates difficulties in developing proper requirements – too little interaction leads to poor requirement creation.
  • Increases pipeline delays in delivering solutions – waiting to schedule meetings with people you seldom interact to resolve delivery problems.
  • Increases the probability of miscommunication on status, needs and challenges which in turn decrease the probability of success

Examples: The notion of a product owner embedded within Scrum teams is how Scrum attempts to solve this problem. But you need not follow Scrum to benefit from business interaction. You simply need to ensure that someone empowered to make product decisions for the benefit of the customer is embedded within each team.

Potential Pitfalls: The most common failure we see here is when teams define roles such as a “technical product owner”. The purpose of this principle is to ensure that the people who are making decisions about the business and product are involved in the development of the product. Roles like business analysts and technical product owners do not solve the need of the business (or product) needing to be involved in actual development. Instead, these roles add an additional layer between the business/product person and the technical team doing the work.