Deep Dive: Theory of Constraints: Software Development
I recently read Agile Project Management with Kanban by Eric Brechner. It was recommended to me by a colleague. He’d been thinking about using it with a software development team he’s working with. He’d also had success using it with previous software development teams.
Meanwhile I’d been telling everyone to read The Goal by Eliyahu Goldratt and he was one of the people that picked it up but he’s still early on in the book.
I start having all these conversations about how we might use the concepts in The Goal to improve the flow of software solutions through our little internal organization and it turns out that the Kanban book is steeped in and references Goldratt’s work. Gotta love coincidences. Always fun.
I’d been rereading The Goal as part of a work book club and we’d be doing all these mental gymnastics to try to figure out how to apply The Goal to the teams around us. These conversations were great and better than the 30 minute versions here and there with the teams and leaders themselves but still we didn’t really get as far as we’d have liked.
The Kanban book though has done all this work for us. Flow and Theory of Constraints for Software development. An easy how to apply. What a godsend!
Let me step through some of my takeaways.
First off what is the problem?
In The Goal and The Phoenix Project the authors do great jobs painting a picture of teams or organizations that are really struggling. I once enumerated all the symptoms of a not great situation from these two books and came up with the following.
Expediting, fires
Rushing, overtime
Burnout
Heroics (one of the more toxic)
Customers complaining
Customers voting with their feet/wallets to competitors
General, pervasive unhappiness and malaise
Where the above symptoms live, I think, one can use the quick start guide in the kanban book to treat these social-organizational symptoms. I think of these symptoms as all possibly categorized into one of these buckets:
Efficiency
Predictability
Simplicity
And they are the main problem spaces of production whether it be of a good or a service or software as a service.
How do you treat these symptoms? According to the book…
Samepageiness
I was once at a company offsite and had to write what I wanted to get out of the day on a whiteboard. I wrote “samepageiness”. The word has stuck with me ever since. In that little startup we were all over the place all the time. If you want to move from barely or full on not surviving to thriving you need to get on the same page about what’s getting worked on and who’s working on it and what the friction is for it getting done. What better way to get on the same page than to get on the same wall or web page Kanban board.
Kanban is central to this book and this remedy so you know you’re going to have a board. But why not have it be clear and common to all. This is the principle of making work visible or “samepageiness”.
Limits on chaos
Brechner makes a really interesting point about Scrum and Kanban. They differ in how they manage chaos. Chaos is the norm. It’s your baseline. In a world of complexity, complicated work, statistical fluctuations and dependent events and human emotions and never-written problem statements, chaos is the norm. The question is what are you going to do amongst it all?
To contrast, Brechner points out, Scrum makes the sprint sacred. Nothing makes it onto the to do list. Only off of it for the pre-agreed upon period of time, usually a week or two. In Kanban, you have your steps in your development process and each step has a Work in Progress (WIP) limit calculated in a reasonable way (he shares how he calculates an initial number in the book).
What effect does this have on the normal chaos? It smoothes it out creating a less bumpy and less painful road to travel over. Over time it makes things more predictable. And it makes everyone’s life simpler.
Break it up or make your batch sizes smaller
“Build app for auto reposting theory of constraints content from all over the web” and “draft design doc about surfacing certain kinds of content from all over the web” are two very different software development tasks. I took a stab at taking an example task and breaking it down a bit. Really one could break it down a lot more and probably a lot more intelligently than I did.
In the context of chaos above, the most ideal, least chaotic software development or like in a previous post, manufacturing, is single piece flow. One item flows through the software development or manufacturing process at a time, beginning to end. No blockages, no bottlenecks, no overcomplication, no expediting. One thing at a time.
No one anywhere will ever reach this ideal. However, one can asymptotically approach it. One begins the journey toward approaching it by cutting down batch sizes by breaking up large tasks into smaller, more predictable, doable tasks. This makes for a smoother ride. Think of it this way. Would you rather pour solids through the neck of a wine bottle or liquids?
Define done
Kanban regulates quality through a deceptively simple mechanism. Before a note card is moved from the left to the right column of a step, the work on that item must pass certain rules—your definition of “done” for that step (also known as the pull criteria).
Obviously, it is never only about quantity or velocity. It’s also about quality. Ensure quality at every step in your process and you don’t have to learn you made a mistake when the product is in the customers hands or even when it’s ready to be shipped sitting in a pile of to dos for quality assurance (QA). Deceptively simple is right. And fits with the takeaway above. Smaller is better. The smaller the unit the better the flow.
Higher level takeaways
But the biggest takeaway for me is this: We go about our days having adopted a “process” no matter what. What if minor changes to our process could resolve the slowness, burnout, frustration, confusion and sometimes proper failure? A general lack of curiosity into what might be causing these problems and what might resolve them both surprises me and saddens me. We could be creating so much more together with the same amount of effort. We could be driving on autobahns while we choose to drive on potholed dirt roads. Don’t get me wrong, I love myself a slow dirt road Sunday drive. I love the random cobble stone streets around NYC. But I’d never choose to travel on either kind of road at speed. And sometimes I do wish to go faster.
And maybe that’s the biggest takeaway of all. We can consciously choose the rate at which we create value rather than feeling a victim assuming we’re accomplishing all we can. Books like this point to the choice we’re not realizing we’re making every day.