3 ms·

>> or Scaled Agile for larger teams IMO I STRONGLY disagree with this, conceptually, logically and in practice. Scaled agile approaches make you plan your spri

>> or Scaled Agile for larger teams IMO I STRONGLY disagree with this, conceptually, logically and in practice. Scaled agile approaches make you plan your sprints way further in advance and account for emerging (or sustainment) work with the use of reserving a percentage of capacity. This works about as well as riding out a run of bad luck at the casino while you wait for the odds to balance out. Scaling "up" the existing practices to a department or company level will not help an interrupt-driven team. Scaled agile doesn't work for pure development teams; i'ts even less likely to work for an SRE team.

brightball 4y ago
Again, this will depend on the size of the team. Planning on a longer time window while giving dev teams a time to coordinate, get everybody on the same page about what you're doing and why...works. It works extremely well. It gets the plan in front of everybody so you can discuss the tradeoffs and risks too. There's an entire open session as part of it called R.O.A.M. where risks to the ability to deliver the plan are discussed, not just with the tech people but with the business folks too. That portion of PI planning is where you call out things that could break the plan. Emerging (or sustainment) work is one of those risks and you have to call it out, then once it's called out you have to discuss what the organization is going to do to prevent it. Capacity isn't going to just spring forth out of nowhere, so what are we pushing off if there's more of it than expected? Do we need to prioritize preventative work to make sure we don't have problems? Do we need some type of infrastructure, monitoring system or automation in our devops process? Everywhere I've been, the PI Planning process has led to less "we have to do this now" and more "we need to see if this can be included in the next PI", which creates significantly less disruptions to the development team focus. The only remaining interruptions should be production issues (preventable) or significant market shifts (rare). It doesn't work when people try to adhere to that plan so rigidly that it becomes a waterfall system.
bradwood 4y ago
LeSS beats Scaled Agile hands down IMHO
- brightball 4y ago
  Reading about LeSS, it looks like it's basically the same thing? As long as you're doing PI Planning you're a step above virtually every other org out there. It looks like it could be a good fit for some groups I know who aren't quite big enough for SAFe though, while still drilling in the same core ideas. IMO the biggest issue with Scaled Agile always comes down to leadership IMO. It's not supposed to be rigid. It's supposed to be adapted to your organization and put the plans in the hands of the developers. The horror stories about SAFe that I've seen on here usually end up with me asking a few followup questions and those questions make it clear that something was terribly wrong. One guy on here told me they did PI Planning for 2 full weeks, which is abject insanity.

brightball 4y ago

Again, this will depend on the size of the team. Planning on a longer time window while giving dev teams a time to coordinate, get everybody on the same page about what you're doing and why...works. It works extremely well. It gets the plan in front of everybody so you can discuss the tradeoffs and risks too. There's an entire open session as part of it called R.O.A.M. where risks to the ability to deliver the plan are discussed, not just with the tech people but with the business folks too. That portion of PI planning is where you call out things that could break the plan. Emerging (or sustainment) work is one of those risks and you have to call it out, then once it's called out you have to discuss what the organization is going to do to prevent it. Capacity isn't going to just spring forth out of nowhere, so what are we pushing off if there's more of it than expected? Do we need to prioritize preventative work to make sure we don't have problems? Do we need some type of infrastructure, monitoring system or automation in our devops process? Everywhere I've been, the PI Planning process has led to less "we have to do this now" and more "we need to see if this can be included in the next PI", which creates significantly less disruptions to the development team focus. The only remaining interruptions should be production issues (preventable) or significant market shifts (rare). It doesn't work when people try to adhere to that plan so rigidly that it becomes a waterfall system.

bradwood 4y ago

LeSS beats Scaled Agile hands down IMHO

brightball 4y ago
Reading about LeSS, it looks like it's basically the same thing? As long as you're doing PI Planning you're a step above virtually every other org out there. It looks like it could be a good fit for some groups I know who aren't quite big enough for SAFe though, while still drilling in the same core ideas. IMO the biggest issue with Scaled Agile always comes down to leadership IMO. It's not supposed to be rigid. It's supposed to be adapted to your organization and put the plans in the hands of the developers. The horror stories about SAFe that I've seen on here usually end up with me asking a few followup questions and those questions make it clear that something was terribly wrong. One guy on here told me they did PI Planning for 2 full weeks, which is abject insanity.