Let’s digress first, and then come back to a better answer.
To digress….why are honesty and transparency important?
IMO, in two ways. The main reason: we can manage better with the truth. For example, we get better feedback in the Sprint Review. If we can see the product transparently and if people speak honestly. The same notion applies in all official or unofficial meetings a Scrum team might have.
And because there is less to remember.
Honesty is also important in personal relationships. People tend to like people who are honest. More trust. More sense that they know the real person.
And, of course, as it has for centuries, honesty has a bad side too. These days we use the phrase ‘too much information’ or ‘over-sharing’. Or we wince when someone gives feedback harshly. Or says something in an ‘awkward’ way when a ‘smoother’ way would have been just as effective.
Then we have to face life, and some of us find certain parts of life very discomforting. By this, I mean by work-related things, and things only indirectly related to work.
Here are some general facts we must face:
our strengths and weaknesses
time is short
‘all things must pass’
humans are a lot like primates
humans are not as rational as we want them to be (at least sometimes)
certain body functions (was that delicate enough foryou)
the classic topics: sex and religion (and politics and money)
I tease. Humans are primates. And in so many ways, maybe for good or ill or both, we refuse to think of ourselves as animals. Weird.
There are plenty of roughly similar ‘hard to discuss’ topics at your work. But I won’t list those now.
As we work together, we must expect these ‘awkward’ topics to surface.
To some degree, as we gain trust with our teammates; they forgive us and we forgive them. And its okay. We talk openly, give feedback, and set some better boundaries. But it can be awkward some times.
The main points here are a few.
We want more transparency and honesty in Scrum. Mostly this is just to help make work better.
Much of the honesty is refreshing and welcome. It’s fun to be known for who we really are.
Still, humans will never be completely honest. Ever (I think).
Sooner or later, you are gonna hear things you do not want (or need, in your opinion) to hear. We will tease ourselves with this quip: Some things you can’t unhear.
The ScrumMasters, the Team and others will forever be working to help people be more honest. Also, sometimes ‘less honest’ (about some things).
People will make mistakes; that it will be painful sometimes…is to be expected. It will just happen.
Mostly it is better. “No place to run to, no place to hide” is a good song, mostly.
Every year a local Kiwanis group sponsors a “Christmas Baskets” program to help the children at Berryhill school.
Berryhill is an elementary school in Charlotte, NC with children and families that are struggling. This is probably true at many schools in our area, but this is the school they selected. And the Communities in Schools program facilitates this with Berryhill.
You are invited to help or donate funds.
Please contact Cassandra at the office, (704-376-8881) or email (email@example.com). She will put you in touch with the right person.
Below are details with some explanation. You will be glad you gave; it is not hard to do.
What is it really?
Families with children at Berryhill elementary school sign up, asking for help.
We provide about $75 of food and other ‘essentials’ per family. (Donations toward this are gladly accepted by that Kiwanis group. They do the shopping. I suppose you could help them shop. Or find a firm to donate some items.) The families typically do not have the funds for a holiday meal. And, again, it is not only food, other basic necessities are requested.
People select specific families to buy presents for. Basically, presents for the children. Typically, they need clothes, shoes and similar basics. They also want toys and games, to have a festive holiday.
So, you are invited to ‘take a family’ and buy presents for them, (3 kids and a mother, for example). They are most grateful. You will receive a sheet with ‘requests’ and clothing sizes and ages), get a ‘return receipt’ (often the sizes will be off), wrap the presents and then deliver them.
You do not have to do the delivery; but I recommend it. I believe the delivery will happen on November 19th. I have had my daughters participate in the deliver every year for many years now. It is a good experience for them. It should respect for the receipts (whom we are helping, but really only helping a little bit), and it… it changes you.
On the delivery day, you will work briefly with a group of people who volunteered for this. Some coffee and donuts. Some briefly friendly chatter. Some work (organizing stuff into boxes). Some packing into cars. Maybe a picture. This is done at a church that is roughly near the Harris Y (but toward South Park Mall).
Some of the families who ask for help have their ‘act together’ to a good degree. They may not have much money, but they are making progress, getting there. Other families are struggling more. It is a fairly wide range. But all the kids, as I recall over the years, all the kids are optimistic and have their whole lives ahead of them. They are always ‘playful puppies’ (if you do not mind a ‘masculine metaphor’ covering boys, girls, and all kinds of kids). They have happy eyes, and they are eager to learn.
It is not very much work (especially if you do the shopping with your children and let them help with the wrapping). It is fairly easy to do — when you deliver, the people are friendly, you talk with them briefly, wish them Merry Christmas (or sometimes Happy Holidays), and then you are on your way.
You will be glad you did it.
If you are interested in participating, please contact Cassandra at the office (704-376-8881) or via email, and she will put you in touch with the right person.
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 areLarman’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 asorganizational learningare 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 originalpage. Some key information on getting organizations to change.
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.
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 astrongconfidence 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.