Scrum 201: Desire

Posted on April 24, 2013 by Joe Little

Any sports coach knows that the Team must have desire.

In my classes I talk to the people about how much improvement they expect to make in 1 year. With 1 team. Often it is in the 20% range.

And I use Henry Ford’s famous quote: “Whether you think you can, or you can’t, you’re right.” So, I usually think that 100% improvement in 1 year is realistic for a specific team.

As a coach or a SM, if they are going to achieve hyperproductivity, the Team must want it. And, to some degree, they must believe it is possible.

So, the question becomes, how do you get them to have the desire?

This is not an easy thing. In fact, you cannot make them have desire. But, if there is something inside them, you can draw on that. You can blow on that ember of desire, and make it blaze.

Sometimes you can give them a challenge. To be the best team in your company, or your state. For example. Or to be much better than they are today, and prove that with metrics.

In Lean, we have the idea, expressed in a Lexus ad, of the ‘continuous pursuit of perfection.’ So, we establish a vision of perfection. (Usually we know this vision is not perfect, or later we see it is not really perfect. But it motivates us; it gives us something concrete that seems within our grasp.) So, we use the vision of perfection to build the desire.

Little’s Second Law: People are remarkably good at doing what they want to do.

So, if you can help them build their desire, in a concrete way, then they can start to make the changes that can drive tremendous improvement.

We band of brothers

Posted on March 7, 2013 by Joe Little

“We few, we happy few, we band of brothers.” A great speech did Shakespeare write.

Here it is explained. The leadership in the real field of battle, against great odds. You may find this interesting as well.

Here it is enacted. Kenneth Branagh. You may wish to go to about 2 mins 20 secs in.

A bit later King Henry speaks:

We are but warriors for the working-day;
Our gayness and our gilt are all besmirch’d
With rainy marching in the painful field;
…

And time hath worn us into slovenry:
But, by the mass, our hearts are in the trim;

You may perhaps recognize yourself in this situation: that time hath worn you down, yet still your heart is in the trim.

Enjoy!

And may your Team have its heart half so much in the trim.

We want a Stable Team

Posted on January 27, 2013 by Joe Little

I think our (your) business is about knowledge creation. (Well, knowledge creation is key for almost all the people who come to my courses and workshops.) It is about innovation, creativity, inventiveness. About cool solutions to hard business-technology problems. It is about some sort of intersection between people and technology. So, coming up with a great product requires something special.

And I believe the ‘special thing’ these days is far more likely to come out of a good Team.

So, from a business management viewpoint (and it is the managers we most need to convince about this) — we need a stable Team.

And it needs to include virtually all the functions (or far more so than we ever did before). And that also means it needs to include business people and technology people. Just for amusement, I like to call them suits and geeks. To me it suggests that it just might be ‘interesting’ to put them together.

We must mention two things.

It should be FUN to work in a real Team. And in fact, in Scrum with all but dysfunctional teams, it is fun. (But maybe could be more fun, if you had a good ScrumMaster helping the fun along.)

It should be more satisfying working in a Team. It is my belief that the human animal has been selected to enjoy life in a small Team. Like a family, but a bit different. A small ‘pack’. Maybe within a larger pack.

So, how long should a Team be stable?

To answer this question, we need to identify basically three situations.

1. Mediocre Team. This team improves 20-50% with Scrum. Give them 6 months. If they don’t become better by then, then try putting the individuals in different Teams.

2. Good Team. This team improves in the 100-200% range. Wow. Leave them alone. They are doing pretty darn well.

3. Great Team. This team improves in the 5x-10x range. Wow! Don’t mess with them. This is the goose that laid the golden egg. You would be crazy to bother them unless and until they want to be bothered (want to change). And, if you continue to give them good satisfying work to do, they may never need to change. But, of course, something will eventually happen…one of the usual human things (birth, marriage, death, move, etc, etc).

(There is also the situation of the occasional dysfunctional team. Usually that can be identified in a few Sprints. As soon as you are sure it is not just ‘storming’, then you must change the team composition or totally bust up the team.)

***

This idea of stable teams leads to a major shift in orientation. (The change can happen over time.) We no longer start with projects, and find people to do them. We now start with a Team, and find good work for it to do. Who knew that people were important?

Who is Scrum for?

Posted on November 27, 2012 by Joe Little

A few months ago someone I know and respect in the Agile community said that they do agile to make the world safe for programmers.

This phrase has stuck with me. I don’t know how seriously the person meant it. I suspect it was partially a joke and partially a stronger statement than one might think. I suspect it is a real driving force for that person.

And it is true that many implementers have had terrible lives, at least often, and making the world better for them is a very good thing.

But I think we should strive for more than that.

We need to make the world better for everyone.

For example, the customers do not want software (usually), they want something useful that will make their lives better. The managers need a better life. The project managers need a better life. The business owners need a better life. The testers need a better life.

Everyone around or affected by Scrum should be getting a noticeably better life. And one easily noticed, in terms of the improvement.

This is happening, although it is not happening as much and for as many people as it should. And when it is happening, it is not being noticed and celebrated as much as it should.

Why?

Well, I think one fairly important reason is that too many of us are being selfish. For example, we are so afraid that the programmer may have to work and be modest and admit failure, that we disable the mechanisms (velocity and demos, for example) that enable the customers and business people to collaborate with the Team.

Anyway: It is an odd request. We want everyone’s life to improve at the same time. No trade offs.

Can it be true every minute? Well, perhaps not. But can it be true every sprint, looking back at the sprint in total? Yes, I think so.

Meet the Meeting Killers

Posted on May 17, 2012 by Joe Little

Here is an entertaining article in the WSJ. About people “types” that kill meetings.

Scrum of course has some meetings. It is trying to minimize meetings, and make meetings better.

But as soon as you have people and meetings, you can have some….umm…interesting times. So, may your meetings not be interesting this way.

More on: The Product Owner and the Team

Posted on February 16, 2012 by Joe Little

There has been some interesting discussion on this topic recently.

Two things I wanted to add to my prior post.

1. The business side cannot force the Doers to “do all that I say” in the Sprint.

This is of course a well-known rule of Scrum. But this rule does eject the PO from the Team.

So, in one scenario, the PO cannot force the Team to do all X stories that he or she wants done in the Sprint.

But even before that, the PO should want reliability, meaning, if the Team commits to 8 stories, then at least 8 stories will get done (or done, done — if you prefer) in that Sprint. The PO does some of the ‘real work’ (in the form of providing information about the stories and feedback, mainly), so the PO has a say about what he/she can or cannot do to support the Team that Sprint.

What I usually find in the real world, is that the Doers (eg, the coders and testers) want to over-commit. And the PO (at least) should be saying “no, let’s not over-commit — I and we need to predict for the customer, and we need to know what the Team can really do at sustainable pace”.

But at least the Business side (often in the person of the PO) cannot force the Team to do 8 stories when, in their professional judgment, they can only do 7. As an example.

Exactly how the Team self-organizes to reach that judgment is up to each team, but ejecting the PO is not an option. The PO has at least some lights on the problem, and so should be heard, just as, for example, the junior tester has some lights on the problem.

There are many possible scenarios, but these are the basics.

2. The issue of whether the PO is part of the Team (yes!) is far greater than just the issue of Sprint commitment.

Yes, Scrum teams have problems with the Sprint commitment. All kinds of problems, with multiple root causes. This was partly discussed (indirectly) in a recent post.

But in the shorter term (eg, intra-day) and in the longer-term (eg, release), the PO is an important part of the (full) Team.

Let’s take the Release, and the use of Pareto’s idea of the vital few. So, the whole team must be optimizing the 80-20 rule at every level of work (tasks, stories, epics, etc.). And discovering how to do the least amount of work to deliver quickly the best possible product. (See the Agile Principles.) This is a Team effort, led in large part by the PO. But still a full Team effort. The key related idea is cost-benefit analysis (hey, there’s another new one!)… how to get the most benefit or business value for the least effort. Again, a joint effort by the full Team.

When troubles arise (and troubles in some sense always arise), who is the Team that will address them? ….well, both the Business side and the Technology side together must collaborate to address them. We might too easily say that in general, both sides must compromise. Each side must accept “lack of control” but high “power to influence”, and create some modus vivendi….some way out of the problem together. How do we do this in a practical manner? The simple way of saying it is that the full Team (with the PO) must figure it out.

Again, there are many scenarios, but those seem to us the basics.

***
Yes, I know there is much ‘legacy code’ in our wetware (our brains, etc.). But this I think is the way forward.

Respect

Posted on August 19, 2010 by Joe Little

I just led a course in Charleston. To mostly people working in/on government or military projects.

I was asked many good questions, and I was not able, in the time allotted (2 days) to answer them all as well as they deserved.

I have other clients who have also very difficult situations to deal with, but I was and remain very sympathetic with the difficulties they (this government-military group) face. In implementing Agile, for example. Still very possible. And still I believe it will yield very clear benefits. But also difficult. Perhaps especially given the surrounding ‘culture’.

So, first, if my answers ever appeared to be disrespectful of the difficulties and challenges you face, my apologies. This was never my intent.

I, like you, have struggled and sweated or worried about how to implement lean-agile-scrum in specific situations. It is indeed hard. In fact, always it feels hard, in part because one wants to do it perfectly. So, again, if my comments seemed to be flip, they were not said with that intent.

So, what was I mainly trying to say?

1. Sometimes, we worry too much. Yes, sometimes we get all in a sweat about a certain issue and in fact that issue will resolve itself easily in good time (sometimes that means quickly, even). (This one is not #1, so much as easy and quick to say.)

2. Mindset, ie, the first and often hardest thing to change is our own mindset about the problem.

a. In part, this means we must start by seeing we are ‘right’, and they are wrong. Not in an arrogant way, but more in the core of our being. We hold the truth and therefore the real power, and we are patiently waiting for them (maybe a manager) to get a clue and get out of their fantasy world.

This attitude, if not done arrogantly, they can still feel. And it makes them realize, sub-consciously, that they are in the wrong place, and must change. Now, we sympathize with them as persons, but not with their wrong ideas.

b. We must understand that we approach certain ideas and issues with very different premises than they do. And so, understanding the mindset shift, we look for statements from them that reveal the old mindset so that we can attack it. For example, we know we want to optimize delivery to the customer. When they say they want to keep the workers busy, that opens up a good conversation about the goals of management.

Sp, often I did or will answer your question with something, maybe a sports metaphor, from left field (as we say). The reason often is to focus on the mindset shift. Not to diminish your issue or question.

3. Time.
Often attendees ask very good and very difficult questions. A good answer would really require 2 hours of Q&A to be sure I really understood the specifics of their situation. And probably then another hour to formulate and explain 10 approaches to dealing with a hard issue. In the CSM course, understandably, I do not have time for 3 hours devoted to one good question.

So, I say something brief. And I often worry later that it can be taken the wrong way by the questioner. I do usually ask “did I address your question at all or well enough?”, but maybe in specific situations I need to say more to be better understood.

4. Self-sufficiency.
One of the properties of complex adaptive systems is that they ‘solve’ their own problems. Not always in isolation or fully or completely. But they can learn and can adapt. So, in part I am relying on you to use the values and principles we discuss (and maybe even some of the practices) to devise your own answers to the problems you pose.

I have confidence that you can and you will.

5. We always have impediments.
Meaning: We can still be successful even with lots and lots of impediments. Success with waterfall is one example of that. But, more generally, even though none of us ever reaches perfection, still we may say we are having many successes (eg, with lean-agile-scrum).

So, I know from experience, that even though your question may be about a very big impediment for you, still, even if we do not even address it, almost surely (I have seen this so many many times) you and your team can still have better success with Scrum than with what you used before. Even if that impediment is not addressed at all.

Now, yes, a few people might have had an impediment that does stop them in their tracks. I think this is possible. But, honestly, I have been doing and talking about this for a good while with many people, and I never seen such a case, I think. With the exception of ‘people’, which is indeed very difficulty to deal with. (“Our manager won’t let us use Agile.”)

Anyway, if I have seemed less than sufficiently concerned about your issue, it was not that I did not have sympathy, but maybe that I did think you could work through it or be successful despite it.

I did respect your question.

If you wait for perfection, …

Posted on April 1, 2010 by Joe Little

If you wait for perfection, you might wait too long.

There are some similar quotes, but so far as I know, this quote is mine. As the father, I kind of like it. But most parents love their own children. (If I am not the father, tell me now.)

This applies to all of life. And to Scrum and Agile and Lean. As the guy said to Jack Lemmon in that famous movie, “Nobody’s perfect.” In fact, not a single thing is perfect. So, my advice is: Don’t wait for perfection.

Still a big problem out there. Too many people doing it. I usually don’t do it more than 3 times per day.

Use this quote to work on ‘em. Make life better now, before it gets to ‘perfect.’

One of the biggest business problems we have.

How honest should you be in Scrum?

Posted on March 17, 2009 by Joe Little

First answer: Completely.

Ah, if only the answer were that simple. Sorry, George, but Scrum and Agile provide no cookbook answer to this question.

Some people use “honesty” to mean they get a right to be brutal to others (and also to ignore their own imperfections).

Much more often, the de facto thinking is “honesty means I won’t say anything obviously incorrect and I will speak up more than I did before.” (Well, I don’t want to hurt anyone’s feelings. And I didn’t say much before anyway.)

So, for most people, the operational answer is: Be a LOT more honest than you were before. Both with good news and with bad. And even about yourself.

It turns out that once there is trust on the team, this is not so hard.

Still, like most things: Easy for me to talk about here. Always challenging for a team to do at the highest level in the real world.

All business is personal

Posted on September 14, 2008 by Joe Little

We are in the political season, sometimes called the silly season. I will avoid discussions of politics, but I said that to introduce a well-worn phrase: “All politics are local.”

Whether that is true or not, it led me to the observation that “all business is personal.” That phrase and a note on this blog by Shannon Wagner. And a discussion with my sister-in-law in the mountains.

Business is a revealing of who we really are. Business is an acting out of “love thine enemies”. Business is the 12-step program to becoming a mature person. Business is how we really help our grandmothers, our kids and those members of our families who have known hard times. Business helps us appreciate that it is more blessed to give than to receive.

Yes, Virginia, there is much evil and much failure in our being and our doing. Business is that process of refining that out, however slowly it may drip out, drop by drop.

Some people think business is about money, as though it were a zero-sum game. This is not so.

Yes, making a reasonable return for capital investors is a constraint. Like side-lines in a football game. But it is not the game. In business, you score each time you make someone happy. Make just one someone happy…(if you remember that song that Jimmy Durante sang).

Agile is personal, for example. It’s between persons.