3 ms·

This hits on exactly why I was drawn to SAFe. After all the feedback I got from this... https://news.ycombinator.com/item?id=17154355 https://news.ycombinator

This hits on exactly why I was drawn to SAFe. After all the feedback I got from this... https://news.ycombinator.com/item?id=17154355 https://news.ycombinator.com/item?id=17154355 Someone pointed me to Reinertsen's Principles of Product Development Flow book, which put into numbers and models everything I'd been trying to say (and then some). It worked great with my team, but I was failing hard at communicating and involving everyone on the business side so I started researching for something that provided the business side, wrapped around his methods. Which drew me to Scaled Agile Framework. There's a lot in it, but the core of it is simply on a pace of 8-12 week increments, you spend 2 days letting your developers provide you with a plan, estimated based on 2/3 of their actual available time. They make the plan...not management. The plan is presented to management, management discusses tradeoffs and options, then ultimately management will accept a final plan and the developers provide a confidence level in their ability to deliver the plan that they have set out. When new requests come in, they are discussed for the next 8-12 week increment so the developers can focus on executing the plan that everyone agreed on. There's still room left for small things that come up, there are progress check-ins and communications that happen along the way. Risks to the plan are identified and discussed so everyone is aware of them up front. Variability is assumed (up and down) throughout the plan. The only assumed commitment is to the 8-12 week deliverable. Nothing in between is expected to have a guaranteed delivery date. It leaves little room for surprises and plenty of room for people to work in a reasonable manner. I can't speak highly enough of how effective it is to addressing this problem.

andi999 7y ago
You should multiply the plan of the developers by 3-4 before presenting to management. So management can cut to factor of 2-3 and you will barely reach it. I never met a developer who doesnt underestimate the effort needed by a vast amount. (including myself)
- brightball 7y ago
  Management doesn’t get to cut the plan. They get to ask “what if we don’t do this, would it be possible to get this instead?” There’s no “we said it will take X” and management saying “do it in X/3”. That’s no longer a plan made by developers that developers are comfortable standing behind. Over 10 weeks, you would plan based on 2/3 of time for 8 weeks, with nothing planned in the final 2. If things are running behind, this becomes buffer to finish it out. If things are finished on schedule by the 8 week mark then the final 2 weeks becomes time for developers to pursue other things. Training, prototyping things they’ve wanted to build, whatever. It’s the old Google 20% time concept built into each increment.
bdavisx 7y ago
The problem with safe is the problem with every other "agile" methodology wrt the article - too many people expect a commitment to all items in the 8-12 week plan, so quality starts to get sacrificed somewhere around the 7-8 or earlier of the 12 week plan.
- brightball 7y ago
  All that is communicated up front. If a deliverable is projected near the very end of the plan, it’s at risk and may not actually be delivered. But it works wonders for keeping out midstream new work from side tracking your team so that you can actually deliver on that commitment.

andi999 7y ago

You should multiply the plan of the developers by 3-4 before presenting to management. So management can cut to factor of 2-3 and you will barely reach it. I never met a developer who doesnt underestimate the effort needed by a vast amount. (including myself)

brightball 7y ago
Management doesn’t get to cut the plan. They get to ask “what if we don’t do this, would it be possible to get this instead?” There’s no “we said it will take X” and management saying “do it in X/3”. That’s no longer a plan made by developers that developers are comfortable standing behind. Over 10 weeks, you would plan based on 2/3 of time for 8 weeks, with nothing planned in the final 2. If things are running behind, this becomes buffer to finish it out. If things are finished on schedule by the 8 week mark then the final 2 weeks becomes time for developers to pursue other things. Training, prototyping things they’ve wanted to build, whatever. It’s the old Google 20% time concept built into each increment.

bdavisx 7y ago

The problem with safe is the problem with every other "agile" methodology wrt the article - too many people expect a commitment to all items in the 8-12 week plan, so quality starts to get sacrificed somewhere around the 7-8 or earlier of the 12 week plan.

brightball 7y ago
All that is communicated up front. If a deliverable is projected near the very end of the plan, it’s at risk and may not actually be delivered. But it works wonders for keeping out midstream new work from side tracking your team so that you can actually deliver on that commitment.