Agile methodology: what it means in practice
By: Sitecore MVP Jason St-Cyr
If you’ve been considering incorporating the agile methodology into your organization, be sure that your team understands what it means in practice. Avoid being caught up in the buzz with this primer on agile in the iron triangle.
It’s no secret that developers everywhere rejoiced at the thought that agile practices would finally bring about proper business prioritization and the understanding that scope should be flexible, not fixed. Unfortunately, this is not the reality of agile project development.
The agile method is quickly gaining prominence in many markets due to a popularity buzz, as opposed to a comprehensive understanding of how the methodology works.
The same problems still exist: a desire for fixed scope, with a fixed date, and at a fixed cost.
This iron triangle oftentimes cements its way into the minds of your stakeholders, and once it has, no development process is going to save you.
When you encounter the iron triangle, a compromise will need to be made with the client. We’re not necessary talking about an external client- depending on the makeup of your project that client could be your manager, someone else on your team or another outside party.
The Agile iron triangle
Regardless of who the client may be, they’ll need to choose from one of the following (or a balance of all of them):
- Scope adjustment: You may need to drop some features to allow room for changes. Some changes to already-delivered features may indeed be more important than building new features that might still be in your backlog. Your product owner (or whomever is helping determine priority) can work this out with the client so they don’t ask for a change and lose a feature they actually wanted more, or vice versa. Keeping an eye on business priority is key here!
- Schedule adjustment: Allow for a later delivery date, or allow for multiple delivery dates where an initial set of features is delivered on time and then the team delivers a second release with the new scope at a later date. Ask your client: “Is it okay to deliver what we have now on time and deliver that change you want two weeks later?” This is iterative development, so development should be able to be continuously delivered across scenarios.
- Budget adjustment: This is probably the hardest to do, as most clients have fixed budgets for projects. If the date is really important (go-to-market plans are in place and missing the date is not an option) and the scope cannot be reduced to fit into the timeline, you can use a request for additional budget to increase the size of your team to allow you to do more within a given iteration. WARNING: Be wary of the mythical man month!
The most important component in all of this is that the client needs to understand the impact of what they’re asking for. When they ask for a change, they are either losing a feature, missing the date, or increasing the cost of the project. Making sure the client understands the impact of their request is paramount and one of the many reasons that we continuously encourage someone playing the role of product owner with the client in order to keep expectations in check.
In some cases, development teams experience this pressure from an internal client: your manager. Your execution team may need a team lead that interfaces with the team’s manager and is having these discussions with them about the impact of changes to the backlog. The team’s manager doesn’t want you to fail either, but sometimes it is just a lack of understanding somewhere along the chain. It’s entirely possible that your manager might have somebody coming down on them about the schedule, so giving your manager ammunition to go back up the chain and fight for more time, budget, or scope reductions will help them and you!
Wondering how you too can become an agile ace? Check out our nonlinear digital bootcamps on agile project management.
