How to deal with clients' resistance to smaller deliveries?

Question

When I read this question (Dealing with external departments continuous delivery / smaller feature scope), it made me think of our situation at work. The major difference, though, is that the resistance to continuous delivery is mainly coming from our clients.

Context

I work in a small b2b2c company that caters to large online real estate platforms. My role (similar to that of a scrum master) is to help our (cross-functional) dev team become more agile by simplifying/optimizing workflows, facilitating collaboration and learning, and encouraging incremental value creation. We're using a loose kanban framework, but I think this issue would apply even if we were using Scrum or XP (hence the tags). No one on the team has experience with Agile/Lean, but I've seen steady progress in that regard over the last year.

Issue

Strangely enough, the main problem I'm facing as I'm trying to suggest more vertical slicing to create value faster (e.g. releasing one feature in less than a week instead of waiting three to four weeks to release five) and shorten the feedback loop, is that clients would rather we release updates less often. From my understanding, it's because our products are embedded on our their website, so they use the same (slow and heavy) processes that they use for their own website and products, for both QA and marketing purposes.

It seems to me that it would still make sense to ship small increments internally, and then bundle them in a release to our clients, but given the team's lack of experience with Agile practices, they'd rather do the following:

• do the "full flow" (from design to deployment on our testing server) for one feature
• for the rest, use vertical slicing, i.e. create one card (task) for data collection, one card for data processing, and so on up until the front-end integration.

The team's point is that given that we can't ship before the full release is done, it's more efficient to do all the processing at once. Since they're not used to Agile practices, this is also more consistent with the way they've always worked.

From my perspective, this adds a lot of pressure to the person at the end of the process (i.e. front-end integration) and it removes flexibility in that if we're running out of time we can't just drop features.

Question

What are good approaches to dealing with these kinds of clients? Even if the client didn't want to change, should I nudge the team to ship smaller increments internally?

Answer 1

I would focus on changing the customers' processes to integrate your releases more easily. But there are many details to consider.

• You talked about QA. Does your customers' QA influence your product release/development?
• Are customers directly involved in your development process?
• Do you develop your customers' requests and your customers' product?

If not, I would not care about their processes. They get the release whenever they want. If they skip releases and take every 5th release, it's on them. You need to make sure that they can skip.

If so, since you develop your customers' product, try to understand completely why your customers are not willing/able to release faster. Check out what the benefits for them could be if they would change. Check out how they would need to change, to gain these benefits. Consult them to optimize their release processes.

But anyway, small incremental releases should be preferred internally. I don't know the exact relation you're in with your customers, but if it's unrealistic to change anything with your customers, try to encapsulate your release process from the rest. You stay effective, flexible, and transparent, and your customers check in whenever they're ready. They always get a finished piece of software. The benefits of incremental development are known.

Answer 2

You may want to consider using feature toggles.

This will allow you to do frequent production releases, but give your clients the option to only make features live when they are happy with their functionality.

In the long-term, it might be worth working with your clients to improve their delivery processes. Continuous delivery works best when it is end-to-end.