Defining Solution Intent for Large-Scale Agile Projects
At Universal Mind we often hear from clients who are eager to use agile development methodologies for smaller projects but are skeptical that agile is feasible for larger initiatives. “Agile works great for small apps and prototypes,” we’ve heard, “but we could never use it for something mission critical like our SAP implementation.”
Such comments may seem surprising. Agile software development is now several decades old, and a deep body of evidence has accumulated over the years to demonstrate the benefits of agile, including increased productivity and flexibility in adapting to changing business demands. If agile is so great at increasing productivity, why wouldn’t one want to realize its benefits on an organization’s most expensive initiatives?
No More Planning Or Documentation?
Lingering skepticism about agile’s suitability for complex initiatives is understandable if one remembers a common misperception about agile principles. Agile, it is said, is about ditching up-front planning so that developers can create on the fly. This myth was memorably captured in a Dilbert cartoon many years back. To Dilbert’s Pointy-Haired Boss, agile means “no more planning and no more documentation. Just start writing code”. The Manifesto for Agile Software Development itself seems to support this view when it argues for “responding to change over following a plan” and “working software over comprehensive documentation”.
The notion of jumping straight into writing code for an enterprise resource planning system is, of course, ludicrous. A typical ERP solution touches a large number of business processes, from finance to HR, and these require a high level of compliance review that makes documentation necessary. Hundreds of team members can be involved, and external vendors or suppliers often play significant roles. Given the level of investment for such initiatives, executives are wise to ensure that all parties have a clear understanding of scope and design prior to committing budget and resources to implementation.
The myth that agile is all about enabling cowboy coders to run as fast as they can without direction has been steadily debunked in recent years, however. Agile methodologies have been successfully used to develop such complex, mission-critical systems as fighter jets and medical devices. SAP itself long ago introduced an agile version of its ASAP methodology for SAP ERP implementations. And frameworks such as the Scaled Agile Framework (SAFe) now serve as a playbook for scaling agile to programs involving hundreds or thousands of people.
SAFe & Solution Intent
SAFe is Universal Mind’s framework of choice for scaling agile past team-level Scrum. SAFe has long emphasized the role of rigorous planning in agile organizations and proposes a well-defined set of planning activities that can allow organizations to define a longer-term roadmap while remaining agile. However, until recently SAFe has been less clear about the nature of requirements documentation beyond traditional user stories and acceptance criteria. This has changed in the latest version of SAFe with its introduction of “Solution Intent” as a mechanism for fixing requirements up front while remaining true to the spirit of agile.
SAFe’s concept of Solution Intent launched in early 2016 as part of SAFe 4.0’s new “Value Stream Level”. The Value Stream Level was inspired by Boeing and other organizations running the largest SAFe implementations, often in highly regulated industries with significant compliance and traceability requirements. As defined by SAFe, Solution Intent is a single source of truth that captures use cases, requirements, design and system architecture in order to meet those compliance demands and align a large number of teams and suppliers to a common purpose, typically before development starts.
Definition & Design Best Practices
The concept of Solution Intent is new to SAFe, but not to Universal Mind. Formal solution definition has been a part of Universal Mind’s agile approach for years. We typically start our engagements with Definition and Design phases that confirm high-level requirements prior to a more specific implementation phase. These initial phases can last anywhere from a few weeks to many months, and they produce a wide variety of requirements artifacts that will later form the basis for detailed user stories. These artifacts also help teams to refine high-level estimates for planning and budgeting purposes.
It’s important to emphasize that Universal Mind’s approach to requirements definition and SAFe’s Solution Intent are not just a return to “Big Design Up Front” approaches that front load projects with monolithic functional specifications. Here are a number of best practices that Universal Mind follows to ensure that Solution Intent doesn’t turn a dynamic agile engagement into a static waterfall one:
- Leave options open. Universal Mind fixes as few requirements up front so that specific implementation details can be deferred to local decision making by teams responsible for implementing features, often after prototyping and validation testing. The use cases and desired outcomes of a solution are described in SAFe as the “fixed” part of Solution Intent, while the specific mechanics of a solution are the “variable” part of Solution Intent, refined iteratively and only finalized once a solution releases.
- Build prototypes. Prototypes, models and technical proof-of-concepts can be used to test different implementation options and often serve as a more effective way of communicating requirements than static text documentation. Prototypes need not be high-fidelity; simple tools like InVision or Proto.io can create clickable prototypes that go a long way to confirming Solution Intent across a wide audience.
- Keep it lightweight. Effective requirements documentation need not always follow an old-school “functional specification” format or even classic user story/acceptance criteria structure. In addition to prototypes and models, use cases, context scenarios, whiteboard sketches and spreadsheets can be a better means of establishing a shared understanding of intent, especially when stored in a shared repository like a Wiki.
- Develop standards. User and technical interface standards can help to keep documentation lightweight by providing a means with which to describe common elements in a centralized location so that they don’t need to be locally respecified for individual feature implementations. For example, Universal Mind often creates digital style guides that serve as a visual experience guide and also provide reusable front-end code snippets.
- Stick to a timebox. Requirements definition, like other activities in an effective agile implementation, should not be open-ended but should instead be timeboxed and subject to work-in-process limits so that teams can complete definition activities in a timely manner. At Universal Mind, this means ensuring that high-level Solution Intent artifacts such as wireframes and data models are defined at least one SAFe program increment in advance of the program increment in which a feature is intended to be executed, with implementation teams later defining detailed requirements in a just-in-time fashion.
In other words, the goal of SAFe’s Solution Intent is not “comprehensive documentation” before working software. It is to provide just enough requirements artifacts to enable teams to work from a common understanding of the intended solution.
A major barrier to agile adoption continues to be the perception that agile methodologies discourage the kind of robust documentation and planning that is a prerequisite for large, complex enterprise initiatives. In fact, proper documentation and planning is critical for the success of agile projects, and Universal Mind conducts a wide variety of Definition and Design activities with clients prior to moving ahead to coding. The result of these activities is what the Scaled Agile Framework calls Solution Intent: a high-level body of requirements, including use cases and architecture, that can be defined in a way that leaves room for agile teams to iteratively fill in the details later.