At the ScrumGathering, Tues (tomorrow) I will do a mini workshop on Business Value Engineering. At 1:30pm.

Here are the slides: http://bit.ly/cXmYaI

Most of the slide deck is for reference; only a few of the slides will be used in the workshop. The mini workshop is about 2 exercises.
#1 Define at your table Business Value.
#2 Articulate your BV Engineering approach. (Map, BV Model, Theories, Timeboxes/Feedback loops)

I hope in this way that people will start to see this framework can be used. And also used to look at all the other great ideas about business value that others are discussing. Each of those must be put in the context of an overall framework. This BV framework hopes to be that general context.

BV Engineering is a framework, kind of like Scrum and kind of like Lean. So, as in Lean, we ask that people make explicit the BV "cycle" and approach, much as Value Stream mapping does.

I hope you will find these ideas and practices useful.

 Subscribe in a reader

Joe Little will be leading a Certified ScrumMaster course (2 days), followed by an optional workshop (2 days). In Ottawa, Mar 1-4.

Here are the details: http://leanagiletraining.com/LittleOttawa/LittleOttawaCourse.html

The workshop is good for any team that needs a boost. Either at the beginning, or in the middle.

Please don't hesitate to contact us if you have any questions.

 Subscribe in a reader

Occasionally I hear the complaint: "Oh, you [scrum, agile, lean, x] guys have drunk the Kool-Aid. You don't care how reality intrudes, you're just going to propose your [X] solutions."

And what does this person mean? He might mean: "Completely on faith, without any support of reason and facts, you are a strong advocate of a certain set of views." He might also mean that we have let out minds be clouded with too much emotion and too much enthusiasm.

And of course, in the Agile community, there are indeed some people who resemble this remark. His (or her) comments do indeed have some traction. (Maybe I think not very much, but at least some.)

So, what is the right way to play Agile?

Well, first, of all the rigorous approaches to new product development, I find Scrum and Lean to be the MOST reality based. For example, the principles of Scrum require us to be transparent about the truth. Require us to keep an honest velocity. And require us to admit *every* Sprint the painful truth that we are not (yet?!?!) perfect, and we must remove one impediment now, and get better. And we try to immediately use all the good and bad aspects of the truth, as it minute-by-minute unfolds, to get better.

To be honest, I still lie. But I must say, when I did waterfall, I felt it was helping me lie, while when I do Scrum, it puts the mirror up and makes me see how much I still continue to avoid the truth. So that I almost can't avoid. (Of course, being a clever guy, I still do avoid it some.)

So, when a Scrum theory or practice hits a hard reality, Scrum allows that the hard reality wins. It also demands that the onlooker examine yet again how they are twisting the truth out there in the very process of trying to perceive it....but when we really understand the truth, the truth always wins.

Now let's move to emotion. It is right to say that any sport, if you play to win, it must be played with intense...energy or intention. Some wish to call this emotion...ok. And Scrum is such a team sport. But to play any sport at a high level, one must ride one's emotions, but at the same time control them. All the winners know this, and it is indeed this that is their greatest struggle (I am thinking Roger Federer just now, but many great athletes will tell you this if you have not experienced it yourself).

Now, being emotion in this way does not mean that the energy is allowed to deceive our good perception of reality. In fact, to play a sport well, one always wants a hyper-perception of reality. They say: "It was as if the ball was moving in slow motion." As one example.

Now, junior level athletes forget these great lessons more often, and sometimes have not even become accomplished enough to start to deal with these lessons yet. But do not blame tennis that some people play it terribly. Do not blame Scrum that some people allow their emotions to cloud their judgment. Scrum is only a vehicle to enable them, in the time that God may appoint, to learn to live better in this real world.

Oh, and if you play Scrum, don't forget to drink the Gatorade. Your body needs that hydration and the electrolytes. To also help enable the creativity.

 Subscribe in a reader

It is probably true that the Product Owner is yet more important than the ScrumMaster for the success of the Team.

The ScrumMaster should, almost by herself, triple the velocity of the Team. She is the ingredient, without which it does not happen.

And the Product Owner can execute the 85-33 Rule. Where the $1 million of annual cost to $3 million of annual NPV moves to getting $9 million of NPV for the same cost. (I will discuss the 85-33 rule again soon.) Ah, yes, another tripling, independent of the tripling of velocity.

(What if both things tripled? Would anyone at your firm notice? [Ok, a bit of sarcasm there.])

Suffice to say that the Product Owner is very very important. For the Customer and for the Team. Even for the Firm and its shareholders.

We also think Business Value Engineering is very very important. (Discussed in earlier blog posts.)

So, we are very happy to have two Certified Scrum Product Owner courses coming up. To us, the CSPO courses should be at least as popular as the CSM courses. They are certainly as much (now more) needed.

We have one coming up Feb 24-25 in Montreal and one in NYC (Mar 24-25). See LeanAgileTraining.com.

 Subscribe in a reader

Why is it that we change? And how do we feel about it? And how does change stick?

My business is to change people, including myself. As a change agent, one is always interested to know more about why people change. No, not that really, but rather, how do we get people to change. And stay changed.

One idea is that you discuss things rationally, and if the reason says 'yes' then the person will change. Now, this is obviously a very simplistic idea of what people are about. Simple is good sometimes, but I find this simple idea, much as I sometimes want it to be true, is just wrong. Almost always. Even those who say they are rational are not. For example.

So, spending all your time appealing to the reason is probably not the best idea. (This is not to suggest you propose ideas that are not reasonable.) It may be that if something else in the person wishes already to say yes, then the reason may slow him down, maybe even turn the answer to a 'no'. But the reason is not where real change comes from. Or such is my current theory for virtually everyone.

My god, I lift my eyes up unto the hills, from whence cometh my help. I am lost in this wilderness of change. How will I be found?

Yes, change will happen, despite what anyone wants or says. So, if you are a change agent, one must wait for the wave of change to arise and ride and even direct it as best one can.

So, how might we direct it?

Well, if a person can see an attractor, or a higher attractor, in the change that you are proposing (versus other options), she is more likely to move toward the change you propose.

We also know that most people resist moving from the 'comfort' that they know, so often she needs a reason to leave the current comfort. Often despite the fact that she feels that current 'comfort' as painful sometimes or even often. 'The devil one knows is better than the devil one doesn't know.' So, one thing a change agent can do is enable higher perception of the pain of the current situation.

These are simple ideas, yes. Ones you probably know. But it is the simplest ideas that are the hardest to execute on. Over and over and over and over again. As Churchill said: "Never, never, never, never give in." And he did not.

Now, making this pleasure-pain idea richer does not require a return to the hedonists of Greek philosophy. What people feel as pleasure and pain (in this context) has many dimensions or attributes. Not just the five senses. Not just ego. Not just Maslow's hierarchy of needs, etc, etc.

Deploying this pleasure-pain idea to help people change is, on one view, quite simple, and on another, quite sophisticated. In life, most of us are like 4 year olds being utterly manipulated (for own benefit) by our mothers. You must become that mother. That good mother who does not always explain all. The focus is upon the lollipop as we go to the doctor's office (not that needle).

How do we sustain the change?

Well, from economics (the dismal science) we know of a thing called buyers remorse. We know that very often people buy 'agile' not because they want it, or because of agile itself, but because they invest it with all the attributes of things they do want. They make it more than anything can be. And then later they feel disappointed.

Like the lotus-eaters in the Odyssey, we want to eat the leaf to stay in a state of pleasure, indolent and unaware of the truth. Well, at least part of us wants to do, a lot of the time.

But later we reject this, feeling a buyers remorse, since we maybe bought the wrong thing (or, agile turns out to be different than the fantasy we wanted it to be). And Scrum can certainly show lots of painful bits. But it is not Scrum that is painful; Scrum just allows us to see the painful bits more clearly, will not let us avoid seeing them.

So how to sustain the change?

First, we must expect it to be somewhat hard. We must set reasonable expectations, as they say.

And we must put again and again the focus on the real lollipop. On the many many many good things that Scrum also gives us.

There are many good things. Let me focus on one now. Improved velocity, velocity based on story points completed per Sprint.

If you were Michael Phelps, and you had no measurement, and your coach asked you to get better again today, what would you say? You would likely say "Coach, I am already better than everyone in this pool here in South Carolina the last 3 weeks. I can't get any better. I need time off to go smoke some weed!" But you as a coach know that, yes, the body needs some pleasures, but the soul in the longer term will take more satisfaction by achieving a great goal, but showing others that despite having many faults (and Michael Phelps, like the rest of us, has many faults and weaknesses), despite all that one can achieve great great things.

And fortunately, that coach has a way of clearly measuring success and clearly measuring improvement. And clearly measuring the improvement of the competitors.

And we have this in Scrum too. For the Team, it is velocity measured in story points. Without that, the Team says: "Well, I think we have improved a lot. And we always have impediments. Let's not do a retrospective, let's not take time to remove impediments, let's just chip away at the real work and try to make the deadline." (And let's make sure we are not held accountable.)

But really, while so many times velocity is the cross upon which the Team will be crucified, it is in fact the glory of the Team. It shows how much they have improved. It gives them the pride to know they are hyperproductive (if they are, and they all can be...well, virtually all, by their own standard).

We need the numbers to have the emotion. Odd, but true. Or so I think and feel.

 Subscribe in a reader

Taylor Swift just won the Grammy for, I think, album of the year. And I think a few other Grammies.

Taylor Swift has a song out called Change. Maybe "old" now by music industry standards.

See here: http://bit.ly/9Bos9y

In 1988 there was a movie with Uma Thurman called Dangerous Liasons. OK, Uma Thurman was not the only good actor in the show (but I am a man, perhaps I forgot). Oh, yes, they had Glenn Close and John Malkovich also. And some kid named Keanu Reeves. And, oh yes, Michelle Pfeiffer. The show was based on the fairly famous French novel. See: http://en.wikipedia.org/wiki/Dangerous_Liaisons

One famous line in that show was: "It's beyond my control."

I have been in a few companies recently where the fundamental feeling is hopelessness and helplessness. "It is beyond my control."

As soon as we say it that way, any six-year old will say "This is clearly not a way to live. " There is not much more to say about it than: "If you can't change your organization, then you must change your organization." ie, get out even in the midst of a recession.

Perhaps it is also useful to remember: "Everything changes, nothing remains the same." A recent idea from the Buddha, only 2,000+ years old. This is to say, we, as individuals, don't make the real waves in the world, but we can ride the waves. And in small groups even, we must remember that people will change. They only really resist being changed. They want their freedom.

So, stop feeling helpless and hopeless. (We all do sometimes.) [If it seemed a missed a few steps in the logic there, I trust you can add them.]

So, where does this stupid kid, Taylor Swift, come in?

Well, her song starts this way:
And it's a sad picture, the final blow hits you
Somebody else gets what you wanted again
You know it's all the same, another time and place
Repeating history and you're getting sick of itCertainly I have felt kind of this way when I felt helpless.

And then she asks you to imagine that things just might change.
And she offers to help you (ok, the idea that Taylor Swift personally will actually help is a silly teenage fantasy, but the idea of us helping each other in agile is quite quite real).

And she asks you to imagine, afterward, that you accomplished something you didn't really think was possible. And how proud you will be then that you never, never, never, never gave up. (OK, I added a bit of Churchill there.)

I dare you to listen to the song.

There are no doubt a few stupid ideas being spoken of by agile people. But the body of ideas is a great set.

Agile is here not to make some minor improvement. It can be a big change in, well, even your life. It can enable you to make big changes in the lives of people you really care about. If you have started, don't stop. Strap on your armour again. And fight. With a smile.

 Subscribe in a reader

Also wanted to make a quick post about this course. Mary & Tom Poppendieck recently completed their new book (of basically the same title). They will be leading this course in Chicago on February 10-11.

They gave essentially the same course in Chicago last year just after Agile2009. Everyone was happy with it. The lean ideas are very important.

Hope you can join us.

See here: http://bit.ly/b67Dyz

 Subscribe in a reader

Just a quick post to mention this course. We were up in Ottawa recently and enjoyed it. (Although cold to a guy from NC.)

This should be a good course, and hope you can attend.

For details, see here: http://bit.ly/9aSHmd

 Subscribe in a reader

I didn't know before, but apparently this is a complex subject.

This post is mainly for those who wish to pay for our... ...LeanAgileTraining courses. But others are welcome to use it.

First, there are many ways to pay: check, cash, wire transfer, Intuit Payment Network, barter, etc. If you have a question about this, contact Julia Hill (julia.hill@LeanAgileTraining.com).

Second, the two "easy" ways to pay are PayPal and GoogleCheckout. We always have those "buy now" buttons on the course listing.

They seem easy...use your credit card or your bank account and the buttons take care of the details.

But, in lots of ways, only some of which I understand, it is complex.

First, there are fraud detection systems that are, these days, hyperactive. Some of the key data they are sniffing includes: Name, address, card number, expiry date, and the special code. (Watch out for typos; you'll trip the wires!)

They are biased against first-time internet buyers.
They are biased against large amounts.
If you have a corporate card, your corporation may set special rules, and not tell you.
You probably know that each card has (kind of, at least) an overall limit. But there can be transaction limits and daily limits, etc.
Amex seems to insist that certain transactions be done in USD (even though PayPal allows CAD or EUR, which may be fine if you use Visa or MasterCard or Discover).
PayPal says no single transaction can exceed USD10,000. (Google may say the same.)

There are probably more rules or exceptions; I just don't know them all yet.

It is true that you do not have to become a member of PayPal or GoogleCheckout to use them. But the screens may imply that to you.

ACTION
1. Don't feel forced to use PayPal or Google Checkout. There are almost always other options. For example, you can call us, and we can take your CC info over the phone. And, given enough time, we prefer a wire transfer or check in USD.
2. Before using a credit card, take 5 minutes to call the number on the back of your card and tell them you are about to do a/an (internet) transaction of X amount. Ask them if they see any problem with that. Often the humans can actually force the fraud sniffer systems into reasonability.
3. If you try PayPal or GoogleCheckout and have any problems, please contact Julia Hill (julia.hill@LeanAgileTraining.com) immediately. If she can't help you, I will try also.

Finally, an apology. In the past, we had clients who had problems with PayPal and Google Checkout. Frankly, we thought they just had not managed their CC well. It turns out that maybe most of those people were just having stupid problems with the system, through no fault of their own. So, our sincere apologies for not offering to help more then. Live and learn.

 Subscribe in a reader

One of the great themes of Agile is freedom.

There is no doubt that some take this idea in a wrong way, and what they get is more like anarchy, which is not freedom. But, from what I see, most people don't really understand freedom. Based on actions, they seem to think it means: "I am free to do whatever I want, and you are free to do a lot of the things I want you to do." In other words, they accept that others have some degree of autonomy, but "they still report to me", meaning they must mostly do what I say.

Well, perhaps I am putting too much attention on where freedom is abridged and not counting enough where it waves free, but the abridgment is where we need to be fighting.

I can accept that in business we must make some decisions, many decisions are difficult and are ones where full consensus is not possible, and so we must have some authority. But still managers forget too often Little's second law: People are remarkably good at doing what they want to do. Frankly, I forget it too, on a daily basis.

At least, managers should let people have their say. Each worker (for lack of a better word) doesn't require that the team do exactly what she says, but she can go with the group's decision more if she feels the group heard her. Take the time to listen. You can learn a lot just by listening. (Apologies Yogi.)

Which brings me to political correctness, which I see as mainly a corporate abrogation of our free speech rights. Yes, some of the -isms are evil at the extremes. But, IMO, the corporate "PC" codes have de facto gone way too far. Maybe what is written is ok, but the de facto effect is very very bad. At least where I see them.

Definition of Belief in Free Speech: You only believe in free speech if you are willing to defend a person whose speech you strongly disagree with. (This is a famous definition; I will later credit it.)

What the PC ethos does is cause people to lie and cover up and not tell the truth. Sometimes even to themselves. So all the "imperfections" that we all have come seeping out another way. Freud showed this. And all of your experience shows this. Or mine does.

We must accept that every person holds biases and generalizations. These can be useful, even life preserving, but equally they can be un-useful or hurtful or stupid or worse. But it is the nature of how our minds work that we generalize, and some become biases, prejudices, discriminations, etc. Any thinking person should examine his generalizations and expect a bunch of them to be stupid. Also, as Linda Rising famously (to me) summarized, it is the way our animal being works. We are pack animals, for example.

Free speech is not just for the non-stupid.

The effect of the PC "rules", however perfect they sounded on some stupid bureaucrat's desk, is that they create a culture where people withhold stupid thoughts. And it is only by putting stupid thoughts on the table that the team can examine them and correct them.

(I may like the person, but I hate the bureaucrat almost every time.)

Now, we do need some rules for extreme behavior. If a large majority (say, 95%) of people would say some behavior is wrong, we probably can safely issue a rule. (Example: This word ("<...>") is not acceptable in our offices. Or: Extended verbal harassment after x, y, z is unacceptable.) But they need to be very clear rules that close to 95% clearly support.

Words that merely hurt our feelings cannot be unacceptable. In business, we have to hurt feelings. A person might roughly say: "Oh, you suit, you guys never understand the technical stuff." A gross generalization, but until it is on the table, the team can't examine how true it might be.

A person might say: "Oh, geez, you're so like a chick with these concerns about emotions. Let's get on with it." Again, a gross generalization. Maybe that team needs to work on emotional IQ or not, but they can't deal with it until the issue is on the table.

A person might say: "Typical guy; gotta fidget with your tool endlessly. Bring your head up out of the screen, and consider the people just a bit. Dude!" Again, a gross generalization. But the PC impact is that these rough words don't get said.

Now for a fun example. Is the following video "acceptable" as a teaching tool to convey three ideas:
a. It is important to tell the truth. ("Hips don't lie")
b. Human beings, while they may occasionally be rational, are often not rational. Often like an animal.
c. You must feel the music of the values and principles of Agile in order to be better at dancing the specific practices of agile.

Here is a link to the YouTube: http://www.youtube.com/watch?v=DUT5rEU6pqM

So, is this video acceptable?

Or does it impinge too much on the religious or sexual-political sensitivities of others too much?
Does a corporation have a right to censor its use? By a non-employee? Or by an employee?
Your comments below please.

How quickly some of us show we care nothing for freedom. Shame.

 Subscribe in a reader

One of the famous phrases from this season (in the so-called Christian part of the world) is this:
Behold, I bring you good tidings of great joy which shall be to all people.

A slightly similar agile saying is: If you are not having fun, you are not doing it right.

This is very true.
And very important.

So, why does the Scrooge CEO want us all, everyone, to be having fun?

Well, there are many reasons. But the most important reason is... only when we are having fun will we be the most inventive and creative.

And our work is NOT about mindless, brutish hard work. But about newish, creativity, inventiveness, and giving them something simple that hits the target. One can argue which comes first: joy or creativity. But they are associated.

Even the managers get to have more fun. In Agile. But that's a topic for another post.

 Subscribe in a reader

I will not remember this well (knowledge decay), but there is a great quote from Fujio Cho (now Chairman of Toyota) at the beginning of Liker's The Toyota Way. Something like: "There are many things you do not understand, and therefore we ask you, 'why don't you just take action? Try to do something.'" With the idea that you thus cut the gordian knot of inaction, and start real learning.

What happens if we do not? The opposite: "And thus the native hue of resolution is sicklied o'er with the pale cast of thought."
And enterprises of great pitch and moment
With this regard their currents turn awry
And lose the name of action.
I have been in projects like that, and so have many of you. (These last two quotes are from a play, not Fujio Cho.)

The soft spider web of thought can be the hardest, most granite-like roadblock.

Yesterday I finished helping to teach a Certified ScrumMaster course with Jeff Sutherland. So, a couple of related thoughts from several conversations.

1. Spontaneous Organization. In the agile community, we are fond of self-organization and complex adaptive systems. And these ideas go way back. Chuangtze and Laotze taught us that the Tao that can be expressed is not the true Tao. That Tao organizes itself in things great and small. And Chuangtze especially talked about the spontaneous organization of things, nature, people, society. That if left alone, they would move toward Tao; that human meddling would more likely move them away from Tao. Better that they take on that more perfect imperfection of Tao, he seemed to say.

Like many another idea, these ideas were picked up later by others, by Proudon and Hayek for example. Tolstoy speaks of this when he talks about the hive of Moscow after the battle of Borodino in War and Peace. We see this in the things of nature, where Energy and Mass self-organize at the speed of light. (OK, perhaps a play on Einstein.) But there is a natural organic spontaneous organization of things.

Now, in real life, that spontaneous organization might be at a mediocre level or a hyperproductive level. The ScrumMaster may have more influence over this fork in the road than she has accepted yet.

I suggest to you that the ScrumMaster, at least, think deeply on how to put these mere thoughts into action for each team. And stir the pot gently. Maybe start here: http://en.wikipedia.org/wiki/Spontaneous_order

It is by spontaneous order that free enterprise gives you your daily bread. However much we may say (and it is true) that man does not live by bread alone, still we must have bread.

2. The ineluctable contradictoriness of things. We humans have this wish for things, for life, to be simple. And so in some ways it is indeed. "A kiss is still a kiss." But we are everyday forced, if we allow our eyes to see, that in so many things there are contradictions. Male and female. Good and bad. Black and white. Darkly wise and rudely great. Go fast slowly. Achieve by not trying. I must be cruel only to be kind.

Sometimes we see through the glass, darkly, that these contradictions do not need to ensnare us, but rather they give us balance.

So, for a pedestrian example, the ScrumMaster should be a servant-leader. The Team should use velocity to push back at the magical-thinking managers who demand they double output; and the next minute demand of themselves that they push velocity to hyperproductivity. From a certain point of view, these can seem utter contradictions.

In theory, we may think these contradictions should make us fail; in practice, done well, we come to know they do the opposite.

Perhaps a few of you will find the famous Butterfly Dream (see that link) an apt koan for the harmonious contradictoriness of things. Chuangtze has other, perhaps better, stories that deal with this.

ScrumMasters: They can cut through their mental spider webs in a minute. Or in two years. You can be a key difference. This is your great refactoring work. Find that sharp, swift, gentle, liberating sword. And pull it out.

 Subscribe in a reader

We hear a lot about all the problems of life. People are bad. Things fall apart. The center cannot hold. (Help me W.B. Yeats, you're my only hope.)

Today I would like to share an unsolicited note. Jeff Sutherland and I are doing a CSM class next week (Dec 15-16) in NYC. In connection with that, Jeff is speaking at Google and at NYCSPIN.

In connection with the talks, Gabe Yarra at Wireless Generation started am email conversation with me. Excerpts follow.

Thanks Joe,

Yes, I think we had 6 people train [with Jeff Sutherland and me, a while back], and there are 100+ developers who are very happy about it. We have been completely successful in our scrum adoption. Devs are happy with it, PMs are happy, management is happy. It took awhile for everyone to get it, but we're now completely on board as a company. It saves us a ton of headache in terms of scheduling and managing projects. We still have problems, but a whole class of problems disappeared and there is much less stress around certain areas.
....
Moving to agile was a somewhat bumpy ride that took about 6 months. There was a certain amount of skepticism, or just feeling that certain things wouldn't work, until they did work. It helped a lot that we had management and development committed before we started. Again, the whole company is very happy with the results.

By the way, my company is continuously growing and expanding, so if you know of any top-notch developers who want to work at an agile company with a great company culture, feel free to send them my way.

More detail to come, I hope, about how the Scrum adoption went. And is expected to go.

Wireless Generation does good work, IMO. See wirelessgeneration.com

What's not to like?

Change is tough. We sympathize, to a point. Stick with it. Go after it.
No one said the good stuff was for free.

 Subscribe in a reader

I just got an email where someone said that their group does not have a real project-type project. This got me thinking.

Key idea: How do we know our Agile teams are getting the best work?

It seems to me we have the theory that, magically, "the users" will ask us for the best work we could possibly do.

So, let's parse this a bit. The users might be the business or management or the customer. And the best work might be the most important thing we could do, or the most valuable or the highest business value, etc.

OK, so as soon as we make transparent the hypothesis we can see at least 4 holes.

1. The users are always human, and almost never can identify the highest value things. Consistently, reliably.
2. Identifying the highest value things (product, project, story, whatever) is, in large part, cost-benefit analysis. Only if the decision maker has complete understanding of all the benefits and all the costs (risks), can she make the best decision. If we technologists don't tell the business folks about the costs, how can they possibly give us the best stuff?
3. Do you know what you are really capable of? For sure, most business guys do not know what technology is really capable of. And they don't know what your Dev team is capable of.
4. Are we technologists capable of keeping up with all the extensions inherent in existing technology? Or keeping up with technology innovation? Even less can the business guys do that.

How do we fix this mess?

The issue here is that, although we are doing important work, we are still "failing" if it is not the most important work.

Well, I will suggest we need to get business and technology people together more, and the technologists need to ask: "How could we be more sure that we are getting the best work... so we, together, can make the greatest possible contribution around here?"

There are about 250 business days each year. I bet there are 250 ways to phrase that question.

 Subscribe in a reader

A course attendee asked about Scrum Tools.

First, in the Agile Manifesto it says "Individuals and Interactions over Processes and Tools". Naturally, being geeks, the first the we want to talk about in or after the course is...[drumroll]...tools. We have to have a sense of humor about this.

First, I recommend that people learn Scrum (for the first 6 Sprints or so) using magnetic stick pins and cards on a magnetic whiteboard. Or similar. With maybe an Excel sheet to do some math. Very simple.

I have an Excel spreadsheet I give away. You can find a link to it at the bottom of this page. (BTW, there are MANY other resources on that page.) Pretty darn simple XLS. For example, it creates a graph for the burndown chart.

THEN...if you are distributed, then you likely need a tool.

The last thing to do is scale. And often one team is more productive than 100 people. But many of you will scale anyway. So you often need a tool if you scale (one meaning: multiple teams on the same effort).

Here are some tools:

The two best known are Rally and VersionOne.

Jeff Sutherland likes PivotalTracker for some applications.

I hear many good things about Jira with Greenhopper, an extension to Jira from the same source. (OK, a pun on 'open source', which this SW is.) Jira is a bug/issue tracker and Greenhopper is an Agile PM plug-in to Jira.

I know friends who use XPlanner. Even I have used it a bit.

Advice: All of these products (and many more) are changing all the time. NONE are perfect. Perfection to me would start to arrive if the tool could project "virtual" cards on a glass wall that one could touch and move on a visual scrum board just like 4x6 index cards.

Here is some more info from Boris Gloger...here. Boris is a great guy, a friend, and a very experienced agile coach.

Here is another "tools roundup" that Boris also links to. No doubt there are others.

Let me also suggest that tools are discussed frequently on the ScrumDev yahoo group. You might want to check there.

Last advice, usually worth twice the price: Don't get your knickers wrapped about the axle to find "the best" Scrum tool. The tool will not write code and will not make the team more creative. Spend more time doing Scrum (and your work) and less time "tooling up".

I seriously doubt if a Scrum Tool is your biggest impediment. In any case, don't let it be the impediment you work on for very long.

 Subscribe in a reader

Questioner: How do I sell my executive team on doing this stuff?
Jim Highsmith: Don't. Just do it. They don't know what you're doing anyway.

Umm. This is taken from a tagline on a Ron Jeffries' email. Ron has many wonderful taglines. Watch for them.

Tom Peters thinks that John Chambers may be the best business leader we have these days. One fairly wise opinion. Ecco homo. (Said not without irony in this season.)

So, do we need permission to live our lives? Often, it is better to ask occasionally for forgiveness, rather than wasting so much time asking repeatedly for permission.

Still, it is usually better if eventually you get the senior guys involved, on-board, on the program, drinking the kool-aid, supporting the new idea.

First, "don't follow leaders, watch your parking meters". Said a long time ago, but true way before then. Leaders are much over-rated. Napoleon met his Waterloo. And his Moscow. Following leaders can get you killed. Leaders are as much followers as anything. If they are smart.

By which we mean "the big guy at the top". The Supreme Leader.

Individual acts of real leadership happen all the time, at all levels, and they are still and always important. But expecting the pronunciamentos of any one person to forecast the weather very reliably (or anything else reliably) is a fool's errand. Not that Leaders are bad, just that they are, well, human. Have you noticed that lately? (In fact, it is in the newspapers daily. Probably hourly or less.) Power corrupts and the more the power, the faster and more complete the corruption. Or so Lord Acton taught us. It's just human nature. We wish to fantasize that we are [pick your superlative] than we are. We would be just like them. Almost every single one of us.

Still, maybe it is worth some time, at some point, getting "some senior guys" to support Agile, Scrum, Lean or whatever. I think I agree with that. So, four suggestions:

1. First, in your own head, don't make it so important. For exmaple, everyone in sports knows that if you try to hard to hit a homer, your likelihood of striking out goes up a lot.
2. Read Fearless Change by Manns and Rising. Lots of good, specific ideas.
3. Read A Sense of Urgency by John Kotter. Short (a virtue) and again, lots of good actionable ideas.
4. It is not one punch, but several rounds. As in boxing.

First, a "leader" is not going to really start to understand agile/scrum/lean until she sees and touches it. Do a pilot so she can. Do not expect to fully convince in the first discussion. Or at first sight. Expect many conversations and experiences. No one knows which one will be the tipping point, and probably will not be able to say accurately later which one was. But truth, told with honesty, will win in the end.

Sometimes, in their fantasy, they want a silver bullet. Never lie that agile/Scrum/lean is a silver bullet.

My Hapkido master once showed me how the stomach can "defend" against one hard punch. But two lighter punches, delivered almost at the same time, set up a vibration in the gut that is most uncomfortable, usually one becomes incapacitated. In a similar way, we know in football, that it you hit someone high with one blocker and low with another blocker coming another way, almost always that man will fall.

Perhaps even more revealing, any 6 year old can throw a 300 pound man, if they apply learned cleverness (from many of several martial arts). If they use the energy of their opponent. The same is true in other parts of life, as story after story tells. David can best Goliath.

5. "People don't resist change. They resist being changed." Umm. Might even apply here. Let it become their idea. 'Nuf said?

Find your lever, Archimedes. You can move the world.

 Subscribe in a reader

Sometimes I want our Scrumming to be perfect.

I want everyone to be happy, I want no arguments, I want ultimate Business Value, no mistakes, no wasted time, no re-work, no stupid ideas, no mis-understanding what the customer wanted, no muss, no fuss, no confusion, no chaos.

Then I heard again for the first time this song by Frank Sinatra. http://bit.ly/8Cyaml

Here is an excerpt of the lyrics:

The broken dates,
the endless waits,
the lovely loving and the hateful hates,
the conversations with the flying plates
I wish I were in love again!

(See here for the rest of the lyrics: http://bit.ly/7QoNA6)

If you ever have to go back to waterfall, you might say:
"I wish I were in Scrum again!"

What Scrum opens up and makes plain is all the ugly wonderfulness of real life. Where things are messy, where creation happens, where ideas are invented from who knows where. Where we fall in love for God knows what logical reason. It's crazy (to some degree), but c'est la vie.

C'est la Scrum.

Scrum stoops to wallow with us in our complex, blessed imperfectness. And helps us correct ourselves as we go.

 Subscribe in a reader

In a recent discussion Jeff Sutherland was talking about how important it was to have working software at the end of every Sprint.

As a small part of that discussion, I suggested several reasons WHY working SW (or what I call done, done SW) is so important. Here is an excerpt from what I said then. (This happened to be something that one colleague "*really*" (to use his characters) liked.)

So, how do we explain (better) why done, done SW is so important at
the end of the Sprint? Here are the two ways I am focusing on now.
Perhaps not original with me.
1. Bad news does not get better with age. That is, fixing a bug now
is much much cheaper than fixing a bug later. Or an arch or design
issue. So, it has to be "done".
2. I know it when I see it. The users can't give us feedback without
something concrete to look at. So, done has to mean that as well. It
is concrete-enough to enable feedback (yes, usually more bad news, sooner).
3. It ain't over til it's over. Man, have we lived that nightmare in
spades. Only if it is done do we have a clue if we have made real
progress. And thus judge when the release will hit.
4. Don't build on a bad foundation. You don't want to build new SW on top of buggy SW. If we change the stuff at the bottom, the whole house can come tumbling down. So, again, no bugs escape the sprint.Well, more than 2 ways. No doubt you have yet more compelling ways of saying this.

This is in part why the Definition of Done is starting to be considered a core artifact of Scrum.

 Subscribe in a reader

I am next looking forward to doing a CSM course with Jeff Sutherland on Dec 15-16.

Should be lots of fun. I hope Jeff (or I) will take enough time to talk about The Concept of Ba, by Takeuchi and Nonaka. You might want to Google that.

I truly enjoy working with Jeff. Lots of reasons.

If you are interested, see here: http://leanagiletraining.com/Sutherland%20NYC%20CSM/Sutherland%20NYC%20CSM.html

 Subscribe in a reader

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?

 Subscribe in a reader