Agile is the default software development approach worldwide.  The foundation upon which Agile approaches (e.g., Scrum, Kanban) rest consists of the Agile Manifesto for Software Development and the 12 Principles of Agile Software.  We consider practices that align with the Manifesto’s values and underlying principles to be Agile.  Unfortunately, too many organizations do not achieve the benefits of agility because they engage in the mechanics of an Agile approach without understanding and implementing its foundational values and principles.

One of the most common examples of this disconnect between Agile software development practice, values, and principles is organizing work into iterations or sprints while releasing infrequently, often only towards the end of a project.  By release, I mean making new software functionality available to customers and end users.  This practice runs counter to the third principle of Agile software development:

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

The 12 Principles of Agile Software Development: https://agilemanifesto.org/principles.html

Agile Empiricism

Agile software development teams do not immediately release everything they develop.  Sometimes they must wait on external technical dependencies.  Other times, customers and end users are not ready to accept new functionality.  Examples include:

• Users may need training on new functionality
• Business and mission processes and workflows may need to change before release
• Project sponsors and stakeholders may decide that a particular release candidate is not what is needed or desired

However, product management/owners, sponsors, and stakeholders should strive to release valuable business or mission capabilities frequently, cost effectively, and in time to be valuable.  You see, it is not possible to determine the actual business or mission value of a software feature or capability until actual customers and end users use it to achieve desired outcomes.  Until then, software features are hypotheses of what product teams believe will best address customer and end user needs.

Allowing too much time to pass before exposing an evolving solution to target customers and end users risks developing unwanted and/or under-performing features and capabilities.  Since Agile projects are controlled primarily by managing scope, losing touch with customer and end user needs translates into:

• Wasted effort
• Higher development, testing, and operational costs
• Longer development cycles
• Less feedback to inform product management, project management, and Software Development Lifecycle (SDLC) activities

Agile development is empirical.  In other words, Agile teams monitor progress, make decisions, and act based on lessons learned from previous releases.  In Agile efforts, customer and end-user input and feedback inform planning, implementation, testing, and release of software features and capabilities.  Thus, Agile teams deliver and release relatively small increments of functionality within short time frames (weeks).  They continually gauge the level of business or mission value software release increments provide and how well those increments perform relative to technical specifications.

Agilefall

The less frequently software development teams release, the less “Agile” a software project becomes.  The project increasingly resembles a traditional project management / Waterfall project.

This conflating of Agile and Waterfall is often referred to as Agilefall.  Agilefall is not a formal SDLC approach.  Thus, there is no set of best practices to guide its implementation.  In fact, Agilefall is an Agile anti-pattern.

The typical Agilefall scenario involves Scrum Teams developing and testing system components for eventual integration, deployment, and release to production.  Software teams develop and deploy components or portions of components every iteration.  They may do some degree of integration during development but deliver and release little to nothing of business or mission value to customers and end users until near the end of the project.  Customer and end user input and feedback do not inform iteration planning. 

Agilefall typically leads to a divergence between what the solution offers and customer and end user needs.  It also leads to costly problems during integration and testing since development teams have fewer opportunities to integrate what they develop and to test those integrations. Agilefall is, in essence, a Waterfall project with software teams performing Scrum “mechanics”.

Agile Delivery

Agile software releases are feature based, not component-based.  Instead of delivering system components, Agile software teams deliver features.  Features are cohesive and complete slices of system functionality capable of performing useful work from the perspective of customers and end users.  This approach to value delivery ensures that:

• Customers and end users gain access to valuable functionality early and often
• Lessons learned from previous releases inform future releases

The more frequently software teams deliver and release, the more opportunities exist to course correct planning and execution.  Requirements are often fuzzy until members of the stakeholder community can see and experience functionality for themselves.  Problems are easier and cheaper to fix when caught early in development.

DevOps

DevOps is an Agile implementation of the SDLC.  It facilitates Agile’s iterative and incremental delivery model.  DevOps leverages automation and a culture of close collaboration between development and operations teams to:

• Promote faster and more frequent deployment of useful capabilities through delivery of small increments of business or mission value
• Apply lessons learned and insights gained from customer and end-user interaction with released software
• Avoid time-wasting hand-offs between phases and teams
• Accelerate development, testing, deployment, and release of software features as well as their integration into complete and cohesive systems or solutions

Conclusion

Frequent releases help buy down risk across the entire SDLC while making valuable business or mission software capabilities available sooner.  DevOps practices enable this value delivery approach.  The best Agile software teams release so frequently, their releases approach a continuous flow.

The promise of Agile is to deliver software capabilities faster and more cost effectively, while improving quality and alignment to customer and end user needs.  Keeping this promise requires adherence to fundamental Agile values and principles, regardless of the chosen Agile approach.

Last Updated on February 2, 2022