Product Development Processes You Might Not Have Heard of (2022)
departmentofproduct.com
departmentofproduct.com
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.
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.
The book is called "Shape Up" (doh) and the electronic version is totally free:
I would also really recommend the rest of the books, lots of great thoughts on development and management from actual experience. Also free:
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.
You can get feedback without sprints. But they make it easier, and encourage getting something in front of a user fast.
At best it led to a stakeholder demo where some business people would look at a form or something, ask some minor questions, then a new cycle would begin (with its context switching, planning stress and perverse JIRA games - all the negatives of Scrum).
I don't think many companies use such regular user feedback in their development process.
Perhaps it's that they don't need to? I actually think a lot of company dysfunction happens when the "official" system purports one set of goals (user feedback, regular pivots) but the "real" system purports others (executive driven initiatives, long sales cycles)
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?
There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.
The best ones I have worked with are competent, they dont make me do their work, they keep their promises, they dont waste my time, they see organizational issues and take point on them, and they generally were unflappable in targeting organizational discomfort about tackling an issue or talking to so and so.
This is really hard for someone jr to the space, but humility in the face of everyone's priorities is a great start.
Yeah but my problem is that they are the ones with grand visions that may or may not ever come to fruition, and I am the one left with half-baked features that the business clearly needs to fix right now but are seen as unfashionable to work on.
Recently I was at a point where I've suggested to onboard a junior resource to mop the metaphorical floor. I'm starting to think that, next time, I should ask to have different degrees of seniority in the team to make it more balanced.
This generally works because I target the smaller companies and so actually making money is at issue, in a large enough org you can go half a decade before anything shakes up dumb stuff.
And 5), which is why we called this pattern a "do-it-cracy" in our Hackerspace - someone might do something and get 90% done before other people notice, and when they do, it turns out >50% of them absolutely do not want it, and would've objected given the chance.
(Then again, we've found that "do-it-cracy" can arise as a rebellion against excessive bike-shedding, which is something groups of people love to do.)
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.
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).
Well put. There's just too much going on in some organisations for leadership to make meaningful decisions. Your comment reminds me of the Viable Systems model, which was a welcome gem hidden away in (the other) Michael Jackson's systems thinking slab of a textbook.
My go to means of ensuring that executive (including me) can keep their finger on the pulse is to encourage people to be open in large and informal chat platforms like Teams and Discord.
If your pivot frequency < 2 weeks, sprint length is not the problem.