Yogi Berra quotes

As some of you may know, my sense of humor, such as it is, finds Yogi Berra quotes both entertaining and educational.  I use some of them in my classes. My hope is that the humor allows people to remember things a bit better.  Or in some other magical way, helps learning.

For those who don't know who Yogi Berra is, he was a famous catcher for the New York Yankees baseball team, and later the coach for that team.

Here is an article about him:
http://en.wikipedia.org/wiki/Yogi_Berra

And here is a collection of his quotes:
http://agileconsortium.pbworks.com/w/page/44303643/Yogi%20Berra%20Quotes

A fact checker has not ascertained whether each and every quote is a certified Yogi Berra quote.  But then, as he said "I didn't really say everything I said."

I think some of them even directly apply to Agile. But you be the judge.

In any case, enjoy.

The Four Key Things

In my courses, I strive for 4 key things.

1. I want you to believe "I can do it".

2. I want you to have some clue about the direction and what you want to do.

3. I want you to be scared. Yes, scared. At least some.

4. "If you wait for perfection, you might wait too long." So, don't wait. Start now.

Why scared? Well, I want lean-agile-scrum to be so important, so good, so useful in your opinion, that you are anxious that you won't do it well enough. You know you don't know enough to do it perfectly. While it is simple, yet it is complex. You know it is hard. And yet, you still do it.

So, you can see that balancing 1 & 3 is hard.

Of course, you know the definition of courage. It is: Doing something even though you are afraid. If you do something with no fear, then there is no courage. You might be overly-confident, or you might be foolhardy. But you are not courageous.

And I know you have courage.

Let me end with two Yogi-isms. (Yogi Berra, that is.)

When asked "what time is it?", he answered: "You mean now?"

He also said: "The future ain't what it used to be."
I like to think he had become more optimistic. With every mistake we must surely be learning.

Leadership - 1

Takeuchi and Nonaka have written an article on Leadership in the Harvard Business Review. The latest issue.

Since they are the godfathers of Scrum, one feels compelled to discuss leadership in the context of Scrum.

First. we must note this is a big topic, and with somewhat different issues depending on the size of the firm. Also, leadership is separable from lean-agile-scrum.

Within the context of Scrum, let's over-simplify and consider leadership at three levels. Within the team, immediately around the team, and top-level leadership.

Within the team.

We find that the most important thing that a team does is create knowledge. (Knowledge creation has been one of the main topics for Takeuchi and Nonaka throughout their careers.)

We find that power and knowledge creation do not go well together. Let's mention some words that go with knowledge creation: innovation, invention, creativity, discovery, seeing new, finding creative unexpected solutions to tough technical problems, intuition, prescience, sympathy.

And the innovation, the new new product, must be not only clearly new, but also relevant to the customers. And, usually, something that can also make money for the firm. And we want all three of these (new, for customer, brings bucks) to the utmost degree.

So, inventing a new product is somewhat like magic. Certainly in some degree, it is magical when successful.

So, perhaps you can see now why power and creativity do not work well together. We want all the team to contribute together, to try to see, like blind men, the full elephant together. Acting from power, or even just perceiving power, can inhibit this creativity. Or so it can usually. And the inhibition is hard to see or feel.

Leadership and power are not the same thing. Of course. Although they are often thought to be related.

The Product Owner and the ScrumMaster are often thought to be leadership roles. And I would agree. This means, when things must happen or when decisions must be made, they should make them. Typically, each in his own sphere. (We won't go here into the distinctions between the two roles.)

As Yogi Berra said: When you come to a fork in the road, take it. Or, as Ken Schwaber has said: Few things are worse than not taking the decision. It is almost always better to take the decision and learn from the results. (Not always, but almost always.)

We also recommend each member of the team consider himself or herself a leader in some area (typically, the area where he or she is strongest). Depending on who each team member is, this may not be realistic, but I suggest it is almost always realistic to some degree. In any case, we suggest that team members consider that they are all responsible for the success of the team. This means that. when they see something that should be exploited more, or a problems that must be addressed, that they each have the right and the responsibility to step up and lead in addressing that issue.

The standard leadership style recommended with Scrum is what Robert Greenleaf called Servant Leadership. The simplest version of that is the ScrumMaster who asks the team 'what is your biggest impediment now?' and then goes about getting it addressed.

The more complex version involves a few things:
* caring for the team (so that the team know it)
* trying to help the team be more successful, both in their immediate effort (the new product goal), but more broadly as a team and as individuals, each in his own life.
* being willing to sacrifice himself for the benefit of the team
* respecting the team

Let us stop for today on this difficult and interesting topic.
More soon.

Implementing Scrum when not everyone is a believer

How do you implement Scrum in an organization where not everyone is a believer?

Umm. This is a common question and a hard one. And yet also easy.

First, one misconception is that Scrum is a religion that only true believers practice. Scrum is actually empirical. Now, it should be said that Scrum (and lean-agile-scrum) has ideas that are on the surface counter-intuitive, perhaps we might even call them paradoxical. Example: "You have to go slow to go fast."

(I hope you will smile to see the picture of the waterfall model true believer.)

But mainly, we want everyone practicing Scrum to do so out of free will, and with an appreciation that it can and will produce a better result. And, if, after giving it a fair trial, it does not produce a better result, then you should examine the root causes. It just might be that the root cause is that Scrum is 'wrong for us'. Scrum is empirical. We live with reality; we face the truth.

Let me be honest. I do think there are some people in a few of the Myers-Briggs categories who should not be doing Scrum. Because it has too much relative 'chaos' for their personality type....but indeed, for that personality type, there is in reality too much chaos in new product development in general. They also should not be doing new product development.

Still, for most people, if 'scrum' seems to fail, I have never been convinced that it was really Scrum that failed. Typically, at least in my opinion based on what I knew, they did not do it well enough, fully enough or professionally enough. So, it was not truly Scrum that failed. But I might be wrong; I certainly have a limited data set; I have not seen anything close to every Scrum implementation.

Next: Most people who start Scrum are not really all that familiar with lean-agile-scrum ideas when they start Scrum. So, we are asking them to willingly suspend disbelief for some trial period. They are welcome to remain skeptical in a sense, but should make every effort to give it a fair trial. And they will do it 'ugly', as any beginner will. What is quite remarkable, in fact very very remarkable, is that even after only three 2-week Sprints, the Scrum that the beginning team plays is already better than what they were doing before (which they had practiced and used for some years, typically). This is really extraordinary!

Let me emphasize this again, another way. Many of the ideas of lean-agile-scrum are counter-intuitive and for many people will appear to be 'wrong' in many common situations. It is only with experience that the ideas will start to be regularly obvious and intuitive. This is not because the ideas are wrong, but simply because our minds are so used to (wrongly) another paradigm of looking at our work.

Now, sometimes, especially if they feel forced to do Scrum, the team cannot help but sabotage it. They can indeed, in my opinion, make it fail.

So, before the trial project, we should make reasonable efforts to get them to a place where they can give it a fair trial. And feel somewhat comfortable doing so. (Change is always somewhat uncomfortable, so expecting every team to start with 'excitement' is not realistic.)

Some suggestions in this area:

1. Give them training. Example: A Scrum course.

2. Give them a workshop. Example: To do release planning and sprint planning as a team.

3. Give them coaching. Example: Coaching for 3 consecutive days at the beginning of the first Sprint. And then 3 more days at the end of the first Sprint and the beginning of the 2nd Sprint.

4. Talk to them about lean-agile-scrum principles, so they start to understand the music behind the Scrum dance steps. Reinforce this as they experience 'issues' in the real-world implementation of Scrum. ("Talk" can include books and articles.)

5. Do not expect that they will fully understand it immediately. (Did you fully understand baseball when you first started playing it?) Expect them to forget even some of the basics that you told them or they were taught. All lessons, for all humans, must be repeated. The best we can say for people good at change is that we need fewer repetitions of the basic lessons. And do not expect all your people to be good at change. (That does not mean that they will be bad team members....They are good at other things, just not good at change.)

6. Do not let them feel Scrum is the idea of one person. It is not owned by you. It is not 'owned' by one trainer. It is not just Jeff Sutherland's or Ken Schwaber's idea. Many, many, many people have contributed to the idea set. Many, many, many different teams have used it with success. In almost every conceivable environment.

7. Find out what they might propose instead of Scrum. If it is waterfall, help them to understand that even the key people who originally advocated waterfall (the US DOD and Dr. Royce, for example) no longer do so. (In the case of Dr, Royce, his son no longer advocates waterfall.)

8. There are lots and lots of techniques and an endless list of specific things you can do to influence people. See, for example, Fearless Change by Manns and Rising. The list is indeed endless; you never run out of more things you can do. You might exhaust you own patience to continue trying to change someone who seems completely unwilling to change.

9. Remember this famous adage: "People do not resist change. They resist being changed." One meaning: Be sure your 'target' does not feel you have to change him. He should feel as though you are helpfully, fairmindedly sharing ideas that might actually help him in his own life (as he values things in his life).

10. Remember to go with the flow. In Hapkido (martial arts), if the opponent resists going one way, then we use their counter-energy to flip them the other way. There is always a way you can use their energy against them. Assuming you are aligned with the source of energy and truth. Laughter is one of those paradoxically powerful forces.

Remain positive, realistic and undaunted. You are indeed helping the world be better; yet you know it will never be perfect. Be patient with those whose eagerness to change is less than yours. As Yogi Berra said: If the world were perfect, it wouldn't be.

Dear Rob - 2

Rob, as some readers may recall from the first post, is a made-up character, representing a typical senior business executive, responsible at a high level for the agile initiative, among many other things. Perhaps the CEO (although probably not a CEO at the Jack Welch level at GE.)

In this post, we talk about Quality and Technical Debt.

****
Dear Rob,

It is interesting that you want to focus on quality first. This is actually a very good thing.

In Agile, we start to do professional testing in the very first Sprint. This is much earlier than in Waterfall, as you know. Many reasons for this; among them, we can measure progress by the amount of completed, 'fully' tested code.

In Scrum, we have what we call a Definition of Done for the team. It defines, for the typical 'story' they are working on, how 'done' the story will get to. Like the meat metaphor: rare, medium rare, medium, medium-well, and well done.

Fully done, done, done means the product (and the newly finished stories) is/are in production and being used by the customer with no problems. Most teams have too many impediments to get to done, done, done in one Sprint (1-4 weeks). At first.

The Definition of Done should also make clear, especially for the Product Owner, what is not being done in the Sprint. For example, often the team can't do a full, full regression test in a fully integrated environment. Often (full) performance testing can't be done. Etc.

As Ken Schwaber suggests, this 'undone' work needs to be added to the Product Backlog somewhere.

Two reasons we don't like anything but 'done, done, done' product increments. (They are related reasons.)
1. The bad news is getting better with age. Meaning, of course, worse. For example, all the undiscovered bugs are quickly becoming harder and harder to fix.

2. The 90% problem is growing.
The 90% problem is, for example, very common in software development. A manager goes to a team and asks them how complete they are. They say 90%. And then he (usually a he) asks, 'how much longer to be 100% done?' And they say, 'oh, it took us about 9 months to get to here....ummm, that will be another 9 months.' Yogi Berra summarized this problem by saying: "It ain't over until it's over."

So, any time the Product Owner sees things in the Definition of Done that are not getting done in the Sprint, he should worry about the 90% problem and discuss them.

Technical Debt

What does this mean? Well, there is no one simple definition of technical debt. I say it is anything in or around the system that makes it harder to change.

Examples include: duplicative functions or modules in the code, spaghetti code, lack of automated tests, zero or poor documentation (in the code, perhaps), code written by George (when George has left the firm), the bug list, any upgrade (eg, to the database or the language or some middleware) that we have put off, etc, etc, etc.

Every system that is 6 months old has some technical debt. And it is starting to be obvious that it is hurting us. Older systems have more technical debt.

If your product is older than 2 years, I can just about guarantee that technical debt is a (very) serious problem in your shop. And that real velocity is (very) low.

In simple terms, technical debt decreases the velocity of Scrum teams.

We (seemingly purposefully) grow technical debt by saying "we have to deliver features now; let's put that stuff off until later." And then we do that. That 'that stuff' is identifying bugs, upgrading the XYZ, fixing bugs, etc.

Every manager must start understanding technical debt, and fight to get the team to dig out of technical debt. If you want any business agility. Meaning: We can adapt and change with the market and customers faster than our competition.

Impediments

As we discuss these matters, you will find that your shop (and every shop) will discover impediments. It is tempting to say: This is Scrum's fault! In fact, Scrum is only making the problems around quality and technical debt more visible. To blame Scrum is only to blame the messenger.

So, don't be surprised that the group identified a bunch of impediments. And that they cost money to fix. And that you will get real business results (better quality, eventually lower cost, etc.) from that.

How do we dig out of Technical Debt?
How do we improve the Definition of Done over time?
Mainly by removing or reducing (certain kinds of) impediments.

Quality Metrics

One way of minimizing and maybe reducing technical debt is to focus on quality.

Now, quality is itself a complex subject, and its full and complete nature depends on the specific product and your customers.

But in simplistic terms, one might say it is the lack of technical debt. Or one might say that it means the customer gets a perfectly fitting product (to her problem), with no added 'features' (eg, bugs), no extra delays, no extra effort.

As relatively low-level indicators of quality in Scrum, we can measure:
* no bugs escaped the Sprint this week. Meaning: For all the stories we say we completed in the Sprint, we did a professional (automated) testing effort (eg, unit and functional, at least), and any bugs identified were fixed and retested in the Sprint.
* X number of new automated tests were built this week (maybe one number at the unit level and another at the functional level)
* Y number of automated tests are passing in the regression tests this week.
* Our Definition of Done is relatively strong, meaning that, in areas 1-5, when a story is done, it means that no technical debt was built in those areas (at least). Or at least we made a serious effort to minimize the new technical debt being built.
* The list of (pre)existing bugs is prioritized, and shrunk by Z items or A% this week.
* We have prioritized the work around an increase of code coverage by the automated tests, and it increased B percentage points in the past week. (And these were meaningful, useful tests, not just baloney tests to make the coverage metrics look better.)
* We saw that in the last release, field issues decreased by C%, comparing first month to first month.
* Our velocity has increased X percent. This is in part due to less technical debt and in part due to less effort per unit of work...due to: better configuration management, better continuous integration, better testing tools, and faster testing servers. (* If you don't understand some of these terms, and how they are inter-linked, we should talk. You need to understand them a bit, since they are key to each (Scrum) team's success.)

Measuring quality is complicated, and my comments above are over-simplified. But, if the business and technology folks both know you care about quality, that will help a lot. A reasonable, and fairly frequent, discussion around quality metrics can help focus their attention on that. Be careful about getting too focused on one aspect of quality, one metric. The keys are (a) higher quality for the customer, as the customer defines quality, and (b) lower technical debt.

Regards,
Joe

***

Again, please give me feedback. Did this all make sense? Or did some of it sound too geeky?

It is actually not all that geeky, but if there are some geeky terms that we need to explain, I think almost surely you need to learn them a bit. Not become an expert in them, just understand them enough to guide the product development group.

Also, please give feedback on what you want to discuss next.

CSM + Workshop: Why so successful?

At the insistence of my good friend and colleague, Catherine Louis, I started doing Certified ScrumMaster courses (2 days) followed immediately by a 2 day Workshop.

This experiment (which it was for me at first) has proven completely successful.

I am now convinced that this is the best way to learn Scrum. Period. And I am convinced mainly because everyone tells us this is so. ScrumMasters, Product Owners, Team members, Managers. Including the managers who insist that it is a MUCH better value to pay extra to get them into the full 4 days.

What do we mean?

First: The best is to have the whole team and some closely related managers attend the whole 2 day Certified ScrumMaster course. Obviously, it isn't just for ScrumMasters anymore. (Was it ever?)

I won't describe that course here, but suffice to say that the way we do it includes lots of interaction, some challenging questions, some improv, some team exercises, including a very realistic Release Planning exercise.

Then, we have the same real team (well, teams, really) do the 2 day Workshop. Each Workshop is a little bit different. But the focus is on two things.

Complete a good (decent) Release Planning for the real project or effort that the team is working on. It is best if the team is just starting the effort. And it is best if the team has access to all the people and resources to make the Release Planning effective. Release Planning includes (over-simplified): Vision, Product Backlog development, Business Value (points), Story Pointing, Risks-dependencies-other, Ordering the work, Deciding the scope-date trade-off, Budget. We also talk about infrastructure, architecture, and design (IAD).

Second, complete a version of Sprint Planning. Over-simplified, this includes: Agreeing on the PBIs (product backlog items, or user stories) to commit to in the Sprint, and breaking the Stories into tasks. And fully committing. (I define this as: "We believe, 9 times out of 10, with the usual "stuff happens" around here, we can get all these stories done, in our best professional judgment. And maybe do more.")

Why is the Workshop so important?

Well, in theory, it should not be. But in practice, it is very important for almost every person.

Because it takes the "theory" of the course, and puts it into ineluctable practice. (Ineluctable is a fancy word from James Joyce, meaning "incapable of being avoided".) So that the stark and real meaning of the ideas becomes so much clearer in the real world of the team's real work.

The Workshop is done under the guidance of typically two very experienced coaches (Catherine Louis and myself, so far). We offer has much coaching as we think appropriate, which is more than directly asked for. We keep in mind Yogi Berra's advice (about hitting in baseball): "Think? How am I gonna think and hit at the same time?" That is, too much advice can actually hurt beginners more than help them.

The head-bobbing in the course no longer is good enough. One either "gets it" (to some degree) and does it. Or not.

Some times some resistance becomes more obvious. But usually in the 2 days of the Workshop, that resistance is overcome. Not by the teachers talking at them, nor by anyone else just talking at them. But because their concerns, which maybe have some basis, are soon seen to be minor compared to the benefits. (I do not wish to suggest that all resistance is always and completely overcome. Just that it is addressed much more effectively.)

Does that help? Is that enough?

FAQ

Here are some frequently asked questions.

1. What if I am not attending with my own team?

We can form a Team of people, and you can participate with that Team. Or you can join a real team, for the Workshop, as a consultant (with their permission). If you are partly of an ad hoc team, then we want the Product Owner of that team to be working on his real project or product or effect. So, at least for him or her, it is very real. And that person is responsible for making it real for you.

Is it less effective? Yes, probably somewhat. Is it still useful? Yes. We have had no-one in this category say it was not useful.

2. How many teams are you coaching at a time?

In the workshops, we think it is best to have about two teams per coach, maybe three. So, if there is a large group, there typically will be two coaches.

3. Do we need to prepare?

Yes! As much as you can. It will still be useful even if you do not prepare at all. But the more the Product Owner is prepared with all the information the team will need to do Release Planning, the more effective will be the use of your time. This ideally and typically means including the other key business stakeholders (SMEs) in the workshop team. If you can.

But "if you wait for perfection, you might wait too long." Do what you can before the Workshop, then, wherever you are, do the Workshop.

For a client perspective on the workshop, see here.

How I teach - 1

For those who will teach and for some puzzled course attendees, I want to do a series of posts about how I teach.

First, the goal is not to teach. Or, more clearly, the goal is neither teaching nor learning, but results (ie, more than just action, but actual results from action). Results for you, for your team, for your customers. That is the only goal that counts.

If you think I 'fail' as a teacher, and yet you get results...to me I have succeeded. Such 'failures' I will take any day.

OK, so I conduct the class in such a way as I think best will lead to the most results for the most people.

Right away you see certain 'philosophical' or fundamental issues have been addressed with certain assumptions. Assumptions that we have developed over many years of experience, but assumptions nonetheless, as we are far far from omniscient.

For example, we don't assume that everyone is the same. (In fact, closer to the opposite.) Nonetheless, at any moment, in overly simple terms, only one style of teaching is going on at that moment.

Second, I don't assume that the brain is the most important part of the human being. The soul, the spirit, the heart, the guts, the will, and many other parts are also important. There is increasing evidence that they are more important. At least in terms of real results.

Third, we have a theory, based partly on Piaget and others, that the mind resists changes to its fundamental constructs of the universe, of how 'things work'. And we have a theory that lean-agile-scrum is a fundamental paradigm shift in many of these constructs. So we are subversive. There, we have admitted it openly. We are trying to sneak up on your brain. But in a good way. Not to rob you, but to give you a gift more quickly.

Fourth, while lean-agile and scrum particularly are very simple (like all great things), at the same time, they are very complex. We hold the perhaps arrogant view that, at least vis-a-vis lean-agile-scrum, we are smarter than you. (And that's why we are leading the course, and not you.) So, while we get you active and talking, there are, sometimes rather indirectly, some things we are trying to tell you. We might wait for you to discover them on your own, and we might wait for monkeys at a typewriter to eventually write Hamlet. But, frankly, while we have some exercises where you discover things for yourself, for everything we are not that patient. Given that we only have 2 days for the basic course. So, we "tell you". (Some might call it 'lecture', although you might not. In any case, a different kind of lecture than most are used to.) Yes, yes, yes; we know all the problems with that. But we actually think that some people, if we add jokes and other tricks, actually stay awake, actually listen, and actually learn this way.

As Yogi Berra said, if people don't want to come out to the ballpark, nobody's going to stop them. Meaning: If they don't want to learn, fugetaboutit!

Also, we frankly are not clever enough to come up with enough exercises that can be done quickly. And, having felt 'played with' (in a bad way) by some of these kinds of games ourselves, we are sympathetic with those who are naturally skeptical of games. So, we still do some games and exercises, but maybe not as many as others. Instead, we use other tricks.

It perhaps bears saying at this point.... What we teach are not ideas that we invented. We feel we have been blessed to share the wisdom from men and women on whose shoulders (as the metaphor goes) we stand. It is a great wisdom, from the gods one might say, and we are humble about our real ability to pass it along as accurately as it deserves. And yet, despite the jokes and playfulness, which in some eyes might imply lack of caring, we value this wisdom very highly. And we think reaching the inner secrets of this wisdom is difficult. Realizing in a full way the most benefits is very very difficult. And, paradoxically, as with all great things, it is in fun and with great ease that the most benefits are realized. Trying too hard does not help. As any baseball player knows, we must simply swing the bat, and just let happen what may. So, the main point here is a certain kind of humility.

More later....

And your comments and reflections on this are solicited.

Note: The picture is of Carolyn Eyles, an award-winning teacher in Canada. Google her.

Agile Principles

I often say that you can't do the dance if you don't feel the music.

In a discussion list now, there is a heated discussion about the principles that underlie Scrum. I hope no one hurts themselves. By which I mean to jest that we often have the biggest fights about abstract things ... about which we want, or at least tend, to disagree.

About concrete facts that all can see with their own eyes, it is harder to have arguments.

OK. Here are some principles that I see at play in Lean-Agile and in Scrum. Part of the fun of putting this list out there is the hope and expectation that you will discover for me yet better ways of expressing these or other principles at work. My list was done hastily, so you are welcome to complain. Also.

A quick list....
* all work-in-process is waste (and we want to eliminate as much of it as we can possibly imagine)
* two heads are better than one; three are better than two
* with our work, the productivity of the individual is fairly meaningless (no individual alone can produce the product); the productivity of a small group is meaningful
* bad news does not get better with age
* truth and love are the true foundation
* how hard we work is not important; what is important is making a few people's lives better
* we have failures in communication all the time; the problem is to identify the biggest ones as fast as possible, and correct them quickly
* the best way to communicate about this very abstract work is to make it as concrete as possible. And then get as full and direct feedback as we can bear.
* in theory there is no difference between theory and practice. In practice there is. Yogi Berra. One Meaning: In our minds all our ideas seems to work. In practice we all always see many mistakes and problems.
* knowledge creation is what it's all about
* "There are many things one doesn’t understand, and therefore we ask them: why don’t you just go ahead and take action; try to do something?" Fujio Cho.
* You learn fastest by small mistakes.
* Where there is no vision, the people perish. Proverbs.
* People are remarkably good at doing what they want to do. (Little's Second Law)
* I know it when I see it. Judge Potter Stewart.
* How does a project get one year late? One day at a time. Fred Brooks.
* You don't need to motivate them. You need to get the de-motivators out of the way.
* People work best when allowed to make small promises.
* Don't over-stress the system (the team).
* Because business and technology decisions are inter-dependent, business people and technologists must work together daily.
* There will never come a day when there are no impediments. We can always improve. We must work on the biggest impediment each day.
* "Depend upon it sir; the prospect of being hanged in a fortnight concentrates the mind wonderfully." Samuel Johnson.
* To predict is difficult, particularly of the future. (A Chinese proverb?)
* We are organic, transient animals. We are not machines nor are we constructs of the mind.
* There is a lot of variation amongst and between individuals. And perhaps more so amongst and between teams.
* Man is "a being darkly wise and rudely great". (Alex. Pope) Of a mixed nature. None of us will be perfect soon.
* Micro-managing workers never helps. A bit of coaching might help some.
* Pretending to be more productive by lowering quality is just pretending.

Your comments?

How do we know we have a good idea?

I was reading the new book by Bas Vodde and Craig Larman recently. Recommended.

In the beginning of the book, they give lots of ideas about "how to think". At first, I found this curious, although the suggestions were very good.

Only today did I connect it to what I think is our biggest problem.

This is how Yogi Berra (and Nancy V) put it:
"In theory there is no difference between theory and practice. In practice, there is?"

Or -- how do we know any idea is really any good?

We could assume, but as we know, that can have bad consequences.

In other words. In my mind, my ideas (and your's and your's) are always perfect. But only in reality do we find out they are always less than perfect.

So, how do we discover the stupidness in every idea? More quickly.

So, this applies each Sprint.
And this applies in changing from waterfall to Scrum. (Yes, Virginia, even Scrum will be a little rough around the edges when applied in real life.)

So, Vodde and Larman, at a high level, are helping you discover all the stupid "truths" you currently think are right. And helping give you a means to gently convince others that their strongly held truths are just plain wrong.

A respected colleagues says: Assume half of what you "know" is wrong. Seems good advice.

I think: There will never come a day when we are finished rooting out stupidity. In ourselves (so be a bit compassionate), in any one person, and certainly in the whole team and the larger firm culture. Toyota has gone further: they are rooting out stupidity in the flow of value from one firm to another.

Taiichi Ohno started implementing Lean at Toyota in the 1940's. He was not finished when he retired in the 1980's. I am thinking with Agile, while we can be a bit impatient, we also need to take a longer view. But maybe I'm wrong.

What to do first?

I just got an email from someone who recently went to one of our Scrum courses. [Note: This is a long but, I think, interesting post. Bear with it, if you can.]

QUOTE
Hi,
Let's say one is going to work as a team lead for a software project in an organization that currently does not use Scrum and that may or may not in the future.

Let's assume that the org currently uses a matrixed structure where developers are shared between projects and their time is allocated via some sort of resource manager to individual projects.

Let's also assume that you, as the new team lead, can't just unilaterally say that you are going to manage the project using Scrum but have to peacefully coexist in this matrix environment.

Let's also say as the team lead you wanted to introduce Scrum but realize that trying to initially go 100% Scrum wouldn't be organizationally possible.

Finally, the question ...
As a team lead in such an environment, which Scrum/XP practices would you try to introduce first, in which order and why?

Thanks,
Robert
UNQUOTE

This is what I wrote him quickly, slightly edited. (Sorry, can't promise such a long reply to every question. And, as a wit said, "sorry for the long email, I didn't have time to write a short one.")

QUOTE
Hi,

The situation you describe is classic. (With of course a million minor variations.)

So, let me start with the story of the American couple who flew to Dublin in early Dec. They rent a car and travel around the countryside. At 4pm that day they are in a small village, lost, and need to get back to Dublin before dark. They go up to a little old man and ask, "how do we get back to Dublin?" He says: "If I were you, I wouldn't start from here."

We all of course say this. Almost every day. And it is useful to chuckle at ourselves when we do.

Now, I do not mean to minimize the difficulties you rehearse. They are hard. And life itself is sometimes hard. But that's why we do this interesting work.

My brother has also reminded me that there are two times not to give advice. When someone asks for it, and when they don't. Nonetheless, I will give this advice.

1. Start from where you are.
2. Believe in your own power to influence the situation, in large part by recruiting the help of others (up, down and sideways). As you know, to get another person to do what you want, you must help them see with their own eyes why they want to do it (usually positive reasons are best). You win by showing them the truth (perhaps slowly). You can never win (in the long term) with power, so do not pine for your own lack of so-called power. Your power is in being truthful and being right. Be happy that people will all the more readily tell you what they really think.
3. Find an important project and a good team. Including a good PO. (Assuming you will be the SM.)
4. Start working on a round of influencing to a core team of stakeholders, to this effect: Getting them to support you on the project, to make it a success, by using Scrum, and by removing impediments.
5. Get a minimal level of buy-in from this stakeholder team. Perhaps just enough to start the effort with Scum for a couple of months. Get them to buy-in on principle that the new team needs to NOT do things the old way.
5a. For example, I would hope, given your own great personal powers of persuasion, that you could convince them for this one team, that the "pigs" will be allocated at least 80%. Partly because this is such an important project (ah! that's why you wanted an important project). 20% allocation to doing old stuff or helping out other (new) projects.
6. Do a product backlog with business value and story points, etc.
7. Get a Team Room and collocate (as much as possible). It is so much easier for them to learn Agile that way. Maybe this is step 12.
8. Pick a Sprint length (I like 2 weeks almost always...more feedback, faster).
9. Focus on all the core Scrum things: the 3 roles, the Daily Scrum, the Sprint Planning Mtg, the daily work, the Sprint Review, the Retro. And the Scrum artifacts: Pro Bklg, Sprint Bklog, Scrum Board, Burndowns (or Release Burnup), the "potentially shippable product increment". The Impediments List. Fix the top impediment (over and over again). And the values and principles behind them.
Note. There will never come a day when they (and there are many people in "they") totally understand Scrum (or even you do). They will forget. You will always be explaining Scrum, and why each piece is useful.
Ex: George may understand the Daily Scrum for awhile, and then he will forget, or stopping doing it as well. The SM must explain it to him again.
10. Deliver something meaningful, at a reasonable date. Let's say in 2 months (4 Sprints). Release 1.0. [Note: This period can vary a bit...but remember the business side is your friend (or will be soon)...they want stuff now!]
11. Once you start to make the business side happy, work with your PO (a business guy, right? well, typically)...to gather their buy-in to helping you push down impediments. Now you start to have some real power behind the changes you want to make. IT managers can drive you nuts, but magically they often shut up when the right business guy is in the room. Funny how that happens. Explicitly or implicitly, the senior business guy is saying "we have business goals to accomplish, and all that IT political BS is not helping. Get the heck out of the way of my effort."

Notice a few things:
1. I kept all of bare simple Scrum in the initial "big change".
2. I did not suggest big changes to engineering practices first. Planning Poker, yes. User Stories, yes, probably. Anything else from XP that I can get "for free". But my political capital is not put there first.
3. I bent them, but did not break them.
4. I did not even talk about how you convince the team itself. Sometimes that is an issue.
5. Lots of things might be issues. But you won't get all issues throw at you in a specific situation. Only fight the issues you really have today.
6. If you have to compromise on Scrum (team allocation, interruptions, etc), make it clear/visible (in a nice way) and keep asking...is this the best way we can do things? With matrix, I am betting the slide about doing 3 projects at once should be compelling. Discuss that.

Here is another mantra for you to some managers:
"Let me do what I want with this team for awhile. Just think of it as magic. Hold me accountable for getting more results out, and don't ask how I do it, and why I do it this way. Just help me do it." A colleague tells the story about getting expresso makers. "Just think of it as magic. I pour expresso into the room and out magically every 2 weeks pops working software." (Your team may not care about expresso, but you get the idea.)

The Agile community has not scientifically proved this (that Scrum is the minimum), but it is emerging that Scrum is probably the bare minimum that you need to start. That's my answer to "why". There is no better Agile answer to the bare minimum (that has much support). Like all the good Scrum people I know, eventually you want all (or almost all) the XP stuff and all the Lean SW Dev stuff also. Just not on Day 1.

Does this help?
Did you have an "oh, $#!&" moment? Yes, it ain't easy and you have some hard work to do. Go get that Dale Carnegie book (How to win friends and influence people)...or something similar (Fearless Change).

Best regards, Joe
UNQUOTE


Depending on your situation, one of the following might also be helpful.

1. "When you come to a fork in the road, take it." Yogi Berra. (A little humor always helps.)

2. See The Road Not Taken.

3. Keep cranking the sausage maker. You (and they) learn most by seeing what comes out. (Scrum helps instantiate the sausage maker.)

4. In most situations, take a decision. There are few things worse than no decision. However bad the decision was, you can inspect and adapt shortly, and make an improved decision with more information. (This is almost a quote from Ken Schwaber.)

5. If you wait for perfection, you might wait too long. (I guess this is my quote. Said with a smile, since I find that nothing is perfect. And, as Yogi Berra so rightly says, if the world were perfect, it wouldn't be.)

"You can observe a lot by just watching"

As some of you may know, I am a fan of Yogi Berra quotes. The guy is amazingly stupid-smart. And, since he was a coach, I can relate.

One of his quotes is: You can observe a lot by just watching.

Why is this relevant to Agile?

Well, it seems obvious to me. But it seems it needs to be explained, and I need reminding too.

Let me start by stating my hypothesis, that everything we do in working as a team is imperfect, everything can be improved. My related hypothesis is that people and their interactions are complex. And another related hypothesis is that only by sharing tacit knowledge can the team create new knowledge and become truly successful in creating a new product for its set of customers (a new piece of software for example).

So the ScrumMaster watches the team to see what is really going on. How the productivity is working. And he evaluates...what are the top impediments and what can we do about them.

These impediments can be anything. Any thing. People, technology, external intrusions, light/heat, attitude, process, whatever. So the ScrumMaster evaluates what is important enough to be worth taking action on.

Thus, as I am trying to explain, the ScrumMaster needs time to observe the team (and things around the team). Time to smoke out what is noise and what is real. Time to let the introverts speak with their actions. What are the usual complaints about "work" or "life" (we all always have these), and what are the top one or two impediments that, if changed or improved on, will give the team greater velocity.

It's not hard if you relax and concentrate. (The paradox that martial arts and most sports and, indeed, life itself always bring us back to. Mastery with some time.)

Business Value: What is it?

On Wednesday, I will lead a session on Business Value in Charlotte, NC. That night the topic will be "what is it?" This is part 1 of the full session I will lead at Agile 2007. (Part 2 in Charlotte will happen on May 24th.)

My hypothesis is that we don't know as much about Business Value as we need to know. And that we are discovering business value all along the way, just as business value is changing. (What? Customers change their minds?)

In that session on Wednesday we will discuss these questions:

1. Why is Business Value important?
2. What is Business Value?
3. Which definitions of Business Value align best with which people?
4. What do customers really want? What did you buy today and why?
5. Does the Business Value of a project ever change? Why? How did you discover that change?
6. Which tools should we use to uncover Business Value?
7. In a project, who should care about Business Value?
8. Does Business Value seem easier or harder now?

To me, this all relates to what Yogi Berra said: "You've got to be very careful if you don't know where you're going, because you might not get there."

Do all the people on your team agree on the definition of business value? Is it tangible to them? Are they always driving toward it (and nothing else)? Or do they, like most humans, say after a few days "what was it you wanted?"