Once upon a time...
...there was this BigCorp that decided to reorganize its workforce into "product oriented squads".
You are probably familiar with how this tale continues: BigCorp also had at the time a few long running projects doing some work that was orthogonal to the product development mandate the new "value stream squads" had been given. These projects were organized around project teams, whose members would now be assigned to the new squads.
It was decided that launching the new "squad operating model" couldn't wait for those projects to finish, so instead they would go ahead with the reorganization, and some squad members would continue doing project work, "for now". After all, the projects would end at some point, and until then the new squads could account for slightly diminished "capacity" as part of their planning.
So, the new squads launched with pomp and circumstance. The friction between the two "operating models" was quick to become apparent, but everybody agreed that it was to be expected. As a countermeasure, teams had been asked to make sure they visualized all their work (both project and product related) on their tracking boards, to help them make the appropriate decisions.
What wasn't anticipated, however, was that even though some of those projects indeed ended, others were started under the same premise (that is, "borrowing" team members from the squads). So, the practice of part-time, "shared team members" was more difficult to eradicate than expected.
But in addition to that, visualization of all the work wasn't really helping the teams deal with the situation. Most teams noticed that there wasn't much interest in discussing project related work during their stand-ups. Many Project Managers like to keep their own project boards (which, of course, didn't include product squad work), so there was also the additional overhead of duplicating tickets. Eventually, most squads abandoned the practice.
Some were intrigued with the fact that visualizing the work didn't seem to have much of an effect helping teams arrive to a solution, but the question of why that was the case was quickly glossed over with a different one: "isn't the solution obvious? independent teams with full-time membership!"
Independent, fully dedicated teams: #ifonly
Let's be clear about something: teams that are fully independent, with team members that are fully dedicated come with lots of benefits; we could even call this "the ideal situation". You will hear stories of companies that did it, and achieved lots of success with this model. In my personal experience, however, I've heard and seen much more frequently organizations that found it very difficult to do, and ended up with some compromise (just like BigCorp in the story above).
There's a saying in the Kanban coaching world: if you find yourself saying 'if only...', it's the signal that you've gone too far" (and probably stepping right into wishful thinking territory). The reasons why this is the case for the idea of "fully dedicated, independent teams" is something I explored in more detail in a talk about the Limits of Cross-functional Teams, but suffice to say that things like scarcity of specialized skills, domain specific knowledge, technology "bounded contexts", HR policies, and other things like that will throw a wrench into plans to build these ideal teams. And to that, you need to add cultural values and beliefs around multitasking abilities, and the attitudes towards perceptions of "being idle" and "running out of work".
By all means, consider ideas that you think are ideal, but recognize that lots of compromises will have to be made, and that you probably will have to evolve towards that "ideal" position. Which brings me back to the question of the "failure of visualization".
Visualize... and then, what?
Asking teams to visualize all the work was the right instinct. But it needs to be just the first leg in a three-legged stool.
Visualizing works when it allows people to see things they need to see, but they couldn't before. The fact that there's project and non-project work is not it; they already know that.
So, when you're asking your team to visualize something, you need to ask yourself: what is it that I need them to see?
In this case, I'd argue that what they need to "unhide" is the imbalance caused by having two sources of demand, and the specific ways in which one kind of work interferes with the other.
This might include:
Who's working on what, to make obvious the level of multitasking and context switching that people are experiencing;
Which ticket can't make progress (is "blocked") because attention is given to other work, or because a specialist is not available to help with it (and where that specialist is focusing on)
Arrivals of new work, perhaps at disruptive times, or with different cadences, and with different priorities (or "class of service")
Conflicting schedules for meetings, and other forms of overhead.
How everything connects, and what it all means will not be immediately self-evident. This is where the second leg comes in: in addition to visualization, you'll need to introduce some form of "reflection mechanism": a space that allows you to interpret what you can now see, to make sense of it all.
Your daily stand-up can be one of those "reflection mechanisms", but there's a catch: it needs to be structured in such a way that goes beyond providing status, and it turns into a sense-making event. A meeting structured around flow (rather than the usual, dreaded "three questions") can be a step in the right direction.
But daily stand-ups are not going to be enough; you will also need some form of periodic analysis of the larger picture, to observe and analyze trends. Retrospectives and Service Delivery Reviews can serve this purpose (again, assuming they have been designed with all this in mind, and go beyond the anecdotic).
But there's another question to ask: who is this visualization directed to? who's observing? And to what effect?
Let's do something about it
As the section above shows, we need to be very intentional about what we choose to visualize. At the same time, I pointed out that we may have an "ideal solution" in mind that can be impractical in our context, leaving us with a compromise that causes various forms of dissatisfaction, with a solution that will need to be found through evolution (AKA "trial and error"). So, how can we be intentional, then?
I may not be able to tell you what organizational design will solve your "shared team members" problems, but we can have a conversation about how the current situation is causing you pain. Or there may be things at play that I (as a coach, consultant, or external observer) may need to help you see first, so that we can start talking about potential solutions. Visualization can then be used to expose things that make us feel a little "uncomfortable" (such as the usual dependency on Brent, the sys admin, or the untimely and frequent arrival of "project emergencies"), so we can't ignore them and we keep them front of mind. We call such a mechanism a "stressor".
But we don't introduce stress to a team out of a strange sense of "fun"; we do it because we know that some level of stress, when calibrated properly, can move people to action. It can encourage an act of leadership, with someone saying "let's do something about this". And that's the third leg of the stool.
It's important, however, to understand who can say "let's do something about it", and within what scope.
In general terms, we always want to encourage acts of leadership at all levels, and that includes team members. Therefore, it's perfectly legitimate to solicit (and expect) ideas from team members on how to solve this problem. At the same time, however, we need to recognize that the problem in this story is systemic in nature: it stems from organizational design decisions, and it has ramifications that go well outside team boundaries. It's unrealistic to believe that teams, making localized decisions, will be able to tackle it.
At the end of the day, the people who need to "feel the stress" out of visualization, reflect on its meaning during various reviews and meetings, and eventually decide to "do something about it" are the people given responsibility to lead these teams, manage their delivery efforts, and make external commitments on their behalf.
In BigCorp's case, that meant the "Product Owners" assigned as "squad leads", and the Project Managers running projects. Moreover, it will be important for them to realize that this will be a cooperative game: they will have to make decisions together, to manage the whole system collectively.
Here are some examples of the decisions they might eventually arrive to:
Visualizing work by service (project, product value stream, etc) rather than by team.
Synchronized schedule for recurring meetings (so that there's no overlaps), or perhaps joint meetings between project and product value streams.
Protecting the access to scarce specialists, to limit context switching. For example, they might decide that Brent (the sys admin) only personally works on some high-profile items, while pairing with other people to mentor them on lesser important items.
Clear policies for shared team members about how to split their time between different kinds of work. For example: "project work only in the mornings".
Better decisions about when (and if) to start new projects, essentially managing and limiting work in progress.
Explicit policies about class of service (priority) given to works of different kinds coming from different sources. For example: "production bugs for the product line will take priority over project work, but date sensitive project work will take priority over product features".
Explicit capacity allocation by source of work: "we take at most 10 things at a given time: 7 from the squad backlog, 3 from the project backlog"
Afterthought on "Shared Services"
There's an additional insight from the BigCorp story here, although the route to it is slightly indirect.
When we have two (or more) value streams that all depend on work performed by a third, we call that one a "shared service". In the BigCorp scenario, the product and project value streams share people, not work, so it's not the same thing, but interestingly the mechanisms to resolve the tensions in both cases are similar: ultimately, the solution requires close collaboration of the people responsible for each service, so that they manage the whole from a systemic point of view.
What I find interesting is that many times we arrive to the "non-dedicated team member" problems by attempting to create completely cross-functional teams through the elimination of shared services, only to find that the skills (and many of the practices) that are required to solve the "non-dedicated team member" problem are the same we'd need to effectively manage shared services.
In any case, exploring the world of shared services will have to wait for another future article, but the thought here is that perhaps organizations could side-step many headaches by accepting that shared services won't go away any time soon. #ifonly....
Take-aways
In the Kanban coaching world we call this "three-legged stool" the "formula for evolutionary change": to catalyze change, think about the introduction of three ingredients:
a stressor (to shake the status-quo)
a reflection mechanism (to make sense of that stress)
acts of leadership (to do something about it)
In the BigCorp story we started with, there were two legs missing, which might explain why the only one in place ("visualize all the work") wasn't as effective as expected.
This "three-legged stool" is for those responsible for delivery in the various value streams to sit on; it's not for team members. These managers need to come to the realization that they all rely on the same, finite capacity to produce the value they need to deliver, and that they have to collectively treat it as a systemic whole, or they will end up suffering from their version of the "tragedy of the commons".
Comments