This has some very interesting ideas, with some also interesting assumptions. One of the biggest assumptions here is that your team will understand this. That your team's member are highly competent, in synch, on board, and critical thinkers. Also, a very open minded stakeholders. If you think you can build that team, then this might be worth trying. In all other cases, seems too risky.
I saw another video from Ryan saying they split teams on 1-2 enginers and 1 designer, and these squads do their own shaping. I don't know how much developers we are talking here, but it's a good strategy to split as much as you could to keep everyone commited on working in one single thing during the 6-week cycle.
Great video Ryan! How do you "enforce" done though? So the designer and the two devs work incredibly hard for a cycle but they don't get to a point where they can ship the feature....how do you guys handle that?
I don't know if you got your answer but basically if they don't get to done they might decide to drop the thing alltogether or give it another week or two depending on how confident they are it will ship after that. You can watch their other videos - just search: how we work at basecamp This should help
What happens to products that will take more than 3 engineers and 6 weeks to build? Does this approach go out the window, or do they start a new 6 week cycle until it's officially "done"?
Hello Ricardo. I'm not sure if you got your answer yet. I believe you must break the whole more than 6 week product concept into pieces of it working, when must-haves are prioritized. In 6 weeks you might have something to learn with your customers or a test group, working "clickable" software, despite it's not yet in the desired ready state. Then, you can go for other cycles to shape and build another piece. I think when it requires PoCs or some research, it might be done on cool-down and shaping.
@@brunosp86 I kinda see the unrealistic part of this. Like, (according to this talk and your comment) this is an approach that has been working in 1 company. There are more than 1 companies in the world. This approach assumes a high level of competence (not only technical, but business like) for Engineers. Very open mind from stakeholders (They do not know what they are gonna get... they just got a feeling). The level of trust here is huge. (or perhaps the same, but just more honest). With a world with a huge demand for software engineers, this approach seems to be for very particular cases.
![MonYAY: Dismantling the myth of hustle culture - David Heinemeier Hansson [SaaS Revolution Show]](/img/n.gif)
This has some very interesting ideas, with some also interesting assumptions.
One of the biggest assumptions here is that your team will understand this. That your team's member are highly competent, in synch, on board, and critical thinkers.
Also, a very open minded stakeholders.
If you think you can build that team, then this might be worth trying.
In all other cases, seems too risky.
just read the book .. how does this scale?
I saw another video from Ryan saying they split teams on 1-2 enginers and 1 designer, and these squads do their own shaping. I don't know how much developers we are talking here, but it's a good strategy to split as much as you could to keep everyone commited on working in one single thing during the 6-week cycle.
why does this guy reminds me of that main character from silicon Valley? :DDD
Came to the comments for this :D
Great video Ryan! How do you "enforce" done though? So the designer and the two devs work incredibly hard for a cycle but they don't get to a point where they can ship the feature....how do you guys handle that?
I don't know if you got your answer but basically if they don't get to done they might decide to drop the thing alltogether or give it another week or two depending on how confident they are it will ship after that. You can watch their other videos - just search: how we work at basecamp
This should help
What happens to products that will take more than 3 engineers and 6 weeks to build? Does this approach go out the window, or do they start a new 6 week cycle until it's officially "done"?
Hello Ricardo. I'm not sure if you got your answer yet. I believe you must break the whole more than 6 week product concept into pieces of it working, when must-haves are prioritized. In 6 weeks you might have something to learn with your customers or a test group, working "clickable" software, despite it's not yet in the desired ready state. Then, you can go for other cycles to shape and build another piece. I think when it requires PoCs or some research, it might be done on cool-down and shaping.
@@douglashaubert7678 That's just going back to regular Agile then.
Very interesting idea.
He looks like Curtain from this country
Lol
I think Ryan is a very handsome guy. And yes, I'm a dude. Wish he was my boyfriend!
Smart and handsome.
So many unrealistic ideas.
He actually said that his company been doing this for the past ten or so years... How's that unrealistic?
@@brunosp86 I kinda see the unrealistic part of this.
Like, (according to this talk and your comment) this is an approach that has been working in 1 company.
There are more than 1 companies in the world.
This approach assumes a high level of competence (not only technical, but business like) for Engineers.
Very open mind from stakeholders (They do not know what they are gonna get... they just got a feeling).
The level of trust here is huge. (or perhaps the same, but just more honest).
With a world with a huge demand for software engineers, this approach seems to be for very particular cases.