3 ms·

> The odds of that being right are very slim This really depends on the industry and the domain experience of the team. The deeper the domain experience, the

> The odds of that being right are very slim This really depends on the industry and the domain experience of the team. The deeper the domain experience, the more likely you are to get it right. It also helps to limit the scope of what you do (big part of the Shape Up process). Works well for life sciences, for example, where we're replacing a paper process with a digital process. Not so well for SV startups where first time founders are trying to figure out product-market-fit. > ...saves a lot of time at project start Often just shifting the work to a later cycle to get it right. In life sciences when supporting a GxP process, validation (which is rooted in documentation and specifications) is unavoidable. In that environment, figuring out how to move fast despite the constraints yielded a Basecamp Shape Up like process. I think every team that believes big-A Agile is The One True Way take a look at Shape Up.

Zigurd 3y ago
,> This really depends on the industry... That's correct. One of the commonest ways for agile to fail is to apply it to the wrong kind of project. If you have strong dependencies between tasks and things like lead times for hardware you will want to do project planning that can take those things into account early in the project.
jacobr1 3y ago
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
> we're replacing a paper process with a digital process It's worth noting that what you seem to be talking about it "replacing a process done on paper with the _same_ process done digitally". If you were actually changing the process, per se, (to one that achieves the same "goal", but is more suited to a digital approach) there would be a lot of unknowns; and a more agile approach would help. That's not to say one is wrong and the other is right; just that they are two different scopes of work. And, for some situations (government paperwork / regulations), changing the actual process may not be viable.
- CharlieDigital 3y ago
  Precisely; I think the maturity of the team also matters. Agile-ish is going to work better in SV where you have younger founding teams and working at the edges of technology and ideas. Waterfall-ish processes work much better with more mature and experienced teams that have deeper domain knowledge.
Zigurd 3y ago
I have not run a project using Shape Up, but my knowledge of what it consists of leads me to think it doesn't directly address some problems agile projects encounter. Specifically, Continuous Delivery can have problems because it does not directly replace waterfall QA test plans. It works for a lot of projects because unit tests, improved linting, and leak-finding tools cover a lot of what used to go into a waterfall test plan, but capacity, security, and other sources of bugs are not helped as much by CD. It looks as if it can improve intermediate deliveries of a project, but there are still things agile abandoned without having a replacement.
- CharlieDigital 3y ago
  Shape Up isn't about continuous delivery; it's the opposite. First, we work in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The majority of our new features are built and released in one six-week cycle. Our decisions are based on moving the product forward in the next six weeks, not micromanaging time. We don’t count hours or question how individual days are spent. We don’t have daily meetings. We don’t rethink our roadmap every two weeks. Our focus is at a higher level. We say to ourselves: “If this project ships after six weeks, we’ll be really happy. We’ll feel our time was well spent.” Then we commit the six weeks and leave the team alone to get it done. It's 100% worth the read if you are deeply interested in addressing the problems with Agile today.

Zigurd 3y ago

,> This really depends on the industry... That's correct. One of the commonest ways for agile to fail is to apply it to the wrong kind of project. If you have strong dependencies between tasks and things like lead times for hardware you will want to do project planning that can take those things into account early in the project.

jacobr1 3y ago

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

> we're replacing a paper process with a digital process It's worth noting that what you seem to be talking about it "replacing a process done on paper with the _same_ process done digitally". If you were actually changing the process, per se, (to one that achieves the same "goal", but is more suited to a digital approach) there would be a lot of unknowns; and a more agile approach would help. That's not to say one is wrong and the other is right; just that they are two different scopes of work. And, for some situations (government paperwork / regulations), changing the actual process may not be viable.

CharlieDigital 3y ago
Precisely; I think the maturity of the team also matters. Agile-ish is going to work better in SV where you have younger founding teams and working at the edges of technology and ideas. Waterfall-ish processes work much better with more mature and experienced teams that have deeper domain knowledge.

Zigurd 3y ago

I have not run a project using Shape Up, but my knowledge of what it consists of leads me to think it doesn't directly address some problems agile projects encounter. Specifically, Continuous Delivery can have problems because it does not directly replace waterfall QA test plans. It works for a lot of projects because unit tests, improved linting, and leak-finding tools cover a lot of what used to go into a waterfall test plan, but capacity, security, and other sources of bugs are not helped as much by CD. It looks as if it can improve intermediate deliveries of a project, but there are still things agile abandoned without having a replacement.

CharlieDigital 3y ago
Shape Up isn't about continuous delivery; it's the opposite. First, we work in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The majority of our new features are built and released in one six-week cycle. Our decisions are based on moving the product forward in the next six weeks, not micromanaging time. We don’t count hours or question how individual days are spent. We don’t have daily meetings. We don’t rethink our roadmap every two weeks. Our focus is at a higher level. We say to ourselves: “If this project ships after six weeks, we’ll be really happy. We’ll feel our time was well spent.” Then we commit the six weeks and leave the team alone to get it done. It's 100% worth the read if you are deeply interested in addressing the problems with Agile today.