5 ms·

> Delivering teams deliver on the market cadence. "delivering teams deliver" -- got that. "... on the market cadence" -- err... market. cadence?

lucozade 9y ago
As "market cadence" doesn't mean anything but sort of sounds like it does, you can just define your delivery schedule as being on the market cadence and you are now a delivering team. When it all goes to shit, the person brought in to clear up the mess can just tut and state that the problem was that the team wasn't delivering on the market cadence after all. Very handy term if you want to sound good but don't actually want to change anything.
dullgiulio 9y ago
Yeah, it's written in Consultenglish, not the language you speak. But that sentence just means "an effective team delivers in time for a product to be useful." ... now that is 5000 euros for my consulting service.
- dep_b 9y ago
  Consultlish, right-clicked it and tapped "add to dictionary"
quetzthecoatl 9y ago
I think it means the teams deliver what the market wants in agile-pugilist speak (cadence of delivery is in sync with the cadence of changing requirements of market).
swanson 9y ago
I think it captures a subtle nuance pretty well. If you're building a SaaS app, you can release several times a day and users will not notice and be fine. If you're building a mobile app, you can release maybe 1-2 times a month and users will be fine. If you push out 3 app store updates every day, that is going against the market cadence. If you're building software for automated machinery, you can release maybe 1-2 times a year. The market will not accept running updates every night. Without considering the context of your market, saying things like "we need to be doing more CI/CD" or "we need to be working in 2 weeks sprints" or "we'll be ready to release the new version in 18 months" might not make much sense at all.
- jdmichal 9y ago
  I disagree. I got the opportunity to hear a talk from Jez Humble, and one of his examples was HP and printer drivers. So this is likely in your last scenario there. They still reaped a lot of benefits from fixing their development processes and advancing continuous integration and automated testing. It looks like it might be mentioned in this podcast, though I haven't listened yet: http://www.se-radio.net/2015/02/episode-221-jez-humble-on-continuous-delivery/ http://www.se-radio.net/2015/02/episode-221-jez-humble-on-co... EDIT: HP is covered roughly minutes 8-10. Also found this, though I'm having trouble getting the video to load to vet it: https://www.safaribooksonline.com/library/view/continuous-delivery/9780134389363/CONT_01_05.html https://www.safaribooksonline.com/library/view/continuous-de...
  - swanson 9y ago
    I don't think we are in disagreement. Certainly there are benefits from these things. The crux is that practices will reach diminishing returns at different times depending on context -- one such piece of context being market cadence. Is continuous integration and automated testing helpful? Yes. Is the cost/effort to move from a process that can deploy monthly to one than deploy hourly worth it? Well, it depends -- if our customers want software updates once per year, then no, it doesn't particularly matter if "master is ALWAYS deployable" or "no builds are failing" on a given day.
    - jdmichal 9y ago
      Except what happens is that business want to release a completed feature. But you're half-way through your monthly deploy cycle and thereby have to either push the date or force your process faster. TheCoelacanth made a sibling comment to yours which I think addresses the idea very well: https://news.ycombinator.com/item?id=16774940 https://news.ycombinator.com/item?id=16774940
  - TheCoelacanth 9y ago
    They define releasing at market cadence as being capable of releasing at will, so that you can release at any time that the market conditions make it desirable to release. That is in no way in conflict with CI and automated testing. In fact, it would be very difficult to achieve without them.
Lunivore 9y ago
I've also heard the Agile Fluency people use the term "Release at Will". The idea is that you could release, if you wanted to... but there might be good reason not to want to, in a particular market. For instance, a retailer might time the release of certain features around Christmas or summer clearance.
jdlshore 9y ago
First two sentences of that section: > Fluent Delivering teams not only focus on business value, they realize that value by shipping as often as their market will accept it. This is called “shipping on the market’s cadence.”

lucozade 9y ago

As "market cadence" doesn't mean anything but sort of sounds like it does, you can just define your delivery schedule as being on the market cadence and you are now a delivering team. When it all goes to shit, the person brought in to clear up the mess can just tut and state that the problem was that the team wasn't delivering on the market cadence after all. Very handy term if you want to sound good but don't actually want to change anything.

dullgiulio 9y ago

Yeah, it's written in Consultenglish, not the language you speak. But that sentence just means "an effective team delivers in time for a product to be useful." ... now that is 5000 euros for my consulting service.

dep_b 9y ago
Consultlish, right-clicked it and tapped "add to dictionary"

quetzthecoatl 9y ago

I think it means the teams deliver what the market wants in agile-pugilist speak (cadence of delivery is in sync with the cadence of changing requirements of market).

swanson 9y ago

I think it captures a subtle nuance pretty well. If you're building a SaaS app, you can release several times a day and users will not notice and be fine. If you're building a mobile app, you can release maybe 1-2 times a month and users will be fine. If you push out 3 app store updates every day, that is going against the market cadence. If you're building software for automated machinery, you can release maybe 1-2 times a year. The market will not accept running updates every night. Without considering the context of your market, saying things like "we need to be doing more CI/CD" or "we need to be working in 2 weeks sprints" or "we'll be ready to release the new version in 18 months" might not make much sense at all.

jdmichal 9y ago
I disagree. I got the opportunity to hear a talk from Jez Humble, and one of his examples was HP and printer drivers. So this is likely in your last scenario there. They still reaped a lot of benefits from fixing their development processes and advancing continuous integration and automated testing. It looks like it might be mentioned in this podcast, though I haven't listened yet: http://www.se-radio.net/2015/02/episode-221-jez-humble-on-continuous-delivery/ http://www.se-radio.net/2015/02/episode-221-jez-humble-on-co... EDIT: HP is covered roughly minutes 8-10. Also found this, though I'm having trouble getting the video to load to vet it: https://www.safaribooksonline.com/library/view/continuous-delivery/9780134389363/CONT_01_05.html https://www.safaribooksonline.com/library/view/continuous-de...
- swanson 9y ago
  I don't think we are in disagreement. Certainly there are benefits from these things. The crux is that practices will reach diminishing returns at different times depending on context -- one such piece of context being market cadence. Is continuous integration and automated testing helpful? Yes. Is the cost/effort to move from a process that can deploy monthly to one than deploy hourly worth it? Well, it depends -- if our customers want software updates once per year, then no, it doesn't particularly matter if "master is ALWAYS deployable" or "no builds are failing" on a given day.
  - jdmichal 9y ago
    Except what happens is that business want to release a completed feature. But you're half-way through your monthly deploy cycle and thereby have to either push the date or force your process faster. TheCoelacanth made a sibling comment to yours which I think addresses the idea very well: https://news.ycombinator.com/item?id=16774940 https://news.ycombinator.com/item?id=16774940
- TheCoelacanth 9y ago
  They define releasing at market cadence as being capable of releasing at will, so that you can release at any time that the market conditions make it desirable to release. That is in no way in conflict with CI and automated testing. In fact, it would be very difficult to achieve without them.

Lunivore 9y ago

I've also heard the Agile Fluency people use the term "Release at Will". The idea is that you could release, if you wanted to... but there might be good reason not to want to, in a particular market. For instance, a retailer might time the release of certain features around Christmas or summer clearance.

jdlshore 9y ago

First two sentences of that section: > Fluent Delivering teams not only focus on business value, they realize that value by shipping as often as their market will accept it. This is called “shipping on the market’s cadence.”