Search

Wednesday, October 10, 2007

Daily Common Sense

Complacency is the enemy of product development, but it's in our nature to seek it in our lives and our work. This is reflected in the processes we traditionally use to make things:
  • Document everything out up front so we don't have to worry so much about it later.
  • Schedule out all the work that needs to be done to insure that we know what the cost, schedule and scope is.
  • Implement process rules. If the rules are followed, everything will work out.
Agile addresses the first two clearly, but it is a danger with many agile adoptions to get too complacent about the practices. It's a natural law that complex things decay. Processes, machines and organizations break down all on their own. If there isn't constant attention paid to this, then things can get real bad.
















One of my favorite Ken Schwaber phrases is "Scrum is about making things visible so you can make common sense decisions". We often view processes as doing more for us, maybe solving our problems. This certainly isn't the case with agile.

Examples of the practices being 'practiced', but something is wrong:
  • We might be meeting everyday, but if there are no impediments being reported and the build is broken.
  • The builds are stable, the Sprints are all successful, but the game is not fun.
  • We're pair programming and writing unit tests, but the continuous integration server is showing errors half the time.
The list can go on. The main question is how do we build a culture where improvement is the consequence of visible problems everywhere in the organization?

4 comments:

Paul said...

Hi Clinton,

At least one game developer I have worked for used critical stage analysis. Simply put it's a post mortem for a stage of development. Scrum practitioners could perform one after each sprint for example. When things were going well it seemed like a pointless exercise and after a while they stopped doing it. But I was surprised by how quickly things degraded when they did, so I badgered them until they got it going again. If you want to get your whole team focussed on process improvement, CSA is a good way to do it.

Clinton Keith said...

Hi Paul,

Perfect example of "fix and forget" Retrospectives don't even have to be canceled to stop working. All that needs to happen is to stop thinking about the reasons for why the team needs the retrospectives and go through the motions of having them.

As you know, it's really a shift of attitude than practices.

Paul.J said...

Hello Clinton,

We're in the process of applying Scrum in MMO game development.
I'm worried about "but the game is not fun." part. because of the practices we're doing in our studio, everyone(mostly engineers) is happy how Agile method is helping our project. However, pessimistic about game designs being incremented. Is it too much?

Clinton Keith said...

Hi Paul,

I hear that. In fact I wrote about it earlier in the year:
http://www.agilegamedevelopment.com/2007/06/ugly-child-syndrome.html

The key is to not relying on the team to be the only customer for "fun". Good luck!