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.
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.
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.)
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.
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.
If your pivot frequency < 2 weeks, sprint length is not the problem.
