Wednesday, December 31, 2014

How many people do you need in your team?

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:
  1. If you are trying to keep costs down, a team size of 3 people or less is optimal.
  2. If you are trying to get a result as quickly as possible, a team size of 5 to 7 people is optimal.
  3. 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.
  4. 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 them cycling between lowest cost and fastest delivery, which is probably a sweet spot to find yourself in.

OTOH - This study is largely based on waterfall projects. Does anyone have the data to create a similar study of agile projects?

Friday, December 19, 2014

Why are you doing Scrum?

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 times more effective than average. Those patterns are probably the same patterns as you experienced in your own best projects!

So why are you doing Scrum?

Saturday, December 13, 2014

What is the Agile Way to Adopt Agile?

 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 people are not currently working on their best project ever. In fact, usually only about 10% of the people in the room are currently working on a great project. Very often no one at all is currently working on their best project ever. (I have seen numbers as high as 50%, but the difference between 10% and the higher score has always been a group doing Scrum!)

Would you like to be working now on your best project ever? Most people would! Could you agree to implement the patterns which made your best projects so awesome? Most people are willing to do that.

Wait! What exactly have we agreed to? Well at this point, I start to introduce Scrum (my favorite place to start), not as a set a of roles and processes, but rather as a small set of patterns. These patterns are easy to recognize in people's own successful projects. What patterns do we find?
  • Deliver something that works regularly
  • Inspect and Adapt regularly
  • A small interdisciplinary team solves the problem
  • Once voice speaks for the customer / user / stakeholders
  • Management guides and helps, and knows when to stay out of the way
  • High performance is achieved through continuous improvement 
So now agreeing to do Scrum is quite easy, and we can start without any significant resistance. Why? People recognize Scrum as a place they want to be, because it is a place they have already visited and liked: A great project where work is fun.