It was true that Scrum wasn't helping. The group of people working on the architecture were all working on independent tasks. They had nothing to talk about throughout the day and didn't commit to a shared sprint goal, so there was little feeling of "team" among them.
As I asked around, I found that those dependent on the graphics architecture felt that this group usually delivered their work late and what was actually delivered wasn't exactly what they'd asked for. As a result they were impacted through crunch and the game's quality was compromised.
The architectural manager had never heard this. That was an interesting "tell".
Asking around further, I found that the graphics architectural work was driven by detailed requirements from the artists and designers written at the start of the project.
Now the picture was becoming clear.
When planning starts with high detail, we often create a push system that drives many behaviors throughout a development process. It can create a vicious cycle:
|The vicious planning cycle|
Agile is a pull system where the work is pulled towards a vision of what we want in the game and what the game is telling us. We measure what's pulled into the game and adjust our plans based on the pace of that and what the needs of the players and developers are.
Scrum wasn't doing them much good. We needed to look at how it was being used.
The organization of the graphics group looked like this:
- The manager pushes the vision through a schedule of assigned tasks
- The manager owns the schedule
- The team is a group of developers which execute assigned tasks
- The manager coordinates cross-functional dependencies
- The manager solves cross-fucntional problems
- Integration is painful, which leads to its deferral (which makes it even more painful).
|Pulling work into a swarming team|
- The team executes based on a shared vision that pulls iteration goals in.
- Work is planned by the team based on those iteration goals.
- The team owns the short-term schedule (iteration)
- The team can address most dependencies and problems themselves
- The team consists of people who can address each other's problems through swarming
- The game or architecture has frequent integrations to test the emergent value and address risk.
Moving from Push to Pull
Push systems have been largely discredited even in manufacturing industries, which have far more predictability than game development, but push is still prevalent in many software development companies as well as game development. There are many cultural reasons it sticks around, such as:
- Silo'd discipline structures
- Lack of trust
- Management by fear
- The myth of up-front planning
These don't go away overnight with the wave of a wand. They melt away slowly through the slow application of agility:
- Breaking large cycles of integration, test and validation (e.g. 6 months in this case) into shorter ones.
- Iterating against player goals, not architectural goals, as much as possible.
- Breaking large detailed designs into prioritized outcome-based goals with shorter-term details.
- Replace documented hand-offs with face-to-face conversations.
There is a slow transformation away from managing for components to managing for player outcomes that doesn't occur overnight, but this transformation can begin immediately and the benefits can be seen every iteration.