Optimizing With Scrum

Problem

One time, I was able to turn an entire project around using Scrum. I joined the company as a producer, which is basically a project manager in the game industry. I had joined another big project that was in dire need of help.

The project had lost its publisher, which is the entity that publishes the game and that pays the salaries of the developers in our industry. The team was now making absolutely no progress. At that time, I was the only person on the team who had ever shipped a next-generation title before. This was supposed to be their big marquee project, the flagship, triple-A offering that they were going to make their name with.

I agreed, but with one caveat: that I would be given carte blanche, and that I would be able to do whatever was necessary in order to succeed. I wanted to be able to exercise my best judgment honestly when assessing things like the organization of the project and the leadership within the team. The technical leadership was not strong.

Actions taken

I quickly surmised that the way that the team was organized and siloed was very similar to the traditional style of waterfall management that preceded the Agile way of thinking. Everything was broken down by discipline, and nobody was really working on the product specifications.

Instead, they were working on things that went into the product. I decided that the implementation of Scrum would solve the problems that were impeding the technical end of the work.

I reorganized this cross-discipline team; each division would work on systems, features, and all of those sorts of things. I put together a training course on Scrum, an introduction to the methodology, and what it stood to offer the team.

I didn’t want to just force them to learn about Scrum. I wanted to give them only what they needed, some clarity on its goals and its positions on leadership so that they would be able to grab ahold of it for themselves. With these new concepts in mind, it would be much easier to focus on making a better game every single sprint.

All of the rest — the jargon, the burn-down — that stuff is great if you’re a product manager. Artists and programmers, on the other hand, they’re out there doing their things passionately. They don’t want to learn about all of this extra noise and stuff. It’s snake oil to them.

I try to strip all of that out so that the things that will be most useful to them will be apparent immediately. These things give them the freedom to deliver together as a team.

Within a few weeks, we were seeing great results. The product was finally starting to move forward. Eventually, we’d managed to get signed by a huge game company.

Lessons learned

• I went around the organization in order to find all of our strongest leaders. I evaluated their common sense and their ability to see things and to be practical in their interpretation of them. By rallying this group of very strong leaders around me, we were able to turn the entire project around within a very short period of time.
• I’ve always found that when things aren’t working well, it was rarely the people who were the real problem. It would usually be the way that they were organized and put to use. The leadership ends up mattering more than anything else. The people have the talent. Underperformance is a matter of how the team is built and utilized.
• Agile has become such an industry thing. People are so focused on making money with it and selling courses. The core of it is forgotten. It was created to help a lot of people who were failing in their projects but who didn’t really understand why.