This is the third part of a multi-part series on how to perform evaluations of Agile Development Processes. The first article in this series evaluated the first 4 principles of the Agile Manifesto as an approach to perform Agile evaluations. The second article focused on principles five through 8. This article completes principles 9 through 12.

Principle 9 – Continuous attention to technical excellence and good design enhances agility

Reason it exists: This principle addresses the need for continuous, rather than discrete or periodic, architectural review and analysis. Many teams refer to this as “evolutionary” rather than “revolutionary” architecture. By continuously focusing on our architectural needs, and making maintenance modifications over time, we can avoid the costly and risky approach of re-implementation. No more “next generation” initiatives.

Examples: We are not aware of any methodology that enforces the notion of continuous design and architecture. Rather, it is something that you will need to “build into” your Agile implementation.

Potential Pitfalls: Many teams reference this principle when they embark upon the dissolution or elimination of an existing centralized architecture team with periodic reviews. While this elimination may make sense relative to the principle, it also very commonly results in losing guidance and standards that help ensure uniformity between teams.

You likely need a centralized architecture team, however you do not need this team to conduct design reviews on work completed by other teams. Those reviews and analysis should be performed by individual teams leveraging the principles, patterns and anti-patterns of the centralized team. The centralized team then works with product management to help inform the art of what is possible and to distribute architecture improvement stories to each of the delivery teams.

Principle 10 – Simplicity--the art of maximizing the amount of work not done--is essential.

Reason it exists: The focus of this principle is wide-ranging and multi-fold:

  • For a product owner, this means pushing back on what constitutes a minimum viable product for either a whole product or a feature. The more work we put into something, the higher the probability of wasted work. As much as 50 percent of what we build either never gets used or does not achieve the expected return. By minimizing work per release, we minimize the probability of “wasted effort”. Upon release, with actual usage, we are likely to glean new insights that take us in different directions for our next short iteration. Short iterations with limited functionality are always better than long iterations with extensive waste.
  • For engineering teams, this means eliminating “make work”. While documentation is useful, most documentation is wasted effort with long living documents that rarely get updated and are essentially incomplete or worse misleading over time. Focus on good verbal communication with limited but valuable supporting documentation. Eliminate activities that are not clearly value add. Cumbersome time tracking processes, while necessary in some contexts, are often an example of velocity destroying activities.

Examples: Examples of processes to consider eliminating or streamlining include but are not limited to:

  • Cumbersome time tracking solutions tracking each activity.
  • Extensive documentation processes that are rarely referenced or maintained.
  • Meetings outside of operational standups that require the entire delivery team to be present.
  • Extensive manual checklists that might otherwise be automated as in a CI/CD delivery pipeline.

Potential Pitfalls: The following are some extreme examples that teams have implemented in the name of this principle. These are offered as examples of “what not to do” when following this principle:

  • Elimination of all documentation. Everyone abhors documentation. But zero documentation is never the answer. Your documentation should cover basics and things that are unlikely to change.
  • Elimination of KPI gathering and analysis of KPIs. Many teams despise data collection and go to extremes including elimination of velocity calculations. More still never attempt to calculate the efficacy of their products in profits or end-user benefits. All of these are necessary inputs to improvement processes.
  • Elimination of retrospectives and learning. Whether eliminated or never implemented, and as we will see in Principle 12, these are necessary for continuous improvement.

Principle 11 – The best architectures, requirements, and designs emerge from self-organizing teams.

Reason it exists: Teams inherently have a better collective understanding of their capabilities than any single member of that team has of the team’s capabilities. When teams work together to determine what should be done, and who should accomplish component tasks, they communicate both their desires and their capabilities with both being valuable to an outcome. Desire often increases drive which increases quality and decreases time to market. Experience obviously benefits the solution as well. Morale in self-organizing teams increases as teams report more autonomy. Such teams enjoy low relative turnover.

Examples: Neither Scrum nor Kanban provide much help here beyond lip service to the notion of being self-organizing. The test is in what managers and leaders need to do to get a team moving. Success is being able to describe a goal and outcome without needing to decompose either into tasks that are then assigned to the team. Failure is when managers must decompose objectives into tasks and assign them to specific individuals.

Potential Pitfalls:

  • “Self-organizing teams don’t need managers”. Not true. Ever. Someone is funding this team – that might be an owner, or it may be the proxy of the owner through a manager. That manager is responsible for delivering goals and desired outcomes to the team. A team is self-organizing if they can then develop tasks and work them without the manager breaking those tasks down. Someone or something still needs to define goals and outcomes and evaluate the team against the desired results.
  • “Self-organizing teams don’t need principles, standards, patterns or anti-patterns”. Rarely true. The only case where this is true is when a team is small and represents an entire company. As additional teams are added, principles and standards need to be present to ensure some level of consistency and interoperability. Those things don’t happen when teams are completely isolated.

Principle 12 – At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Reason it exists: This is the concept of retrospectives in both Scrum and Kanban. This critical principle addresses the need for continuous process improvement. What went well? What went poorly? How do we have more of the good and less of the bad? What processes or approaches should change? What products were successful, and which weren’t?

Absent this, the team becomes the opposite of Agile – static in their thinking and approach.

Examples: Retrospectives prescribed in both Kanban and Scrum are examples of this principle.

Potential Pitfalls: The most common pitfalls with this principle are two-fold:

  • No Retrospectives. Eliminating retrospectives eliminates the opportunity to learn, mature and become more successful and efficient at what we do.
  • Rubber Stamp Retrospectives. This is more common, with teams performing 15-minute retros as a “feel good” end of iteration event. Retrospectives should be blameless, difficult and enlightening; they should highlight failures and suggest fixes.

Our series continues in part 4 with common Agile implementation questions.