New conference

Waterfall2006.

Enjoy.

Scrum Master Tip

With all recent CSM grads and visit from Mike Cohn, we're making a lot of tweaks to the process. One great tip came from Mike (based on a question from a new Scrum Master):

People on a team will get into the habit of answering the three Daily Scrum questions by addressing the Scrum Master directly. This reinforces the "Scrum Master is the Lead" mind-set, which is not what you want. Each team member is addressing the team as a whole, making a commitment to them.

The tip is for the SM to avoid eye contact. Look at the ground, at the task board, etc. This forces the speaker to address others in the team.

Works like a charm!

Certified Scrum Master Training

We sent nine people to CSM training last week. I can't recommend it enough. They see the light. The one practice I'd suggest is to get them together in a room and talk about what they learned and reflect on how the company is using Scrum. There's not "one way" to do Scrum. You are encouraged to change the practice as you use it to fit your environment. It is useful to "follow the rules" at the beginning to learn the reasons for Agile let team ownership soak into the culture.

However new CSM grads can be a bit fanatical. Talk it through before they hit the team!

Retrospectives

We've started doing retrospectives (I'm tired of hearing the gasps when I tell experienced CSMs that we weren't doing them).

Whare are retrospectives? It's a team meeting that takes place after a Sprint review. The team gets together and answers the following questions:

1. What should we start doing?
2. What should we stop doing
3. What should we continue doing?

The team reflects on their practices and things which affect their team. They pick a number of things to start and stop to work on over the next sprint. These things show up as "continue" items (along with other good practices) at the next retrospective.

This meeting should be time-boxed to 30 minutes. Since we were doing our first (with our consultant Mike Cohn in attendance) we took more time. A LOT of interesting stuff came out of it!

Evolution of Scrum Teams

In adopting Scrum, we've gone through a number of evolutions of the makeup and backlog of Scrum teams:

- Functional Teams
Teams that are mostly programmers, artists or designers. This rose due to the early adoption of Scrum by the programmers. Art and design participated, but still worked from a schedule (especially in the last year of Darkwatch).

- Feature Teams
Teams that focused on a feature (such as AI, animation, levels, etc). These teams didn't change much, but started to look like mini-teams that were more self-contained. The problem with them is that you get uneven production of features and delayed integration (e.g. AI in levels with good animation).

- Subgame Teams
I'm tempted to call these "demo teams", but many times "demo" implies shortcuts that you wouldn't ship. These teams produce completed portions of the game in releases that you could use for magazine demos. Usually each subgame has 2-4 teams working on it. The goal is to have a version of the subgame every 1-3 sprints (with separate teams showing their work at reviews otherwise).

This evolution leads to teams that show true product value more frequently.

Scrum FAQ at Conchango

Conchango has been doing some great work with Ken Schwaber on creating online resources for Scrum. They've created a great website to introduce Scrum (with video clips by Ken). They've just released a great Scrum FAQ. This is a must see site for developers new to Scrum.

High Moon Acquired by VUG!

Great news! Why?

- VUG has been very enthusiastic about Scrum. Other VUG developers have started using it.
- Their product vision is great. Can't talk about the work we are doing with them, but it's very exciting.

We have a very talented group of people at HMS, super culture and a great facility to grow into and I'd like to think that continuous high value delivered every Sprint was a selling point as well.