While making prudent project compromises and tradeoffs is a critical success factor in any project, in agile projects, there are certain factors that make it more challenging and more crucial.Linear projects
In a typical linear or waterfall project, the requirements definition process is a distinct and front-loaded exercise, and much of the negotiation over features to be included is done up front. In fact, this early scope definition process, with all feature determinations and "horse-trading" done before any design or development begins, is the defining feature of a traditional project approach. Anyone who has ever worked on a traditional project knows that new features and ideas will arise during the design and development phase, no matter how frosty the "frozen" specifications are; however, in a disciplined methodology, these modifications will be managed by a change control process that will require a detailed impact analysis and the submission of all change ideas to a Control Board for further evaluation.
These controls solve the problem of scope creep (which has always plagued IT projects), but the controls create unintended consequences. The process of capturing the client's changing requirements and developing and documenting an impact analysis and then shepherding that through a Change Control Board is time-consuming and resource intensive. Also, the process is so onerous that people are discouraged from making a change request, which, in the days of frozen specs and linear projects, was considered a positive.Agile development
The key insight of agile development is that change, while inconvenient for the development team, is frequently beneficial. In fact, openness to beneficial change is the catalyst for projects that actually deliver what the customer wants and needs in a dynamic and turbulent business environment.
One of the key tenets of agile development is transparency. We collaborate closely with the client and other stakeholders throughout the project so that they can see the design decisions we're making firsthand; they can also work side-by-side with us as we grapple with the tradeoffs and the compromises that are a key part of any product development project.
In order to stay true to the agile concept of openness and visibility, I recommend using the tradeoff matrix as an aid to facilitation and discussion when modifying the feature set we're committed to deliver.
Using the tradeoff matrix
The tradeoff matrix is not a new idea, and it's not exclusive to agile development. I first encountered it when training in the Microsoft Solutions Framework (MSF), a software development life cycle promoted by Microsoft for its development partners and internal teams. Although the MSF was originally offered by Microsoft to partners and developers as a program of guidance for development disciplines, it has evolved into an agile-friendly methodology that endorses many of the collaborative, iterative concepts that are common to agile methods.
Every PM is familiar with the triple constraint; that is, the idea that projects are always constrained by schedule (or time), by features (or scope), and by resources (which include money and talent). When any of these elements change, it requires a tradeoff in one of the other components. For example, adding scope typically requires that the schedule be extended or that resources be added, while decreasing time or resources usually means that the feature set must be reduced. I say typically and usually because every PM has experienced the client or manager who insists on changing elements of the constraint without making corresponding adjustments in the other constraints. This rejection of reality by project sponsors is a driving concept behind agile development. One reason we collaborate with the client or sponsor, bringing them completely into the process, is because only they know what they're visualizing for the product. Agile practitioners insist on the sort of transparency that makes it clear to all participants that wishes, threats, or miracles cannot change the fact that additional scope takes time and resources.
The tradeoff triangle (or the triple constraint) is a useful tool for educating clients and sponsors regarding the unbreakable connection between time, scope, and cost. The use of the tradeoff matrix (depicted on TechNet) takes this conversation a step further. It requires the working team to recognize the reality of the project at hand by categorizing each constraint as either fixed, chosen, or adjustable.
- Fixed constraints (e.g., the drop-dead project delivery date) can't change.
- Chosen constraints are based on priority choices made by the team and its sponsors. For example, the decision that, for a particular project or iteration, meeting schedule is more important than including all features, and so some features could be compromised out or "de-scoped" if necessary to meet the schedule.
- Adjustable constraints are subject to negotiation and compromise.
The tradeoff matrix can be used at the project level to document an agreement between the development team and its sponsors that the entire project will be focused on meeting schedule, for example, and that features and resources can be negotiated and changed. It can also be used at the iteration level to ensure that all team players have a consistent understanding of the priorities and possible adjustments to this particular iteration (priorities can change from iteration to iteration, as teams reach the boundaries of schedule or budget, for example). It's also useful at the feature level, when clients are attempting to add features, to remind sponsors of the agreements and priorities set at the beginning.
The tradeoff matrix is often used as an internal tool for conversation and agreement by the development team. In the agile world, however, it becomes a much more inclusive conversation, in which sponsors, managers, and users also participate in the conversation and have a vote in the outcome. In agile environments, tradeoff conversations are run as facilitated work sessions, and the agile PM leads the collaborative team through the process of filling in the blanks to the following sentence:Given fixed ____________, we will choose a ___________ and adjust ___________ as necessary.
Whether the team is setting priorities for an entire project, an iteration, or a specific feature, the questions are the same: For the particular project element under review, where must we conform to our previous plan, and where is there room for compromise? In an iterative, time-boxed development project, such as Scrum, where, for example, the typical iteration is constrained to 30 days, we'd start with the premise that:Given a fixed schedule, we will choose a level of resources and adjust the features set as necessary.
Depending on the project and the determinations made by the team, the resources or budget may be the fixed elements, requiring compromise in time or features. The key point is that these decisions are made by the entire team in full view of all so that issues and disagreements can be worked through. Also, these decisions are made in recognition of the reality that, while agile projects are open to change, change is not cost-free, and any modifications in features, schedule, or resources requires adjustment to the other elements of the tradeoff triangle.Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!
Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile practices and migrate successfully.