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.

I was asked today for my main suggestions for getting better at distributed Scrum.

Advice 1. Make a fair comparison between distributed and collocated in your specific situation.
a. Cost per hour, usually lower.
b. Hours of “distributed” members, usually more.
c. Hours for “local” members, usually more.
d. Net effect on delivery time, usually delayed.
Then, calculate the net net effect.  Does it still make sense to be distributed?  Often yes, and also often no.

Our opinion is that the main focus for the team should be on creating new knowledge. So, the old idea that we always find the people with the best existing knowledge is flawed. Creating knowledge is best done collocated.

So, here are some more ideas.

First, I find that collocated Scrum is always better.  Xebia has an argument that the way they do distributed Scrum is even better than collocated Scrum.  Maybe, but I do not think their hypothesis has been given a fair test. (This is a big subject; not the main topic here.)

Second, there are many types of distributed Scrum.  Some examples.
a. Distributed in the same city.
b. Distributed in only two team rooms, each in a different city, the cities not more than 2 time zones apart.
c. Dispersed across a continent (eg, the US), no two people in the same building, across 3 time zones.
d. Distributed in only two team rooms, each in a different city, the cities about 6 time zones apart.
e. Distributed in only two team rooms, each in a different city, the cities about 10-12 time zones apart.

There are some similarities across these situations, but they each are pretty different.  And might require different key components to the solution.

We have not mentioned yet cultural, language, and accent issues.  We have not mentioned organizational issues (eg, different firms, departments or reporting lines). 

1. Communication will be harder in many ways.

We know in our business (new product development) successful communication is very hard. And that’s when they are collocated. Any kind of distance makes this worse.  So, we do everything we can think of to make it better. 

2. The team needs to Form, Storm, Norm and then Perform.

This is harder when they are not collocated.
Often they can get stuck in “high frustration.”

3. The team needs to share information.

This is related to communication, but different.  Here we are talking about things like sharing documents, sharing diagrams, sharing code, etc, etc.

Advice 2: get your team to compare your current situation to a collocated situation.  What is the worst thing about it, as you all compare?  Work on that one big impediment.

There is ALWAYS something more that needs to be improved.  And usually that something will be a weakness arising from being distributed.

Ok, now I get to a series of suggestions, not all of which will apply to your specific situation.

Suggestion 1. In the beginning, get the Team collocated as much as possible. Ideally for release planning and the several initial sprints.   Many reasons, but probably the main one is they get to really know each other.  Very important.

Suggestion 2. Get them together more often than you currently can imagine. If in the same city, one day per week (or more).  If in two continents, a week each month (or as often as you can get).

Suggestion 3. Minimize the dispersion.  Two team rooms, each with 4 people is best.  Try hard to get the 4 to collocate in a team room.

Suggestion 4. Have frequent visits. Have one person from Bangalore visit the US. Then wait a week, and have a person from the US visit Bangalore. Do this more than you can currently imagine.

Suggestion 5. Spend money on really good tooling. This means: Scrum tool, great video conferencing, fancy Polycomm phones, leaving the Polycomm on during the day for impromptu conversations, high bandwidth between locations, fancy tools to emulate white-boarding or common editing of documents, common storage areas (eg, wiki or Sharepoint) that work really well. Plenty of throughput on the servers, plenty of server space.

Some teams may be into virtual presence things. Try them. If they work for your team, use them.

Suggestion 6. One of the key issues is: do they all ‘feel’ as though they are one team?  Or is there an us/them feeling?  (We want the former, and it seems to be key, almost always.)  If not ‘one team’, make that issue visible, acknowledge it as a normal problem, and then work on it.  (See some of the other suggestions, but there are also other solutions.)

Suggestion 7.  Culture. I find that cultural issues and misunderstanding go down when people start to know each other personally. So, first, do that. (See Suggestion 1.) But, depending on the people, there can still be ‘cultural issues’.  Even within the US, for example, but certainly between two countries or two languages or two cultures (eg, east Germans and west Germans).  Get everyone some cultural education, courses, etc. Acknowledge that it is a common problem. And take the time to deal with it.

Now some more specific issues…

Issue 1. Where should the PO be?  No strong opinion. Where the best PO is.  Near the customers and near the team. With one of the two ‘pods’ of 4 people (half the team).  It depends on many factors.

Issue 2. Where should the SM be?  Again, no strong opinion. Where the best SM is. With one of the two pods. Ideally visiting both (or all) sites with some frequency.  Again, it depends on many factors.

Issue 3. When should the Daily Standup be?  Usually in the morning of one team, typically the “later” team.  If necessary, both teams should compromise some on the timing.

Issue 4. Language, accent issues in the Daily Scrum. This is a fairly common problem. Often the “early” people (if they exist) can write their answers to the three questions and send that to the “late” team.  And the discussion is more about clarifying and fixing things, than about the answer per se.  Of course, the better solution is to fix the problem at its source: improve the Polycomm or equivalent or send them to a language course.

Many other issues and ideas, but those suggestions should keep you busy for awhile.

Note: We have not yet considered scaling with distributed teams. This can be done.  With some success.  It is hard, it is ugly, but it can still be successful. We can say that Scrum will enable you to see the ugliest thing today, which does help you fix it.

One can go many places with this question, and there could be other questions within this questions.

For now, let me answer two questions.


1. In general the culture and the management systems (eg, metrics) is used to waterfall.  With a Scrum team(s), what should we do about this?


The finding is that this will remain a small-ish and firm and increasingly annoying impediment until you fix it.  


Fixing it entails, ultimately, changing the whole company culture in a pretty significant way. Which, for a large company, takes a long time.  Sometimes, you can select out a major group within the larger company, and just change that culture.


Doing this is hard work and takes time.  It must be balanced against fixing more immediate and pressing impediments now.


How to do it?  


Gather a small group of change agents. Regularly.  Identify the changes you want to put into effect…how you want to go about changing the culture, at least in some ways.


Fearless Change by Manns & Rising and A Sense of Urgency by Kotter are two places to get ideas about how to effect the change.


For metrics, I would initially get the Scrum teams exempted as pilot efforts.  Then I would suggest that the basic Scrum metrics (velocity, Sprint burndown, Release burndown, etc, etc) be used in place of the old metrics.  You will win some of these discussions and lose others. Typically, this means the team must do “extra” metrics, typically for no good reason except that “they are there.”  Make clear the extra cost to the team in doing the extra metrics.  Over time, you will likely win more and more of these discussions as people become less afraid of the Scrum teams.


2. A Scrum team must work with other groups that are used to waterfall.  What should we do about this?


The main advice is: use common sense and do just barely enough to make it work.


In general, different people will react differently to an agile-scrum team.  So, your response will depend in part on how the other people react and perform.


In simple terms, there are two situations: 
(a) they provide deliverables to the Scrum team, which affects what we can deliver or complete.
(b) we provide deliverables to them (which affects them and our reputation).


First, prioritize the groups the Scrum team is working with.  Put the most ‘work’ in on the team that is most important (obvious as soon as I say it).


Second, are there any personal relationships we can leverage, such as, Team Member John is a friend of George (who is in Dept 1)?  

Often, John can visit George, and discuss agile-scrum a bit. (And maybe take the time to discuss Scrum over lunch with George’s manager too.)  This reassures George.

Then John should ask George “I know this Scrum stuff sounds a bit weird and is certainly different than what you are used to, but can you help us out?”  And often George will do it, especially if we/John make things a bit easier for George. (“I’ll scratch your back, if you scratch mine.”)  It’s all part of the unofficial ‘pizza & beer network’ that many of you know well.


Sometimes this is enough.


Third, let’s imagine that George’s boss hears that George is “being easy” on the Scrum team and orders him to “be tough, demand that those guys fill out all the usual waterfall forms each time! And abide strictly by the rules!”.  And let’s assume we know that this is a silly bureaucratic waste (mostly).


The next step is to have a high-level “Impediment Removal Team” (IRT) that hears about all the top impediments from all the Scrum teams.  Assuming this impediment (George’s boss) is important and we are sure we are right to complain, then the Scrum team sends this impediment to the IRT.  A person from the IRT (a senior level person) goes to talk sense to George’s boss. If done right, surprisingly George becomes more cooperative with our Scrum team in a few days.


Sometimes this is enough.


Sometimes the problem is not George’s boss, but only that George has 15 things in the air, and we are not that important to him, so his performance for our team is not reliable.  In that case, we can set up a special board (in the team room or virtual team room) and John or someone else in the Scrum team can ‘manage’ George, eg, visit him often, send him ticklers, go to his boss, help George fix his own impediments, etc, etc. 


Sometimes George is so key to the Scrum team for a Sprint or two, that we have him come to the Daily Scrum every day to report on his progress.  Sometimes we have somewhat formal ‘weekly’ meetings with George.


The main thing is: we add to ‘Scrum’ just enough other stuff to make things work with George and Dept 1.  We try to ignore or minimize the stupid stuff as much as possible, and get as much value from Dept 1 with as little effort as possible.  Sometimes we just accept some degree of ‘stupid stuff’ from Dept 1 for a while….but only for a while.


Again, each department or group will be different. Some of things we do for Dept 1 might be overkill for Dept 2.  So, we adjust our response for each department and each “George”.  Based on our team’s need and who they are.  So, the way we work with Dept 3 will be different than how we worked with both Dept 1 and Dept 2.


Sometimes a ‘serious’ issue comes up.  Be ready to explain Scrum, explain how it is less risky than other approaches, and why it does not need to comply (completely) with the usual BS bureaucratic stuff that we have always been doing.  But learn to say this in a nice, non-confrontational way.  That sounds (and is) supportive of the main business drivers in your firm (“we have to have faster time to market”, “we must reduce costs”, or others).  But be reasonable.  Bend ‘em but don’t break ‘em.  Remember that changing organizations takes time, and much of it is based on goodwill.  So, increase your capital of goodwill and spend it judiciously.  


Changing an organization takes time.  Keep plugging, but have reasonable expectations.  You don’t have to win every battle in the first minute.  Be adaptive.

• Why do we care about velocity?

To be honest, higher velocity is less important than better focus on business value. Higher velocity going the wrong direction does not help at all, and usually hurts. We always need more clarity on: (a) what the customer will really want (when we deliver), and (b) how focus on only the ‘vital few’ things (eg, for the next release).  These two things are more important than higher velocity (in all real life situations that I see). (A nod to Ron Jeffries for forcing me to say this.)

But, if we assume that the Product Owner is taking us in the right direction (having us build high business value items) and on the MMFS (minimum marketable feature set), then higher velocity is better.

And, when we remove impediments, one of our key reasons for doing so is higher velocity.  Yes, we want more fun, we want more creativity (which does not always result in higher velocity per se), we want higher quality, we want less technical debt (which should come out as higher velocity eventually), etc.  Still, I assume the other things, and so higher velocity is the key thing.

• Higher velocity is just another way for managers to screw the team members

Well, I completely reject this way of thinking.

Not that it doesn’t happen.  It does.  But no self-respecting manager should think this way.  About teams doing knowledge creation work. 

If as a manager you have an important project, and you think the only way to be more productive is to work harder (higher stress) and longer hours, then, based on over 20+ years of experience, I think you either have a bad team or you are a bad manager.

Higher velocity never means working harder (well, more than 40 hours per week). Often it means working fewer hours.

Velocity should never be used to drive the team into a death march.

The team should use velocity to protect themselves from what I call “the magical thinking managers”, which just stamp their foot in demanding ‘higher productivity’. Stamping of feet and slogans are useless. In overly-simple terms, we must remove impediments.

• For the A3, it is difficult to estimate the velocity impact of fixing an impediment

Yes, “to predict is difficult, particularly of the future”.  This is true, and always will be true. Nonetheless, we must.

An predicting things related to human behavior is hard. Predicting things related to multiple variables is hard, but always required in business (or so I find). There are timing issues related to prediction (when will the benefits start to show).

My recommendation is to under-estimate the velocity impact to some degree. And to explain the issues of prediction to the manager. A decent manager understands these issues. A decent manager does not expect the team to be accurate in predicting each team. A decent manager expects the team, over a series of A3′s, to achieve somewhat more results than they predict on average.

Remember that we only have to predict enough improvement to justify the cost of investing in the fix.  Again, I find that we can under-estimate the velocity improvement and still easily justify the cost of the fix.  Usually.

Remember that the main reason to spend time or money in fixing an impediment is the benefit, and the main benefit is improved velocity. At least to a manager.

• For some impediment fixes, the main benefit is not velocity improvement

Fine. True. Give velocity improvement its proper place. If it is third, then list it third.

However, it is my experience that velocity improvement is more important a factor than most team’s think. Largely because most teams are not used to thinking about velocity.

• We can only make minor improvements in velocity

 This is baloney!  “We can’t possibly go any faster, captain!” (In a Scottish accent.)  Baloney!

This is the major problem, I find.  This belief that we as a team are almost perfect.  It is, of course, usually expressed in the negative of “we can hardly go any faster.”  Everyone recognizes the idiocy of saying “we are perfect”, but to suggest we are close to reaching some upper threshold of productivity sounds reasonable.  I mean, we are all smart people around here, right? And we run a professional IT shop, right?  And we are a strong team, right?  And we have all the right tools to run Agile, right?

To be honest, there is so much improvement to be made, it is unbelievable!  To be honest, “it’s not what you don’t know, it’s what you know that ain’t so.”  We are smart, but some of our smarts are unbelievably dumb!  And all the rest of those assumptions above (and others) leave even more room for improvement.

Now, it is true that the team is working hard already, probably already too many hours. And so “being more productive” feels like a request for more hours.  And a request for more hours is wrong! I won’t try to explain here why it is wrong.  But it is wrong! Wrong!

But that does not lead, logically or any other way, to the notion of “we can hardly go any faster”.

Usually we can easily go twice as fast in the next 6 months. If…  And the main “if” is (I think)….if we will open our minds to identifying some of the real impediments around here. But, to be honest, there are many “if’s”.

• If we go faster, we’ll get into more technical debt

Wait a minute!  When I usually hear this, it tells me that the team has a weak definition of done (which maybe it does not follow for much, really). And it is, in effect, pretending to have a certain velocity, but is is really just lying to itself.

It is like saying “I ran a mile at sustainable pace”, but in fact it was 8/10′s of a mile and you are just about dead.

A real velocity should accumulate zero (well, almost zero) technical debt and should be achieved at a sustainable pace. And it should be based on a strong definition of done. That the team actually follows.

So, once you identify your real velocity (much lower), then doubling it will be relatively easy.

***
Enough for today.