Scrum teams and our Mammalian nature

My experience with people doing Scrum is that we tend to take the "man is rational and isolated" hypothesis to easily.  Often it is not a thoughtful choice, just the implicit assumption of the way we are thinking or the way we speak.

Isolated and individualistic are key words. If you believed in them, you would build cube farms for people to work in. For example.

Is there another hypothesis? Turns our there might be several, but one is that humans are fundamentally like all 'pack' mammals.  We work and have worked, over thousands of years, in small teams, and these teams support the members inside the team.  We have a limbic brain or limbic system that supports the huge emotional and 'social processing' needs of pack living.

Here is an article on the limbic system.
http://en.wikipedia.org/wiki/Limbic_system
(As you will start to see, the spiritual, physical and thought-memory processing aspects of the brain are quite complex, largely sub-conscious, and quite fascinating. And there is much for us still to learn, IMO.)

How does Scrum inter-operate with this? 

Well, first Scrum seems implicitly to recognize the pack or mammalian nature of people, and organizes individuals into teams.  (Our mammalian natures may be one of the reasons for this, but certainly not the only reason.)

Scrum implicitly seems to understand that the team starts to be a source of well-being and of motivation for the individual. While the team demands something of the individual, it also supports him (eg. "can I help you with that?").   The team provides this 'pack' sense of belonging.  That they say we all need. (And I think I believe 'them' on this.)

More than a sense of belonging, it gives us a sense of purpose.  We want the team (pack) to succeed.  And we want to contribute to the team's success.   To the degree that each person identifies with the team, this is a whole set of subconscious associations that each of us tends to make with the team.

Did the designers of Scrum do all of this on purpose?  Well, I have worked with Jeff Sutherland a lot, and I have never heard him put things this way. But he has suggested that there is more going on than can be explained.

And now to you....

Assuming that we as humans are largely pre-rational mammals with a need for a 'pack', in what specific ways would you use this information to make your Scrum team more successful?

Thanks.

More about distributed Scrum - one example

There are so many situations and variations on distributed Scrum.  So that there then becomes so much to say about it.

So, as one example, imagine you have customers in the US, and your business people are in the US, and the best Product Owner is one of these business people.  He is pretty good as a Product Owner.

Imagine that you are doing a major add-on to an existing system.  The add-on can be considered a separate product.  So, knowledge of the existing system is important.  And a quick release of the new product is also important (within 4 months).  Assume that your current implementers are collocated in one city in the US (and could be collocated in one team room).  And assume that you can get people who are 50% cheaper in cost-per-hour (and by resume just as good) within 3 time zones (eg, in Canada or Argentina).  And that the cultural and language issues per se are not an obvious roadblock. And assume for now we are talking about only one Scrum team (about 8 people in total).  This is not a huge project.

What should you do?

Well, first, I can say from experience having worked with a couple of situations like this, that this kind of distributed can work.  Successfully (although to be fair, we did not do a blind trial to compare to an alternative course that might have been more successful).  And your firm does not have to be 'the best' at doing distributed Scrum (although it would of course help).

But nor would I assume, from what I have said so far, that distributed is necessarily the best course. Collocated might still be.

Let's go back a step.  How do you decide?

One question is: how do you define success?

Is it ROI?  Is it lower cost?  Is it productivity per unit of cost?  Is it faster time to market?  Is it less wear-and-tear on management?   Is it reduced risk?  Is it more accuracy in hitting just what the customer wants?  (And there are many others.)

Note: I find that faster time to market is often more important than many people realize.  In this example, I said 4 months.  This allows some time, but not too much, for knowledge transfer from the home people to the near-shore people. So, to me, in this example, it is a key issue, but not determinative by itself.

So, first, in your context, define success.  At least what you think it would be. (It may turn out to be something different later.  Live and learn.)  Look to optimize that success.

Then, do your best to look honestly at your situation (there is always the fog of war, or the fog of business or life).  What things should you do to make it (collocated or distributed) work better?  What specific questions should you ask (of each alternative)?

A couple of suggestions that might be helpful, depending on the situation.

• visit the 'near-shore' team.  Pick specific people.
• assuming you could pick 8 home people, when making the distributed comparison, decide who the 'top 4' would be. How would these people work with the 4 near-shore people?

Note: I have a strong bias that a distributed team should consist of 4 in team room and 4 in another team room.  This minimizes the typical us-them problem, and makes that problem more manageable. The us-them problem (or overcoming it) seems to be the key to real success with distributed.  From my experience and from what I hear from others.

• of course you will look at skill sets. I have already implied that both sets of people have essentially equal skill sets, but of course this may not be true in your specific situation.  In any case, you must look at how the skill sets of the 8 specific people mesh. Sometimes the resumes of the near-shore people are exaggerated. OTOH, sometimes we are surprised to find that the near-shore people are immediately better than our home people on our own systems. (Shocking, but it can be true.) 
• is your 'home' team diverse enough in a useful, knowledge creation way?  Will the near-shore people make the 'home' guys think more creatively?
• will the near-shore folks understand our business and the customers intuitively? (Do they have that tacit knowledge?)  If not, how much would it take for them to get it (more)?  Would that be a good challenge for the 'home' guys, to pass on that knowledge?
• will the Product Owner be able to motivate the near-shore people as effectively as the home people?  And communicate with them well, so that they quickly get the tacit knowledge of what is needed?  And therefore can build it better?
• is the PO willing to travel to the near-shore location? 
• how would the PO get the business value and requirements specifics to the near-shore people?
• how would the PO give the near-shore people daily feedback?
• to the degree there is a time zone difference (and in this example, we assumed that is relatively small), how will this work out practically?  Will one or both sides compromise?  eg, on the timing of the daily stand-up?

I hope these questions did not seem strongly in favor of collocated nor strongly in favor of distributed. One should approach the question, I find, with an open mind that is willing to find either answer as being 'right for this situation, as best we can tell now.'

There are lots and lots of other detailed questions to ask. 

Notice that I did not ask questions (yet) about how all the technical supports for distributed would work (although these are important questions, sometimes hugely important).  And notice that I asked a lot about how the business information, and specially tacit knowledge around the customers, gets into the heads of the near-shore people.  (Not that we can't also have a problem with that with our home people too.)

I also want to emphasize the knowledge creation dimension of the team.  Sometimes the near-shore people can add to that tremendously.  Sometimes they can seriously harm the knowledge creation.  It depends on the specific people, to a large degree.  As best I can figure out.

Enough for now.  Hope those ideas stimulated your thinking on the subject.

And hope you see (again) that 'distributed' is a very very big subject.

3 Drivers of productivity with Scrum

One question is: "How important is Scrum anyway?  I mean, it is always the team that does the work, whether they use Scrum or not."

And this is true. But I do think most teams (if not all) that use Scrum give themselves a big advantage.  They are more likely to be more successful if they use Scrum.  And if they will fail, that failure is more likely to be identified sooner. Which is actually a win!

OK, so what are the 3 drivers of productivity in Scrum?

Well, I want to focus on some not-so-obvious things.  Not the explicit dance steps of Scrum, but other things.

1. Creativity.  The team can and should be more creative than before.  Well, we all can always be more creative.  And one thinks that the Scrum team enables more creativity.  In every meaningful dimension relevant to their specific situation.

2. Velocity.  By removing impediments, the team can increase their velocity, as measured by story points completed per Sprint.

3. "The vital few."  By selecting the very least amount of work (features) to do (that still make up a minimum marketable feature set), we can get it done more quickly, not bore them with features they care little about, and make the system more elegant and easier to maintain and grow.  This can lead to much much greater productivity.

It may be easier to talk of these three things as completely separate. But, just as it is amusing to speak of body and soul as separate entities, it is more fun to live them as joint and inseparable entities.