Director of Engineering
The project management triangle is comprised of three project constraints or boundaries: time, scope, and cost. The best product companies understand that flexibility is often required on at least one of these boundaries. As needs and objectives evolve, knowing which boundary is flexible lets you adapt seamlessly without affecting your ability to deliver a successful product.
Essentially, it’s a way of assuming the unknown and accounting for the fact that things don’t always go as planned.
Flexibility isn’t a bad thing; on the contrary, building it into your process is a way to mitigate risk, which it’s encouraged in agile development. The key is understanding exactly where your flexibility lies.
Where Does Flexibility Lie?
“Knowing which boundary is flexible lets you adapt seamlessly without affecting your ability to deliver a successful product”
There are some projects where delivery date is set in stone. The product may need to be released simultaneously with another launch; for example, a pre-loaded app that needs to be ready for the release of a new device or prior to a scheduled event. When this is the case, one of the other two boundaries will need to be flexible.
For other projects, time may not be the most important aspect. If your business goals dictate that the product needs a certain amount of features and functionalities or needs to be developed within a particular budget, time will be the flexible boundary.
When time or budget are rigid, scope is where the flexibility needs to lie. There is nothing wrong with having to scale back features and functionalities; on the contrary, going to market with a minimum viable product and following a rapid and frequent delivery model allows you to collect data and use learnings to add value to users on a continuing basis. It’s also a good way to prove concepts in the market, which can be used to create a business case for additional budget/funding from stakeholders.
If there is scope creep or project scope increases but timeline is rigid, budget needs to become the flexible boundary. When more resources are required to deliver and more features and functionalities are requested for the product, budget changes.
Identifying Your Flexible Boundary
While there are variations in the way agile development is practiced, a foundational aspect is the ability to adapt and respond to changes without losing velocity. To achieve this, flexibility is a necessity.
In an ideal world, you wouldn’t need to be flexible on time, scope, or budget. But failing to account for the fact that you might have to bend as products evolve or new needs arise is very risky; if something does change, there is no contingency plan that allows you to deliver a market-ready product.
Enter flexibility. You have identified which of the project boundaries is flexible, which allows you to adapt without losing velocity. Consider the following scenario:
You have identified that scope is your flexible boundary. You know which features and functionalities are critical for your minimum viable product, and there are others on the product roadmap that are highly desired and nice to have. You prioritize tasks accordingly using the MoSCoW technique (Must have, Should have, Could have, Won’t Have), aiming for a particular number of features/functionalities. But, you have accounted for the fact that if there are issues, you can scale back and still have the capacity to deliver your minimum viable product within the other two boundaries. As a result, if there is a snag, you are now able to focus resources on the critical aspects of the project and save lower priorities for future releases.
“Failing to account for the fact that you might have to bend as products evolve or new needs arise is very risky”
In this scenario, if scope wasn’t identified as a flexible boundary, the result would be a sub-par product with partially completed or improperly tested features, delivered in a rush and likely defective. Trying to deliver everything would essentially give the user nothing – except a poor user experience.
The same principle applies to time and budget. If you plan for the possibility that things may not go as planned, you are able to adapt.
Building Flexibility Into Your Process
There are practices that allow you to bake flexibility into the agile app development process itself. These practices help with time, scope, and budget management, but also allow for rapid adaptability to changing needs. At Clearbridge, we use an agile squad model that includes a number of these practices.
- Squad-based agile development – Squads are small co-located teams that are responsible for the end-to-end delivery of a product. They plan together, share knowledge, and have a known capacity. This reduces risk and allows for predictable velocity.
- Rolling wave planning – Rolling wave planning involves delaying product decisions until you’re in the best position to make them. It lets you analyze and act upon knowledge that wasn’t available at project kick-off. This lowers your risk, minimizes downtime, and allows you to adjust to changing product needs.
- Flexible capacity – Squads have a known maximum capacity, but the ability to scale up or down within that capacity. Since all members share knowledge of the project, when you need the squad at full capacity every team member can easily jump in; when the workload is lighter resources can be scaled down.
Ultimately, flexibility is at the basis of a truly agile development methodology. Identifying where your flexibility lies, accounting for it in your project plan, and building it into your development process will allow you to adapt to changes and still have the ability to deliver a successful product.
To learn more about our squad-based agile development process, click the article below or get in touch.