Hacker News Reader

,> 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.

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.

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

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

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.

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.)

> 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`

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

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).

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.

> 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.

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.

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.

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.