Skip to main content

Value Definition in Agile Transformation

Reading: Value Definition in Agile Transformation
Value Definition in Agile Transformation

I have largely been exposed to Agile transformations in which the completion, more often than not, results in building more stuff faster. In other words, there’s a laundry list of things in the backlog and organizations want to maximize their output to not only play catch up with business requests but to get things to market faster and more predictably. What many Agile Transformations fail to address, however, is the question of why are we building what we are building in the first place.

When an organization finds itself frustrated and asking:Why did I spend $100MM on an application that still isn’t solving the problem I thought it would?” I find myself thinking about the problem being solved and whether that piece was front and center vs. the build itself.

Agile Transformation tends to have a starting point: IT. More often than not, Agile Transformations are happening in a Business Value Vacuum, meaning: we have gotten predictable, but our Business Partners are still frustrated with us. This begs the question: “We are building stuff well, but are we taking into account when—and how often—we are checking to see if we are solving things well?”

This all hovers around the concept of Value. What does “Value” mean, to which set of people, and how are we leveraging that definition in the context of our business strategy?

What is Value?

The first definition of value in the dictionary is “relative worth, merit, or importance.” The keyword here is relative.  If you sequester your value definitions only through an Information Technology lens, I’ve found that value tends to be measured and explained in Agile metrics as part of execution and product delivery. 

While understanding the kind of stability and predictability you have with your delivery teams is important, this definition is really only indirectly valuable to the company as a whole: getting better at creating value is valuable – but not as valuable as creating value. Decisions made only from this perspective treat efficiency and technical stability as primary, but rarely address the questions as to whether it is helping the struggling business partner meet their goals.

In short: what is important to the business stakeholder may not be important, or as important, to IT leadership. I have seen this manifest in wildly different goals between IT and Business Stakeholders.

And there’s the rub. Many orgs have this IT vs. Business mentality and go so far as to keep those areas siloed creating a value vacuum, and nature abhors a vacuum. Organizations often find themselves drawing lines in the sand over things being a Business Objective vs. an IT objective when defining Transformation objectives, part of the hard work is defining goals for the IT org which are demonstrably contributing to the goals of the organization overall.

Who Needs to Weigh In on Value? 

Does Business or IT get to make the decisions on what gets built, when, and why? After all, IT is an enabler of business. However, this can lend itself to weaponization and drive other antipatterns including lack of creativity and malicious compliance. I have seen time and time again where the transactional relationship between the two silos has individuals demanding that things get built instead of problems being solved. This boxes both organizations into a chaotic swirl of solution demand for a misunderstood problem. 

If everything IT does is dictated by the business, you run the risk of having a different problem: now everything is just about fulfilling orders and the technology ecosystem will suffer. So, without the advancement of technology, none of these neat toys can be built with any type of process rigor, so there’s a lot to be said for prioritizing the technology side and forcing the Business to limp along in a fragile technological ecosystem while things get advanced.

So, Why Not Both?

Many organizations have competing goals between IT and business. As the line blurs between the two, and we approach true business Agility, there is an absolute necessity for technical and business leaders to align around what they are trying to achieve around strategy and move forward with investment spending around that unified approach.

When these leaders converge around Value propositions – what are we promising to our customers right now – and OKRs – what do we want to bring to market to solve these customers problems so we can make good on our promises – you force the discussion to be around the cooperation between business and IT and start down the path of business Agility.

Next Why Beta Testing: Why It Matters

Leave a comment

Your email address will not be published. Required fields are marked *