Scrum Breakfast

How big should your team be? It depends on what your goal is. In my classes, I have been showing the relationship between project size, cost and calendar time forever, based on research I had read, but could no longer find. Well, I think I have found the source, a 2005 paper from Team Size can be the Key to a Successful Software Project.

How big should your team be? Well it depends on what your most important goal is:
If you are trying to keep costs down, a team size of 3 people or less is optimal.If you are trying to get a result as quickly as possible, a team size of 5 to 7 people is optimal.If you are trying to hit a budget or deadline as accurately as possible, again a team size of 5 to 7 people is optimal.If you are trying to burn a large budget, team sizes of 9 and up are best. These effects appear to be exponential. Is item 4 really a goal? Nevermind. Silly question.
I think this data explains the Guidewire approach of keeping teams between 3 and 6 people. In effect, this has th…

I am often asked questions like, "What do I do in Scrum when my team is spread across three locations?" My answer is usually something like, "you will suck." "Don't tell me that! That's insulting! I have to do that." At this point, I smile to myself and think, "that may be true, but you will still suck."

Why do I have conversations like this?

Last week, a got a question about electronic task boards. I could smell another one of these 'yes, but' discussion starting, so I chose to answer the question with a question: Why are you doing Scrum? I drew this picture on a flip chart and invited the participants to put dots on the location corresponding to their (organization's) goals:


Most dots were to the left of middle, the low performance choice, which explains why people did not like the high performance answer.

Scrum is based on the patterns of the 95th percentile of project performance, i.e. those awesome teams that are 3 to 10…

Pearl Zhu just posted an interesting question on the Stoos linkedin group. "What is the agile way to adopt agile?" Her answer did not resonate much with me, so I'd like to share how I start a company down the agile path.

Agile is about people, both the people doing the work ("People and Interactions over Process and Tools") and the beneficiaries of the work ("Our highest priority is to satisfy the customer through early and continuous delivery...."). I believe people's own experience makes the most convincing arguments.

So I start by asking the people involved what has worked for them in the past. I ask them to remember their best projects and share the stories of those projects with other people in the room. (See Remembering Heaven for a description of how I do it). After hearing everyone's best projects and identifying the most promising role models for moving forward, we reflect on the patterns that made those projects successful.

Most peop…