Wednesday, July 30, 2008

Hyper-productive Teams

A hyper-productive team is a phrase often used in Scrum literature to identify teams that have achieved a state of ownership, commitment and collaboration that allows them to be far more productive in creating “product value” on a regular basis.

I view hyper-productive teams as independent of Scrum. There are many examples of teams that have been hyper-productive independently of the process they’ve used. I’ve been on several in my career from the defense industry to the games industry. They are the highlights of my career. I never worked harder and never had more fun than when I was on those teams.

The first was the YF-23 avionics integration team that I worked on for 10 months in 1990 at the McDonnell Douglas plant in Saint Louis. We were led by a retired F-14 Tomcat squadron commander. We actually had 10-15 minute stand-up meetings every morning to go over the issues and daily goals. He called it the huddle. We were a team under siege in a hostile environment as contractors working the midnight shift.

Another hyper-productive team was the Midtown Madness One team. Most of the team (including me, the product director) had never worked on a game before. However, we were given almost complete autonomy by Angel Studios (and largely by even Microsoft) to build the game we wanted. I recall all of us stopping work to play the game at 6 PM every night and then stopping at 9 PM to drink beers in the conference room and discuss ways of improving the game. I would arrive some mornings to find that members of the team had reworked the rendering engine or vehicle dashboard models overnight to greatly improve a weak part of the game. We didn’t use Scrum either, but we had some TDD like practices and even posted burndown charts which visibly tracked key statistics such as polygon budgets for the level, etc.

Hyper-productive teams are hard to define. To paraphrase a common quote: “it’s like porn…you can’t define it, but you know it when you see it”. In addition to talent, hyper-productive teams are the greatest contributors to the creation of a hit game.

I try to define conditions that support, or are common to, hyper-productive teams. In addition to educating teams on how to use Scrum, a main goal of mine is to facilitate teams on becoming hyper-productive.

So what are the conditions that allow a hyper-productive team? I’ll identify a few I feel are important:
  • Independence and a sense of ownership - The team needs to feel that they can contribute creatively and have some control over the game. This isn’t necessarily total ownership, but some.
  • Leadership - There needs to be one leader on the team who can communicate a vision between the team and the customers and keep the team focused.
  • A core competency - Not everyone on the team needs to be an expert, but on the hyper-productive teams I have seen there have been at least one core expert. This isn’t a lead position defined by a role, but by actions. This person supports the vision with brilliance that the team can be confident in and rally around.
  • Team collaboration - Teams grow into great teams organically. There are countless articles and books written about how this happens (here is one of my favorites). This is where facilitation can help a team transform itself.
As mentioned, these teams form independent of process. However, Scrum can support and nourish hyper-productive teams based on its practices and principles. Team self-organization, Sprint goal ownership and commitment and a daily dose of visibility can support and grow hyper-productive teams.

Monday, July 28, 2008

Product Owner as Pig?

Scrum defines two types of individuals associated with a project using Scrum; one type is fully committed in a project, the other is merely involved. A commonly referenced joke about the commitment of the pig and the involvement of the chicken in a ham-and-eggs dinner illustrates this and is used to name the roles. The product owner is often referred to as a “chicken” because they aren’t committed to the work to be accomplished by the team every Sprint. They are only involved with the outcome while members of the team are called “pigs” because they truly commit to the work of the Sprint.

The product owner (PO) for a video game project can be compared to the role played by key visionaries such as Shigeru Miyamoto, Will Wright, Tim Schafer and Sid Meier on their projects. A PO represents the ultimate customer during development: the player. The PO has to foresee what the market will want up to three years in advance. They have to know the mind and emotional responses of the player. Pure iteration is not enough for video game development. We typically have one true release to get things right. Most of our games can’t slowly grow their feature sets and market simultaneously like other products. This requires great vision. This is unavoidable.

You might ask “can’t we iterate and focus test our iterations?”. I wish it were so, but over the years I’ve discovered it isn’t enough. Focus testing will tell you how your game compares with the focus tester's current favorite games. Additionally there is a huge discrepancy between the people you focus test and the people you have to impress to get market awareness (e.g. reviewers and hard-core-gamer-mavens). That’s a bigger topic.

Originally the Product Owner role was considered a “chicken” role. That’s to say it was a role that required no commitment to the Sprint goals. This has changed over the past as the product owner role has been identified as a key to success or failure of a project. This is no more true that for game development. As a result, many projects consider their POs as “pigs” (we used the terms “ninjas” and “pirates” for these concepts of commitment because, for some reason, people dislike the labels "pig" and "chicken").

“PO as pig” is needed because we can’t always know what’s fun two weeks from now. Questions about how “bouncy” a physics response should be or how “snappy” an animation transition needs to be, etc, etc are subjective and may need daily feedback from the visionary.

The question this raises is “how can the team commit to Sprint goals if the PO is giving direction every day?”. The answer is that they can’t commit to same level of detail. They have to commit to higher level goals, especially when they are in pre-production. This can be difficult for veteran Scrum teams to accept, but when the PO is a pig, the PO is making a commitment as well. Their “skin is in the game” with the rest of the team. They should commit to goals with the rest of the team. Highly details Sprint goals are meant to improve communication between pigs and chickens, but if your #1 customer is on the team, then the communication problem is reduced.

A PO can’t be a pig on 10 teams however. Some games have a “hierarchy of POs” with the main product owner and a number of POs for major mechanics or functions reporting to them. This is a common solution used in many industries adopting Scrum.

One word of warning. If you are working on a game (agile or not) without a single strong visionary who is clearly calling the shots about the features regularly and transparently, then you may have a problem.

Tuesday, July 15, 2008

Feedback: "Top 10 Pitfalls Using Scrum Methodology for Video Game Development"

Gamasutra just posted an good article by Paul Miller called "Top 10 Pitfalls Using Scrum Methodology for Video Game Development". I found it interesting. I agree with some points and disagree with others. The article highlights some misconceptions and myths about Scrum. Since they come from a person which has gone through a product cycle with Scrum, it's very useful to discuss them.

I'll start from the top:

10. A Game Design Document (GDD) isn't needed anymore because the backlog spreadsheet replaces it.

This is one of the biggest misconceptions of Scrum. Agile does not eliminate documentation or planning. It does focus more value on a working game over a design document, but that doesn't mean that we should eliminate all documentation. It just means that we don't rely entirely on the GDD alone to define what the game will be. GDDs can often become too detailed. I've seen GDDs for shooters that try to define the number of bullets in a clip for a fictional shooter. Why can't some of those things be decided while developing the game?

On the other hand we should document what we know about the game. You can't plan away uncertainty, but we should communicate what we are certain about.

I assume that by "backlog" he means "product backlog". If your product backlog is becoming too big to manage, then perhaps it is too granular for future releases.

9. Interrupt what people are doing to have them come to the daily 15 minute stand up meeting.

This sounds like the "daily scrum is about tasks" smell. The daily Scrum is for the benefit of the team and the product. If there are "
developers had already been through a couple development cycles on various projects and had an established track record of working on the correct tasks and shipping products on time" then they should help mentor the others who don't have this experience.

If the Scrum is starting late, then the Scrum Master should fix that. Lateness to the Daily Scrum is an impediment because it wastes time. It's the SMs role to fix impediments.

It always amazes me to hear the argument that 15 minutes is too costly an amount of time to spend per day to insure that all 8-10 people on the team are on track. Do companies track bathroom, coffee, lunch and web surfing breaks to insure that we don't waste 15 minutes or more per day? It's not about the time. It's about the resistance to collaborate. As a former CTO I can clearly identify this issue as one which affects senior programmers quite often! ;)

8. Moving all team members into a dedicated team room or team area does not cross-pollinate with cubicle assignments in the per-discipline-organized cubicle farm.

I agree. One point is that when teams reach the proper level of collaboration, they drive this themselves.

7. A team member says "I'm not doing something right now because I was told there needs to be a task entered into the backlog and the task needs to be assigned to me by the project manager."

Teams should have total control over how they achieve the Sprint goals they've committed to. The Sprint goals are increments of value for the customer. I'd suggest to this team that:
- They don't have project managers assign tasks (that's not Scrum).
- They put the Sprint backlog on a task board (3x5 cards) and ditch the spreadsheet.
- They take control of the execution order and creation of tasks within the Sprint.
- Focus on release goals. He mentions that the team is only focused on 2 weeks. This is why there are 2-6 month releases where the team focuses on Big Hairy Audacious Goals (BHAGs).

6. Start managing stories and sprints before all the people are on the team. Decide that your Scrum stories and sprints are 100% completed months before the project even has a QA tester.

Very good point!

5. Scrum Pitfall: The 15-minute daily stand-up meeting degenerates into a daily go-around-the-table-and-each-person-give-a-status-report.

Many teams new to Scrum hit this issues and the result can often lead to managers saying "let's manage the team out of it". There was a recent post on this topic. It is very difficult for teams to achieve the collaboration to become hyper-productive. Sometime the team is not formed correctly, sometimes managers won't let it happen.

4. Make Scrum mandatory.

He makes a very good point about management feedback. One of the biggest problems I find is to get management to understand that each Sprint should show improved value and to have honest discussions about what is working and what is not. Too many times, the "work in is in progress and we'll show more value someday" pattern remains after a team adopts agile.

3. Implement only two weeks' worth of work and write only the code based on what you currently know about the game design.

I agree. Studies have shown that we solve problems best by a combined top-down and bottom-up approach. I've never been very comfortable with XP's "do just what's needed for the next two weeks" philosophy. Experienced developers will have more knowledge and can create farther reaching solutions. However, the problem is that they usually go too far. The opposite side of the problem is with programmers who only code for the current iteration and don't refactor constantly.

2. "Sprint Zero" is pre-production time.

I don't get this one. Prototyping is for knowledge. Knowledge has great value in building and refining the product backlog. I won't limit prototyping to a set number of Sprints (much less one).

1. Start managing the project by prioritizing tasks and asking for time estimates even before any GDD is written.

So what does the team do while the GDD is being written? If I know I'm going to be working on an FPS, I might want to get a camera and character controller working while the customers are trying to define the characters themselves. Perhaps there are questions that come up in the GDD writing process that would benefit from some early prototyping? This relates to #10, but it also reflects the impression that the GDD will answer all questions. If they can honestly say that the games they ship completely match version 1.0 of the GDD, then power to them. I've never seen it.

I'm also getting the impression that their product backlog is a huge spreadsheet of tasks that is prioritized and assigned up front. Tasks should only exist in the Sprint Backlog. Let the team worry about the tasks and their estimates. Estimate the Product Backlog in Story Points or Ideal Days. Don't create too granular of a Product Backlog. It becomes too difficult to manage.

I'm really glad to see such articles written. It reinforces what I've seen as a coach these past six months. The issues that teams adopting Scrum are seeing have patterns. Patterns can have solutions which can be shared.