12

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!

  • 4
    A point I would like to make is that Scrum recommends cross-functional teams, not necessarily a cross-functional individuals. That is you can have a team of 5 folks that are 3 developers, 1 designer, 1 DBA. An important fact here is that you want to make the team cross-functional for the problem you are try to solve. That means if the product you are creating requires skill set of programming, graphics, databases, etc then you would want to have at least one person with one of those skills on your team. But, it would be great if a person has multiple skills sets :) – H A Sep 14 '16 at 19:53
  • 2
    Tons of related answers on utilization. You can also search for slack or capacity. – Todd A. Jacobs Sep 15 '16 at 19:40
  • You say that there is little if any dependency between the discipline's work. Is there any reason, therefore, that they could not be treated as separate teams? – Weckar E. Jul 29 at 19:17
6

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.

  • Thanks! The Kanban suggestion is a good one, and I'm glad my Scrum suggestion isn't awful! I've misunderstood 'cross-functional team' for a long time by the sounds of things - that always gets mentioned alongside "T-shaped people" which is probably what confused me. – Ben Hymers Sep 19 '16 at 15:26
3

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 you 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.

  • I'm still not sure I understand this "100% utilization fallacy". I mean, I maybe understand it if I was manager of a factory, but I can't imagine sat here looking at my team of 6, 3 of whom are sat idle, thinking "this is fine, I shouldn't aim for 100% utilisation". Those other guys could be getting on with the next thing they'll probably be needed for, because I'm paying them anyway. It's waste anyway, I might as well get some 'possible future product' out of them as well, right? – Ben Hymers Sep 19 '16 at 14:40
  • I've thought more about this and I'm sure that it's not a fallacy with this kind of work - it's a matter of pipelining. Say the project is really very simple and has mostly A working early, then B working more later in the project. If we divide time up so A is 100% utilised early on with B taking breaks so A and B are always working on the same story, then vice-versa later in the project, overall both utilisation and flow aren't optimal. If we let B get ahead a bit (by working on their part of future stories) the product gets done quicker. Isn't that better? – Ben Hymers Sep 19 '16 at 15:34
  • 2
    The problem is that if you're always planning for 100% capacity, what happens when something urgent comes up? No one has any time to deal with it. So either someone drops whatever they're doing and switches tasks to fix this urgent thing then has to switch back (BAD - task switching has been shown to be costly) or else it gets ignored completely (REALLY BAD). That's not even counting the stress cost, or loss of quality. Knowledge workers are similar to CPUs - as you approach 100% usage, everything slows down. If you just google '100% utilization fallacy', you'll get some good results. – Sarov Sep 19 '16 at 15:34
  • I find that a bit of a straw-man argument really, when I read "100% utilisation" I'm not imagining the team literally working non-stop all day, I read it as "100% of their non-break, useful time". Say people are generally comfortable working 80% of the working day, with the rest of the time spent going for a walk or watching cat videos or drinking tea. I want 100% of that 80% used. If there literally isn't the work for them to do because they're not allowed to move ahead, that seems like a bad thing - they've already had their tea break but they go back to their desk and... what? Wait? – Ben Hymers Sep 19 '16 at 15:43
  • (sorry, I know the place for this is probably another question - I'm not trying to argue, just trying to understand! Thanks for helping :) ) – Ben Hymers Sep 19 '16 at 15:44
2

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.

1

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.

0

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.

  • This is partly why I'm asking this question really; almost all examples of Kanban projects I see suggested use a product that resembles a factory line (I shouldn't be surprised given its origin!), but making a game (or most other software) isn't like that at all, it's very iterative and all tasks are heterogenous and variable. – Ben Hymers Sep 19 '16 at 15:31
  • 2
    Well that depends how you go about it. In mt experience you can normally seperate 'content' tasks from dev tasks. Ie. Make level 3 with placeholder assets which the designers will fill in later – Ewan Sep 19 '16 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.