In this video, Frank Velazquez explains how Agile accelerates value delivery.
Many organizational leaders think of Agile as a way to speed up software development, and nothing more. They approach Agile with a traditional project management emphasis on improving efficiency. In doing so, they unwittingly corrupt Agile practices to the point of undermining the very agility they are trying to achieve.
Agile software development teams develop more software functionality faster by focusing on diminishing what Lean terms lead time and cycle time. Agile teams diminish lead time and cycle time by:
Minimizing waste from software development processes
Managing technical scope (increasing flow)
Striving for high quality through technical excellence
Constraints are your friends. Stop treating them like obstacles.
Table of Contents
Developing and fielding software solutions is hard. Turning a set of requirements into a viable and useful solution often feels like embarking on a voyage of discovery. Along the way, we deal with previously known and unknown constraints on what the solution can be, what it can do, and how well it can do it.
Many managers and technical implementers fail to see the difference between constraints and impediments. As a result, we deal with issues we could have planned for ahead of time only after they become impediments to progress. Also, an unwillingness to remain open to alternative ways of fulfilling requirements locks us into “all or nothing” thinking that causes us to fight against constraints instead of leveraging them to better define solutions.
Constraints vs. Impediments
For the purposes of this article, a constraint is anything that restricts the implementation and behavior of a solution. Constraints shape the solution by placing limits or imposing requirements on how we develop, deploy, support, and use the solution. Impediments, on the other hand, are occurrences or circumstances that prevent us from making progress towards developing, deploying, and supporting the solution. We are much more able to plan for constraints than for impediments. Ignoring or not adequately managing constraints leads to impediments, sometimes project wrecking ones.
I categorize constraints as fundamental and organizational. Before discussing how to manage these constraints, let’s understand what they are.
The Fundamental Constraints
The four fundamental constraints on all solutions are solution requirements and the constraints of the Iron Triangle: cost, schedule, and scope.
Solution Requirements
If we do a good job of defining needs, without jumping to specify solutions, we end up with requirements. Requirements are the first constraint on what a solution will offer and how it will perform. Solution capabilities or features are functional requirements. How well the solution performs or behaves is characterized by non-functional requirements (NFRs). Requirements start to narrow the infinite range of approaches we could take towards solving problems or addressing needs.
Figure 1: Small-Scale Manual Catalog Solution
For example, a small town library may be fine using a card catalog to track its holdings. Due to the relatively small amount of content offered and number of library patrons, manual tracking via cards and lists works both from a functional perspective (tracking books/media) and from the perspectives of cost and simplicity (NFRs). The same solution would be woefully inadequate at a large university or the Library of Congress. For large libraries, solutions must be highly automated and digitized to be viable and cost effective. The NFRs associated with managing the holdings of a large library filter out the option of using manually-intensive solutions.
Cost, Schedule, and Scope
The narrowing of solution approaches continues as we account for the constraints of the Iron Triangle. Requirements inform analysis of project scope. The more requirements we address, the larger the solution becomes (greater scope). The number of requirements, and their relative complexity, drive schedule and cost. Smaller budgets and/or tighter schedules typically drive down the amount of scope development teams can deliver. Not aligning scope to budget and schedule constraints risks degrading quality.
NFRs drive the level of quality necessary for the solution to be viable and effective. The Iron Triangle constrains quality indirectly. We can’t buy quality as a system feature delivered by a certain time. Instead, we build quality into the solution by ensuring we build the right things in the right ways.
Organizational Constraints on Solution Development
Organizations that develop and/or sponsor development, fielding, and support of software solutions impose constraints on those solutions. These organizational constraints tend to reinforce the fundamental constraints discussed in the previous section. I categorize organizational constraints as Enterprise Governance, Programmatic, and Implementation constraints. These categories align with organizational structures typically found in large organizations. In large organizations, most software systems development supports systems integration as opposed to product development.
Figure 2: Organizational Constraint Levels
Enterprise Governance Constraints
MITRE defines enterprise governance as:
The structure and relationships that control, direct, or regulate the performance of an enterprise [and its] projects, portfolios, infrastructure, and processes
Constraints at the enterprise level inform constraints at the program and project levels of the organization. Table 1 below lists the most common examples:
Table 1: Common Enterprise Governance Constraints
Programmatic Constraints
Along with ensuring implementation of enterprise governance constraints, program management offices (PMOs) also impose their own constraints on the development, fielding, and support of software solutions. PMOs focus primarily on the day-to-day management of Iron Triangle constraints across development projects and sustainment efforts as well as the associated contractual mechanisms that enforce those constraints.
Implementation Constraints
Individual projects add requirements, design specifications, and technical implementation details to the full weight of constraints flowing down from enterprise and program organizational levels. Considerations directly tied to development of solution capabilities further constrain implementation choices.
This applies to both what development teams develop and how. From a technical implementation perspective, the following are examples of choices often constrained by policies and procedures from higher organizational levels:
Forms of application or system architecture (e.g., service-oriented, monolithic, client-server)
Which technologies development teams employ
How development teams implement business / mission rules
The same applies for how development teams work. For example:
Contractual requirements may specify that teams must work within an Agile framework such as Scrum or SAFe
Developers may be required to use enterprise CM, Agile, and DevOps tooling and deployment environments provided and maintained by the organization
Managing Software Solution Constraints
People often see constraints as inherently bad. They see them as frustrating inconveniences or problems that hamper solutions development. Instead, we should see constraints as criteria that help narrow design and implementation choices to those most likely to foster solution success. Delivering on requirements while aligning solutions to enterprise, programmatic, and implementation constraints achieves fit. By fit I mean that a solution performs its work, at expected levels of performance and quality, in harmony with organizational, contractual, technological, and procedural realities.
Figure 3 and Table 2 below outline a process for managing software solution constraints.
Figure 3: Managing Constraints on Software Systems DevelopmentTable 2: Process for Managing Constraints on Software Solutions
Implementing Workarounds
A workaround is a way of accomplishing the same work or achieving the same results when a preferred approach would violate constraints. Workarounds allow us to implement solutions that would otherwise not align with constraints. There are two ways of working around constraints that can’t be waived or changed:
Technological Workarounds: Implement new or use existing technologies, services, systems, applications, etc. to address constraints. Chosen approaches become part of the solution’s implementation and architecture.
Procedural Workarounds: Implement auxiliary processes or procedures. For example, manual processes may fill requirements gaps not addressed by a solution.
Managing Project Scope
An agile way of managing constraints is through managing project scope. For example, a constraint keeps us from implementing a feature in its entirety. The constraint can’t be waived or changed away. We could break up the feature to only implement functionality that does not break the constraint while we look for alternatives. We can choose to deal with the constraint at a later time while working within the constraint. A limited implementation of the feature may turn out to be good enough.
Conclusion
Traditional project management has conditioned us to think in terms of “getting it all done.” In other words, implementing solutions according to predictive plans and designs that can’t be changed. This is unrealistic because, try as we might, we will not identify all of the constraints we will encounter before we start.
We have to do our best in identifying constraints as soon as possible so we can address them before they become impediments. At the same time, we need the agility to deal with unanticipated constraints. We achieve this balance by not treating constraints as obstacles but as influences that help shape what solutions will become.
NFRs are part of Agile projects too. Here’s how to handle them.
In this video, Frank Velazquez explains Non-Functional Requirements (NFRs) in the context of requirements management and how to address them in Agile projects.
It is quite common for people who sponsor, manage, and develop software systems to misunderstand NFRs and struggle in applying them to Agile requirements management. User Stories make mapping of system-level NFRs to functional requirements easier. Acceptance criteria link functional requirements to tests that demonstrate satisfaction of NFRs. Coupled with frequent integrations and regression testing, this approach to NFRs ensures the delivery of expected system behavior to customers and end users.
If you are managing software development efforts as projects, you are doing it wrong. Instead of managing projects, organizations that sponsor and develop software solutions need to shift towards managing solutions as products. A product management approach to software development aligns with modern software development and with Agile’s inherent product management bias.
Project Management vs. Product Management
In a nutshell, project management differs from product management in that the former is primarily concerned with managing people, schedules, and tasks while the latter focuses on managing the product and how it is created.
Table 1: Product Management vs. Project Management
Traditional project management is misaligned with modern software development for two reasons:
An overemphasis on managing the triple constraints of the “Iron triangle” to the detriment of technical execution, product quality, and value delivery
An overemphasis on control to the detriment of speed and flexibility
The “Iron Triangle”
Traditional program management focuses on enforcing the triple constraints of the Iron Triangle: cost, schedule, and scope (the amount of work done). The objective is to deliver expected value on time and on budget. Unfortunately, fixing the three constraints leaves quality as the only variable, opening the door to sacrificing quality when things don’t go as planned. Because no one can predict the future, most traditional projects fail to deliver on at least one of these constraints. In other words, “I can get it to you cheap, fast, or good. Pick any two.”
Figure 1: The Iron Triangle
Traditional project managers manage against detailed plans that attempt to fix all three constraints for the life of the project. They base plans on estimates of how long it will take a certain number of people, with specific skills, to accomplish a set amount of work at a certain cost. As problems arise, managers work to keep the project as close to the original plan as possible. If project reality strays too far from the plan, they develop a new project plan or scrap the project altogether. Replanning is a risky and expensive proposition, so project managers work mightily to avoid it.
Fixing cost and schedule begins by fixing scope. The more detailed project requirements are upfront, the more precise the cost and schedule estimates become. However, these calculations are not necessarily more accurate because they are based on estimates and on requirements that will likely change the bigger and more complex project scope becomes.
How Enforcing the Iron Triangle Affects Software Development
The problem with applying traditional project management to software development is that development of non-trivial and/or large-scale software solutions is too complex for linear predictive planning. As software solutions grow and evolve, their complexity increases, sometimes at a seemingly exponential rate. Since we can develop and modify software solutions in infinite ways, they are often significantly more complex than physical systems of comparable cost.
Enforcement of the Iron Triangle in software development projects often leads to the following problems:
Narrowing requirements and technical approaches too early – Predictive project planning typically forces teams to define what they will build and how before they really understand the business/mission and technology domains they will work in. This often leads to developing things that customers and end users do not need or that do not adequately address their needs.
Tendency to overengineer solutions – Specifying technical scope upfront often leads to overengineering. Defining and developing features that few, if any, customers or end users will actually use is quite common. Also, overengineering can lead to creating complex features or functionality where simpler versions could have satisfied requirements. All those rarely-used or overly complex features cost money to develop and maintain. They rob time and budget from developing and releasing features customers and end users truly value.
Difficulty managing risks and taking advantage of opportunities – In the zeal to keep projects “on plan”, planners often identify emerging risks too late to keep them from becoming issues or forgo opportunities to improve the product and how it is developed.
Forgoing opportunities to validate solutions – Projects based on predictive planning, such as Waterfall projects, often afford only one chance to validate what teams develop. Typically, validation of the solution occurs towards the end of the project, when the time to address problems is most limited.
Delaying delivery of business or mission value – With only one chance to deliver / release, sponsors, stakeholders, customers, and end users must wait until the end of the project to gain access to solution features.
Agile “Breaks” the Iron Triangle
Instead of attempting to fix all three constraints of the Iron Triangle, Agile fixes cost and schedule while allowing scope to “float”. In other words, Agile efforts are managed primarily by managing scope.
Under an Agile approach, there are no surprises. We have a certain amount of budget and time to spend developing software capabilities. We continuously verify (test) the solution as we build it to ensure we are building things right and demonstrate and release functionality often to ensure we built the right things. Since we build and deliver solutions iteratively and incrementally, customers and end users get valuable business or mission capabilities sooner.
Figure 2: Waterfall, Agilefall, and Agile Release Frequencies
For as long as we have enough budget and schedule, we have the option to continue developing functionality or stop after realizing enough value. We also have the option to pivot to a different solution approach or cancel the solution altogether. When budget and schedule run out, we can choose to invest more on the solution based on demonstrated functionality and customer and end-user feedback.
Figure 3: Pivot or Persevere
Overemphasizing Control
Enforcing the constraints of the Iron Triangle causes project management to implement heavyweight management and reporting processes. These processes are attempts to lower risk by increasing control. Overemphasizing control slows software development and decreases the flexibility necessary to tackle risks and challenges. On the other hand, underemphasizing control can turn flexibility into chaos, robbing software development teams of both planning and process stability, thereby slowing progress. An optimal balance between control, flexibility, and speed requires empowering technical contributors to plan their own work based on sponsor, stakeholder, customer, and end user needs and enterprise technical constraints. The main reason for this is the inherent complexity of software systems.
High-performing teams are empowered teams. They take on or participate in many duties traditionally left to project management: Devising work plans, decomposing work and deliverables, monitoring task and reporting progress, and meeting commitments.
Software is never finished. We’ve moved away from delivering discrete, standalone software package products (think Windows 95) to continual delivery of new software functionality and bug fixes via updates distributed over the internet. Even in organizational IT and enterprise system integration efforts, development never truly finishes. If any solution or product is to survive, it must adapt to meet changing customer needs while maintaining quality and performance.
Also, software is infinitely changeable. Since software is abstract, we can add and modify it at will with much less effort and expense than physical solutions or products. Thus, we don’t see the same level of resistance to updating software solutions as we see with physical products. The very nature of software solutions makes them likely to continue changing and evolving long after initial development.
Thus, managing the development and evolution of software solutions as projects that start and stop does not make sense. All software solutions go through the stages of the Product Lifecycle.
The Product Lifecycle
Figure 4: The Product Lifecycle
The Product Lifecycle includes the phases all products go through during their useful lives: from when they are first conceived, to when they are retired from the market or their mission domains. This cycle focuses on the performance of the product in its intended market or mission domain. All products, including software solutions, commercial or otherwise:
Start out as an idea developed into an initial version of a releasable product
Are introduced / released to their intended consumers or user bases
See their market or user base expand, if successful. This phase tends to drive the most product changes that keep the product relevant and/or profitable
See an eventual stabilization or flattening in customer use, sales, or revenue growth as the product’s market or mission domain matures
See their market or mission domain decline as it becomes saturated or customers move on to new solutions
Are retired when they cease to be profitable, effective, or relevant
Projects Incur Wasteful Overhead
Traditional project management’s focus on projects is wasteful. Starting and stopping projects incurs significant overhead. Examples include:
Contracting activities (and acquisition activities, for government projects) – Finding contractors / vendors, putting them on contract, monitoring performance, “Color of Money” concerns, etc.
Ramping up new employees or vendors to be productive – Accesses, equipment, software tools, training (formal and on-the-job), etc.
Ramping down employees or vendors as projects end – Removing accesses, returning equipment, managing software licenses, etc.
Not having the flexibility to easily terminate failing projects or projects considered no longer necessary or desirable – It is much cheaper and easier to cancel a project after spending $10 million than after spending $100 million
Agile’s Inherent Product Management Bias
So, if we should manage software development as product development efforts, rather than as projects, what does that look like? It looks like Agile software development. Agile software development in general, and Scrum specifically, have an inherent product management bias. Table 2 below shows how Scrum fulfills the product management duties listed in Table 1:
Table 2: How Scrum Fulfills Product Management Duties
Conclusion
In my experience, the single biggest reason why so many Agile software development efforts fail to achieve the benefits of Agile is the conflict between traditional project management thinking and Agile’s inherent product management approach to software development. This is not just my opinion, it is a growing realization Lean-Agile circles[i].
Today, business and mission requirements change too quickly for slow-moving predictive planning and management approaches. To meet the challenges brought about by the quickening pace of technology, we must leverage flexibility and control to achieve speed while maintaining quality. This requires a shift from a project management to a product management mindset.
