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.
Table of Contents
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.
Avoid these Product Owner pitfalls to achieve greater product clarity and better team execution.
Table of Contents
The product owner is one of the three roles defined in Scrum: Product Owner (PO), Scrum Master, and the Development Team. The three combine to form the Scrum Team.
The PO synthesizes the needs of product sponsors, stakeholders, customers, and end users (which I refer to as the Stakeholder Community), with input from the Development Team, into a coherent, viable, and executable product vision. The product vision guides Scrum Team decision making.
POs fill the “The Product Management Vacuum” between company/organizational vision and strategy and the work performed by development teams. Effective POs lead conversations about which digital capabilities to develop and why.
Ineffective POs typically exemplify these four characteristics:
Lack understanding of the target business/mission/market
Lack a product vision
Struggle making tough choices
Are not empowered to make decisions
Ineffective Product Ownership
Lack Understanding of the Business / Mission / Market
The PO is “the voice of the customer” for the Scrum Team. This means POs advocate for the needs, expectations, and desires of customers in the product’s business, mission, or market segment. They define and communicate requirements from the perspective of customers and end users. They can only do so if they posses a deep understanding of the relevant business, mission, or market. In a choice between deep business, mission, or market understanding and technical knowledge, the former trumps the latter.
Ineffective POs lack intimate business, mission or market knowledge. Thus, they often fall into a proxy role between Stakeholder Community members and the Scrum Team. Rather than driving product vision definition in collaboration with the Stakeholder Community and the Scrum Team, they merely document requested features. They struggle to explain the value of requested features or guide Scrum Teams as they learn the business, mission, or market domain.
Lack a Product Vision
A product vision communicates the desired end state of a product in business or mission terms. Possessing a deep understanding of market, customer, and end-user needs is crucial but not enough. The PO must leverage that understanding to develop and evolve a product vision. An ineffective PO either does not see the value of developing a product vision or does not have the skills to do so.
Struggle Making Tough Choices
Making choices about the product is difficult without a clear product vision. Having one enables the following decisions:
Prioritization the Stakeholder Community needs, expectations, and desires
Definition of features likely to address Stakeholder Community needs, expectations, and desires
Prioritization of features into valuable deployable capabilities
Determining which capabilities fit within product scope (when to say no)
A product cannot be all things to all people. Tough decisions about what to include in a product offering are sometimes necessary. Competing priorities and different levels of power or influence among Stakeholder Community members can make this difficult. An effective PO fosters a collaborative atmosphere of give and take while holding firm to a carefully-crafted and evolving product vision. This responsibility goes well beyond inventorying potential features.
Not Empowered to Make Decisions
The most glaring characteristic of ineffective POs is that they are often not empowered to make product decisions. This goes back to the earlier point about POs playing a proxy role. In this case, the proxy role is between the actual decision maker(s) and the Scrum Team.
If the PO does not “own” the product vision, someone else does. Often, organizations cede ownership of the product vision to development teams. This is a dangerous situation in any Scrum project because Scrum/Agile projects are primarily scope driven. Without guidance, development teams implement what they think is important and necessary in ways that are most obvious and straightforward to them. This leads to disconnects between what teams implement and the needs of the Stakeholder Community. It also makes it difficult to determine the business or mission value of released capabilities and when capabilities are complete.
Conclusion
The PO brings together people, technology, and processes to develop valuable software capabilities. A product is far more than a collection of related features.
In Scrum, the product is the result of continual verification, validation, and evaluation of increments of capability delivered iteratively. The product evolves cross increments and iterations/sprints based on an evolving product vision informed by input from the Stakeholder Community, development teams, and real-life results/outcomes attained.
Effective POs are empowered to lead product direction, possess enough business/mission knowledge to guide the Stakeholder Community and Development Team, and have the “soft skills” necessary to foster collaborative discussions about needs and negotiations over product features.
