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.

Better distributed Scrum

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 reason for "Business Value Engineering" - 2nd pass

Let's say some smart people have given you some great ideas about "business value engineering."

Let's say those ideas include:

• More customer demos
• Having the implementors visit the customers as they "do work" or "live" (depending on your product)
• A better BV Model
• Don't talk to customers (they don't know they want an iPad)
• Taking BV metrics after each release
• Using the Pareto rule more to skinny down how many stories go in a release
• Better PMO governance, to assure that problem teams are helped sooner (so that deliveries happen faster)
• Improving the creativity of the Product Owners
• Better brainstorming by the Business Stakeholders (or whatever you call them...the people that 'assist' the Product Owner)
• Priority Poker (wide band delphi to estimate business value, using Fibonacci cards)
• Agile Specs
• Rely less on documentation and more on conversation to assure the Implementors understand the story
• Story Boards
• User Story Mapping
• More wireframes
• Focus on "bang for the buck"
• A story breakdown structure, to use to manage with senior Business Stakeholders
• Completing more projects "early", eg, when we see that the benefit-cost ratio of the project has deteriorated to below alternate projects (and other criteria are met).
• Light use cases
• Etc, etc, etc

Note: I personally like some of these ideas a lot.  On the other hand, some I tend to shy away from.

First thing to observe (and the above is a short list of all the ideas out there): Too many ideas to implement all at once.

Second: Some of these ideas are contradictory.

Third: "Many seem very good ideas for us, but how do I prioritize?"

Yesterday I explained how we can use "BV process mapping" to enable us to see enough to prioritize the improvements we want to make.  (This really includes more than mapping, but let's over-simplify and call it just "mapping.")

As a minor benefit, BV mapping enables you to hear talks, and identify which part of the BV engineering process the person is talking about. In other words, you can put others' ideas in a context that, hopefully, makes the ideas more useful or at least actionable.

One reason for "Business Value Engineering"

I said recently that "business value engineering" is the place we can improve the most.  By which I mean:
(a) identifying the small features that the customer will want the most (once they get them), and
(b) identifying the MMFS (minimum marketable feature set).

Perhaps we should also add to this:
(c) identifying a "business model" that is reasonably attractive to customers and successful for the firm.

By this we mean, all the pricing and servicing and delivery things we put around the product.  If these don't work, the "product" per se may be wonderful, but it will fail.

We need to at least briefly mention the time dimension. For most products, the customer explicitly or intuitively realizes that he is entering into a long-term relationship with you. (At least with all the new products that I deal with.)  So, you must also have something like a "product life cycle" approach that is reasonable.  If you want to succeed longer-term.

I think that improving velocity (as defined by story points) is important (as suggested by recent posts), and important in many ways.  But I think improving business value engineering is, virtually always, the path to more success quicker, for the team.

Almost always, the biggest impediment for a Scrum team is a weak Product Owner (who is responsible for business value engineering).  Usually the person per se is very strong (smart, articulate, etc), but largely untrained and ill-equipped to be a fairly good product owner. Much less an excellent one.

***
When I talk about business value engineering, I always want to talk about the full end-to-end "process".

I think many people have many wonderful ideas about how to improve things.

But, I find that...
(a) no one can implement all of these proposed improvements at one time (usually it would take years to fully implement them)
(b) some of the proposed improvements are contradictory, or at least don't work well together with certain other things
(c) for a given company in a given industry, given their own current "processes," Improvement A is often much more useful than Improvement B.  While, for another company, Improvement B is more important.

So, as with Lean Value Stream Mapping, one of the key reasons to do a business value engineering map (with hypotheses and assumptions) is to identify the priority of the improvements.

Prioritizing the improvements is very important.
I'd rather make a little progress each month than "lots and lots" of progress that is supposed to arrive in 3 years.

Scrum Team in Waterfall Land! What to do?

The real question sent to me was: What are some tips for integrating our SCRUM model with non-Scrum groups who will not be adopting the process?

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.

Getting Higher Velocity - Take 3

A recent conversation leads me to discuss some basic issues.

• 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.

Paying for Courses

As a reminder, we posted about Paying for Courses a while ago.

We wanted to remind people of the problems that can arise, especially with paying with a credit card via the internet.  If can be a problem, and it can seem insurmountable at the time. But actually it is usually very easy to fix.

If it happens to you or a friend, a bit of patience and a phone call or two will get things resolved. Almost always.

See: http://agileconsortium.blogspot.com/2010/01/paying-for-courses.html

Intermediate Certified Product Owner course Charlotte Dec 7-9

We have a intermediate Certified Scrum Product Owner course. In Charlotte, Dec 7-9.

Leader: Joe Little. Because he has an MBA, discusses BV Engineering, and has worked with Jeff Sutherland and the Poppendiecks and other great coaches, we think this course is very valuable.

Potential Product Owners, ScrumMasters, and managers should take this course. This will be an "intermediate" version.

Usually the simplest and biggest change in team performance is "improve the Product Owner".

Go here for further details.

Scrum is a major management discovery

Steve Denning wrote an article titled "Scrum is a major management discovery."

For those of us who have been doing Scrum for a while, saying that Scrum "is a major management discovery" is, well, obvious.  Or it is clear and unfulfilled.  Or it is something we have forgotten.  Or it is something we never thought about ("I thought Scrum was only for people like me, developers!").

In any case, I think it is important to say.  Both today and in the future.

Steve Denning is a good and smart man. A man on a mission, and I think a good mission.  Here is his article.

***
Why is Management important?

So, let's look at this hypothesis (a major management discovery) from a certain point of view.  What is important? Or where is the power?

If one believes that managers are responsible for the mess we are in or, in any case, only managers have the power to change things, then the fact that Scrum is a major management discovery is quite essential.

A contrary hypothesis is that, despite what some people may think, the real power is with each individual, and resides there in such degree as that person is persuasive and connected to the truth (some combination of those two).  In other words, any one of us can have great affect on our brethren if one speaks well and if one proposes actions that are connected to the truth.

Aside: What I have suggested is that the power 'vested' in managers is actually largely a facade of power with little substance, except that other people happen to believe it sometimes. Real power only comes from a person's leadership skills, eg, their ability to persuade and to speak the truth.  And anyone, with or without a manager's official title, might have and use these skills.  How many Arab springs, or 1989s, or American Revolutions will it take until people see that "we hold these truths to be self-evident, that all men..."??  [Be he right or wrong (in whatever dimension you wish to speak of) Hosni Mubarak thought he was pretty darn powerful only a few months ago.]  And that means we all are equal, ultimately, in power.  Even power. Yes, yes, I know it seems to many of you very impractical of me to say so.

Now this second hypothesis does not imply that we leave official 'managers' out.  It just means that anyone can pick up the torch.  Anyone can start the change, or take it to a new level.  You don't have to wait for the managers to be convinced!

***
Scrum changes everything

I agree with the view that as soon as one introduces Scrum into an organization, the people start to see the impediments and they start to realize that almost everything must be changed.  At least some, not completely, but at least some. (Yes, completely, in some areas.)

I agree, based on experience, with the view that Scrum can have a greater positive impact (on people, on the firm, on more customers) if the managers and 'everyone' in the organization 'get it'.  

But Scrum can still make a serious impact on some people's lives before 'managers' know about it.  Or agree with it.  Or do much about it.  We can definitely start Scrum before managers fully 'get it'.

It is perhaps now worth repeating that Scrum itself is not a silver bullet.  Scrum does many things (and one might say that the spirit of Scrum does yet many more things), but one of the chief of them is to set up an inspect and adapt system. This system shows where the biggest problems are.  But it is up to the people to take action on that new knowledge.  Scrum will not magically, by itself, fix things.  The people must do that. And often that means that the managers must (or should) approve the fixes (agree, give people's time, get money approved, whatever).

Also, the basic ideas of Scrum apply to many kinds of work, and in general apply at all levels of an organization.

***

Some additional key ideas

In his article, Steve mentions 10 salient ideas about Scrum.  I strongly recommend that you read his article and consider them.  Steve himself does not think his list is perfect or exhaustive, but it is useful to review and consider and put into action more.

To him, some of the ideas I will mention below were said or implied in what he already said. But I want to make them more explicit.  And perhaps I add one or two new things.

My idea is that these underlying principles of Scrum also apply to management work and to the work that managers do with teams.  So, managers, listen up:

1. How do we know if thinking (knowledge work) is good?  Scrum's idea is that we let 'em think for a while, but show me some 'working product' at the end of the Sprint!  (say, every 2 weeks) So the right people can decide if it is useful thinking.

2. "Six blind men and an elephant."  No one understands 'everything' anymore. To figure out anything, we need to get a small team together, have them fight about it and create knowledge together, and then we can make some progress that the customers would really care about.

3. "The bad news does not get better with age." Yes, some of the suggestions of Scrum and Agile are 'extra' overhead from a certain point of view.  But the benefits of that extra overhead are so great in discovering 'bad thinking' (simple example: bugs in the code) that it is obvious we must accept the 'overheads'.

4. We always start with seriously incomplete knowledge. Therefore we must enhance learning. We must accept small failures as the best way to learn fast. (Well, we must accept small failures in any case. But use them to learn fast also.)  And we must organize things in such a way as to take advantage of that learning as fast and as much as possible.


5. "People are remarkably good at doing what they want to do."  By and large, knowledge work is (or should be) very creative.  (Again, a lot of the creativity happens as a team of 6 or so.)  And the work, if you remove the de-motivators, is inherently interesting (well, to those who will do it well).  So, we must treat the workers more as humans with intrinsic motivation and much much less as things or cattle that must be prodded.  Daniel Pink's book "Drive" gets into how motivation works with people.  But the basic principles were noted by some wise coaches some thousands of years ago when they said: "Do unto others as you would have them do unto you."  Of course, we were all taught this by our mothers, but who knew this would actually help us and our firms make more money in business?  Who knew that customer delight is driven by workers having more fun!

Aside: My strong bias is with Peter Drucker (wikipedia him), when he said that the purpose of the firm is to satisfy customers. (And that shareholder returns were just a constraint.)

6. "You have to go slow to go fast."  Lean-agile-scrum have shown that there are many counter-intuitive principles that must be followed if a team is to achieve real success.  Well, the principles are counter-intuitive to us, who have been trained so long in the wrong ways of thinking about these things.  So, multitasking, stretch goals, giving teams multiple projects at the same time, being sure everyone is 100% occupied, large queues of work -- all these are almost always stupid ideas, even though they seem good from a certain point of view.  Who knew the customer was important?  Who knew that if you did not allow slack in the system, you just about assured that the customer would never see ANY feature any time soon?  One of our favorite counter-intuitive sayings is "you have to go slow to go fast".  Meaning, as indicated earlier: Yes, early and frequent testing is an 'extra' overhead, but the benefits in keeping the bad news from getting worse with age are so great that, it is obvious, we MUST go slow to go fast.

***
In closing

Steve mentions dynamic linking. From that phrase (which I am interpreting a different way than Steve did) I want to lastly emphasize that the values, principles, and practices of Scrum are themselves dynamically linked.

Scrum, if played well, is like a good ice hockey team.  Every player on a great team is inter-linked, and every pass or shot is inter-linked. So that a single pass can be both a great defensive move as well as set up an offensive break-away that leads to success (puck in net) seconds later.  So, similarly, all these things about Scrum are inter-linked.  Fluidly. And some of the linkage is a dynamic tension. Simple example: In general in agile we want less documentation but we want more and better communication.  Which might mean more documentation of just the right sort (I'll call this an agile specification), although overall there is less documentation.

We have so many more benefits to get out of Scrum.  For so many more people.

Freedom

For reasons unknown, I ran into a picture I took of a statue of Jefferson in Paris (it is along the Seine, near the Musee d'Orsay).

Then I saw something else which led me to this quote from Jefferson, mainly about the meaning of July 4th.  I think it has a wider meaning, and so I quote it here:

… May it be to the world, what I believe it will be, (to some parts sooner, to others later, but finally to all,) the Signal of arousing men to burst the chains, under which monkish ignorance and superstition had persuaded them to bind themselves, and to assume the blessings & security of self-government. That form which we have substituted, restores the free right to the unbounded exercise of reason and freedom of opinion. All eyes are opened, or opening, to the rights of man. The general spread of the light of science has already laid open to every view the palpable truth, that the mass of mankind has not been born with saddles on their backs, nor a favored few booted and spurred, ready to ride them legitimately, by the grace of god. These are grounds of hope for others. For ourselves, let the annual return of this day forever refresh our recollections of these rights, and an undiminished devotion to them.

Do we each for ourselves, and for those we manage, respect the opportunities and responsibilities of freedom?

Adam Smith described well how the invisible hand allows the economic participants to enjoy the economic benefits of freedom.  In, say, a country.  We are still learning how the same basic things happen in a group of 100 people.

I do not think waiting for others to tell us what to do, or to wait for them to change, or to wait for them to fix some things, I do not think these things will enhance our freedom. Or really do much for our lives.