Monday, November 2, 2015

Larman's Laws of Organizational Behavior

This is what Craig Larman says on his website.  I quote that page in full:

Larman’s Laws of Organizational Behavior

After decades of observation and organizational consulting, here are Larman’s Laws of Organizational Behavior. These are observations rather than laws to follow.

1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.

2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.

3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, “religion”, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.

4. Culture follows structure.

or, “culture/behavior/mindset follows system & organizational design”i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that’s why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. i discovered that john seddon also observed this: “Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes.”
Here is the original page.  Some key information on getting organizations to change.

The ScrumMaster Should Not be a People Manager - 2

This is a continuation of this post.
Some more observations.
Before we start…some more basics….

1. The PO has an important role.

Especially key in deciding which PBIs or user stories the team will get next, and important in many other ways too.

2. The SM has a key responsibility in making the ‘continuous improvement’ engine work in Scrum, and for the Team.

This is so important.  And soo seldom does it really happen.

3. Each Team is different, each SM is different.

So, while we can describe the SM (or any role) based on the ‘normal desirable’ state, we must also deal with people or groups that are different, or unusual SMs.  These are NOT included in this overall discussion, but are always something we must deal with, sooner or later.

4. Scrum is not the only way.

It is about the only way I advise, for many reasons. And there are some caveats, but too much to discuss here and now.  So, even though something else may work or ‘be better than we were before’, that does not mean one should not have done ‘real Scrum’ and have been yet better than that alternative.
Still, one can do something else, and maybe often get somewhat better results than you had before.
But the question should be: could we have gotten even better results with a different approach?
And, to the degree you are not doing ‘full scrum’, I am suggesting trying full scrum first.  Or as soon as possible.  And seeing if the results are not even better.
So, here are some issues:

A. The PO role is important, and the SM role should not challenge it.

It is true to say that the SM is a kind of leader in the Team.  The PO is a different kind of leader.  But it does not help if the SM challenges the PO in the PO domain. (I will call that domain: deciding which work is most important).
The SM often must teach the PO how to be a good PO, sometimes by helping him for a time.  But this is not taking over the PO job permanently.

B. The SM must make the Team own the success.

Talking as though the SM owns success is not going to help. As soon as the SM gets very powerful, compared to the other team members, it is not likely to be good.
In my opinion, as soon as you say the SM is responsible for success, everyone else in the Team drops down some in motivation and energy, and self-organization is not happening as well anymore.  Sometimes this is very subtle.  Sometimes it is ‘seen’ in the lack of increased productivity that we would have seen if they had continued to self-organize.
Just asking the team (‘do you own success?’) is not sufficient, especially if they know that the ‘right’ answer is yes.

C. The SM must ‘make’ the Team self-organize.

We have said this before.  The point now is, this is difficult, and almost on a knife’s edge.  If the SM moves much away from the servant leader, it is very likely that this will inhibit the self-organization of the Team.
Again, the change can be subtle, and people may barely perceive it at first.  And not talk about it.  If the SM pushes the Team, it may be mainly seen in the lack of improvement in productivity in the Team, rather than a clear decrease in productivity.

D. The Team needs transparency.

The Team must self-organize, self-direct, and self-control itself.  (Outside people can have some role and some influence.  More on that in a later post.)  To do that, the Team (that is, each of its members) needs to know where it is.  The facts need to be transparent. Or, more transparent, to enable the Team to use that information to self-organize more usefully, to make better decisions based on better information.
It is the SM who must foster transparency.  It is human nature to want to hide things, and the SM should be making it ok to tell more of the truth.
Again, the trendline on transparency is subtle.  It is usually either getting better or worse.  But is hard to identify the things that are not said, simply because they were not said.  People like to pretend they are very honest and open with each, and yet that is not really always the truth.  We know this without consulting Dr Freud’s ideas about the unconscious mind.
So, if the SM has power over the Team, especially all the Team, as the one who gives them reviews and compensation increases, then we should expect reduced transparency.  And yet, the SM will never know that the transparency is reduced.  If the Team kind of likes him, they typically will never say ‘I am not telling you everything.’  Often, they will not even admit to themselves they are withholding information.  And yet that is happening.
We think there are a few people who will say almost anything to almost anyone.  That is true.  And if their ‘boss’ is the SM, they will still say (almost?) everything to him (or her).  But we think these people are fewer than some of us want to think.  And even then, these ‘brave’ people are not quite as brave as they say, in our opinion.
Hence, we never advocate that the boss become the SM.  Never. It might work, but we do not advocate it.

E. The SM is essential to continuous improvement.

Even 100% dedicated SMs often ‘slack off’ in driving that impediments are being fixed every day.
If we give George additional roles, George is even more likely to not devote enough attention to impediments.
Impediments are all the things we can work on to become better, to improve.  And sem-naturally, the Team will address really key impediments, eg, the system is down.  But often they ignore impediments and focus on real work (as they call it).
So, the SM is key in making sure someone is working on the top impediment now.  Hence, the Team does not improve nearly as much as it could have.
Can a Team improve without an SM?  Yes, just in the fine art of working better together, a Team can get noticeable improvement.  And this can happen almost as if by magic.  But to get real continuous improvement, and start to get more of that faster, you must have a fulltime SM.
Can we live without doing all these things?
Well, certainly.  We did not die even though most of us a few years ago did not even know about Scrum.
Let me give one concrete example.
You have a person, George, who is the boss of the Team.  You look at the Team, and there is no one who would be a good SM.  You talk to George, and discover that in most respects George would be a good SM.  But, he is the boss of the Team.  You look at the relationships between George and the Team members, and you find that George is an ‘open’ manager, that his Team, by most standards, is very open with him.
Well, in this case, because there are so few options, it may be best to let George be the SM.  It is not the preferred state, and it should be fixed, but one judges that it is probably the least bad of several options, at least for now.
But, this would never lead us to recommend that the boss become the SM.  We might live with it as an accommodation to ‘today’s realities’, but we are not happy with that part of the situation.
Broader suggestions.  The SM must act on the following.
1. The ‘rules’ of Scrum are not as well known as we would like.
2. You may be forced to break the rules of Scrum, but try to do so knowingly, rather than without any thought.
3. Try to measure or in some other ‘open’ way, identify your Team’s biggest problems, and then do something about them.
4. If breaking some of the rules of Scrum turns out to be a big problem, identify that, and fix it soon. If it is a priority.

Sunday, November 1, 2015

The Organization of the Scrum Course - 2

See part 1.  Now continue below with part 2….
One of the big problems is that the attendees, or many of them, resist intellectually.  So, as in Zen, we have to confuse the intellectual mind in order to enable real learning to happen.  Or, as the Army says, we have to break them down in order to build them back up again.
We have to ‘go around’ or ‘get behind’ the intellectual resistance that is common to just about all of us. So, one technique is to do exercises. Not following a highly logical flow is another technique. Surprising the attendees (in small ways) is another. Humor and improvisational exercises are other techniques. Food is another.  Addressing them directly, and getting to know them as a person is another technique.
For some, our techniques are…umm, disconcerting. If a person is a certain type – well-organized, intellectually rigorous, thinking, logical – it can feel a bit uncomfortable.  But if one has at least an intellectual understanding or some real experience that people and  life do not always follow pre-conceived intellectual notions, then it is not so uncomfortable. Very few people are uncomfortable, although a very few are.
So, I admit that the course to a new person, or to a few, might feel uncomfortable. (Actually, my impression is that most people enjoy it. About 98%.  But not all.)
During the course, if you tell me you have that an uncomfortable feeling, then I will offer some advice. First, I will address the topics that are on the one-page (two-sides) outline of ‘Scrum’ I hand out (it is really more than just Scrum).  I will follow the outline on the website. (Except not in that order.)  We will follow the slides, except  we will cover additional material.
We have a strong confidence that most real learning is not logical, per se. It happens in the sub-conscious mind, where experiences are ‘put together’ by the brain into a ‘logical’ way of looking at the world; assembled into a pattern or set of patterns. I try to  force your brain to break down old patterns, and rebuild new patterns.  I have confidence most of our attendees can do that.
And I know, sadly, many are ‘controlled’ by ‘waterfall ideas’ and they will not be able, after only 2 or 3 days, to really replace the waterfall patterns with agile/scrum patterns.  Some people are like that.
Would we succeed better if we presented things in a more organized, more logical way?  Well, a few people might say ‘it was a good logical presentation’.  That small group, would feel better.  But I am completely convinced that, if you look at the overall results, they would be much much lower.
Remember that our goal is not teaching. Nor learning. Nor even action by the attendees. Our goal is that attendees achieve real results with Scrum. For the person, for that person’s team, and for that person’s customers. One will never achieve real results with merely a ‘logical understanding’ of the work.
So, we are not after explicit knowledge. We are after ‘a sense of urgency’ and the tacit knowledge that leads to successful results.
So, I hope now it is clearer why I organize the Scrum course the way I do.
I wish you every success in having fun in achieving real results.