This is the second 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.  This edition focuses on principles 5 through 8 of the Agile Manifesto, explaining the reasons for the principles and giving examples and possible pitfalls of which to be wary.

Principle 5 – Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

Reason it exists: There is a lot to parse in these two sentences.

  • Building around individuals – bring work to individuals, do not form teams around work. The notion of a team is important, and Tuckman’s phases of development clearly indicates we need to keep teams together for extended periods of time to ensure they achieve the “performing phase”.
  • The environment a team needs includes ensuring they have all the necessary skills to get the job done, as well as the tools and capital to achieve their goals. Support includes helping eliminate barriers where they occur.
  • Trust is critical to success and is a two-way street.  Teams trust management when they receive the resources and support they need.  Managers can only really trust teams if managers provide the tools, support, and personnel to achieve the mission.  A failure to provide those will result in mission failure, and the breakage of trust between both the team and manager.

Examples: Very few of the “out of the box” Agile methodologies address team construction. Scrum attempts to address “support” with the inclusion of a Scrum Masterr meant to offload lightweight processes management and metric gathering from the team. This support helps the team focus on execution.

Potential Pitfalls: As indicated above, a process-only focus (e.g. focusing on Scrum or Kanban ceremonies) misses the need to build a self-sufficient team. You cannot effectively trust a team to get a job done if you have not given them the capital, tools and people to achieve the desired outcomes. Furthermore, forming teams around work guarantees that team will be in the Forming and Storming phases of development, with unnecessarily low throughput.  Compare this with moving work to established teams that have established norms and ways of working; such teams will outperform newly formed teams every single time.

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

Reason it exists: This is another principle that reinforces the notion of being a “team”. Its focus is once again multi-fold:

  • Reinforcement of the notion that the business owner (aka product owner) is “part of the team” and should come and interact with the team in critical team meetings.  Eliminating the distance and separation between a team performing the work and a business representative requesting the work helps to reduce time to market, reduce confusing communication, and misunderstanding of intent.  Put simply, whomever is making decisions regarding desired outcomes and approaches should be with the team that produces the solution.
  • Interactions and request for help should be done in a face-to-face fashion, not through email or “ticketing systems”. This doesn’t mean that you can’t log the request for help – but rather that the request should be made face to face and discussed rather than made through an asynchronous system and “read” by a service provider.

Examples: Daily standups where everyone involved in making decisions or doing the work are present are the best example of how to meet this principle. Participants in those meetings should include everyone necessary to resolve issues in real time including a representative of the business decision maker (e.g. product owner), support personnel to cover infrastructure needs, QA, engineers, etc.  Blockers, things that impede progress, should be discussed in this meeting. Similarly, any request for help should be between participants within this meeting.

Potential Pitfalls: The existence of ticketing and service request solutions tend to be the biggest indicator that teams are not communicating effectively. When these solutions are used to initiate a request, they violate this principle. When the solutions are used to document requests after discussions, they do not violate the principle.  Business and product managers or owners who attempt to work through proxies such as technical product owners or business analysts are another violation of this principle.

Principle 7 – Working software is the primary measure of progress.

Reason it exists: Consistent with the AKF Equation (Results = Results; Nothing Else = Results), this principle highlights that working software and further the measurement of software production over time are our most important leading indicators of success. The critical lagging indicator of success is the software’s ability to generate value (profits in for-profit firms, and “good” in not-for-profit firms). This is the principle that leads to the Agile “Definition of Done”.  Past indications of success, such as progress through waterfall cycles (e.g. "development done") have spurious correlation with success.

Examples: Both Kanban and Scrum contain the concept of “Done”. Scrum also offers Velocity as a means by which the amount of “done” activity can be measured. Kanban focuses on throughput which has a correlation to Scrum velocity.

Potential Pitfalls:

  • Many teams either don’t spend time defining “done” or ensuring that all team members understand the concept; is “done” simply the cessation of development activities or does it include completion of testing and launch without failure in a production environment?
  • AKF also likes to add predicates of the development process to the definition of “done”. Examples of these include code reviews passed, security analysis performed, architectural assessment and impact complete, etc.
  • Often teams won’t define how to calculate velocity or throughput leveraging the concept of “done”. In many cases, teams simply do not calculate the velocity or throughput at all. These teams completely miss the opportunity to identify and fix problems in software delivery.

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

Reason it exists: Waterfall methodologies were associated with “Death Marches” to meet dates. The high cost of these death marches often resulted in teams significantly reducing delivery volume immediately following an iteration or project. This “whiplash” effect of high and low periods of effort contributed to confusing metrics that made planning difficult.

Agile methodologies attempt to reduce the standard deviation of delivery cycles to create a sustainable and predictable delivery volume and cadence. When performed successfully, teams are more motivated and retention increases.

Examples: No clear examples exist as this is a desired outcome of a successful Agile implementation rather than an indication that some activity should occur.

Potential Pitfalls: The most common failure is when teams fail to evaluate the curve of their delivery volumes over time. Whether evaluating velocity, or throughput, sustainable development should show a relatively “flat line” without significant deviation in volume between releases. Low standard deviation in volume over time indicates sustainability; sustainability leads to predictability.

Our next article in this series will cover the last four principles within the Agile Manifesto.