In my last post, I talked about comparative advantage and how it can aid you in developing your team and your members’ skills. Now, I’ll talk about another aspect that you need to consider in a lesson from Lean.

I have never described myself as a person who espouses any one single methodology for solving problems, so you won’t ever see me write about the one right way of doing things. Many processes and frameworks were originally designed for one thing, and I have had uneven results applying them to software development. One thing that I have found to be very helpful in developing a team is a specific subset of the Lean concept of muda, which I came to understand when reading the book The Goal.

If you haven’t read this book, it’s highly regarded and a bestseller for making certain business concepts very accessible to the reader. I highly recommend it.

The book has two great takeaways – first is the answer to the question: What is the goal of a company? The answer: To Make Money. It’s a very handy thing to keep in mind.

The second takeaway is the Theory of Constraints. This is the idea that production bottlenecks can take an assembly line and slow it to the speed of its slowest machine.

Lean

When I learned about Lean, I found many helpful concepts that I could apply directly to software development: muri and mura are types of waste based on unnecessary work and unevenness in work, respectively. Who hasn’t had unnecessary demands put on them or had their workflow be uneven? These made immediate sense to me.

When I read about muda, however, I didn’t really see how these forms or waste would apply to writing software. Transport waste wasn’t really a big deal for software.

I asked my father about it, and he told me that when he was in the aerospace industry, Lean approaches had identified cases where re-orienting machinery would save a number of forklift trips between the output of one process and the input of another. This seemed like a good example of this sort of waste, but still not one where I could find parallels in software.

The Goal

When I read The Goal, it finally became clear to me. The Theory of Constraints says that if you have two machines, A and B, one which feed the other, you are constrained by the slower of the two.

This seems obvious, but there is a hidden bit of nuance here: Machine A is the faster of the two, it will build up an inventory waiting to be processed. The system is constrained by the speed of Machine B.

This inventory is literally money that can’t be made. It’s wasted in the value of material stuck between manufacturing processes that cannot be sold until finished. In order to finish it, in this case, you need to either double the efficiency of Machine B, or work machine B twice as hard.

If you reverse the order of the machines, which I will not grace with a scrawled hand-drawing, results in the faster machine being used at half capacity.

And Back to a Small Team

So I’ve digressed a bit from my small team from before, but I imagine you can see why. Paramount to the efficiency of a small team is understanding comparative advantage and process waste and applying these lessons to your staffing and planning. The reason that the choice between choosing specialists and generalists is important is that if you have one specialist that the rest of the team can’t keep pace with, it’s very hard to be efficient.

In a case where a specialist needs to be followed by a member of the team that isn’t as productive as they are, then you have one of two problems: If the specialist’s work need finishing, their work lies idle until someone gets to it, demoralizing your specialist. Otherwise,  you work your non-specialists harder to deliver the finished product, and it seems that you favor your specialists by not having them pull all-nighters.

You can’t just rely on comparative advantage to do your resource management, since you may actually need to slow down your faster resources to be constantly deliver software and not have unfinished product lying around. You need to be constantly matching resources so that you can deliver high-quality software at a predictable rate.

The Real Challenge

As I mentioned in my last post, this is a systems optimization problem. Somewhere in the solution space lies a best solution to optimizing each team’s delivery. The real problem here is that every software engineering task is a bit different, as is every team, so you need several tools in your toolbox to address these. It’s never a one-size-fits-all process.

So when you are building your team out, the RPG problem doesn’t go away. It does, however, evolve as you build your team. As you learn your team members’ skills and strengths, you can more easily apply comparative advantage and constraint theory to find the way to not only maximize your team’s productivity, but to do so over a long time.

Next: Back to our team for some concrete examples.