Methodology? What Methodology?

I think I'm getting kind of post-methodology in my thinking. I don't really care what it is or what it's called, but I do care that it facilitates three critical things: one piece flow, prioritisation and explicit batch size.

The Informative Bit

One piece flow (taking a work item and not diverting from it until it is in production) is essential for getting things done. Deferring the "done-but"s to work on something else only ends in discovering you've got more "but" than "done"; partial progress is one of the most volatile and fast-eroding substances we have yet discovered. Seriously, you can walk away from something when it's 90% done and when you come back all you've got is a merge conflict, 56 failing tests and a new concurrency bug. If you take the need for one piece flow as axiomatic, then it follows that large items kill reactivity, logjamming the team for ages. Sometimes unavoidable, but more frequently not: hand-offs, process overhead and out-of-band review/sign-off are all excellent ways to artificially increase item size.

Casting the scope of one piece flow wider increases its effectiveness. 20 years ago we thought it was just "develop the code", and wondered why downstream phases such as testing and customer review caused so much rework. 10 years ago we thought it was "get it to staging" and wondered why production deployment broke everything. We've kinda solved that side of things but there's a lot of work to do extending the other direction toward ideation, making things like UX and hypothesis formation part of our one piece flow rather than expecting to pull ready-formed designs and test outcomes off the wall. I love working on this side of the problem because we don't really know the answers yet, which makes it all the more rewarding when as a bunch of people you get together and figure something out which works for you.

Prioritisation is how the right things get done, and the only important facet is the ordering of items. Marking everything urgent doesn't get things done any faster than marking them all, "nice if you get a spare moment", considered over a long enough timescale for burnout and attrition to be a factor. Priorities are not a strict order either, as you may have dependencies and prerequisites which result in things being delivered slightly differently. Be aware that such dependencies are often self-inflicted due to team structure or process. With that in mind, attempting to strictly enforce priority order by banning lower priority items from being completed is liable to break one piece flow, resulting in 50% of task B being done to deliver task A, then eroding and needing to be redone for the actual delivery of task B.

Batching is a function of how frequently you need/care to prioritise - essentially "how long can I make up my mind for before something needs to change?" Batches again need to follow one piece flow in order to be effective. A "done-but" batch is just as useless and prone to progress erosion as a "done-but" item. This makes smaller batches tempting, but the trade-off is the volatility and notice period of demand for prioritisation activity. If your batch size is 1 item, then up-to-date priorities will be needed the instant it's finished, or a potentially unimportant thing may be ingested into the one piece flow and tie up the team until it's done. (Or thrown out part way through, wasting effort). Batches sufficiently large to occupy a team for 1,2,3,etc. weeks give you a predictable rhythm at the cost of reactivity - if something goes on fire Tuesday you can't extinguish it until the following Monday.

Modifications to these need to explicitly call out the trade-offs. To take a popular one, you might want to allow interruptions in a batch to deal with unexpected fires. This requires either slack time in the batch, or discardable items. (Prioritisation rearing its head here). If your fire response needs to be instant rather than merely within the batch timeframe, then you also allow for partially-complete items eroding, and needing to be thrown away and restarted.

The Sarcastic Bit

I've deliberately gone this far without naming a single methodology. That's because I think a lot of them either half-ass these things by design, or by the way they're implemented. I'm not actually that bothered by Waterfall's treatment of the entire project as a single batch, I'm more worried about it chopping up one piece flow into huge amounts of inventory waste, such that you're lucky if your specification hasn't fully eroded by the time you're halfway through development. But even so most of its problems in the real world come from people not respecting that single, formidable batch and constantly injecting new priorities. It actually works OK if you set the priorities once and leave them alone. Not great, but a lot better than people give it credit for.

Scrum is basically dying on its arse at this point because nobody is willing to have the discipline on prioritisation, batching or one piece flow despite it not only telling you to do all of these but giving you the tools to accomplish them. I'm not even getting into the bastardised edifice where people have bolted random bits of XP and CD practices on the top of it, the basic vanilla version from the '90s tells you to do all of the above and yet the reality is still teams working to ill-defined priorities, salami-slicing themselves between a dozen different work items, regularly being interrupted mid-batch and treating atomicity failures in batch completion by applauding themselves with a, "wow, 60% of the cards completed this sprint!" I'm also uneasy with the tendency for sprint review and feedback sessions to be used as an excuse to deliver something sloppy in the hope the stakeholders pick it up. What part of "done" in a one piece flow context has your demo presentation interrupted by bugs you're only spotting for the first time?

Don't get me started on SAFe, which seems purpose-engineered to put "done" as far from the team's control as possible. I think I get a cross-alignment penalty from going anywhere near it because I'm not lawful evil.

Kanban theoretically ought to be pretty cool, but find me someone working under it who can both explain what a lane limit is and show you a board where they're observed and I'll order you a unicorn in a colour of your choice. Even if we pretend one piece flow is remotely observed the insane prioritisation demands result in one of two things: either a team who do things essentially at a good-natured version of random, or a gimlet-eyed product manager who quits within 5 years to become a groundskeeper and never speak the word "priority" ever again. (Or indeed speak anything other than mumbled horticulturalese)

XP is fantastic and I think it's one of the genuine failures of the software industry that it didn't see wider adoption given it was being taught as The Glorious Future back in 2002. But it's scary and prescriptive, and tended to be the preserve of greybeards and those oddly cool university lecturers who rode a motorbike they'd welded themselves rather than people who knew how to package it up and sell it as a silver bullet, so here we are still with only one person at a time sitting at the computer. Shame.

I could go on, but point is that if across our whole industry we actually started talking about one piece flow, prioritisation and batching rather than trying to package everything up into shiny folders, we might be in a place where we can have a rewarding time at work, deliver some things on time, and not leave our customers feeling like they're eternal beta testers. But failing that, I'm at least going to make sure that's what my tiny little corner concentrates on.