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.


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.


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.


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?

  • 1
    Do you clients have to update (for example your product breaks the old versions) or could you just ship 20 incremental versions and they take one whenever they feel like integrating?
    – nvoigt
    Commented Apr 21, 2018 at 16:05
  • That's an interesting question. I think that most updates don't break other versions per se, but it would make it much harder for us to maintain several concurrent versions. It also moves in the opposite direction of where we're headed, i.e. more standardization. I also expect resistance from Sales/Customer success because of the confusion that would arise from having different clients using different versions of the products.
    – Balala
    Commented Apr 22, 2018 at 0:50
  • 1
    Another thing that has come up is that our clients are feeling a bit overwhelmed by our pace, so having lots of mini-updates might be a bit hard for them to manage. Having said that, I'll ask - maybe the team or the clients could be open to this.
    – Balala
    Commented Apr 22, 2018 at 0:54
  • Can you decouple the acceptance of a story (it works as we envisioned) from the release (it is available to the end-users)? Commented Apr 23, 2018 at 10:51
  • 1
    @AlanLarimer I changed "horizontal" for "vertical" - my bad.
    – Balala
    Commented Apr 23, 2018 at 12:01

2 Answers 2


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.

  • Thanks for your answer. I will sit down with the team and think about how to do this. I still expect quite a bit resistance, so I was wondering if you have good, succinct articles and videos about the benefits of shipping in small increments. Group activities/workshops would be great too!
    – Balala
    Commented May 3, 2018 at 23:59
  • I would just google some articles. For me the most important one is transparency. You develop one feature after the other and finish them completely. there is no, OK we are almost ready with X, Y, Z, they just need to be tested, they just need to be integrated.
    – Seb
    Commented May 4, 2018 at 10:17

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.