5 ms·

One of the bigger issues with Scrum style agile, is that very rarely does it reach the maturity where "everything is delivered within a sprint." Even if you com

One of the bigger issues with Scrum style agile, is that very rarely does it reach the maturity where "everything is delivered within a sprint." Even if you complete all the cards without carryover or other issues, the product isn't necessarily shippable. So in practice you some form of release planning, often quarterly to align with the business, that gets overlaid. The big insight with ShapeUp for me, was that is really is more a change in how to approach Release planning, than sprint/iteration process. You really can ship an end-to-end feature for a wide variety of software products in a 6 week timeframe, and it is short enough to give a lean focus, outcome oriented on delivery rather than just shipping a code increment. Two weeks is too tight a timeframe to meaningfully pivot larger projects, or make decision about overall feasibility. There always is another 2-weeks to expand upon your sunk costs. But again 6 weeks hits more of a sweet spot in being able to step back and make roadmap tradeoffs.

Zigurd 3y ago
There are a long list of problems with Scrum. The jargon gives me hives, for starters.
datadrivenangel 3y ago
If your product iteration does not result in a potentially stoppable software, it's not True Scrum :TM: and you've failed.
- Jenk 3y ago
  Not true. Delivery doesn't necessarily mean Release. Before the "Continuous Delivery" mantra took flight, Scrum et al came with Delivery Plans and, crucially as a separate artefact, a Release plan. This was specifically to address the nuanced distinction between a bunch of stuff being "done" and "releasable." Now it seems everyone is unable to distinguish between Continuous Delivery and agility.
  - WorldMaker 3y ago
    Even under Continuous Delivery there's still a distinction between "delivered" and "released". It might be delivered behind a feature flag. It might be delivered to a staging/release-planning environment of some sort. (CD doesn't always mean "completes all the way to Production each sprint". The original idea of CD was just focused on development and QA environments to catch what CI doesn't about the usability state of the application as different developer efforts merge together for the first time.)
- jacobr1 3y ago
  > you've failed Yes, and this is very common > potentially stoppable So this is a key difference. ShapeUp is much more focused on Actually Shipping vs `potentially`
CharlieDigital 3y ago
Bonus: product planning time creates space for engineering teams to periodically catch up on tech.
- RHSeeger 3y ago
  How do you plan a project without the engineering teams being involved? As far as I'm concerned, both the developers and QA need to be involved from the beginning; otherwise you get people planning things that aren't realistic (or are a really BAD solution to a problem).
  - CharlieDigital 3y ago
    The planning period involved all key stakeholders and buy-in. This includes QA, engineering, and the customer. In a GxP validated release, everything starts from the documentation and ends with a sign off by the QA team before it's delivered to the customer who does their own validation process. So it was absolutely critical to get agreement between the teams. I was Director of Engineering and represented the engineering team. Over a 1-2 week period, the stakeholders would meet to discuss the objectives and we'd draw up a rough outline ("Business Requirements"). Then each lead would take that rough outline back to their teams to determine feasibility (for the customer team, it was to rank priority so if we came back to make cuts, we knew what to cut). For engineering, we'd review each feature and breakdown to determine if we could do it all given our resource load and time frame ("Technical Design Specification"). We'd provide a rough idea of how we would implement it and consult with the QA team on how they would test it ("Functional Requirements Specification" and "Validation Plan") and if there was some angle we missed. But because a lot of this ended up being negotiations and documentation ("Here's what you want, here's how it'll look, here's how we'll build it, here's how we'll test it, these are the compromises we have to make for now, this sub-feature will be released next cycle"), I ended up doing most of that "dirty work" and only consulted the team when needed and to get their buy in. This left my team with plenty of time to play with that new framework or build a sandbox for some new tooling or build process and so on. Even if you are a skeptic, I strongly recommend reading the Shape Up guide. It's very practical and prescriptive.

Zigurd 3y ago

There are a long list of problems with Scrum. The jargon gives me hives, for starters.

datadrivenangel 3y ago

If your product iteration does not result in a potentially stoppable software, it's not True Scrum :TM: and you've failed.

Jenk 3y ago
Not true. Delivery doesn't necessarily mean Release. Before the "Continuous Delivery" mantra took flight, Scrum et al came with Delivery Plans and, crucially as a separate artefact, a Release plan. This was specifically to address the nuanced distinction between a bunch of stuff being "done" and "releasable." Now it seems everyone is unable to distinguish between Continuous Delivery and agility.
- WorldMaker 3y ago
  Even under Continuous Delivery there's still a distinction between "delivered" and "released". It might be delivered behind a feature flag. It might be delivered to a staging/release-planning environment of some sort. (CD doesn't always mean "completes all the way to Production each sprint". The original idea of CD was just focused on development and QA environments to catch what CI doesn't about the usability state of the application as different developer efforts merge together for the first time.)
jacobr1 3y ago
> you've failed Yes, and this is very common > potentially stoppable So this is a key difference. ShapeUp is much more focused on Actually Shipping vs `potentially`

CharlieDigital 3y ago

Bonus: product planning time creates space for engineering teams to periodically catch up on tech.

RHSeeger 3y ago
How do you plan a project without the engineering teams being involved? As far as I'm concerned, both the developers and QA need to be involved from the beginning; otherwise you get people planning things that aren't realistic (or are a really BAD solution to a problem).
- CharlieDigital 3y ago
  The planning period involved all key stakeholders and buy-in. This includes QA, engineering, and the customer. In a GxP validated release, everything starts from the documentation and ends with a sign off by the QA team before it's delivered to the customer who does their own validation process. So it was absolutely critical to get agreement between the teams. I was Director of Engineering and represented the engineering team. Over a 1-2 week period, the stakeholders would meet to discuss the objectives and we'd draw up a rough outline ("Business Requirements"). Then each lead would take that rough outline back to their teams to determine feasibility (for the customer team, it was to rank priority so if we came back to make cuts, we knew what to cut). For engineering, we'd review each feature and breakdown to determine if we could do it all given our resource load and time frame ("Technical Design Specification"). We'd provide a rough idea of how we would implement it and consult with the QA team on how they would test it ("Functional Requirements Specification" and "Validation Plan") and if there was some angle we missed. But because a lot of this ended up being negotiations and documentation ("Here's what you want, here's how it'll look, here's how we'll build it, here's how we'll test it, these are the compromises we have to make for now, this sub-feature will be released next cycle"), I ended up doing most of that "dirty work" and only consulted the team when needed and to get their buy in. This left my team with plenty of time to play with that new framework or build a sandbox for some new tooling or build process and so on. Even if you are a skeptic, I strongly recommend reading the Shape Up guide. It's very practical and prescriptive.