Many of us are valiantly in the trenches trying to bring agile practices to our teams, clients, and organizations. Others have heard the buzz over the last decade and are starting to make their first steps. Either way, you need to remember that some issues never go away. The old constraints of scope, budget, and time keep coming back, regardless of software methodology involved. Over on the nonlinear blog, I’ve got a new blog up about working with Agile in the Iron Triangle.

UPDATE (2020-03-31): I have discovered that this blog was taken down so I have copied it over to this site. Enjoy!

Agile methodology: what it means in practice

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 necessarily 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 I 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!