Cross-Functional Teams are Gravy

Cross-functional teams are a set of people (and sufficient tools) that have all the abilities to produce a complete increment of work.  Cross-functional teams can self-organize to figure out the best way to complete that work.

I call great cross-functional teams gravy because I grew up in the south and well, we put gravy on everything. An adaptable team can do a variety of things well. So Just like gravy you can pour them on mashed potatoes, but also the fried chicken too! It doesn’t mean we have cogs, but it does mean that they can adapt over time.  They help each other overcome obstacles and they do it through learning and being intentional about where they are improving.

When turning a traditional team into a Scrum team, you get a bunch of people that have very specific roles. BA’s, QA automation, QA testers, UX engineers, Service Engineers, etc.

Waterfall methodologies, as they are implemented in most organizations, incent a person to stay in their specific lane. BA’s do requirements, QA manual testers manually test, and so on. There are a high number of specialists that go deep into their craft.

When you turn those same people into a Scrum team, the incentives change. The people on the team are incentivized to be cross-functional so that roadblocks and bottlenecks are cleared rapidly.

Here’s how I start off new teams when they begin Scrum.

First, we do need some specialists. Not everyone will automate everything, not everyone will know the corporate security protocols. This needs to be acknowledged. It’s not about going to an extreme edge where everyone can do everyone else’s jobs.

Second, it is about bottlenecks. During the task breakdown section of sprint planning, I horizontally map the workflow of the team to the stories they are trying to complete using sticky notes. I find it best to walk backwards from production. How do you promote to production? Did anyone do it for you? Are they on this team or is that a dependency? What about regression? Etc. I do this all the way back to the origin of the work for a new Scrum team.

Next, I ask the team to put their names under each state for what they could possibly do. I will ask them to elaborate on the ability they need to complete the task, (i.e. Java).

Once that is done, we can identify bottlenecks. A certain person may be the only person that can perform a task. If they are out, the team has to wait. That person needs more slack in their personal system so that they are never causing the team to wait.

In order to overcome this, the team can decide if the bottleneck is important enough to cause them to generalize. They may pick one or two members to learn that ability so that the team can remain adaptable in the face of change.  The team needs to consider what to change instead of going all in and trying to become generalists on everything. This method causes the visualization of bottlenecks, skill sets, and will unbury hidden treasure (skills) in the team’s system. The team can then prioritize and tackle the solutions that will make them faster with the same or higher level of quality and really internalize the fact that they are a team. From there, it’s all gravy.