Fixed Budget, Fixed Scope? Be Agile Anyway.

Scrum is typically taught with its most innovation-focused form as the example, born from fast-paced software companies who disrupt markets and kill categories. This is the sexy version of Scrum: a highly elastic process for delivering complex products with emergent design. In the real world this is not the only context in which Agile, Scrum, Lean, and XP principles can and are utilized to increase quality and velocity.

If you are a newly-trained Scrum professional, bright-eyed and full of hope, do not get discouraged by convergent, fixed-budget, fixed-scope, fixed-timeline projects – be agile anyway! This is how to do it.

The Agile Manifesto:

It is important to remember that the Agile Manifesto is a set of priorities, not a set of laws. To any extent we can, we strive to prioritize in the direction of team collaboration, continuous improvement, and emergent value creation. However, there are some occasions when you will have to put additional energy in the secondary priority. Strategy is the art of trade-offs, so make sure your organization is aligned and the strategic vision is deliberate:

Individuals and interactions over processes and tools – Never lose sight of prioritizing the people who huddle around your solution, never stop collaborating. Encourage face time and green time. However, there are highly regulated industries with static expectations, accounting control benchmarks, FDA guidelines, or stable dividends paid to investors for decades. A well-documented, repeatable process for how software, hardware, or other product will be delivered over the course of a long-term project will assist tremendously with stakeholder confidence. Make priorities clear on all sides of the contract, set the expectation that communication and availability are mission-critical, but understand that there will be little risk tolerance for out-of-control processes. Maintain your agility by keeping your document alive and lean, maintain elasticity, but make sure the tools used and the processes adopted, and the pace of process change, gives your fixed-scope, fixed-budget project a stable context for predicting delivery and ROI.

Working software over comprehensive documentation – Delivering builds early and often is the best way to be truly certain of product status. In emergent product design with incremental feature addition this feels natural. There is an MVP planned so an opportunity to pivot is assumed, the feedback loop on the progress of high-quality incremental delivery is the best way for stakeholders and users to see and feel the value that is emerging. When working with waterfall-minded stakeholders – especially if they are an external client – fixed scope, fixed budget, and fixed release dates cannot always be avoided. However, convergent delivery does not preclude the XP and Scrum best practices of well-formed agile teams and an openness to documentation-heavy products will drive velocity and success waterfall organizations have never seen. Instead of negative reactions to the expectation of comprehensive documentation, approach documentation as a secondary product and maintain the same expectations of prioritization, collaboration, and responsiveness. Moreover, a convergent, finite project likely came to you with extensive documentation. This documentation will require some additional work, but it should not be ignored. Even though this is a source of waste that is removed during agile transformation and lean consulting in “sexy” emergent product delivery, handling waterfall requirements as documented stakeholder demands can be incredibly helpful in convergent product delivery. The Product Owner still must aggregate, consolidate, and complete backlog decomposition with the team. The XP user story and a prioritized backlog should still set the delivery cadence. Be open to documentation and transparent to stakeholders about its actual ROI after it is delivered.

Customer collaboration over contract negotiation – Good fences make good neighbors. Some large companies simply cannot risk an open-ended and loosely-defined relationship, especially with vendors or contractors. If you’re competitive strategy relies on these types of contracts, inspect and adapt. Find how negotiation can be expedited, build in the process of collaborative relationship change, and build well-formed teams that are as adept at ramp-up as they are at innovation. The capacity of a Scrum team to quickly assimilate a knew business and architectural context will drive success in products and relationships of all types. Answering the internal needs of various business functions or developing solutions in new industries requires a team aptitude for understanding new contexts effectively and efficiently.

Responding to change over following a plan – Change is inevitable in product delivery – the demands of the market, the technological tools available, and the state of the product being developed are a state of continuous evolution. New requirements previously unnoticed will surface in the course of a project. Even in a mostly-waterfall project, a great Product Owner will apply XP and Lean principals to minimize waste and maximize up-front value. Great Scrum teams will perpetually improve, increasing velocity. We often talk about “waterfall projects” versus “scrum projects” when we really mean emergent versus convergent delivery – fixed budget, scope, and deadlines do not preclude scrum, lean, and XP practices, they constrain them to a known outcome. The difference between delivery by a helpless group of Project Managers and Business Analysts disengaged from team performance versus delivery by a powerful Product Owner and kaizen-crazed ScrumMaster and team is not dependent on emergent product delivery! Collaborating around the highest value backlog items up front, swarming impediments, and tracking the variance of forecasted-to-actual product-level burn down will allow fixed dates to be met appropriately. Responsiveness to change needs to be supported by a strong relationship of trust, which must earned. If you are in a custom software shop, responding to RFP’s and entering into fixed projects is often the inevitable first step to earning the trust that will lead to a more agile relationship, so make efforts to meet the comfort level of the customer’s stakeholders while including a healthy process for addressing requirements changes.

Conclusion:

The values, practices, and behaviors of agile, scrum, lean, and XP have wider applicability than open-ended emergent product design. Staying open to the unique lessons that can be learned in seemingly less-than-ideal projects will be a terrific opportunity for the kaizen-driven team to grow. If a rigid process and convergent projects have caused the shine on your Scrum mindset to dampen, step up or step out: don’t let the context defeat you, stay true to your agile values. On the other hand, if you find yourself in a long-term no-win situation in which you cannot drive change for your team(s) and users, maybe a sexier career path is out there for you to consider.