Cross-Functional Teams & Production Cells
Prior to lean thinking, Taylorism was the dominant managerial philosophy in industry (and it is still a powerful influence). Labor efficiency is a pillar of this approach. To achieve that goal, a common practice was to group together all sets of similar equipment (lathes, drills, presses, etc.). This allowed the technicians to specialize, allowed for redundancies in case one machine went down, and provided a very easy set of metrics by which each set of machines could be measured for success (output, utilization, machine up-time, etc.). Now our leaders are equipped with metrics that tell us about how well their investment is being managed and we have specialized people working with specialized machines that are being fully utilized. Clearly, this is going to maximize the amount of value we’re creating, right?
The same philosophy underscores many software delivery organizations. People are put into functional groups (BA, QA, architect, developer, etc.). Each of these groups is measured for productivity based on hours worked (something like machine up-time) and output (code, tests run, designs written, etc.). It’s the functional manager’s job to make sure that his group has a full queue of work from which to pull at any time in order to make sure that everyone is fully utilized. If all of these expensive humans are constantly doing their thing, we’re definitely delivering the most value, right?
Let me tell you a story about this approach and unintended consequences.
A few people create a new factory for creating chairs. There is a single loading bay at which trucks regularly deliver foam and fabric that is used by the looms and trained techs on Phil’s team to create the sitting surfaces. From the same loading bay, different trucks regularly drop off metal and matte black plastic used by Mary’s team to create the chair frames and covers. Adam’s team is the final stop. They assemble the chairs and prepare them for sale. All told, this is not a complex process and has been modeled below.
This seemed to work for a few batches, but shortly after the first few clients received their chairs, defects were reported. We had hoped to be our own QA, but Phil, Mary, & Adam were so focused on getting things done that they neglected to really scrutinize their own (or each others work) and quality suffered. They had a long talk with senior management about the quality problems, and decided that it’s best if these leaders keep their focus on execution and we’ll hire Connor to lead our new QA team.
That seemed to work out pretty well, but Adam’s team kept pulling ahead of Mary’s team and the metal frames. As a result, Adam’s team wasn’t well enough utilized and he missed his bonus for the month. Mary managed to get some more machines in place to fix the problem going forward, but then one of Phil’s looms broke down and Adam ran out of material again. After a second month with no bonuses, Adam decided to fix the problem once and for all. He idled his team for a week so that Phil & Mary’s teams could build a buffer. Now he had a full week of seating surfaces and frames that his team could run through. If any of Phil or Mary’s machines went down, Adam would not be impacted for almost a week.
Now we have a slightly more complex process.
Unfortunately, Adam and his team underestimated the difficulty in storing and accessing all of these components. They ended up needing to invest into a somewhat expensive storage solution and a few forklift drivers who could ferry components from the trucks to Phil & Mary. The drivers would then take batches from Phil & Mary and put them into storage. As Adam’s team started to get to the end of they’re materials they’d call the forklifts to have them pull more frames and seats from those storage spaces and bring them over for final assembly.
Our real process now looks a bit more like this.
When we organize functionally, it’s easy to paint a very simple picture about how those systems feed each other. Unfortunately, it’s rarely the complete truth.
Organizing functionally creates point efficiencies in an inefficient system. As pictured above, that system looks more like a warehousing operation than anything else. It is. There’s much more inventory on those forklifts and in those queues than is in any of the actual value-adding steps (remember, we’ve optimized those).
What’s worse, QA is happening at the very end. Because we want to make sure that Adam won’t be stopped by upstream issues, if there is a problem with the seat frames, the flaw may have already permeated through a full week of seat frames. Now we’ll need to decide what to do with a week of defective parts. We will either need to be fix them all (expensive), throw them away (expensive) or we’ll just accept the quality deficiency (expensive).
Lean manufacturing challenged the traditional mindset and introduced the idea of a “production cell”, something now generally referred to as cellular manufacturing. Within a production cell, we would expect to find all of the machines and equipment necessary to produce a collection of similar products that will be passed onto the client. This had several important consequences. However, before we go any further it is worth highlighting that the machines are organized based on how they add value, not what they do.
If our factory implemented production cells, maybe we end up with two. The first cell has all of the machines and team members needed to take foam, fabric, metal and plastic in order to create chairs. The second cell may have the exact same configuration, but operates in parallel. If we want to expand capacity, we simply add another cell.
A side effect of the production cell is that these machines won’t be as highly utilized. The same people operating the loom may also be handling the metal and they’re only going to be doing one thing at a time. The machines utilization will go down. Counterintuitively, this produces something that is more efficient. We’ve essentially accepted point inefficiencies for system-wide efficiencies. Where did all of that inventory go? It’s gone. Our need for forklifts is also nearly eliminated.
Now consider our quality problem. If anyone in our cell produces a defective piece, we have one defective piece. We can fix it, educate the person, and move on. We are all responsible for all of the machines and pieces in our cell, so nothing is out of bounds for our own improvement process.
Our incentives are also likely to shift. Rather than measuring machine utilization or up-time, we’d be much more apt to measure the cell based on it’s purpose; the value we’re generating for the client. In this case, perhaps the number of chairs produced.
And now, back to agile software development.
Have you ever worked in a world where there is a queue of requests stored somewhere on a server? Perhaps it’s in a CRM or ERP system by the name of TFS or JIRA. Maybe it’s just an Excel workbook. Either way, your computer is your forklift and the backend for that system is your warehouse. Odds are good that every day you open that tool to find out what needs to be done (the forklift pulling material from the warehouse). You’ll do your thing and when you’re done you go back to the tool and update the state of the task to indicate that you’re done (the forklift putting the material in the storage queue for the next stage). Our raw material is information and the database is our warehouse.
Now let’s talk about a software delivery firm that has a few functional teams; DBAs, designers, and developers.
On day 1, our DBAs pull from that queue and start working on the schema. After all, no proper development can begin without a schema so we need to make sure that our DBAs are working at least a week ahead of our developers.
Perhaps also on day 1, our designers start mocking up the UI and getting some feedback. We can’t let them wait until everything else is done to get started because they’ll have to go through far more iterations than anyone else once the client begins seeing it. They simply can’t afford to wait.
Our development leader will be monitoring the progress of these teams, and once the schema is done and UI is mocked up, he’ll find a developer who has capacity. That developer will be given the task of picking up those pieces, adding some business logic, and making sure everything works together as expected.
Lastly, our QA team is monitoring that queue and deployment reports to see which tasks have been promoted to beta. Once something new pops up, they begin testing new work and executing routine regression tests.
Sound familiar? If not, does it look familiar?
In agile, there is the notion of a cross-functional teams. An agile team is designed to have all of the skills necessary to deliver the value expected by our client.
Moreover, we encourage agile teams to measure they’re productivity not by hours worked, but by the delivery of software. After all, working software is the primary measure of progress.
Sound familiar? How about a picture?
I’ve used work tracking systems to illustrate the system-wide inefficiencies of a functionally segregated IT organization. There is truth in that, but it’s not quite the truth. If that’s not it, then from where does the improvement come?
Cross-functional teams gain system-side efficiency by reducing or eliminating explicit knowledge transfer (read: handoffs).
Each handoff consists of wrapping up work in a pretty bow, which takes time. It is usually done electronically. This means that there is usually some notes added to a backlog item or simply a closed task. This tells the next person things are ready, but that’s it. There is no context. There is no warning of what things may be incorrect and need another look. No one knows the assumptions that were made but the person who did the work and that is rarely shared. The next person must re-learn much of what the previous person discovered, but they must re-learn it on their own. This cycle of learning, doing, handing off, learning, doing, handing off, learning, doing, handing off is ripe with inefficiencies and opportunities for miscommunications. Try asking a QA team member who has worked in a functional organization how often they spent days testing something only to learn that it was actually not ready and the engineers were still working on it; they simply forgot to update the task.
There is much more that can, and will, be said about knowledge transfer as a large factor in software delivery organizations. Ignoring knowledge transfer can be done at the peril of leadership. But for our purposes, that’s not needed to see that an agile cross-functional team and a lean production cell are essentially the same solution to the same problem.
In both cases, we accept point inefficiencies in order to collect system-wide efficiency.