This tongue-in-cheek article highlights how inverse versions of the Agile Manifesto and the 12 Principles of Agile Software Development actually line up with standard software project management practice. Unfortunately, many of the contradictions stated below are common throughout “Agile” projects as well.
The Anti-Agile Manifesto
In the interest of controlling how software development teams develop software, management values:
Processes and tools over individuals and interactions
Comprehensive documentationover working software
Contract negotiation over customer collaboration
Following a plan over responding to change
That is, while we may, if pressed, acknowledge that there is value in the items on the right, we value the items on the left almost exclusively.
The 12 Principles of Anti-Agile Software Development
We follow these principles:
Our highest priority is to ensure developers are on track to finish all of the work defined in the contract, on time, and within budget. Customer satisfaction is a desired outcome but not required to meet contractual obligations.
Prevent requirements changes, as much as possible, to ensure adherence to the plan. Adherence to the constraints of the “Iron Triangle” is more important than advancing the customer’s competitive advantage.
Deliver working software infrequently, from months to years, with a preference for the longer timescale.
Business people and developers avoid working together throughout the project. Communication is mediated through copious documentation and requirements gathering proxies.
Sap project members’ motivation and their urge to self-organize. Make them responsible for results without providing direction, resources, support, trust, or authority to get the job done.
The ways of conveying information best aligned with top-down control of software projects are highly-detailed documentation and continuous status reporting through multiple organizational levels.
Percentage completion of project tasks is the primary measure of progress.
Higher levels of worker productivity are best achieved through arbitrary deadlines and making everything a high priority. Reward individual heroics and blame poor performance on individuals rather than fixing systemic problems. Project and business priorities should drive the pace of software development, not the ability of sponsors, developers, and users to keep pace.
Attention to technical excellence and good design can be ignored when schedule pressures mount.
Simplicity–the art of maximizing the amount of work not done–is lazy and runs counter to maximizing resource (employee) utilization metrics.
The best architectures, requirements, and designs emerge from senior engineers, architects, and business people prescribing the project’s engineering approach upfront.
Teams work best when they follow highly-prescriptive processes and procedures imposed on them from above. Adjusting behavior based on demonstrated results (empiricism) leads to loss of management control.
Conclusion
Turning a concept on its head can help us view it from a different perspective. While it is not the intent of management to establish and perpetuate cultures that stifle agility, traditional project management practices often do. It is proper to define the culture we want to foster however, understanding what we want to avoid is just as important.
Most fixed-price contracts are inherently anti-Agile. It is not because they set a budget ceiling for a project. I and many others argue that budget and schedule constraints actually enable Agile project planning. The issues associated with fixed-price Agile software development contracts lie in how project management determines and enforces scope, budget, and schedule constraints.
Predictive vs. Adaptive Planning
Most fixed-price contracts ignore a fundamental disconnect between traditional project management and Agile practice. Traditional project management planning is predictivewhile Agile planning is adaptive. Fixed-price contracts require planners to define the three constraints of the Iron Triangle – scope, cost/budget, and schedule – upfront.
Figure 1: The Iron Triangle
In traditional software projects, project management closely tracks task progress towards scheduled milestones and the associated budget burn rate. There is little room to change project plans when things go awry. Also, projects lose the flexibility to change plans based on lessons learned and discovery of new requirements during development.
In contrast, Agile planning “breaks” the Iron Triangle by allowing scope to “float” within budget and schedule constraints. This means that given a fixed budget and timeframe, project sponsors, stakeholders, and software development teams collaborate to determine what to build during development. We control Agile software development projects primarily by managing scope.
We determine what viable and valuable capabilities to develop, deploy, and release within budget and time constraints. As long as project sponsors and stakeholders work with development teams to continually refine and prioritize requirements, teams will deliver the most important product / system / solution features at appropriate levels of quality and complexity. In Agile projects, sponsors have the flexibility to:
Continue developing the current implementation as planned
Pivot to a different implementation approach
Stop when enough useful functionality is developed and fielded
Cancel development altogether if necessary
Control vs. Flexibility
Fixed-price contracts are one way traditional project managers attempt to mitigate project risk. Government agencies prefer fixed-priced contracts because they shift project risk onto vendors. Vendors bid based on solution requirements stated in requests for proposals (RFPs). It is up to the vendors to ensure their proposals accurately reflect the cost of satisfying requirements, within the specified timeframe, and at a competitive price that allows them to make money.
Since no one can predict the future, vendors often do the following:
Challenge any interpretation of requirements that may increase project scope (scope creep)
Vendors are disincentivized to accept changes in requirements that may perturb the plan and cost them margin.
Meanwhile, project sponsors worry they will not get what they paid for in terms of functionality and quality. Those worries often translate into burdensome tracking and reporting requirements.
Agile provides opportunities to inspect and adapt solutions and their development. This transparency is Agile’s safeguard against scope creep and project and solution underperformance.
Unfortunately, traditional project managers often forgo opportunities to define and validate solutions during development. Instead, they favor traditional project management tracking and reporting. They focus on tracking tasks completed rather than validating value delivered. Even the misnamed concept of “Earned Value Management” (EVM) assumes a deliverable’s value during development equals the budgeted cost of the effort expended on it, regardless of its ability to provide business or mission value.
The Agile Alternative
Instead of attempting to manage all three Iron Triangle constraints as variables, keep cost and timeframes fixed while managing scope. Rather than tracking task completion, deliver working functionality early and often to validate that development teams built the right things in the right way. This places responsibility for defining the solution or “product’ squarely on project sponsors, with help from stakeholders and development teams. Traditional project managers often struggle with this approach because it is a product management approach rather than a project management approach.
Conclusion
Fixed-price contracts do not have to run counter to Agile practices. They can be written to allow project sponsors and stakeholders to define what business or mission capabilities they need, within fixed cost and schedule constraints.
Doing so encourages developing solutions by starting small and building on successes. After all, it is much easier to cancel a $10 million project after six months than a $100 million dollar project after two years. This Agile approach to fixed-price contracts ensures that something of value comes from the investment while opening the door to future investments based on business or mission success.
Frequent releases help buy down project risk while making valuable software capabilities available sooner.
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 mechanicsof 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
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.
Figure 1: Waterfall, Agilefall, and Agile Release Frequencies
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.
System integration software projects require formal risk management. Here’s how to do it agilely.
If you work in system integration projects, you have likely wondered how to manage project risks within your organization’s chosen Agile approach. This is a topic seldom discussed in certification courses for Agile-based approaches such as Scrum. The two major reasons for this are:
Most of these courses focus exclusively on team-level Agile. In other words, how does a small team of individual contributors work together under the Agile approach? Individual small teams tend to work on smaller efforts that require much less coordination. In most of these situations, formalized risk management is overkill.
Managing risk is baked into Agile because Agile is an inherently empirical way of working. Since Agile development is iterative and incremental, teams narrow the scope of what they build to fit within short time frames. This enables them to, quickly and frequently, build, test, fix, deploy, evaluate and change what they build, and how. Every iteration of value delivery brings multiple opportunities to address risk “in real time.” In other words, Agile spreads risk management across the entire development effort.
However, system integration projects are typically large and complex, with multiple teams working across organizations while managing multiple dependencies. The larger the project, the more risk project sponsors and stakeholders assume. A formalized approach to risk management becomes a priority.
So, what does a formalized Agile risk management approach look like? It looks a lot like a traditional risk management approach with three main differences:
Agile risk management is more adaptive than predictive
Agile projects perform risk management activities more frequently and faster than traditional projects
Risk management activities in Agile projects are much more coupled to project execution than in traditional projects
Before describing a formalized Agile risk management approach, let’s level set understanding about project risk management. Along with the short background provided here, I highly recommend reading this article from pmi.org about risk analysis and management.
Risks, Opportunities, and Issues
The third edition of the Project Management Body of Knowledge (PMBOK Guide) defines risk as:
An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.
Project Management Body of Knowledge (PMBOK Guide), Third Edition
By that definition, risks are not just harbingers of negative outcomes. They may also be opportunitiesto affect positive outcomes. Once a negative risk becomes reality, it becomes an issue.
Risk Categories
Categorizing project risks is helpful. Doing so facilitates risk tracking across the entire project scope. It also communicates that risk management is everyone’s job, not just that of project management. Table 1 lists a typical set of project risk categories and their associated extended categories[1]:
Table 1: Typical Project Risk Categories
Risks belonging to the external, organizational, and project management categories are typically:
Closely aligned to high-level project concerns outside the control of development teams
Less dynamic and fluid than technical risks
Almost exclusively in the realm of project and program management and/or product management
Much of Agile literature and training narrowly focus on technical risks. This aligns with their focus on Agile execution by small teams. However, external, organizational, and project management risks often impact projects far more.
The Risk Management Cycle
Figure 1: The Risk Management Cycle
Both traditional and Agile projects execute the activities of the Risk Management Cycle depicted in Figure 1. Table 2 lists and describes each activity of the cycle[2]:
Traditional project management tries to account for all project tasks and milestones upfront. Agile planning breaks up the planning horizon into increments. These increments facilitate changing plans when circumstances change. To be effective, a project’s risk management approach must align to the chosen project management approach.
While all projects, whether they adopt a predictive or adaptive planning approach, perform every activity of the Risk Management Cycle, they emphasize different activities.
A predictive risk management approach emphasizes risk forecasting (prediction) and analysis. Risk analysis entails determining the probability of occurrence and expected project impact of individual risks. The rationale is that the earlier project managers identify and prioritize project risks, the sooner they can address them before they become issues.
An adaptive risk management approach emphasizes keeping risks small by defining, developing, and delivering system functionality iteratively and incrementally. This allows teams to handle risks while their potential for project impact is small and to continually monitor risks as solutions evolve and grow.
Traditional vs. Agile Risk Management Characteristics
I’ll now discuss the key differences between how traditional and Agile projects manage risk.
Traditional Risk Identification and Evaluation
Traditional projects develop and execute detailed plans that span the entire project timeline. Project management often breaks up larger projects into planning packages as part of “rolling wave planning”, but each of those planning packages are themselves detailed plans. Project plans are based on the resources needed to complete the entire scope of deliverables at a certain cost (The Iron Triangle).
Project plans start with requirements definition. The entire set of approved requirements defines project scope. Changes to requirements mean changes to project scope, which translate into schedule and cost changes.
Similarly, traditional risk management tries to identify and evaluate project risks and opportunities prior to or at the start of projects. While risk management is supposed to happen throughout a project’s timeline, traditional projects tend to perform the bulk of Risk Identification and Evaluation upfront.
The problem with this arrangement is that people cannot predict the future. The larger and more complex the project, the more likely project requirements and risks will change.
Traditional project management develops and executes plans assuming requirements, and the design approaches that implement them, are inherently correct and will not change. This opens projects to the greatest risk of all: building the wrong thing.
Risk Identification and Evaluation activities in traditional projects often cannot keep up with the accelerated pace of modern software development. In many organizations, risk management is relegated to weekly or monthly risk management boards. By the time a board adjudicates a risk it may already be an issue.
Agile Risk Identification and Evaluation
While some degree of upfront Risk identification and Evaluation happens in Agile projects, the planning horizon is typically far shorter than that of traditional projects. Also, most Risk Identification and Evaluation of technical risks happen as part of development, rather than resulting from a separate risk management process.
Traditional Risk Handling and Controlling
Traditional (Waterfall) projects typically get one pass through the Software Development Lifecycle (SCLC). That pass is strictly constrained by schedule, resources, and cost. As a result, there is often little room to add risk management activities to the schedule.
Project managers and developers are incentivized to deliver according to plan. This puts pressure on them to ignore risks until they become issues. They also forgo opportunities in favor of “flying the plan.”
Agile Risk Handling and Controlling
The Agile SDLC is fast moving and iterative. Every feature software development teams deliver goes through its own “mini-SDLC”. Agile planning coupled with DevOps automation support this:
Agile provides frequent opportunities to evaluate what development teams build and how
Adaptive planning allows sponsors, stakeholders, and development teams to change requirements, plans, and approaches
Teams add risks to their work backlogs and prioritize them, thus integrating Risk Handling actions into team workflows
Shorter development timeframes with frequent deliveries / releases provide: 1) More frequent and earlier warning of emerging risks; 2) More feedback from which to gauge the effectiveness of risk management efforts
Recommended Approach
The Agile SDLC improves management of technical risks. However, as stated earlier, external, organizational, and project management risks often impact projects far more than technical risks. Agile teams have the flexibility to manage technical scope. They have far less control over funding and major project milestones.
External, organizational, and project management risks influence the overall business or mission context within which teams develop solutions. Project leadership must actively manage these risks before they impact the work of development teams.
Agile projects should leverage traditional risk management tools and techniques to manage more strategic, slower-moving risks. Project leaders would then work with development teams to translate such risks into actionable work items and prioritize them. All project members should have access to risk management reporting and the ability to submit risk candidates as part of their work.
Conclusion
Too often, risk management gets short shrift, especially in Agile projects. Risk management is an integral part of project planning, regardless of the software development approach employed. Combining Agile requirements definition and planning, with DevOps automation, and a robust risk management process helps teams deliver valuable software capabilities, cost-effectively, and in time to be valuable.
[1,2] Lavanya, N., Malarvizhi, T., “Risk Analysis and Management,” Project Management Institute, 3 March 2008, https://www.pmi.org/learning/library/risk-analysis-project-management-7070
