Changing people (that would include you)

I am involved with Scrum as a coach and trainer. And occasionally (well, more or less daily), I get the question: "I would really really like to do Scrum (better), but I need to change X, Y, and Z." And X, Y and Z are people or groups of people at that person's organization.

And, just to remind us of how utterly impossible it feels, let me add. "People don't resist changing; they resist being changed." ("Zen master, why such an impossible koan today?")

(We must also remember that it is not only "they" who must change. We must change also, starting with our blindness to our own need to change. Arrogance is not charming.)

And I totally sympathize. I too would like to see Scrum used more and better (or better and more). And to me the key impediment is in the mind of man (or particular people).

Or is it in the mind?

I take Hapkido, and I truly like and greatly greatly respect the master of the dojo. An American. One of his favorite phrases is: "Fake it until you make it." And of course that has many applications.

Then, look at this article: http://www.only-positive-news.com/archives/1232
Or maybe better, look at this re-write of that article: http://agileconsortium.blogspot.com/2010/03/re-write.html

I am not all into some of the touchy-feelly stuff in the original article, but the basic point rings truer and truer to me. The action teaches the mind what the values and principles really are. Well, it would if they were paying more attention. And, even when not, it does teach them some. Reality is a great teacher. And then the wiser teacher can teach based upon experience, not upon mere ideas in the mind.

So, today I heard this saying: "We do not think our way into a new way of acting, we act our way into a new way of thinking." (A version of this saying is used in the article.)

Surely this saying needs some explanation, especially for those who are strongly (and only) rationalists. And surely it is not complete. But I can tell you from my experience that a man who is only convinced in the head will do the practices of Scrum in a very weak manner, while a person who "gets it" will do them so much better. ["Gets it" is the simple, opaque and yet totally obvious phrase some of us coaches use. If you have not experienced it, apologies, because it will sound totally stupid.]

I call Scrum a "drama-in-real-life". By which I mean that in enacting the drama, the people will learn. All the parties. And, with a wise teacher, over time many good things will result. Many good things will be learned in enacting the drama.

So, one answer to "how do I change those people?" is: start the drama-in-real-life of Scrum, and use that to enable them to change. Wait for the teachable moment, and show them what they are almosting in their knowledge of agile. You can observe a lot just by looking, Yogi said. And learn a lot just by acting, Kert said.

Scrum Success Story

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.

Scrum Tools

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.

Is Scrum perfect?

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.

Why working software is important

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.

Certified ScrumMaster Course with Jeff Sutherland Dec 15

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

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?

The doctrine of sufficiency

Agile and Scrum start with the assumption that a team is sufficient for the task set before it.

This is a bit wacky unless we allow the truth, which is that humans are very inventive.

Thus, a given 7-member Scrum team can do many things to gain success:
* change the team
* get other impediments removed
* work with the Product Owner and maybe customers to redefine what is wanted

Etc, etc.

So, the idea is only common sense. By yourself, you have some power but it is limited. But 7 people, believing in themselves, can do almost anything. If they believe in themselves, they can be almost irresistible. They can reinforce each others' resolve. They can find new resources. They can redefine the problem.

Now, is every team always irresistible? No, not if they do not believe in their mission.

So, Agile and Scrum presume that the doctrine of sufficiency applies. It does not assert that that must always be true, but rather that that is the best going-in assumption.

They assume that by taking action, we can make our lives better. Rather positive, no?

The CSM Exam

As you may know, the Scrum Alliance is implementing a CSM Exam on Oct 1. See scrumalliance.org for details.

This causes us to make a few basic statements.

First, our real purpose is not certification and all that alphabet soup. It might be helpful, it might not. But the real purpose is improving people's lives. The customers, the workers (which includes the managers), and the stakeholders (eg, the shareholders, those widows and orphans).

Second, we have to comment that in some ways, the ScrumMaster title is not fortuitous. It implies, to some, that a CSM is a "master" of something, possibly Scrum. Almost any intelligent person, with a modicum of investigation, sees that that is not true. But some people want to get wrapped around that axle.

Third, we think the CSM Course is a very good course. And, today, the CSM title means you have taken that course. I think taking the course should be viewed as a necessary but not sufficient condition to becoming a ScrumMaster, and probably even to doing Scrum. Other conditions must be met also.

Ok, now on to the Exam itself.

First, putting together a good Exam is very hard. The Scrum Alliance has my sympathies. Even if the initial version is not good enough (it might not be).

Second, the Exam has some practical benefits. It will cause some people to read more. Good, mostly. (Partly bad, because Scrum is more about action than mere knowledge in the head.) It will cause some people to pay attention in class more. Good, mostly. (Partly bad, since they may be paying attention to things to pass a test, and not to the broader meaning and the interconnections and how to make it work in real life.)

Third, the Exam creates a relatively quick feedback loop. Scrum is all about fast feedback. The Exam is not perfect feedback, but better than none.

The Exam is partly bad also. It puts more emphasize on Explicit knowledge, and implies less importance for Tacit knowledge. Certainly the Tacit knowledge about Scrum is very important; I think more important than the Explicit knowledge.

Metaphorically, the Exam suggests that documentation (knowledge unused) is an important measure of progress. But Agile and Scrum say the true measure of progress is working product. In this situation, putting Scrum into practice. In the case of the test, it is ok to test Explicit knowledge, but we need to say that we do not agree with the metaphor. The more important test is: Can you really do it?

In the real world, potential employees and hiring managers want to see "can this person do this thing well". It is reasonable, as I said, to view having a CSM as a necessary condition to becoming a ScrumMaster and probably even to doing Scrum (or a CSPO for Business types), but it is not sufficient. Only in action can you prove that you can do it.

So, I think the CSM Exam is a small positive (despite its drawbacks). We should not get too distracted by it from the main goal. Let's make people's lives better. We need that just about now.

To know ourselves

We are in a recession, so we think especially now that money is important.

Some of us are introvert technical guys. People skills are not our strongest skill set maybe. So we think strong technical thoughts are the most important things.

But at the end of the day, I believe we live for other people.

One of deepest human desires is to know others, and also to be known.

The famous quote goes like this: "For now we see through a glass, darkly; but then face to face. Now we know in part, but then shall I know even as also I am known."

To me, Scrum is a journey to know the customers and what they really want. And to know the Team, and what they really can do. And, in the Team, we get to be who we really are, and to be known for what we really are. Well, within the bounds of workplace norms.

This is very important and profoundly satisfying.

What is Scrum?

I am excited to be giving a Certified ScrumMaster course with Jeff Sutherland next week. In Richmond.

So, I was thinking: what is the essence of Scrum if you would play the game well?

(Remember that Scrum is named for the Scrum formation in Rugby. We often show a video of the famous All Blacks team doing the Haka and playing Scrum. We think Takeuchi and Nonaka, who originated this metaphor, were thinking of these great teams.)

To me the essence is that team spirit that is willing to face a rough opponent and a difficult situation, and overcome any obstacle to win.

I sometimes call this the Michael Phelps attitude. He is thinking: "I broke the world record in each of the last three heats. And now, in the finals, I want to jump in the water and break it again."

There are many things from art and science that we give the teams in the course. But we must convey this essence. Without this tacit knowledge, it avails almost nothing to have all the explicit knowledge in the world.

Completing a Release

OK, so we have a known velocity in Story Points. And, having that, it is an exercise for a 6 year old to figure out how many more sprints until the release.

Example: We have a velocity of 20 and the stories in the backlog for this release have a total of 100 story points, so QED, we have 5 sprints remaining until we can release.

[QED is from my old school days, meaning "which was to be proved".]

Fine, for a shark, a simple project manager or a 6 year old.

What's the problem, you say?

In real life, we need to be cleverer than a shark.

It takes a clever, determined Product Owner (in Scrum terms) to land the release.

We know from long experience that the Product Backlog will (or should) change. New features will be discovered, the customer will "know it when he sees it" (a law of software "requirements"). And "stuff will happen" such that the current known velocity will change.

Most importantly, the PO (Product Owner) will be executing the Pareto Rule, which says that 80% of the value comes from 20% of the stories (maybe better to say 20% of the story points). Maybe not a perfect 80-20 rules, but all those stories slated for the release are NOT required.

Side note: What can happen to velocity? First, it should improve as we remove impediments. Second, "stuff happens" and the foreseeable problems (which we refused to foresee) happen. And the completely unexpectable happens with known regularity (and perhaps some unknown frequency as well).

Let me emphasize again: The PO should dynamically be looking at the product as it grows to determine the Minimum Marketable Feature Set (MMFS) to release. This is a very dynamic process of discovery. Or should be. When you are creating something for the first time, there is always plenty to learn. (Or, if you waited for the "perfection" of the so-called requirements, you probably waited way too long.)

For a given product, we hope there will never come a day when we are finished improving it. When all the stories are done. We are always discovering what they want most NOW. Customers always want more (although the "more" that they want is often less...example: less complexity).

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.

Shock Therapy

Back in September, Jeff Sutherland spoke at the Googleplex in NYC.

Topic: Shock Therapy. Also called: "Self-Organization: The secret sauce for improving your Scrum team".

About 90 minutes.

Here: http://www.youtube.com/watch?v=M1q6b9JI2Wc

Recommended.

Summary: Shock Therapy is a technique for a special and experienced coach to work with a Team to help the team boot up so that they can self-organize to a better life and hyperproductivity. Like many things in Scrum, it sounds paradoxical, but is not in practice.

The great persuader is....you

Last night I was speaking to the Metrolina PMI chapter. Good discussion; lots of interest in Agile. My topic was: Winning With Scrum.

So, on that quickly. My experience and my hypothesis (still not disproved...per the scientific method ), is that Scrum can be more fun and can enable your team(s) to be much more productive. It is designed to allow you to be 5x to 10x more productive that you were. And, on average, 5x-10x more than average. (Yes, logically, if you were already well above average, for whatever reason, the bang might not be that great.)

At the same time, I do not wish to infer that Scrum (or Agile) is a silver bullet or magic pill. It is hard work, painful in terms of change, to do well. Some people don't have the intestinal fortitude. And some people might be in one of the few "wrong" Myers-Briggs boxes to be comfortable using it.

So, we are in for a short, tough economic time.
Scrum can help you team and firm.
Scrum can preserve your career.
If you put your heart into doing it reasonably well.

Enough of that.

One person asked me: "Well, I'd like to do it, but who is going to persuade my boss and my comrades and my company to let me do it?"

The short answer is: You.

Yes, I know this can be tough. Yes, even if you are very good, sometimes you will not succeed.

But usually, where there's a will, there's a way. (It's a cliche because it is usually true.) And nobody else is as well positioned.

A couple of things:
* It is not one conversation, but a series of conversations.
* The influencing does not have to come out of your mouth or even be thought of as (all) coming from you. But you have to organize it and energize it.
* It is not just facts, it's emotion also (yours and his). The most effective emotion is often "quiet" emotion. The other guy gets a sense that you really are determined to make this happen; it gives him confidence that you *will* make this happen. (Often a "him"; your situation may vary of course.)
* Stay yourself. People will not believe professional salesmen. But if you are true to yourself, they will believe you.

Welcome to the most important business skill you will ever develop. Getting someone to buy-in to your good ideas.

Two suggestions:
A Sense of Urgency by John Kotter.
Fearless Change by Manns and Rising.

Go get 'em.

Productivity Now

The economy is in a bit of a tailspin. Chairman Ben may have his way of helping us. But we can help ourselves. If you wait for the Wizards of Washington to help, you might wait for the wrong basketball team.

How do we get ourselves out of this jam?

We need a simple way of telling if we are productive, if the seemingly "brilliant" ideas are actually useful. And of telling whether this group of people or that or those is productive.

How? Measure productivity by team. The Team is the unit to be measured (not the individual, and not a larger group). There are many reasons to measure by team, but the main one is that only the Team can create enough useful knowledge to create (or produce) a (new) product. 7 people, plus or minus two.

Measure it in short iterations...a week, or two or a month at most.

And ask the Team to improve.

If the Team is not producing enough (say, compared to their cost), disband them and tell each person: "Go join or start another Team." If the same person is on two failing Teams, he probably needs to look elsewhere.

And all those other guys who aren't on the producing teams (or any team), why is it that we need them? What value do they add? (Yes, Virginia, they could join a team doing real work. Since they aren't used to it, we'll give them some time to remember how to do real work.)

So, some Teams can fail. But you will generally find that the Team gets creative and productive. They find something to sell that customers actually want. Even customers now.

To do this well, you have to measure productivity. I know there are lies, damn lies and statistics, but you need a little bit of something to make business decisions.

Translation: What I am recommending is Scrum for the whole business. I would recommend Scrum be in the context of Lean thinking about the whole business (although I did not explain that here at all in this post.)

Get on with it. We have a bunch of people to pull out of this economic cycle. Much as we enjoy Scrum, we didn't get into this just for ourselves.

Scrum Certification Test

The Scrum Alliance has recently announced a Scrum Certification test.

Two cheers. This is a minor, good thing.

And it gives us an opportunity to say what makes someone good at Scrum.

Hint: High scores on the Scrum Test probably have very little to do with it.

First, Scrum is a team sport, so how good one person is is almost irrelevant.

Second, explicit knowledge, while somewhat useful, is not the main deal. The juice is in the tacit knowledge.

Third, building unused inventories of explicit knowledge is probably NOT going to help.

Fourth: Courage.

It takes courage to come in each day and face one's own imperfections, and force oneself to get better. Similarly, it takes courage from the team to come in each morning, tell the truth, and face their own imperfections. Every day. (It's fun too, but I think courage is the key.)

And it takes courage to tell the managers of the organization you are in that things need fixing around here.

So...

More book learning about Scrum. Yes, good. Hey, and let's add a minor test just to encourage that.

More courage. Much more useful.

Hyperproductive Distributed Scrum

Back on July 21, 2008, Jeff Sutherland gave a talk on Hyperproductive Distributed Scrum at the Googleplex in NYC.

Here is the video.

What's a team?

Let's review what a team is in Agile.

A small group: 7 plus or minus two.
Motivated by the vision of one person.
Dedicated (ideally 100% but certainly a lot).
With almost all the skills needed to realize the vision.
The team works together daily.

A team is not:
* Lots more people than that (that's a collection of people).
* Motivated by multiple visions (if there is some similarity in the work, that might be a department).
* Following multiple people (that would be confusion).
* Some folks who work together from time to time.

We give a Team a mission, and we expect them to figure out how to deliver it.

For an interesting discussion about how small teams work in warfare, see Maneuver warfare.

Why are teams important?

This may seem obvious to many of you. But even for those, it may be useful to review.

1. No simple problems. We now need a team to figure out almost any problem. We need the knowledge from multiple people.

2. Creating knowledge. The team is the unit that creates the knowledge. The convert tacit knowledge to explicit knowledge. They brainstorm. They convert ideas to something more real, and examine whether they are achieving the vision.

3. Has "it". We can't describe everything that makes a winning team. One day knowledge. One day skill. One day motivation. Every day something different. But they get it done.

4. Motivation. Creating something brand new is hard work. The team members need to motivate each other to get past all the problems and issues. The team has to find its heart. Once it has it, you can let it run.

5. Clarity. If we have a real team, then when we examine what it produces each Sprint, we have clarity about that. The problems are much more obvious. There is much less confusion. The best actions to make further progress are clearer.

6. Fundamental to make Scrum work. Scrum is built upon a team concept. To get the real value from Scrum, you should start with a team. (I have not thought about it as much, but I think this would apply to all or almost all of Agile.)

* * *

Is your team reaching its potential now?

The importance of Velocity

I had an interesting conversation about Agile metrics yesterday, and wanted to share one insight.

Why is velocity so important?

Well, first we should say, that in many ways it is not. Honestly. Velocity can be unmeasured, used badly, up, down, sideways, misunderstood. Whatever. As long as the team produces some business value (eg, software in production) that is seen as a positive multiple to what they cost, that is all the counts. Of course, we customers always want it sooner, but as long as the effort realized good business value, then it was not too late. The product helped that customer set; it probably helped society more generally.

Still, in most real situations is also really need velocity. Why?

First, for those new to Agile, the typical operational definition of "actual velocity" is the number of story points from the stories (features) completed in an iteration, based on the team's (robust) definition of done. (Describing a robust definition of done is a good topic for another post.)

Three words.

1. Defense: The team needs velocity because almost surely some manager is going to ask them to do the impossible and go a lot faster (eg, complete more story points in an iteration) than they can go. Velocity is what the team uses to help that manager accept the true.
2. Challenge: While we do not crucify the team based on demand for magic, at the same time, the team needs to be challenged to make their velocity get faster. This means identifying impediments. And getting them fixed (maybe after management approval, maybe by someone else).
   
3. Justification: "What was it you wanted" is the name of a Dylan song. People forget. Managers will lose interest in Agile if we don't have some data to show them and to explain to them why Agile is important. Velocity is one of those key numbers. It helps explain why good teams, good Product Owners, good ScrumMasters, good coaches are needed. It helps keep Agile from being "the flavor of the month" (if you are persuasive in explaining the numbers).
   

What do you think? Helpful?