Ways to sabotage agility #1 — prevent business engagement

Chris Davies
Jul 22, 2017 · 4 min read

This is the first in a serious of posts about how to sabotage business agility — the things organisations do that actively get in the way of agility.

A collaborative way of working is fundamental to agility. Remember the Manifesto for Agile Software Development — “Individuals and Interactions over Processes and Tools”?

Well, that’s generally what we’re talking about here — the most fundamental value of agile. Specifically, we are referring to Principle 4, which states:

Business people and developers must work together daily throughout the project.

How must business involvement you need will depend hugely on the nature of the work you are doing, the expected outcomes and whether the product already exists or not.

But, you can actively prevent business involvement in two main ways.

The first is to ensure business people don’t have the time to spend with the team.

As an example of this, one day in 2011, I flew to a major European city to present a one-day overview of Agile to a senior management group. Each person present represented one of the business areas in their region of this global organisation. The Managing Director was there, as were the heads of Finance, HR, Product Development, Marketing, and others.

The morning went well. I talked them through the origins of Agile, the problems typically associated with more traditional plan-driven, predictive project approaches, and the basic principles and practices inherent to Agile approaches. Heads were nodding, and there were smiles aplenty at first. But as the day wore on, brows began to furrow and the smiles and laughter of the morning gradually disappeared.

When we reconvened after lunch, I started by asking if everyone had understood what we’d covered in the morning sessions, and if anyone had any questions or concerns. One lady raised her hand and then immediately turned to the MD, and said:

“This is an excellent way to work, and I agree that this is how we should be working, but how can we spare the people to spend that much time on IT projects? I have 12 people in my department and they are all working 9 hours every day doing their normal job. They have no time to attend these workshops, stand-up meetings and reviews that Chris is talking about.”

The MD looked at me, so I replied:

“How good are IT at interpreting your needs and then meeting them?” He smiled and shrugged his shoulders.

“The only way that IT know what you want is to ask you. But your staff need to be available to be asked. And the only way that you know whether what IT are building meets your needs is to look at it on a regular basis. And your staff need to be available to do that too.”

A lack of business involvement in software projects is always a problem, even in traditional ‘plan-driven, projects. But in agile, it’s critical.

If the development team are trying to work in an agile way, there is a risk that, without active business involvement, they will be making assumptions about the business needs and how to meet them. And they will develop a solution that only partially meets the business need, or they develop the wrong solution entirely, because they didn’t understand the key requirements or priorities.

I can think of at least one project that was badly compromised because the development team did not understand the single biggest requirement — decommissioning of an existing system. With no business involvement, they designed a new system that relied totally on the legacy database underlying the system they were trying to replace. So the new system, being also entirely reliant on the old database, became an expensive front-end, with no benefit being realised by the expected decommissioning, which now could not occur.

Generally speaking, business departments are staffed for ‘business as usual’ — enough people to get the day to day work of the department done. Allocating a portion of staff budget for project involvement is rather rare, I find. But that is basically what is required.

It need not be a huge amount either. A Product Owner is typically not required to be engaged with the team on a full-time basis. Depending on the type of project, the knowledge of the people involved and the complexity and stability of the requirements, this can be a part-time role. If the Product Owner has a restricted amount of time available, the best thing to do is negotiate it.

* * * * *

The other way in which you can actively prevent business engagement is to put a layer of proxy business people in-between the real customers and the developers. This ensures that the proxy group are able to overlay their own opinions, prejudices and biases onto what the real customers have asked for.

One B2B organisation had a Product department, whose members served as Product Owners for a handful of Scrum teams. At a high-level, each P.O. pulled new features from a single Product Backlog, but these were assigned to specific P.O.’s (and hence to their teams) well in advance of development starting.

They had to juggle the demands of several client organisations (which is normal), but they were also giving directions to the teams based on which client was shouting loudest at the time, or was most likely to cancel their contract. Neither the people in the client organisations, nor their account reps ever came anywhere near the development teams. They never contributed to planning sessions, at any level never saw a demo by the development teams.

They were given demonstrations, though — carefully scripted ones by the Product teams, with little or no feedback ever reaching the development teams.

By far the most damaging part of this structure was that the Sales & Marketing people were presenting clients, and prospective clients, with the long-term vision for the product, the sort of features that they hoped to build. These were, of course, not demonstrations at all, but overly-optimistic sales pitches, that simply set the teams up for failure.

We often wondered how much the features we were building would actually be used when they were completed and shipped.

Chris Davies

Written by

Team Coach | Leadership Coach | Agile Coach | ORSC Practitioner. I write about teams, leadership, organisations and agile. www.chrisdavies.coach

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade