Business readiness – is there readiness for agile development in business?

The development departments are increasingly aligning themselves with the agile topic. As a result, agile development is gradually becoming state-of-the-art. Time and again it creeps into the interface to "Business", as "the other" part of the company is often affectionately called. This is because Business should be closely involved in the development work, as a Product Owner (PO) or a Product Manager (PM à la SAFe), in order to ensure that business value and customer benefits remain in focus and have a high priority. So members of the development department ask: "Is Business ready for agile?"

When tidying up my mailbox, I came across a link to a SAFe discussion in 2016: Under the title "Business readiness for SAFe", someone asked the group for material about the benefits of agility (or SAFe) from a high-level business perspective. The aim was to identify clear benefits from a business perspective, rather than pure development benefits: "Not how effective it is to have cross-functional teams, or why Scrum is great". Brilliantly put! Exactly, such aspects are of no interest to Business. So what did the group have to offer as answers? Curiously, I read on.

And I was rewarded with a wonderful response from a member of the forum: "Agile is much closer to how non-IT business functional areas work. What is a ‘new way of working’ for us is how they’ve always worked: collaboratively and in response to a constantly changing environment". Many thanks, Janet. She provides the example of a legal department that does not have to write a PMO or a change request to adapt to new regulations. "The IT community has constructed its own cage".

This is a tough but clear formulation. We old hands remember: the project management that we now lovingly call "waterfall" had its roots in IT or development in many companies. That was where the first experts who knew how to systematically use the approach were located, and from there it was conveyed to and promoted in the company, in the specialist departments, until ultimately there were business project leaders and even pure business projects. For "scaling", there were various boards at the program and portfolio levels, to help manage the interests and conflicts. IT/Development is now ridding itself of this "corset" thanks to the "agile revolution" and is asking: is Business ready for agility?

It does not matter to me if this assumption is actually correct. What I like about the wording is the change of perspective: it is not about good IT/Development against evil, unwilling specialist departments, nor the other way around. The reason for the company environment currently working the way it does is not (just) because it has been prescribed that way by the specialist departments or management, but because it has been actively shaped and cultivated in that way. Dear readers: please remember this the next time you are irritated with the specialist departments.

What do we learn from this? As a company, IT, Development and the specialist departments are all in the same boat. None of them can solve all the problems on their own – so let's do it together! Have you ever wondered how the specialist department works? How does it handle decentralised decisions and transparency? What makes its world so different from yours? Be curious! Don't be afraid to ask.

A note from me: I came across similar topics in relation to Business Process Management. In this context, the topic of business readiness and change management keeps coming up. Here there are Process Owners, who are a bit like the Scrum Master, as well as the conflict between process and line organisation, with which we are also familiar in project management in Development.

I have been building bridges between IT/Development and Business for 20 years. The distance between them remains, as the differences in language and visions are too great. But it is precisely these different perspectives that provide enrichment and help us move forwards. Remain curious. Help those who try to build bridges. Agility, SAFe and Lean will not be sufficient on their own, as they simply provide a modified way of building bridges. Ultimately, people have to work together and communicate with each other for the company to succeed. And, as always, respect, empathy, openness and transparency help in this regard. And respect. And reliability. And respect. But that was the same in Waterfall times as it is in Scrum times.

Remain curious!

By Ina Paschen