I’m struggling with a concept from Toyota Kata, by Mike Rother. The way I’m reading it, teams of cross-functional individuals hide dysfunctions and can slow process improvement efforts. Or, to be precise, allowing cross-functional team members to assist others hides a potential improvement opportunity by limiting the pain of not having work balanced appropriately (heijunka).
Let me explain.
The Arguments from Toyota Kata
In Chapter 5, Mike talks about 1×1 flow (AKA single piece flow), whose purpose is to reveal dysfunctions or problems in the current process. He contrasts two manufacturing teams to illustrate.
In Example 1, Figure 5-6 in his book, the people are all working at their assembly stations (and there is some slack in the system), and when one person gets overwhelmed with work, a downstream employee who is starved for work will move to assist, thus increasing overall throughput. Now, this process is flexible, the employees can work around problems, and they can absorb any variation in the processes.
In Example 2, Figure 5-7 in his book, the people have no slack, and are matched to each. Now, if an operator experiences a problem, throughput immediately suffers, since there is no slack, and any problems, including issues such as variation in the process length, are apparent, and can be handled by process improvement efforts.
The first process has a lot of flexibility, and allows the team to make production. However, “…at Toyota this sort of flexibility is considered negative, since problems go unresolved and the process gets into a non-improving, firefighting cycle.”
He then specifically addresses cross-functional teamwork as an issue. “To compensate for this fluctuation, the downstream operators naturally walk from one value stream to assist in another, rather than idly waiting… Of course, this workaround is not a process improvement, and although it is done with good intention, it introduces even more fluctuation into the value streams.” And, even more strongly worded: “At Toyota, such self-compensating flexibility in processes would strike fear in the hearts of managers… Such a mode of operation would not be allowed, and would be viewed as a failure to manage the process.”
Pull Systems (Kanban)
Chapter 5 also addresses pull systems such as Kanban. In Figure 5-13, he shows a Supplying Department with numerous machines, each of which can produce items for a machine in the Customer Department (the next step in the process). The important thing to note is that every machine on the left can produce an item for every machine on the right. In other words, these machines are purely “cross-functional” and can “fill in” for any other machine in the same department.
Next, the author recommends putting a kanban system between them. He states we need two pieces of information: 1) Where the parts associated with a kanban card are located, and 2) On what machines the parts associated with the kanban card should be produced. Number 1 is pretty clear – we need to be able to go find the pieces. But number 2 is challenging. Mike states we should specify which machine actually produces the part we need, since this “helps us to see what kanban in really about at Toyota.”
He continues, and I’ll quote at length, “How do you think the supervisor will respond if we ask him to define what parts run on what machine? The supervisor is likely to object to someone taking away his flexibility to run the parts on whatever machine is available. Perhaps he will say something like, ‘If we are going to define what parts will run on what machine, and thereby reduce my ability to run items on any machine, then we better start improving the reliability of those machines.’ And so kanban has already started working for us.” This is illustrated in Figure 5-14, where the second pattern makes it “Easier-to-understand causes of problems”
Finally (last set of quotes, I promise): “If your purpose is ‘make production’ then the flexible system looks good because despite the existence of problems you can work around them and still make the numbers.” and “Flexible systems that autonomously bypass problems are by their nature nonimproving.”
This flies in the face of so much I’ve thought in the past that the past few days I haven’t been able to get it out of my mind. I’ve been going back and forth with Hakan Forss and Alan Shalloway for a while, but the 140 character limits are too constraining for actually fleshing out a thought.
Then, while doing some test process consulting with a local client, I ran across an example.
The Scrum team has a total of 7 people on the team, and are a cross functional (in the sense they have everyone necessary to build product) and the developers on the team are cross functional (in the sense they can work on tester tasks). The team has been successfully delivering value at the end of every Sprint. By all external Scrum measures they look good. However, in their retrospectives, they’ve been frustrated by the amount of testing-related work that the developer-focused team members are doing. Not surprisingly, they’ve been told that good Scrum teams work with each other to ensure delivery of working software at the end of the Sprint.
The team believed it was “under committing” to what could be delivered in a Sprint due to severe constraints in the capacity of team members focused on testing. Now, if that’s all the tested features they could deliver in a Sprint, then they were committing correctly. But we have a problem. Since the coding folks were helping out on the testing tasks, they couldn’t code as productively as they would have liked.
Question: “What if the developers couldn’t work on the tester’s tasks any longer” (ala Toyota Kata).
Breakthrough! We restructured the development process to allow each team to focus on their core competencies, while they will still be able to deliver tested, high quality code. We used a target condition, from Toyota Kata, to stimulate the creativity and come up with solutions.
So, in my first use of the “cross functional individuals can hide dysfunctions” thought pattern, I believe we made serious headway in a difficult problem. It provided a very useful lens.
Do we give up on Cross Functional Individuals?
No. I don’t believe so. I believe it to be a very useful thought pattern, but software development is radically different from manufacturing.
- Variation in Software is High – Extreme variation exists among seemingly equivalently sized tasks. Task time variation of hundreds or thousands of percent is common in software development. This means that if we have a “balanced line” (heijunka) on AVERAGE, we will be out of balance the vast majority of the time. To put it in Theory of Constraints terms, the constraint would whipsaw around the team unpredictably. Without at least some “load balancing” we might identify a whole host of problems, but nearly all of them would be variation-related. Trying to solve for variation in software development is a fool’s errand, and would block discovery of more substantial issues.
- Strong Teams Perform Better – High performing teams are generally made up of people who assist one another and form strong personal bonds. Working together on a difficult task can bring two people together in a way that working separately (even if cooperatively) can. This one is a bit fuzzy for me, since strong teams are surely created in Toyota; but I still have a gut feel that teams in which people are willing to bail each other out creates more positive improvement than can otherwise be gained with a strict load balancing effort.
My bottom line – I will continue to encourage teams to work cross-functionally and assist one another, but will periodically use the “cross functional teams and individuals can hide dysfunctions” thought pattern for process improvement.
What am I missing?
In doing some research for this post, I re-read the new Scrum Guide (from Scrum.org), and noticed that there is no mention of individuals on a team acting cross-functionally. In fact, it only states “Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” Thus, it appears the team could , in formal Scrum, be made up of two testers, two developers, one SQL DBA and one build engineer, all of whom only focus on their own core competencies and do act as “cross-functional individuals” to assist one another. (I’m NOT saying this is a good idea, just saying it doesn’t appear to violate Scrum, which surprised me greatly.)
Did Ken Schwaber see this as a possible dysfunction already?