Product Development Processes You Might Not Have Heard of (2022)

[adamtaylor_13]

My team (3 devs) has been using Shape Up since January and it’s been amazing. I don’t think I can ever go back to scrum.

It allows devs to be creative, do what needs to be done, and ship a real feature. All without any product managers, and zero meetings.

Corporate companies could never imagine not counting all their beans, but man it is so freeing if you have the option.

[seamossfet]

Same! I run the engineering department for a medium sized software consultancy, we're on contract with several large enterprises. In terms of output, we run circles around their internal delivery teams. Not because our engineers are better than them, we've just fully embraced shape up as our development process.

This has also let us bid on projects as fixed rate instead of T&M since we budget time as appetite instead of how long we think something will take to build.

There are still some hurdles we have to overcome, like we can still run into unexpected things that we didn't know about during the betting process, but deep behind the philosophy of Shape Up it feels like something that translates extremely well to more creative R&D development projects like what we do.

[mindcrash]

In case you are interested in Shape Up and want read more about it, Ryan Singer - the inventor of the methodology - has written a really great book about how they have been, and currently are, building and shipping products and features at 37signals.

The book is called "Shape Up" (doh) and the electronic version is totally free:

https://basecamp.com/shapeup

I would also really recommend the rest of the books, lots of great thoughts on development and management from actual experience. Also free:

https://37signals.com/books

[gcanyon]

In addition to the roughly standard 2-week scrum teams I work with, I am also working on launching a from-scratch project with two developers, and our process is roughly:

1. I keep a backlog of new features that are needed. 2. The backlog items vary in completeness/specificity from "mostly there" to "a sentence or two description". Some of the items are large and need to be subdivided. 3. At any given time, the devs each have 2-3 items they are actively working on. 4. The items range from a day or two up to a week or two for the really big ticket items (e.g. "get performance in boundary cases from 'won't load at all' to 'loads in < 10 seconds'") 5. When a dev puts something in for code review, if they're down to too few items, they check in with me to figure out what to add to their active list. We go over the outstanding list to figure out value vs. effort and make some choices.

Item 5 generally happens weekly, sometimes even every few days. They work fast.

[recursivecaveat]

That is the only way I have worked across 3 employers. I hope I never have to work in arbitrary time-boxed 'sprint' units or something. I never understood the appeal outside of pretty specific circumstances.

[Animats]

Symantec, which once sold programming tools, tried a unique approach - scheduled maintenance. The product team worked on one product at a time. When they finished an update, they'd go on to the next product. Products were not updated out of cycle.

[hiAndrewQuinn]

The "betting table" reminds me that I continue to think there's a large, mostly untapped market for good internal betting and prediction market software in large software companies. The primary problem around them seems to be psychological: it's very, very painful to lose a bet that feature X will be shipped by date Y in state Z, and even more painful to see your own track record of failures grow over time, even if you are also accumulating successes.

[jgoldfar0nil]

I like this concept – when isn’t a commitment a bet that we can achieve Z by date Y? To make it concrete is not dissimilar from the other gamified features different work planning tools have been adding in recent years

Your point about seeing the inevitable lost bets add up is well taken, though from what I have seen the healthy responses to loss tend to be close to “either we win or we learn”.

So you want your team to make smarter bets and win bigger over time, and/or learn more from their losses. Can a software product make that process anything but a burden? Is there more there than other types of performance incentive systems?

[greggsy]

I know these have their place in complex projects, but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done.

There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.

[jdlshore]

When you have more than a few people, “talking about things and doing what needs to be done” breaks down. You can end up in analysis paralysis (endless talking), wild west (everybody doing their own thing and not doing things that work together), wild hares (doing things that aren’t important) or even all three.

[asplake]

> but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done.

A few people might do that informally, sure, even as part of something bigger, but there’s no escaping the needs to 1) coordinate over shared resources and 2) organise around shared commitments. And where do those commitments come from? Implies some kind of strategising, and if that’s not a collective thing, then you’re relying on someone doing the telling. And of the options that are strategised, what’s acceptable and what’s outside our purpose, identity, etc?

There are theoretical limits on what formal organisational systems can achieve in terms of information flow (so managers shouldn’t over-depend on them), but nevertheless, the above activities are fundamental. Take any of them away and you no longer have a viable system, one capable of ensuring it’s ability to maintain itself, to act independently, and to increase possibility in a changing and perhaps hostile environment.

Disclosure: I have a book coming out on this stuff shortly, bringing some decades-old, well-tested, and well-regarded theory up to date. FWIW I also wrote one of the leading books on Kanban (2014), not that this changes any of the above, apart from that Kanban is among other things an effective coordination system (though incomplete in the above terms, but then so are all the others).

[intelVISA]

You can only be productive 'talking about something' if you understand the concepts to later 'do what needs to be done'.

In the absence of tech leadership it might as well be magic. I wouldn't understand the working details of doctors or lawyers on a medical, or legal, project but you'd bet I'd be praying to any agile deity listening to drag it over the finish line, trusting that the profit margins would help obscure this uncomfortable reality.

[karhuton]

> Scrum with 2 week sprints may work very well in larger corporates, but startups who need to pivot regularly and change direction may not be as well suited to such a fixed process.

If your pivot frequency < 2 weeks, sprint length is not the problem.

[contingencies]

Our (complex physical product in a combined design office / factory) method: 10 minute chat together in the morning, identify any problems we'd like help with, anyone can ask to change focus at any time. Sometimes a team works on the same problem, usually people take sole responsibility for something on their own but take it from and bring it back to the group to keep everyone vaguely aware of where things are going. We may state what we think we'll get sorted for the day and what we're aiming for the next few days or week. Rarely do we look beyond a few days because it's too vague/unrealiable. At the end of the week we quickie summarize what got done by email (way shorter/higher level than git logs). If there's an over-arching goal or time pressure everyone is informed and we work toward it. No forms or friction for lateness, leave, lunch, ordering stuff, printing, etc. People are judged on commitment, ideas and progress. Factory floor and equipment, design office and electronics lab all on site. No management except keeping a weekly journal for the team's aggregate progress, setting some priorities start of week, and compressing updates to stakeholders. Oh yeah, and mobile devices are locked in a cabinet at the front door during work hours - if you don't like it work somewhere else or take the day off.

[Xiol32]

The phone thing is weird given you treat everyone like adults otherwise.

[AntonCTO]

In good hands, any product development process works well; in bad hands, any product development process fails. It is not about processes, methodologies, or frameworks - it is about people and what people do.

[holowoodman]

I'm a fan of https://programming-motherfucker.com/