How IT can build an agile business partnership

Organizations are using agile at an increasing rate, citing numerous benefits stemming from both formal Agile practices and those advanced by similar methodologies such as DevOps. Yet obstacles towards a broader embrace of an agile business partnership remain.

The 13^th annual State of Agile Report released in 2019 cited 11 common challenges to adopting and scaling agile. Moreover, it found that the three biggest barriers were organizational. The most commonly cited challenge was organizational cultural being at odds with agile value (52%), followed by organizational resistance to change (48%), and inadequate management support and sponsorship (44%).

In this Q&A, Gene Kim, an award-winning researcher, author -- his latest book is The Unicorn Project -- and founder of IT Revolution, discusses how CIOs and other enterprise technology leaders can move agile beyond IT. Get his views on implementing an agile business partnership and steps to take if stakeholders resist. The interview has been edited for length and clarity.

Is there still a disconnect between IT and the business on what agile processes, from the official Agile methodology to DevOps, mean and how they're defined?

Gene Kim: Problems can be bypassed by using [agile and DevOps expert] Jonathan Smart's definition of DevOps: better value sooner, safer, happier. It's hard to argue with that. Who doesn't want more value, less time, with more happiness? It neutralizes questions and objections. And it's a great way to get a productive conversation started.

Gene Kim

We know agile is a radically different way of work where we have a more collaborative relationship with our stakeholders that leads to far better outcomes. So rather than arguing about how we define specific terms, which doesn't advance the discussion or put us in the direction we want, we can say, 'I'd love to work in a way that delivers better value sooner, safer, happier.'

IT seems to know whether they're doing agile well. What does a successful agile business partnership implementation look like for the whole enterprise?

Kim: My favorite presentation from the DevOps Enterprise Summit [run by IT Revolution] is when technology leaders present with their business counterparts. The business leaders aren't just proximate to them on stage, they're saying, 'Here [are] my biggest goals, dreams and aspirations and without this technology person none of it would have been achieved, and here [are] all the ways we were able to win in the marketplace as a result.'

I love it because that's the relationship we all want -- one of mutual collaboration and mutual support with common goals and shared credit. That's the goal. And those are the technology leaders who are being promoted, given more budget and being asked to take on bigger initiatives.

As CIOs try to bring agile to the broader enterprise to form an agile business partnership, what roadblocks do they typically encounter?

Kim: Whenever technologists hear from their business counterparts, 'We're not winning in the marketplace because we can't deliver on our customer needs fast enough at the quality we want,' we should be concerned. So, it's incumbent on technologists to educate their business counterparts on agile.

But there are things business people can do that jeopardize those goals [such as] not paying down technical debt, not allowing engineers time to fix defects, [and] not allowing engineers time to improve the systems [the business] relies on in their daily work. When that's happening, that brings the death spiral.

There can also be a misunderstanding of how work is done. There's the notion they can divide up all the work and outsource it to different parts of the globe and expect better outcomes. But coding is knowledge work, not factory work. Coding is a conversational and exploratory endeavor.

And many things go wrong when you deprive engineers of the ability and freedom that enables that endeavor, like writing 40-page requirement documents and holding them prematurely accountable to cost, scope and date when the problem they're trying to solve is not well enough understood.

This problem was co-created by business and technology leadership so the solution must be co-created by business and technology leadership. [The presenters at the DevOps Enterprise Summit] are working together, removing obstacles and they have a shared understanding of the problem. If you listen to them talk, there's a trusted working relationship I think every technology leader would envy and almost every technology leader would aspire to have.

CIOs frequently hear about building trust. How does one do that?

Kim: Trust is created when there's a combination of 'I understand what the problems are, I can capably deploy the resources to solve that problem and I do it in a way that achieves those objectives.'

I think a common dysfunction is when technology says we can't get permission to automate or improve systems or to reassign people to do experiments. Often, my response is 'Since when do you need permission?' Every leader is responsible for improving the procedures and processes they use in their daily work. Doing that earns us trust.

Can you run down some key steps to successfully creating an agile business partnership?

Kim: Have dedicated teams working solely on those features and capabilities and the outcomes they need. They're not scattered the way many teams are -- they're not working on eight or nine or 10 different projects. They're not broken up and reshuffled just when they've become effective. You bring work to the teams, not the teams to the work. Long live teams.

Short intervals. It's not six months between checkpoints; it's once a week where the business stakeholders are reviewing what's created and giving rapid feedback. Waiting too long for feedback is a death knell.

Project owners. A great project owner will interact with a team 10 times a day and the engineers will have questions for the product owner 10 times a day, which shows how critical it is to have business stakeholders involved.

And there are the right technical pieces: automated tests and, ideally, an environment where everything is being tested frequently, [and] where they're merging their code frequently so it can be demoed and used at any time. If testing and deployment happen infrequently, it can end in disastrous results. You don't want to do [testing and deployment] right before [the product is] supposed to be used by customers.

And if the business still doesn't embrace agile?

Kim: One thing that makes me angry is when technology builds a feature and, at some point, there's a demo to get feedback and the business stakeholders don't show up. It's not only a demeaning thing to do to fellow employees but a disrespectful use of some of the most important talent in a company.

Sometimes the advice given when the business owners don't show up is 'Don't work on the features because it must not be important to [the business unit].' It seems so obvious to me that if you have business stakeholders who don't show up at the meeting then they don't care about it. You want your teams working on the most important problems, so if your colleagues continue to not show up, then work on the things where you have truly engaged business colleagues who want to be co-creating the solution with you.

You want an enthusiastic engaged workforce that is using its engineering to solve problems, and you want software engineers to be productive. [And] considering how much they're paid, you can't afford to have developers not developing.

Clearly, you want everybody engaged, working together and being a good partner, but unfortunately you only have so much control. [Showcase] examples of business leaders and technologists who work together to win in the marketplace and ask your [reluctant] business colleagues: 'What can we do to make that happen? How would you like to co-create some solutions for our future?' If they say yes, then you have the basis for a good conversation. If they say no, then you gave it a shot. Go find something else to work on.