How to deal with the situation that some people's work is not fulfilled during a sprint?

Question

We are game developers and just began our Scrum practice. We found something like this:

During a sprint, we have several user stories to complete, but some of our members' work is not fulfilled. At the same time, someone may work overtime to complete them. This is basically caused by role differences, like artists vs. programmers, etc. For example, we have enough artists but not enough programmers, so that when programmers are working hard to death, artists may find themselves having nothing to do. So ok, I think saying that "caused by role differences" is wrong. More precisely, it is caused by lack of people of certain professions. Of course we're hiring, but how to get this through now?

Our solution now is to create small user stories dedicated to the people whose work is not fulfilled, like "concept art for character X", but apparently it is not a normal user story for us. Why abnormal? Because usually our user story is kind of "make character X", which includes concept art, animations, feature implementations, etc. "concept art for character X" is just too small and not on the same level of detail here.

So what's the best practice to deal with this kind of situation?

Answer 1

Unpopular opinion

Scrum is not wholly suitable for game design and development due to numerous factors.

• Definition of Done can extend from 2 to 6 versions

https://www.mountaingoatsoftware.com/blog/multiple-levels-of-done

• Senior game developers like John Carmack (Doom) have rejected Agile/Scrum as a delivery method for game design and complex software engineering

https://news.ycombinator.com/item?id=10212629

• The aim of Scrum is to produce a valuable working product increment every timebox that is potentially releasable

Game development does not work in this manner and certainly not within the smaller timeboxes that Scrum prescribes (1-4 weeks).

If you cannot potentially ship the product increment you cannot be doing Scrum. You are doing something and it may be Agile but it is not Scrum.

Scrum was originally designed for small cross-functional teams that had absolute minimal dependencies and could deliver value incrementally; improving as they went.

Producing a game does not fit well within that framework and certainly not within arbitrary timeboxes. The entire process has complex inter-dependencies between product, operations and technical activities including, but not exclusive to, direct customer feedback. Narratives need decided before level design can be implemented. Level design is required before AI and environment specific variables.

It is more akin to producing a movie which cannot be accomplished in a Scrum manner.

Answer 2

Your team doesn't contain the skills you need. Ideally, everyone should be able to have some level of flexibility to step out of their particular specialism and take on the tasks to push the sprint forward. You may have come across the phrase "T-shaped" people. Scrum isn't wrong or unhelpful, it's just honestly pointing out a problem you have.

Fix your underlying problem: Everyone doing everything isn't necessarily attainable, but it should be your idea. Train your team: help your non technical staff acquire technical skills. Not everyone needs to learn to code to help out. Programmers also do a lot of stuff that isn't coding, checking logs, deployments, even doing basic IT help for their colleagues. Hiring more programmers would help as well.

Deal with it in the short term: It's important to remember that your job isn't to keep people busy but to deliver value. By creating art assets you may just be creating 'inventory' (lean people hate this) at a higher rate than your team can clear. it's not worthless, it's just not super valuable.

I would ask yourself this question though. Do you maybe have something actually valuable that could be delivered without much programming effort?

I don't think your example, concept art, necessarily is inventory however. I do see some independent value in being able to user test, distribute and market these new characters. As well as thinking about how to deliver valuable stuff, it's also useful to think about how to get the value out of the stuff you do deliver.

Answer 3

Scrum doesn't really work well for software with different disciplines waiting on each other. Scrum teams are expected to be cross-functional, but also should also be balanced so that the whole team can work in a sustainable pace. Working overtime is never a good idea, this will only hurt you on the long run. Tired developers have a netto negative productivity and they will just create a mess that needs to be cleaned-up in the days to come.

I would suggest using Kanban and visualising your current workflow. This to find your bottlenecks. Are you sure you need more programmers? Do you really need all that art work implemented? Maybe decrease on the artists instead. What do you really need? YAGNI!.

Personally I like the roles of Scrum and also the inspect and adapt meetings. Some teams then also combine Scrum and Kanban into ScrumBan. This just removes the iteration period where you forecast what work will be completed in 1-4 weeks, planning is more just-in-time. It will more be a flow of work continuously being completed.

This might still lead to work being stuck in the development phases, but at-least it will be visible. Also you do not have the disappointment and demotivation of uncompleted sprint after sprint.

Use regular retrospectives to trigger the team to optimise their own process, maybe they can figure out something on their own. Keep experimenting until you find the correct balance.