Scrum teams and our Mammalian nature

Posted on October 24, 2011 by Joe Little

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

Posted on October 23, 2011 by Joe Little

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.

The Unbearable Lightness of Being

Posted on January 22, 2011 by Joe Little

Just finished The Unbearable Lightness of Being by Milan Kundera. As a start, see this: http://bit.ly/gdfnRF

A few observations from it about our work.

1. In our work, we too feel everything is unbelievably ‘light’ and transient. At least some of us do some of the time. And, with all the change, a sense of meaninglessness can creep in. In the scheme of life, it is perhaps a minor observation, but Scrum does many things to put meaning back in our work.

2. The lightness also reflects how many things are in constant change. Which is what we need to adapt to in business. Some of these changes are ‘bad’ or at least unwelcome. And some are good (for example, new learning). But adapt to both, it seems to me, we must do. To minimize the damage and to maximize the advantage.

3. Toward the end of the book, Kundera talks about how Tereza loves the dog completely and without reservation. And also let’s him be completely free. She does not require the dog to love her (although it does), nor to love her exclusively. She allows the dog to be a dog, just as it is.

In business, it seems that it is often hard for people to admit and accept that each and every person is free. We (as managers) must always ask them, for example, ‘do you want to do this work?’ Just because we pay them, they do not suddenly become our slaves.

To me, Scrum is quite clear how important this notion of freedom is. And does many things to work in harmony with that notion, rather than against it.

* * *

Not everything is about ‘work’. I also recommend the book for many reasons that are outside the boundaries of work. Please enjoy. May your heart (and perhaps our parts of your being) be touched by it.

The goal

Posted on January 12, 2011 by Joe Little

Elihu Goldratt wrote a book called The Goal, which we recommend. TOC (theory of constraints) is embedded, to some degree, in Scrum, for example, we think.

But we wanted to talk about “the goal” a different way.

What is the goal of our courses?

Being shy and modest by nature (ok, yes, we act a different role if the part requires it, but this is our nature)…we do not think the goal has much to do with us. It is not, for example, what we say in the course.

Nor is it what the attendees learn. I really don’t care about that anymore. Up, down, sideways: it is not really key. Necessary probably, but not key.

Nor is it the actions that the attendees take after they attend the course/workshop.

The goal: That they make their own lives better, that they make their team’s lives better, that they make their customers lives better. And more than that, but that is enough.

We want results.

Now, our talking, their learning (Tacit and Explicit), their actions — these are probably all necessary conditions to getting the results. But not sufficient. And maybe we want the results to also include money, but we agree with Peter Drucker that the purpose of the firm is to satisfy customers (not to get shareholder returns).

Now, what is our vision of the goal for Scrum?

Certification? Certainly not.

More ‘scrum’. Well….no.

More good Scrum (with no Scrum-But). Well….still no.

Again, to us the only worthwhile goal is better lives for the people involved.

Now, again, we do think more certifications, more courses, more Scrum, better/deeper Scrum, much less Scrum-But, etc, etc probably are necessary conditions to getting better real results. In fact, let me say that more strongly: Based on real experience, I am convinced that Scrum and better Scrum are key to better results for all new product development teams I can imagine. And for other kinds of teams as well. But not the sufficient, sole key.

(Unless one assumes that by starting continuous improvement, the team will necessarily go as fast as possible in the direction of positive change. A sweet assumption in some ways, but not one that attracts me as correct. In this “best of all possible worlds” — meaning I think Voltaire satirized this sweet viewpoint quite well.)

And some other things are also needed (a nod to Ron Jeffries and others re this comment, to be discussed later).

“Where there is no vision, the people perish.”

Meaning: If we all do not articulate a clear, strong, good, and bright vision, Scrum could be far less successful than it by rights ought to be. And “we all” are the Scrum community, speaking to ourselves and speaking to those who look to Scrum for some improvement. If we fail in this or do a poor job, many many people will have poorer lives than they deserve. And, god knows, there is so much improvement to make in our lives. Even in 2011. (smile)

PS. The picture is of the Blue Ridge Mountains. I go to them sometimes, when I need a moment of peace, of inspiration. “I lift mine eyes up unto the hills…” They are said to be the oldest mountains in the world, and this is almost actually true. Surely they have some majesty. Surely this is not without meaning.

The biggest impediment

Posted on January 11, 2011 by Joe Little

To start the new year, perhaps we should focus on the biggest impediment.

Now, of course, we don’t know the biggest impediment at your place.

But we can tell you what we see at clients, and what makes sense to us, given human nature.

In our view, it is human nature to feel, “We canna push it any faster, captain.” (See the picture of Scotty.) Meaning: We feel we are going as fast as we can. So, we ignore impediments. We don’t even see them. Now, there is actually a lot more to say in this vein, but we will ignore that for now.

The biggest impediment, in our view, that we most commonly see is a lack of focus on removing impediments. Now, this has several manifestations and several root causes. We have just mentioned one of the key root causes. (To which maybe we could ask more “whys”.) But, we think that is a useful way to describe the impediment.

Here are some of the manifestations:
* No public impediment list (Do you know where your public impediment list is?)
* No or poor prioritization of the impediments
* A retrospective that focuses too much on the ‘pluses’ and on lots of impediments (without a focus on the one top impediment now)
* No effective action taken after the retrospective to reduce the impact of the impediment
* No serious thought about the whole impediment removal process (eg, an assumption that the simple framework of Scrum tells us everything we need to know about removing impediments)
* Too much work on the wrong impediments
* No transparency about the group’s (or firm’s) overall impediment management regime
* Not enough allocation of the ScrumMaster (and perhaps others, perhaps $) to removing impediments
* Comments like “Why are we working on impediments? We should be doing ‘real work’?”

This is serious. We think a decent ScrumMaster, with decent organizational support (helped along by the SM being persuasive), can double the velocity of a team in the first 6 months. You do the math. Would that be worthwhile at your place?

PS. Because of possible misunderstandings, we must always repeat that doubling velocity does NOT mean that the Team works harder (No death march). Often it means that the Team works fewer hours than what has become ‘normal’. In fact, the Team should feel that removing impediments is kind of a fun activity.

Responsibility

Posted on December 13, 2010 by Joe Little

In my last post, I talked about responsibility. Or mentioned it briefly.

As I was walking my dog today, I was thinking of what I would say. And I thought of the famous line from that movie: “I’m mad as hell, and I’m not going to take this anymore.” (Network) [This is a rather complicated allusion, so apologies to those expecting a simple one.]

So, if we are free, we have to also acknowledge our duty, our responsibility. This is an ancient concept in all cultures. Freedom to be completely irresponsible is not a thing any civilized person wants.

At the personal level, responsibility means first we must take care of ourselves, without violating the freedom of others. And take care of our immediate families and friends.

But, and perhaps in this season and in my culture influenced by Christ, we may say responsibility joyfully also includes: It is more blessed to give than to receive. More broadly to our, as it was quaintly phrased, to give to our neighbors. To those we know but have no real connection to.

In business this may seem a paradox. And for me for most of my life this seemed hard: That I should give more than I get. But it does not say that. To me it says: by focusing on the giving, you actually receive more. Not unlike what Peter Drucker said (that the purpose of the firm was to serve the customers).

Receive more of what? Ah, yes, of the more valuable things. Let me leave it at that. No doubt in some way you have experienced this.

Business is a wonderful transaction, where each side gives less than he gets. One side pays less than the object is worth to them. And the other side gives up a (to them) less valuable object (or service) for the money they need more. It is wonderful magic. The magic of freedom, and free enterprise.

So, what am I mad about? I look about me and see, so plainly, so much imperfection. So much want. So much need. So many tears. So many who deny such large parts of their full humanity. As though life or the world is so dreadful, they must hole themselves up inside a ‘resource’ that is barely more than a thinking machine that drinks coffee. They willingly give up such large parts of their full humanity. I too have done this. We are so much more than we have yet become.

So, if you are a little bit free, if you have a little bit more of material wealth or perhaps that greater wealth, confidence that in life (as in death) all will be well if we stride confidently toward our dreams, then you have the responsibility to give that to others. Make them more free. Make them more confident that they can make of their own lives a better life. And themselves do that too, for others. Not abstractly, but one moist, shaking, confused, imperfect, animalistic, feeling, breath-inspiring, mistake-making, incompletely understanding child of god at a time. Make ready one person waiting to shine as the paragon of animals. This is where the real value is.

Now, I am not against money and business. Far far from that. I believe in money, as one of the more useful illusions of man. But money and business were made to serve man, not man to serve them. I am speaking now of the music that plays beneath all the MBA stuff you may have learned.

You have the responsibility, as you well know, to serve a higher purpose.

I do not sound this call to ask you to make an unreasonable sacrifice, which would most likely be only an ego-trip. No, within the real humility of your real self and station, neither too high nor too low, you can do more easily. If you put yourself in the flow of the truth and the way. Easily. If you stand upon the truth, and act in concert with your friends and colleagues, the world cannot resist you. Fearsome as it may seem sometimes, it cannot resist you. We have so many examples, do you need to hear them again? I will mention, as one overwhelming to me, the falling of the Iron Curtain in 1989.

So, this is our responsibility. To act somewhat more greatly than we have till this day. And yet to recognize that even our enemies are our friends. Fight them if we must, but fight them as a way of saying they are worthy of our fight. They are humans who deserve the help of correction.

The first shall be last. And the greatest wash the very feet of their friends. These seem paradoxes, but the wise know that strongest action comes from quietness and balance. You can do it.

Perhaps you do not like, or do not feel called to be responsible to, the purpose I have tried to articulate. No mind. Articulate for yourself and others a yet better purpose.

PS. For those looking for concrete agile ideas, see the next post on Sprint Planning. (Although the ideas in this post really are also agile ideas you can act on.)

Mura, Muri, Muda

Posted on April 17, 2008 by Joe Little

These are Lean words. In Japanese. And I always get them confused, especially the first two, so I am doing this post partly to have a place to remind me what each word means. They are all in the negative.

Mura: unevenness of flow. Thus, the first thing to do is establish a reasonable pull, an even flow.

Muri: overburdening the system. (System being the overall thing you are talking about; generally not a computer system.) Thus, once you establish a production “pipe”, don’t try to force more through that pipe than it can handle. As a fluid dynamics person will tell you, if you overburden the pipe, it means even less liquid will travel through the pipe in a given time period.

Muda: waste. This is further defined by Type I and Type II muda. And by the classic 7 wastes. “Muda” is an ugly work in Japanese. Kind of like an earthy but dirty Anglo-Saxon word, I think.

The classic definition of Type I muda is necessary waste, ie, something that does not add value in the customer’s eyes, but we feel, as a business, that it is necessary. (Compliance with government regs might be an example.) I call this “waste we have not yet figured out how to live without” (maybe not true of all things in this category).

The classic definition of Type II muda is unnecessary waste. I’ll call this obvious waste (as soon as you put yourself in position to see it).

There is of course an inter-relationship between the three (mura, muri, muda).

In general, I find these ideas very similar to things we say in Agile, Scrum, XP, etc.

Jim Womack suggested that Lean thinkers practice those in that order, ie, focus on mura first. Then muri. Then muda. Perhaps this is good advice for Agile. (BTW, if you don’t know Jim Womack, get one of his books: Lean Thinking. Recommended.)

"How to Tap IT’s Hidden Potential"

Posted on March 11, 2008 by Joe Little

“How to Tap IT’s Hidden Potential” was the title of an article in the WSJ on March 10. Published in collaboration with the MIT Sloan Management Review.

The subhead read: “Too often there’s a wall between a company’s information-technology department and everything else. That wall must go.”

I remember getting a paper back in the 10th grade: “You have a firm grasp of the obvious.” I was smart enough then not to feel complimented. (This is perhaps too harsh for these authors; they are raising a very important issue that has not been addressed well enough yet.)

In 1970 Dr. Winston Royce wrote a now-famous article entitled: “Managing the Development of Large Software Systems”. Because of this article he is considered the father of “waterfall”. One of the top five problems he identified he called (in a positive way): “Involve the Customer”. Same basic idea; this was a known problem before 1970. And there have been many surveys of successful projects over the years. One of the top reasons for success always is that the business/customer was more heavily involved.

This gap between IT and the business side is a serious problem, and it is shameful that we (the business community) have not addressed it with much greater success. In my opinion, this is the key reason that we are getting generally a lousy return on our investment in IT. Certainly compared to what we could get. So much so, that management is often so desparate that they use this kind of logic: “Well, it’s probably going to fail for $50 million here in the US. Let’s ship it to India, where it will fail for $25 million.” The logic might be slightly better than that, but not much.

Back now to the WSJ article written by Amit Basu and Chip Jarnagin. So what do they recommend?

Begin with IT literacy – and commitment – at the top.

Hire an IT leader who sees the big picture.

Create demand for IT solutions.

Make sure nothing gets lost in translation.

Rationalize IT spending.

Create an IT portfolio by evaluating risks and returns.

I like some of these ideas. I would put greater emphasis than they did on making these solutions adaptive to change and to learning (they do hint at this). You should read the article. (You may need to join the WSJ online. Or see the comment (below) where the article is available for free.)

But what’s missing with these ideas? Well, in general, they are too high-level. What is needed is a way to get business and IT people collaborating in a specific small team that will accomplish a specific mission. Where the rubber meets the road. To me, this is where Scrum helps to solve this problem.

Tell Her No

Posted on January 18, 2008 by Joe Little

Yesterday I was teaching a class where many of the attendees were from the same company. They had one major issue: Almost every sprint, either the Product Owner or a Stakeholder would add one or more stories in the middle of the Sprint.

I find this is a common problem.

And indeed, the new stories are often very important. Still, that is not necessarily an excuse for adding them (Can’t they wait until the next Sprint? Don’t they want to know what the real velocity of the team is?).

This is a complex problem.

But sometimes it is as simple as…Tell Her No. This is a song by The Zombies. A little fun might make it easier to say No. See here. (And remember the ever-friendly quote: “What is it about No you don’t understand?”)

While we must be compassionate (do I always say No when I should?), still we must say No more. In a nice way. My Yes means very little if I can’t say No. I recommend this book by a friend of mine. Bill Ury also co-wrote Getting To Yes.

Again, No isn’t always the right answer. This is a more complex problem.

Have Compassion

Posted on September 27, 2007 by Joe Little

Today I was in a meeting with Business and Technology folks, and I started talking about Customer Collaboration over Contract Negotiation. (Many will recognize this line from the Agile Manifesto.)

And I talked about how, always, there is distrust and tension and misunderstanding between the Business side and the Technology side. Well, at least on day 1 in every client I walk into. YMMV. With luck, we start building trust right away.

In thinking about this on the plane back home, I wanted to say something to those 12 people. And since they are not with me now, I will say it to you.

Have compassion.

What do I mean by that really?

First, the most important thing is that it is more blessed to give than to receive. More specifically, it is not about you. It is about doing for others, most especially for the end customer.

Let me introduce my second point with a story. When I teach Agile I like to start with the story of the 6 Blind Men and the Elephant. I won’t explain that story now, but one reason I like it is because that story is also related to Buddha. The compassionate Buddha, as he is known. And Buddha had great compassion for us, and our inability to comprehend all the knowledge we needed to know, and to figure out what is really important. And I say, we team members should have compassion for each other and how hard our work it, how much we need to learn. We try to solve the problems if a person who almost always is not there, and do it with a system that is abstracted and non-concrete in the extreme. And all the easy projects have already been done. Difficult work. We need compassion.

My third point is more specific. My experience is that most Technology folks have no conception of how difficult it is for the Business folks to see and be accurate about what the business need to do to satisfy their customers. The customers are changing, the competitors are changing, they don’t have time to understand what is do-able. This is extremely difficult work that only a few are truly insightful about. (In our economy, many are modestly lucky.)

On the other hand, the Business folks need to have more compassion for the technology guys. Technology work is extremely challenging, and offers great opportunities for creativity and discovery for those Business folks willing to travel those uncharted seas. And capable of escaping the dense fogs.

My fourth point starts with Deming, who has many valuable insights. Deming said that all problems in business are caused, in simple terms, by two things: “the system” and the people (vices, true inability, laziness, etc.). The “system” was all the things that were (or were not) there to structure the people and the work to get the work done. Initially he guessed that 80% of problems were caused by the system and 20% by people. As he grew older and learned more he revised that. I think he finally said that 95% of problems are caused by the system and only 5% by the people. And a leader’s job is to get the system improved.

My point here is that, while you may be frustrated in some ways with your colleagues, most of your frustration is not about them, but about how “management” (maybe yourselves) have structured the system through and in which you work together (or not together).

Have compassion. Have patience. And start improving it today.