Business Aspect of Agile

139 views Asked by At

As I understand Agile is more or less like an open/flexible process. Meaning I anticipate and expect stakeholders' rapid changes.

But how about the business aspect of this? What if the stakeholder has a specific budget for a product?

What if their changes go beyond the specified budget?

Is there a term as an "agile contract"?

3

There are 3 answers

0
Joe Ratzer On BEST ANSWER

One benefit of Agile is that unfinished stories are always tracked at the end of each sprint (e.g. 2 weeks).

In contrast, a more Waterfall-like approach can "encourage" the unfinished requirements to go unidentified until the end of the development phase (e.g. months).

Better to know ASAP that certain requirements are not going to be addressed on the current budget.

For these reasons, the most "difficult" requirements are often tackled first.

In short, Agile is perfectly business and budget friendly.

0
will webster On

The business should expect a better product. Typically a large percentage of features are not used or are worked on at the expense of something more valuable.

Leaving decisions of what to build to the last responsible moment and not trying to guess all the detailed requirements up front means you are more likely to get a better product. By collaborating as a team and avoiding costly traditional negotiating over requirements upfront, sign offs, and hand overs you will be more efficient.

Agile explained through the Stacey Matrix and Cyefin helps understand why Agile works best on certain projects.

The Project Management (Iron) Triangle helps demonstrates what suffers with projects when requirements change and budget and cost remain fixed - quality.

This can is a vicious circle as technical debt slows teams down. As they are pressed to deliver more quality gets worse.

0
Steven Voyles On

Other advantages of agile in your scenario are the focus on prioritizing requirements and creating finished work in increments.

When we developed software in phases with Waterfall, and the changes went past the budget, we often found out too late and were forced to choose between supplementing project funding or getting nothing for our sunk cost. Usually the choice was to keep spending so that we'd have something to show for all that effort and project budgets would quickly get out of control.

With agile, we build in order of priority and create production quality work in each increment. When we get to the point that the ask exceeds the budget we are in a better position because now we have a production quality product that includes all of the most important features that could be built for the budget we had. We can still choose to spend more money to get more features if we want to, but we also have the option to stop and we still have a product to show for it.