Behind the scenes of the consulting world, a lot of effort goes into defining the boundary of the service or project at hand. This is to make sure both client and consulting firm are on the same page on in-scope and out-of-scope items. For this purpose, every single agency has their own standard set of items they throw into the Statement of Work (SoW).
Although this exercise of scope definition is relatively common practice, for true Agile work where continuous improvement is the rule of the game, there is a struggle to define the boundary of the project in most cases.
Following “Continuous Improvement” forces teams to avoid upfront-design mindset. And so, with an “Agile over Waterfall” motto, iterative approach to project delivery is mandated. This means that your initial roadmap should leave your product to with room to stretch itself and evolve.
That’s where the contradiction between project scoping and product evolution happens.
Product Mindset over Project Mindset
While projects have a defined budget, scope and lifecycle, products theoretically follow the evolutionary architecture and live longer. A product mindset embraces the more gradual and organic delivery of features and is more so long-term focused.
The Microservice Architecture and Service Oriented Architecture is then used to start a design that can allow a more evolution-based delivery. You may have heard about the Amazon teams’ slogan of “You build it, you run it”. This is where teams can be separated and tasked with a product rather than a project.
Solving the Agile and Scoping Problem
So how do we solve the problem of project scoping in agile delivery? The answer is: “Bounded Context” principle of Microservices or SoA Architecture. You first start with your context (i.e. the product or feature at hand), then define it, and essentially by virtue of defining the context, you will end up with a boundary and scope that you can rely on.
On a more practical note, I believe it will be more in line with the above principle to go with a “Time and Material” contract rather than a “Fixed Price” contract. This allows both consulting firms and the client to be more flexible with the conversation from the beginning. By having the rate cards and the bounded context of the product as the fixed parameters, you are navigating easier in comparison to a fixed project scope from the very start.
We are not avoiding the reality of budget for a project that is mostly fixed cap. What we are doing here by “Bounded Context, T&M contracts and Agile Delivery” is addressing the scoping problem. The fixed budget can be the driving factor on negotiating both the rate card at the consulting side and the bounded context at the client side.
Once stakeholders are aligned on the high-level strategy of delivery and overall intent of the product, setting expectations is much easier to achieve on often boring lines of contracts.