Search

Friday, December 25, 2009

HOW TO FAIL Learn to Let Go: How Success Killed Duke Nukem

Good Wired article about Duke Nukem Forever and what happened at 3DRealms:
http://www.wired.com/magazine/2009/12/fail_duke_nukem/all/1

Many take-aways here:
- Perfection is the enemy of "good enough".
- The danger of the "it's done when it's done" approach.
- The danger of success.
- The second system effect.

Tuesday, December 22, 2009

Book Review: Succeeding with Agile


Overview:
Mike Cohn's latest book: "Succeeding with Agile" is a "must read" for any agile developer. It's not meant to be the first book for those considering Scrum, but if you've read that first book, attended a Certified Scrum Master class or have applied Scrum for even a day, buy this book now!

Background:
Scrum is like chess. It's very simple to learn to start using, but challenging to master. It requires ongoing learning and experimentation to find what works best for your studio and culture, while avoiding the "bad changes" to Scrum practices that can embed organizational flaws.

Scrum pressures managers to focus on mentoring and coaching. It requires overcoming the inertia of "the old way", which includes people doing things for the benefit of their position and not necessarily for the benefit of the product. It involves buy-in from departments like HR, which can resist the emphasis on team performance. It demands people take ownership in areas they had no ownership and give up ownership in areas they once ruled over. It challenges the silos of discipline and the barriers of project managed "phases". It pressures us to change how we test, program, create content, review, manage, promise, motivate, etc.

It's no wonder that understanding Scrum practices is not enough and that so many Scrum teams fail to achieve their full potential. Mastery requires learning and experimentation. Learning comes from many sources including coaching, training, experience and reading books like "Succeeding with Agile".

Succeeding with Agile:
Mike Cohn is one of the founders of the Scrum Alliance and the author of two previous agile books: "User Stories Applied" and "Agile Estimating and Planning". Both these books built upon various knowledge of beneficial agile/Scrum practices and communicated them effectively. Mike is an experienced coach, trainer, product developer and writer (visit www.MountainGoatSoftware.com). His latest book "Succeeding with Agile" is his best.

This book covers every angle of your organization from executives, HR, marketing, developers, IT and even facilities! It covers every aspect of what impacts agile teams and how to handle every conceivable challenge. It examines Scrum roles and practices in depth to help you find ways to find improvement regardless of your company's level or experience.

Synopsis:
Part 1: Getting Started describes a number of ways that Scrum can be introduced into all types organizations. It examines a number of patterns and introduces the ADAPT acronym for adoption, which is brilliant.

Part 2: Individuals focuses on overcoming resistance, examining the changes to roles inside and outside the development team and the influences on the technical side of development. 

Part 3: Teams is the core of the book. It spends 150 of the 450 total pages on the roles, practices, dynamics and organization of teams. Solid gold advice on helping teams succeed.

Part 4: The Organization looks at the entire company structure, how it's influenced by and can continue to influence agile teams. It discusses ways that large scale and distributed Scrum teams work.

Part 5: Wrapping things up points the way forward. How do we measure how the teams are doing on a regular basis? How do we gauge how well the teams have adopted every aspect of agile adoption. This part shows us how.

Conclusion:
The writing is conversational and engaging. The figures and tables are numerous with an outstanding style. The layout of the book includes numerous sidebars that discuss common objections, quotes from developers in the field and practical things that you can try immediately.

This is the best agile book on the market. I'm not just saying that because I've worked with Mike extensively. It is the best.

Friday, December 18, 2009

"Scrum is dangerous"

A good quote from Lyssa Adkins via Tobias Mayer's blog.  Both Lyssa and Tobias are Scrum Trainers and thought leaders.

As the Orson Scott Card quote says, there is something in us that desperately wants to “safely interpret dangerous things in ways that don’t require us to change our lives.” Is Scrum dangerous that way? Absolutely. If you are doing Scrum well it will require you to change your life. You will have to give away your belief that having a checklist makes things run smoothly. You will have to stop chasing the perfect process and, instead, start cultivating your ability to trust the resourcefulness of others. You will cease using line items checked off on a plan as your measure of value. You will face your fears, all of them, about yourself and other people. You will stop making progress and start making products.

Interview: SOE's Yanagi Talks DC Universe Online's Birth & Scrum

http://worldsinmotion.biz/2008/12/interview_soes_yanagi_talks_dc.php

On an everyday basis we have playtests. All the different Scrum teams -- we have a combat team, a content team, an environment team -- they all do their playtests, and they can see what the other teams are doing, and see how their piece fits into the whole.

...using agile is great because, as those issues pop up from that Scrum team's perspective, if they're focused on balancing or getting all these powers working together, that can be their highest priority that they have to deal with.

Sunday, December 13, 2009

Scrum used on Left 4 Dead 2

Former Valve Designer Kim Swift on using Scrum at Valve for Left 4 Dead 2.

Full Gamasutra article.

--------
It sounds kind of funny, just because it's really quick. A quick sequel, which is not Valve's well‑known trait.

KS: Yeah, definitely. We're pretty proud of ourselves for not moving at "Valve time". We practiced a new organizational tool. We used the Scrum method this time. We decided to give it a shot, and it's worked really well for us on the team.

And also, heading into the project, we were pretty sure about what our deadlines were, so we were able to try and be more deliberate with our planning to actually get the sequel out.

So the first game wasn't developed under Scrum and the second one is?

KS: Yeah. We decided to give that method a try.

So have you been seeing more productivity? Obviously, you have one more mission to do. Do you have a perceptible increase in productivity?

KS: I think more than anything it helps us prioritize what to work on. Since we knew that our shipping date was a lot sooner, we were able to sort out which ideas were actually doable in that amount of time, and that we knew were actually going to be successful, rather than trying a whole bunch of different stuff that wasn't necessarily going to be what we shipped.

Friday, December 11, 2009

Brutal Legend and Scrum

"For Brutal Legend, Double Fine adopted agile development, hoping to eradicate the rampant crunching that defined Psychonauts' development cycle -- and it worked:"

Gamasutra article

Repost: the Heart of the Team

I came across this post written a few months back. Shelly Warmuth had some good words to say about the goal of a Scrum team.

At the heart of the scrum team is the interaction of the team. A daily meeting around the task board is interactive, vibrant, collaborative, visual, and tactile. It is a visual way of showing the goal the team is striving toward and the progress they are making. They, each and every member of the team, are peers.

They own the goal. It's a team effort. They gather around the board to align themselves with each other, to honor each others' contribution to the effort, and to course-correct when they are missing the mark. They argue, discuss, share, learn, continually improve, celebrate, boost each other up, and create solutions.

There is another thing that scrum does for the team: it creates transparency. Since scrum depends on collaboration and continual forward progress, problems are addressed by the team as they crop up instead of dealing with them later or covering the problem under a layer of "spin".

A structured, militant environment will never create a team. A team works together toward a shared goal. A group works together toward a goal given to them. Scrum is messy, and noisy. It lives, it breathes, it stretches, it morphs and it expands. Interaction is the heart of the team. The heart of scrum, is the team.

Friday, December 04, 2009

How do we want to make games?

Being a full-time Scrum trainer and agile blabber-mouth has been an interesting experience. I'm between two worlds. I'm not really a game developer any more and I don't want to be a "methodologist" and climb some ivory tower to talk about project management theory all the time. I want to add the most value where I can helping make great products. Right now, this is the best way for me to do that. One value I try to add is by helping "great teams" exist.

Over the course of 20 years I have been a part of several great teams. But the time spent on these teams has accounted for less than 10% of it all. Being a part of a great team was an amazing experience. On such a team, we couldn't spend enough time working on the game or thinking about it when we were away. We were completely absorbed. We all shared a common vision and produced something fantastic and successful. Our passion and productivity made it more than just "work" and it was always a sad occasion when a game shipped and we were all "reallocated" to different projects. We knew something special was going away. I've always sought ways to return to this state of being part of a great team or finding ways to help them exist.

Making great games, being highly productive and absorbed in the enjoyment of it all. Isn't this how we want to be making games? Isn't this the environment that every studio should focus on creating?

What prevents great teams from existing?
  • Goals we don't believe in.
  • Lack of visibility or ownership in what we do.
  • We don't feel like we are a part of something great or adding much of value.
  • Working with groups of people that are not really "teams".
  • A bad physical environment.
  • Spending a great deal of time doing "other stuff" that don't add directly to the value of the game.
There are many more. It would seem that great teams are easy to prevent.

Great teams are not about "methodology" or "process". Some of the great teams I've been on were in waterfall environments. However, methodology can work against great teams. For example, overzealous "resource management" can prevent them from forming long enough to be great.

It's not about culture either. I've seen these teams form in some of the most dysfunctional cultures you could imagine. Culture can also support or work against great teams, but it doesn't determine them.

Great teams have more to do with the right place, the right time, the right people and surfing the edge of chaos. There are many books about great teams. I've read quite a few. They build on the list of things to help create fertile ground and to support them, but there is no science or method. Great teams are complex, like many things in nature. They are like flocks of birds that form amazing patterns, a perfect ocean swell to surf on, or the bumper crop of huge vegetables that grows from your garden every few years.

All of us who think about being part of great teams or try to find ways to allow more of them to form can't act like mechanics or scientists plugging in inputs. We have to think like gardeners. We do our bit to create the right conditions (trimming, weeding, fertilizing, watering, etc), but it's largely outside of our control that the garden will be great. We have far more control to do damage. It require subtle control to help. But full control? It's an illusion.

Nothing worthwhile is easy it seems, but that's what keeps things interesting!