On a recent thread I had started, on Linked In, the conversation turned to whether or not organizations should expect to see a reduction in the cost of their development when they ‘go agile’.

To be clear, Agile frameworks and Agile delivery aren’t about reducing the cost of your development costs, and if that is your goal, then the best way to do that is to stop funding as many projects. Fewer projects will directly reduce your cost of development.

If however,  you are looking to maximize your investment in your software development, then Agile is how you can do that. But don’t expect Agile frameworks to be the sole vehicle do to that.

Frameworks organize work that teams will be taking on, however, if that work is mapped out in a large project orientation, then all you are doing is delivering waterfall in smaller increments.

Instead for you to maximize your development costs you must do two things well:

·        Prioritize by value (strategically aligned with OKR’s)

·        Become engaged more often (via regular reviews)

Again Agile frameworks only get you so far in most of this, and the agile frameworks and community has done a poor job in helping figure out what value means and how to prioritize by it.

The value of what your teams work on will emanate from your organizations’ strategic goals and objectives. Too often I see teams working on things that they are not necessarily sure are the most valuable to the organization, but when left in a feedback void, they will do what they think best. 

Generating a value model is an important first step in value identification (more on this soon). Valuable ideas can and should come from anywhere in the organization. When ideas are submitted you need a quick and easy way to identify value (with a value score) to provide input into your overall portfolio of work.

Having a value-based roadmap of work ensures everyone has transparency to what teams will be working on. This process also provides a smooth flow of work to our teams, which will increase quality and productivity.

The second part of maximizing your development costs surrounds being actively engaged in reviewing what your teams are delivering. This is not about being fed a status report, this is about you the leader sitting in on sprint reviews and seeing the working software as it’s delivered. 

What’s the goal of this? To STOP working on something, when you see either the team has delivered enough to meet your needs today OR the team delivered something that isn’t what you had in mind, which will cause you to go back to create a new hypothesis, or ditch the idea completely.

The objective is a lean concept, there is value in work not done.

In one organization where I worked, we had a large initiative that our leadership wanted us to take on. We broke it out into three phases, with the most important elements being taken into our first set of sprints. Because our leadership was engaged when we delivered during the first phase (MVP), when we were done, they said ‘this is good enough, we have another more pressing need for the team to take on’.

In your waterfall world, two things would have happened if you decided to stop this project (which is your only option) in favor of another one.

• Nothing in the first project would be released, which means no financial benefits (CapEx/OpEx) happening.

• The code from the first project is in the codebase and is now causing bloat and tech debt that will slow down the team(s) long-term.

Working in an engaged Agile environment is what will maximize your development investment.

The goal of agility is about value and speed, not reducing costs.