6 ms·

The article describes a predictive project-management approach, and it's the same misguided focus on deadlines you hear from people with a predictive mindset. B

The article describes a predictive project-management approach, and it's the same misguided focus on deadlines you hear from people with a predictive mindset. But an adaptive approach is so much more effective. The adaptive approach: Products should ship as soon as they're ready for market, not according to some deadline. To ship sooner, they should be sliced into pieces that have compelling individual value. Each piece is shipped when ready. And those pieces ("valuable increments") should be sliced into even more pieces that could be shipped sooner in case new business opportunities come along. That way, when that new business opportunity comes along, you're not left with a choice between abandoning work or ignoring the opportunity in favor of finishing what you started. There are times when deadlines matter, such as regulatory requirements, tax season, the Christmas shopping season... but people who are "setting deadlines" aren't talking about real deadlines; they're talking about artificial deadlines because they think it's the right way to manage software teams. (They don't understand that managing by deadline causes teams to compromise internal quality, and that hurts productivity, which creates stress, which forms a vicious cycle that further harms quality and productivity.) If you do have a real deadline, the correct way to manage the risk of missing that deadline is to, once again, use an adaptive approach: identify the smallest thing that will mitigate the risk, build that first, and then incrementally expand from there in as small pieces as possible. Keep the software shippable at every step of the way and ship on the deadline with whatever you finished.

klenwell 4y ago
This is a good argument for continuous release and agile over waterfall. When making estimates, I also like to differentiate between what I call happy-path projections and lazy-bayesian estimates. The former take a sort of get-there-from-here best-case-scenario approach with some buffer tossed in to make it seem like we're not completely delusional. Lazy-bayesian estimates try to identify similar projects or references as a baseline for forecasting. Daniel Kahnemann refers to the two approaches as the inside and outside view in Thinking Fast and Slow and offers an excellent tale to illustrate the difference: http://txti.es/kahneman-outside-view http://txti.es/kahneman-outside-view I wish I could get every project manager I work with to read this. (I've tried.)
presentation 4y ago
While I prefer working that way, I personally know for myself that when a deadline is coming I get more done closer to the deadline. I don’t think it’s one or the other, but a mix of both.
marsven_422 4y ago
jseban 4y ago
Great way to deliver cake! I wonder if you can slice software in the same way though..
- gherkinnn 4y ago
  You don’t slice software. You layer it.
  - black_13 4y ago
- pjc50 4y ago
  Ironically you can't agile a cake, because the whole thing has to go in the oven at once for a defined time period. Or maybe you could; if management can't or won't specify the cake in advance, say whether it should be round or square until ten minutes before the deadline, you could just bake a pile of cupcakes and squash them into the tin.
  - roeles 4y ago
    > Ironically you can't agile a cake, because the whole thing has to go in the oven at once for a defined time period. There are of course delicious exceptions. :-) https://en.wikipedia.org/wiki/Spekkoek https://en.wikipedia.org/wiki/Spekkoek
quanticle 4y ago
The adaptive approach: Products should ship as soon as they're ready for market, not according to some deadline. To ship sooner, they should be sliced into pieces that have compelling individual value. Each piece is shipped when ready. And those pieces ("valuable increments") should be sliced into even more pieces that could be shipped sooner in case new business opportunities come along. I used to wholeheartedly agree with this view, but I've moderated my position considerably. What I've found is that, in practice, this encourages a mindset where a team (or even an entire company) delivers a lot of "half-assed" products or features. They make a minimally viable thing, ship it, and then move on to the next thing. They never come back to actually complete all the fit and finish work. A great example of this is the "Familiar Faces" feature of Nest security cameras. Nest security cameras have a feature where you can train them to recognize people in your household. Then, when they alert, instead of sending a generic alert, they tell you which person was seen. This is great, but Nest never actually finished the feature. There is no setting which tells the camera to only notify when there's an unfamiliar face. You can get no notifications at all. Or you can get a notification every time the camera notices activity. But there's no way to tell the camera, "Hey, let me know if you see a stranger," despite the camera having the ability to distinguish strangers from friends and family. Alphabet products, in general, suffer from this mindset. Another example is the new Suggested Audio feature of Android Auto [1]. I can tap on the icon and it'll bring up a random selection of podcasts from my (now defunct) Google Podcasts subscriptions. Is there any way to customize which podcasts appear? No. Is there any way to make the icon go away, because I use a different podcast app? No. It's just there, waiting for my finger to accidentally brush against it as I try to fast forward in PocketCasts. They made a minimally viable thing, shipped it, and moved on. I contrast this with Apple, or even Microsoft, where there seems to be a lot more focus on having products that are at least somewhat thought out from the perspective of the user, and not shipping until there is certain level of coherence. Alphabet, on the other hand, ships features as soon as they're ready, but doesn't seem to realize that on buttons are useless without their corresponding off buttons. [1]: https://www.androidpolice.com/2021/08/12/android-auto-starts-suggesting-music-news-and-podcasts-so-you-can-keep-your-focus-on-the-road/ https://www.androidpolice.com/2021/08/12/android-auto-starts...
- AdamN 4y ago
jimnotgym 4y ago
The problem with the adaptive model is in creating the culture inside the company to work with it. It might be easy if you are a software company, but for those of us where software is only a part of what the company does, it can be really difficult to get that mindset. Marketing want to know when the release is going to happen, the MD wants to get to market with this new thing that will do x for y (but won't really).... I believe this is the main source of stress in my life! I have tried everything and I win a bit, some of the time. Despite all of this all I really gained was pushing the launch date back a bit. I have manouvered some other departments into the firing line so I don't get all of the flack. I have set the most demanding stakeholders up to argue their demands for new features in a way that makes them look bad for delaying the project. Sometimes I think we take a step towards an agile organisation, then other times we are back at square one
- thunderbong 4y ago
  Also, this might work for a standalone product. But if the product integrates with other systems the client is already using, it becomes extremely difficult to ship something of which only certain parts work. In this case, the client, usually and in my opinion, correctly, expects the product to fulfill all of the functionality planned for.

klenwell 4y ago

This is a good argument for continuous release and agile over waterfall. When making estimates, I also like to differentiate between what I call happy-path projections and lazy-bayesian estimates. The former take a sort of get-there-from-here best-case-scenario approach with some buffer tossed in to make it seem like we're not completely delusional. Lazy-bayesian estimates try to identify similar projects or references as a baseline for forecasting. Daniel Kahnemann refers to the two approaches as the inside and outside view in Thinking Fast and Slow and offers an excellent tale to illustrate the difference: http://txti.es/kahneman-outside-view http://txti.es/kahneman-outside-view I wish I could get every project manager I work with to read this. (I've tried.)

presentation 4y ago

While I prefer working that way, I personally know for myself that when a deadline is coming I get more done closer to the deadline. I don’t think it’s one or the other, but a mix of both.

marsven_422 4y ago

jseban 4y ago

Great way to deliver cake! I wonder if you can slice software in the same way though..

gherkinnn 4y ago
You don’t slice software. You layer it.
- black_13 4y ago
pjc50 4y ago
Ironically you can't agile a cake, because the whole thing has to go in the oven at once for a defined time period. Or maybe you could; if management can't or won't specify the cake in advance, say whether it should be round or square until ten minutes before the deadline, you could just bake a pile of cupcakes and squash them into the tin.
- roeles 4y ago
  > Ironically you can't agile a cake, because the whole thing has to go in the oven at once for a defined time period. There are of course delicious exceptions. :-) https://en.wikipedia.org/wiki/Spekkoek https://en.wikipedia.org/wiki/Spekkoek

quanticle 4y ago

The adaptive approach: Products should ship as soon as they're ready for market, not according to some deadline. To ship sooner, they should be sliced into pieces that have compelling individual value. Each piece is shipped when ready. And those pieces ("valuable increments") should be sliced into even more pieces that could be shipped sooner in case new business opportunities come along. I used to wholeheartedly agree with this view, but I've moderated my position considerably. What I've found is that, in practice, this encourages a mindset where a team (or even an entire company) delivers a lot of "half-assed" products or features. They make a minimally viable thing, ship it, and then move on to the next thing. They never come back to actually complete all the fit and finish work. A great example of this is the "Familiar Faces" feature of Nest security cameras. Nest security cameras have a feature where you can train them to recognize people in your household. Then, when they alert, instead of sending a generic alert, they tell you which person was seen. This is great, but Nest never actually finished the feature. There is no setting which tells the camera to only notify when there's an unfamiliar face. You can get no notifications at all. Or you can get a notification every time the camera notices activity. But there's no way to tell the camera, "Hey, let me know if you see a stranger," despite the camera having the ability to distinguish strangers from friends and family. Alphabet products, in general, suffer from this mindset. Another example is the new Suggested Audio feature of Android Auto [1]. I can tap on the icon and it'll bring up a random selection of podcasts from my (now defunct) Google Podcasts subscriptions. Is there any way to customize which podcasts appear? No. Is there any way to make the icon go away, because I use a different podcast app? No. It's just there, waiting for my finger to accidentally brush against it as I try to fast forward in PocketCasts. They made a minimally viable thing, shipped it, and moved on. I contrast this with Apple, or even Microsoft, where there seems to be a lot more focus on having products that are at least somewhat thought out from the perspective of the user, and not shipping until there is certain level of coherence. Alphabet, on the other hand, ships features as soon as they're ready, but doesn't seem to realize that on buttons are useless without their corresponding off buttons. [1]: https://www.androidpolice.com/2021/08/12/android-auto-starts-suggesting-music-news-and-podcasts-so-you-can-keep-your-focus-on-the-road/ https://www.androidpolice.com/2021/08/12/android-auto-starts...

AdamN 4y ago

jimnotgym 4y ago

The problem with the adaptive model is in creating the culture inside the company to work with it. It might be easy if you are a software company, but for those of us where software is only a part of what the company does, it can be really difficult to get that mindset. Marketing want to know when the release is going to happen, the MD wants to get to market with this new thing that will do x for y (but won't really).... I believe this is the main source of stress in my life! I have tried everything and I win a bit, some of the time. Despite all of this all I really gained was pushing the launch date back a bit. I have manouvered some other departments into the firing line so I don't get all of the flack. I have set the most demanding stakeholders up to argue their demands for new features in a way that makes them look bad for delaying the project. Sometimes I think we take a step towards an agile organisation, then other times we are back at square one

thunderbong 4y ago
Also, this might work for a standalone product. But if the product integrates with other systems the client is already using, it becomes extremely difficult to ship something of which only certain parts work. In this case, the client, usually and in my opinion, correctly, expects the product to fulfill all of the functionality planned for.