What to do if team can't be made cross-functional?

Question

I work in a small video game development studio, where the whole company is one team working on one product, and each person has a fixed broad function (e.g. programmer, artist, musician). We can't be cross-functional since the range of functions is very wide - it's not like the typical cases I read about where e.g. "the database engineer can do a bit of front-end engineering too" - it's rare to find programmers that have artistic talent and even rarer to find artists that can code at all!

In Kanban, it looks like one recommended way of dealing with this is to have each discipline as a column, and to move stories from e.g. "In progress - engineering" to "In progress - art" as it progresses, but in video games there's generally there's not a hard dependency between the disciplines (don't need to wait for all of one discipline to be done before the other can work), and if there is, the disciplines will work closely together to iterate on that one task/story, so pipelining it like this doesn't make sense to me.

In Scrum, when picking a set of stories to accomplish in one sprint, some sprints will have mostly art-heavy stories queued up, and some sprints will have mostly engineering-heavy stories queued up. By picking the next most important stories, we'd be committing to having some disciplines sat idle once their part is done, since as I said, artists are unable to move on to engineering tasks.

In both cases, in a small company, any spare capacity can't be moved to other teams, and the hiring process (to increase capacity for some disciplines) is far slower than actual work (and of course, not always possible or desirable).

What I think may be good ideas (though I haven't read anything like this anywhere, hence why I'm asking this question!) are:

• For Scrum, fiddle the priorities of stories to account for capacity across disciplines, so rather than take on a second engineering-heavy story, look down the backlog for an art-heavy story, to make sure the sprint contains about the right amount of work for each discipline. This doesn't feel quite right because it means we're not always working on the most important story.

• For Kanban, have a lane for stories, and a lane for each discipline, pull stories into 'doing' when any discipline starts work on it (and to 'done' once all disciplines are done with it), so each discipline can get a bit ahead if there is spare capacity (but if staffing levels are right, it'll average out over the course of the project). This doesn't feel quite right because the stories lane will need to ignore WIP limits, meaning there will be some waste if things change. Also it just looks messy!

Am I thinking about this in the right way? What do other non-cross-functional teams do? And what's the actual name for non-cross-functional team so I can search for this better?

Thanks!

Answer 1

First off, I should note that, as per my understanding of the term 'cross-functional team', it is not a team where every member can do everything. Rather, it is a team that is capable of doing everything. If your team is capable of taking a project from start to finish without waiting on dependencies, then it is cross-functional. If the team has to spend a month waiting for 'the architect guys' or for 'marketing' (ie. external, non-team members) to do their thing, then the team is not cross-functional. Having cross-functional team members is a separate issue that, while also useful, is, as you note, often a pipe dream.

That being said, your suggestion for Scrum seems fine to me, with the caveat that the Product Owner is involved. Keep in mind that the Development Team is not the ones who decide which stories are more 'important'. During the Sprint Planning meeting, the Dev Team will negotiate with the PO on what should be included in the Sprint.

For example, if the Dev Team informs the PO that "For this next sprint, we can either do stories A, D, E, and F, or just stories A and B", then it's entirely possible the PO might decide that D, E, and F suddenly became higher priority then B. Or, the PO might truly decide that B is super important and the Team should work on A and B, even though this means D, E, and F get put off. This is the PO's call. Additionally, keep in mind the 100% utilization fallacy - it's not the end of the world if some members' workloads are not filled up.

Regarding the Kanban: though I've never done it myself, what I've seen done is have stories set up on the left of the board, with their tasks moving through the lanes. Once all the tasks of a story move to 'Done', the story moves as well. In this way, stories are essentially removed from the lanes and the WIP limits, with tasks taking their place.

Answer 2

Optimize for Flow, Not Utilization

In Scrum, when picking a set of stories to accomplish in one sprint, some sprints will have mostly art-heavy stories queued up, and some sprints will have mostly engineering-heavy stories queued up. By picking the next most important stories, we'd be committing to having some disciplines sat idle once their part is done, since as I said, artists are unable to move on to engineering tasks.

You are falling prey to the "100% utilization fallacy." In agile methodologies, the goal is not to keep everyone busy or to optimize for team-member utilization. Rather, the goal is to optimize for a smooth and sustainable flow of features or functionality over time.

With that in mind, there are some things you should do in your specific circumstance:

1. Craft product backlog items that consist of thin, vertical slices of functionality that require the combined skills of the entire team whenever possible. User stories that require only one team member to complete are often a process implementation smell.
2. Encourage whole-team collaboration to complete each user story, rather than parceling out stories to individual silos.
3. Accept that overly-narrow stories may cause idling for some members of the team, but recognize too that this evens out over time. For example, your graphics artists may have more to do one iteration, but your engineers may have the lion's share of work next time. You are optimizing for flow, not utilization!
4. Build in more feedback loops and collaboration opportunities between disciplines. For example, graphics artists and front-end engineers should be collaborating together in a tight feedback loop, not sequenced in a way where change or opportunity costs go up.

Regardless of your agile methodology, your goal should be to reduce hand-offs and queue times. Active collaboration within a Scrum team will do this intrinsically for work-in-progress (WIP). Creating Kanban queues and tracking cycle, lead, and takt times will not inherently do this, but will certainly make process waste visible and explicit.

Answer 3

Good question, first off.

Here are my suggestions, and you pretty much already said it without knowing it is to adopt a more-or-less hybrid framework: Scrumban.

You can have you Kanban Board setup in the way you suggest, in the normal 'To Do', 'Doing', 'Done' fashion (with QA/UAT anything else the actual Programmers/Devs will be doing) and with breakdowns in the Doing to identify an area/discipline.

A more refined way to do that would have your Kanban Cards colored/styled in a way to identify the Team/Discipline working on it - i.e. Red Cards for Dev, Green Cards for Art, Yellow Cards for Engineering, etc. That way your board doesn't get unnaturally big and stays within WIP Limits.

You can also have different boards for different Scrum Teams - if you have truly non-cross-functional - i.e. IT teams, Art teams, Voice Acting teams - you can split them into their own Scrum Team, with different Kanban Boards - however you want to share the same backlog as that is where you measure OVERALL Throughput, Burndown and Cumulative Flow from.

The only problem is where you would have to do things in a iterative/Waterfall fashion, where one task absolutely CANNOT be completed without another user story/card being "Done" - which may cause you to want to either keep the Scrumban/Agile teams together, or if you do decide to split and do different boards, have all the Scrumban/Agile Teams attend the same Daily Standup, so everyone is cognizant of the work besides staring at a Board.

My organization follows this hybrid Scrumban framework - more because the Business Unit outgrew the IT Department and they figured "Scrum" would solve all issues. It works decently well, we have added some 'unofficial' ceremonies/Sprint lengths.

Our Sprints are really 3-work week Iterations of 15 days each, the Domain walk identifies hold-ups, over-commitment and major Roadblocks and also hints at what work will be released to the "To Do" lists upon the next Iteration. We do that so we do not have to do the Sprint Review/Retro and Sprint Planning all the time, it is a constant improvement with the stipulation being abiding by the WIP Limit for that Iteration.

Answer 4

in video games there's generally there's not a hard dependency between the disciplines (don't need to wait for all of one discipline to be done before the other can work), and if there is, the disciplines will work closely together to iterate on that one task/story

You are already cross-functional (CF) to some extent. As Marut pointed out, a CF team does not mean each team member is poly skilled, just that the team is. e.g. a testing team is not a CF team but a development team consisting of front-end and back-end devs, testers, analysts and sysadmins would be considered a CF dev team. You can very well do with a CF team of specialists if the ideal of a team of CF people seems unrealistic. This is discussed in detail in a chapter on Team Design in my book Agile IT Org Design. Coincidentally, the chapter is available as a free sample courtesy of the publisher.

http://www.informit.com/content/images/9780133903355/samplepages/9780133903355.pdf

If the disciplines aren't heavily dependent on each other, they can be treated as three teams as VaeInimicus suggests. Doing so does not degenerate into waterfall in your case because I doubt that your problem space can be decomposed in terms of programming stories each with its own art & music component. Or they can be treated as three logical teams each working off their own backlog but still sitting and working together and reporting to the same product owner.

Answer 5

It's not an unusual problem, like you say, some places divide up their programmers by language.

You have to make a clear distinction between scrum and kanban though. I think a lot of people think kanban is just scrum without sprints, but the philosophy is inherently different.

Lets use an extreme example of we are baking cakes and one team member is solely responsible for putting the cherry on top.

Scrum : The goal is to incrementally build a product. So each sprint you need to finish a set of features to finish at all. If some team members are not fully used, they cant really move onto the next sprint, so you lose that time each sprint.

eg. you can't put the cherry on cake 2 yet because the results of cake 1 might change where you put it.

Kanban : The goal is to push tasks through a series of processes. each task can be completed in of itself. if one of the processes is quicker than the others then you can possibly move it top the start or end and do all the quick processes in one go.

eg. you can back all the cakes and hire the cherry placer for 1 day at the end of the project to put all the cherries on.