Tuesday, October 28, 2008

Discount for Scrum Master Class

I've received some feedback from readers that my Certified Scrum Master class for video game developers after the Montreal Game Summit November 20-21 is a bit too expensive for people who are not members of the Alliance numérique.

I agree and after speaking with the Alliance, they are allowing me to refer attendees to the course at the Alliance numérique membership rate. If you would like to attend at this price, please send me your name, phone number and email address where you can be reached.

Wednesday, October 22, 2008

Reminder: Certified Scrum Master for Video Game Developers course in Montreal

Just wanted to send out a reminder of the course I'll be giving after the Montreal Game Summit. The two day course will take place on November 20-21.

The last one sold out and we're half-way there on this one. Details at:

Deadline for enrollment is November 1st!

Tuesday, October 21, 2008

Scrum is not for everyone

Some adoptions of Scrum won’t be too effective or simply fail at the studio or individual level. Conditions at a studio might not be at the right place to adopt Scrum. Some teams won’t take ownership of their work. Some leaders want to micromanage within a Sprint. Some team members refuse to participate in any team activity (such as a daily Scrum).

Many times adoption failure happens because studios don’t want to face the cost that fundamentally changing their culture might be. For example, there is a level of employee turnover that can occur adopting Scrum. Studios can expect to lose an average of 5% of their people when they adopt Scrum. More if they have a strong “command and control” culture. Some of these people will be valuable. They will leave because they don’t believe in the Scrum vision.

There are many reasons why people might leave or be let go. Let’s take a look at one common occurance.

Occasionally, the teams will “self organize people off the team”. This occurs between Sprints when teams are allowed to change their membership. Poor performers or poor team players can be “voted off the island” by the rest of the team. Some may view this as a potential HR nightmare, but it is necessary to allow teams to truly take ownership and make a commitment to their work. It can also be valuable for the person being ejected from the team. In most cases I have seen, this event is a true “wake up call” for the person told to leave the team. Usually this person has ignored years of management feedback about their poor performance or teamwork. However being ejected from a team cannot be ignored. It is a strong statement from a group of your peers.

At this point, another team has to be found that is willing to have this person join. They have to be made aware of the issues that led to their ejection from the last team. Teams cannot be forced to accept people they don’t want. The reason for this is you can’t expect a team to take full ownership and commitment in their work if they don’t have control over their own membership.

45% of time this person corrects the issues and becomes a valuable member of another team. Another 45% of the time, they find a team where the chemistry is better (you can’t ignore the fact that team chemistry is important). The remaining 10% of the time they move to another team which then has to eventually ask them to leave again. After a few ejections, it’s common to find that no other team will accept this person on their team. It becomes management’s duty to let this person go from the company. Sometimes the person gets the message and leaves on their own accord before this happens.

I’ve only seen this happen a few times. It’s unfortunate, but it makes a statement to the teams; they control their destiny. They are responsible and have the necessary authority to make changes to improve their performance. Failing to create these conditions for a team can lead to valid excuses not to achieve their potential. “We’re stuck with so-and-so and have to live with it” is a common refrain by teams that can’t self organize. They feel helpless to effect the change they need and therefore can’t achieve a high level of commitment.

When you see the performance of teams that achieve their potential you stop questioning the value of these practices. It does take a leap of faith to allow these practices into your studio. Sadly, some don’t take this leap and don’t realize the potential of hyper-productive teams.

Friday, October 10, 2008

Agile is not a "fad"

I've long become used to agile being referred to as "the next new management fad" or something similar. I don't agree with that assessment. When you focus on project management for a good portion of your working hours, you become familiar with the history of project management methodologies. You start to see it as a continuous evolution in the theory and understanding of how people work together. Agile practices have their roots that go back before the second world war.

However, when I hear someone who is credentialed by the "Project Management Institute" say this it makes me wonder. Don't they teach about the last century of management change? All practices have their roots somewhere. Current practices are just a snapshot in time.

The History

Before the 20th century, products were largely created by craftspeople. Things like carriages were made by hand, assembled out of parts that were not too interchangeable. This all started to change in the early 20th century with the assembly line and "Scientific management" (or "Taylorism"). I wrote about this a month ago:

Back in the early days of mass-production, when companies like Ford were discovering the efficiencies of assembly lines, the theories of Fred Taylor were being applied in factories. These theories were based on the idea that complex jobs, such as assembling a Model-T car, could be performed by relatively unskilled and cheap labor if each step in the assembly line was broken down to a simple job that could be standardized. Workers were considered to be interchangeable cogs in a large machine.

Though “Taylorism” has been discredited, many management practices are still based on the idea that as long as a well defined process and set of tools exist, then the work that can be done by a group of people can be predicted and defined up front. Workers are considered “fungible” or replaceable and anonymous on a large project plan that attempts to predict what each part of the whole will take a worker to complete. Managers find comfort in this. As long as people and hours are are interchangeable, then we can play with the amounts of each to achieve predictability.

Taylorism had been largely discredited before and during World War 2 by people like W Edwards Deming who taught that project management needs to facilitate workers to bring their thinking and passion to their job and focus on the whole system, not just their one part. Deming proved his work in the US during the wartime manufacturing expansion. Unfortunately many of these principles were abandoned in the US after the war. Deming found himself in high demand in Japan however and spent time there teaching these principles to Japanese industry after the war.

For the next three decades, much of the innovation in project management came from Japan and the results show the proof. Agile has it's roots in the practices developed at Toyota, Honda, Canon and other successful Japanese companies. Western companies such as Boeing, Ford and Volvo are still catching up with many of these practices (such as Lean production methodologies).

Software development in the west has been at the leading edge of applying these lessons to their products. One of the roots of Scrum is from a paper written by two Japanese business researchers in 1986. XP was built on Scrum practices as well.

Methodology dejour

Sure, there are a numbers of flavors of agile out there. Each week it seems as though someone else is branding their own methodology or misusing the term agile. Some of these are even more fleeting than fads.

In many cases some managers call agile a fad as a way to brush off the challenges of changing their mindset about how people best work together and what their role is in a knowledge focused organization. Perhaps they still think it would be better to manage 100 creative people through a Microsoft Project Server database from their desk.

Alternatively, don't just drink the Kool-aid and bet your company on agile. Step 1 is to learn more. This book is a great start.

Wednesday, October 01, 2008

The role of tools in agile planning

The value of tools
I had a great discussion this morning with the CEO of a company which makes a production management tool that supports agile methods. We discussed the issues of tool use on agile teams and the opportunities for providing tools that don't yet exist.

I am not a big fan of tools that help automate sprint backlog management. Management of the sprint backlog (tasks that the team estimates and updates to achieve their sprint goals) is best left to the team. Any tool that takes any of that ownership away from them is going to harm the team's ability to commit to their sprint goals and take control of improving their effectiveness. Sure, it might save the Scrum Master five minutes a day in producing a burn down chart, but the Scrum Master's role is to facilitate the team to become self managing and commitment driven. Sprints are about adding value and commitment, not about perfect task tracking.

On the other hand, tools for backlog management are very valuable. Product backlogs are living complex plans for the product and must be frequently updated by the product owner to remain relevant. Tools can help.

So what do we look for with tools?'
First and foremost, a tool used to support an agile team must be built with the agile manifesto in mind. The first value applies in full:
Individuals and interactions over processes and tools.

While we value processes and tools, we value individuals and interactions more. Are these at odds? No. Processes and tools can support individuals and interactions. Certainly any process built using Scrum properly supports individuals and interactions. What can tools do to support them?

Let's take mind mapping tools for example. Teams have built and managed entire product backlogs using these tools. Mind maps allow a hierarchical structure to be built and viewesdwithout losing sight of the whole. Teams can form around entire branches of features (e.g. online multiplayer team). Some of these tools allow nodes in the map (user stories) to be prioritized and estimated. During release planning meetings, having the mind map displayed on a projector or large printed format can focus the meeting. It contributes to collaborative meetings where everyone contributes. If you want to have some fun brainstorming a backlog, provide the team with a very large sheet of paper and half a dozen colored Sharpies and have them create a mind map right there.

Compare using Excel spreadsheets to manage the product backlog or release planning, which is common. Hierarchies are not clearly seen in the column-row format of a spreadsheet. It's easy to get lost in the details and forget the big picture. Although I love using Excel for numerous functions, when someone displays a product backlog spreadsheet on the wall, the room usually becomes quiet.

Mike Cohn has suggested another way to visualize a large product backlog. I'd love to have a tool that supports this view!

So how can tools contribute to the value of "individuals and interactions"?
  • Mix global and local views together. Have a view of the data (backlog, plan, etc) that can be zoomed in and out rather than page-flipped. Page flipping a view probably sheds 50% of the context for people in the meeting unless they never blink.
  • Focus on tools that capture collaboratively driven knowledge rather than isolated data entry. For example, have a tool that projects the release plan, one story at a time, and prompts for the story point estimates during a poker planning session. Don't create a poker planning tool that allows everyone to estimate from their desk. The design discussion during poker planning is the point of the exercise!
  • Information radiators are solid gold (burndown charts, unit test coverage, build stability, release plan, etc). Tools should print them out whenever possible and support large format printers.
Distributed teams can't avoid some of the problems with their reliance on tools. The fact is that distributed teams have a harder time achieving the same velocity as co-located teams.

The good news is that the tool makers are listening. New versions of tools are being developed (some even using the agile process) to better support the needs of agile teams.