A few weeks ago I showed this slide during a talk I gave to clients of RJMetrics.
The Goal is legendary in my family as a guide for unlocking throughput in manufacturing. Garvey Corp’s entire business model is helping companies exploit constraints and increase profits. It got me off to a great start in manufacturing, but the reality of workflow always seemed a little more complicated than Goldratt’s stories lead you to believe.
Later I devoured Jeffery Liker’s The Toyota Way, which describes the infamous Toyota Production System. It seemed to me that if you carried Goldratt’s constraint theory logically throughout your production system, you’d probably end up with TPS or something like it. As good as it is, the Toyota Way’s strategies always seemed better suited for a different type of manufacturing. One where you were producing roughly the same thing, slightly customized. My manufacturing reality had tremendous customization and variability.
The Principles of Product Development Flow by Don Reinertsen was what I was looking for. Here are ten things I’m incorporating into my workflow. (Manufacturing bits now instead of machines, of course)
1. Smaller projects – We’ve been shrinking our projects at RJMetrics for a while now, but initially I resisted it. “Some projects just take a long time, but are still worthwhile,” I thought. In 2015, however, the equations making projects worthwhile change fast. It’s better to hit a 2 week checkpoint and say “let’s keep going” than go for 6 months and say, “maybe we shouldn’t have done this.” I’ve even been making a conscious effort to make my pull requests smaller (under 50 lines) and more frequent.
2. No more backlogs – Keep TODO issues in a short list, but kill off the long collection of items that linger forever. This is super hard for a GTD’er like me, where you’re supposed to get everything out of your head and into a system. That system breaks when you get multiple people adding items to a backlog that will never get touched. The real backlog is in your brain. If it’s important enough, it will stay there bugging you to be completed and eventually you’ll add it to your short todo list. The key reason why backlogs are bad is this: Your team is smarter today than it was in in the past. Your issue backlog was created by an inferior version of your team.
3. Late assignment of issues – No one gets assigned anything until they can work on it. Have you ever been stuck in a grocery line behind someone who is super slow? You’ve already committed to that line! You’re stuck there because the physical constraints of a grocery store force assignment of a few customers to a register. When matching devs with issues, wait until the last possible second to make the assignment so that it doesn’t get stuck behind another slower than expected issue.
4. Fast feedback is critical – In 2015, everyone says we need to ship an MVP and iterate, but we still don’t always do it. There are many excuses: “The design isn’t ready”, “It’s not valuable without feature X,” etc. Not only is fast feedback worth overriding these concerns, it’s the best plan for fixing them.
5. Start teams smaller, then bring in reserves – “Make early and meaningful contact with the problem.” Planning is good, but plans get shattered once work starts. Things always turn out to be harder than we thought and the best way to find out where we are is to have someone start working on the project. A single developer will have a better picture in one week than a plan ever will. This is one reason why hackathons pay off so well for RJMetrics. Bring in other team members in week 2 and their start will be better focused. Plans should set goals, but be light on implementation details until work beginds
6. Use Little’s Formula – to provide more accurate response times for issues.
7. Make queues visible – Luckily we have a great BI tool to use for this called RJMetrics. Reinertsen recommends Post It Notes to track queues, but the book was written BT (Before Trello).
8. Queue = Todo + In Progress – Don’t just count items that are waiting. The item you’re currently working on is still in queue. The team’s issue queue should be judged on the sum of Todo and In Progress, not just one.
9. Have a framework for when to escalate team communication – Principles says to use regular meetings over irregular meetings, in person vs email, etc. I’m hesitant to escalate the communication due to the transacational costs associated with context switching, but when do you decide to stop emailing and start chatting? When do you stop chatting and start speaking? I’m going to start using the following framework for communication and adjust it:
– Email goes to chat after 3 emails
– Chat goes to in person after 10 messages
There’s no 10th item. Don’t feel like you have to fill every meeting/PR/project with content to fit the allotted time.
