What gives?

I was just at the Agile Tour at Research Triangle Park in North Carolina. Very good event (kudos to Catherine Louis and the other organizers!!).

Laurie Williams, who is a great person and a great agile researcher, has done some work recently on, and I should use her words but don't have them handy, 'how do we feel about the Agile Manifesto and the Agile Principles now?'

One general reaction I had, which is also a reaction I have had recently in other situations....

When push comes to shove, what should give way: Agile principles or our local organization?

In my view, almost always the problem is 'us' and not the agile values, principles and practices.

And almost always, we make the agile stuff 'give right of way' to what we call 'reality'. But it is not 'reality' as in the law of gravity, but only reality in that these are the stupid ways our organization is doing things today.

Example: Sustainable pace.

Some people complain that the principle of sustainable pace means that managers can whip us to stay at 30 story points per sprint (after the team itself volunteered to go 30), and that it does not allow us to fix the technical debt or do the broader range work that must (at least eventually) be done.

This is my view:
* sustainable pace is very important in many ways. The main way I like to talk about it is that it is no longer about 'hard work', it is about 'creativity' and 'innovation' and 'inventive' solutions to difficult technical problems. Our brains have to be fresh to be creative as a team.

* sustainable pace (as measured via velocity) quickly becomes less valuable unless we are doing virtually everything possible never to allow technical debt to grow. Let's be professional.

* sustainable pace does not mean that the team 'must' maintain the same velocity every sprint. (Yes, Virginia, stuff does happen, for example.) AND, the team should always be challenging itself to remove impediments so that more 'work' can be accomplished in the same amount of time. In other words, in general and on average, 'velocity' should be upwardly sloping. But NOT by working harder.

* an empirical process requires transparency (or a high level of it) and any pretending about or hiding of 'undone work' (as Ken Schwaber likes to call it) is not helpful at all. Sustainable pace quickly becomes meaningless if we do this. (Cf Technical debt above.)

* Bad news does not get better with age. So, sustainable pace must be immediately linked to a strong and improving 'definition of done' for normal stories in a sprint.

* By sustainable we must mean we are doing everything we professionally can to assure we are keeping each sprint up with ALL the different types of work needed to keep the system fully 'done'. This includes fixing all bugs, doing all the refactoring, building all the truly useful documentation, visioning of future sprints, release plan refactoring, etc, etc.

* As soon as we discover some undone work (and we as humans will typically forget something and thus it is undone), we must address it professionally....do it immediately or put it on the product backlog. And consider how much it makes our previous information about velocity and progress a lie. (Always, to some minor degree, and possibly to a significant degree.)

* Just because we will always be imperfect does not mean we should give up on agile or agile principles or practices.

Can you put these ideas into action real soon? (Today is a good day.)

PS. I am not saying the Agile Manifesto and the Agile Principles are perfect. But maybe I am saying that our real worlds are messier than those ideas. Or so I see.

A real person in a good team

Some people take the view that they will be lost in a team. And, to be fair, this can happen. There are bosses and there are teammates who want you to conform, to submit, to lose your identity. To a meaningful degree.

But in a real and good team, the opposite occurs. We each become able to become more of who we are.

We each can learn faster. We can be more honest. We can make mistakes and admit to them. We can learn faster from these mistakes. We can enjoy our colleagues, whom we come to know as more complete people.

Yes, there can be dysfunctions in a team. Some teams can learn their way from those dysfunctions. Some cannot.

So, we and Scrum are not in favor of collectivism, of people losing their identify. We are in favor of each person using his or her unique abilities to be creative. And struggling to find themselves within the context of the team. (Yes, one must face and deal with some compromises, which to the inexperienced or immature can seem really tough. May indeed be really tough sometimes. But unavoidable in our life as humans. 'No man is an island' it was once said.)

So, we are not talking about dysfunctional teams mainly. We are talking about good to great teams.

Perhaps most importantly, I get to contribute to the team making a great product that real customers will like (more). This is very satisfying.

So, it is funny how life can be more satisfying when you give to others. You get more for yourself when you are thinking mainly of others.

Now how are things for the so-called top performer?

Umm. Well, the good team should be able to recognize fairly the talents of all it's members. (But it won't happen every time.)

So, again, we cannot promise nirvana, but we think in good to great teams, even the top performer(s) can have a better life.

Some of this seems paradoxical to those who have been in bad situations. My sympathy to you. But do not lose the faith that some day you will see, in a good team, that it is true.

In my opinion, one of our deepest desires as humans is to be known for that person that we truly are, neither hiding nor boasting, both the good and the bad. It is a deep desire, and a good team can enable you to experience that in a far greater degree than we may have up to now. And it even happens while we are going real work. (ie, Not from some fluffy exercise from a consultant, not in some artificial way.)

The importance of teams

As I teach scrum and lean-agile classes, I often meet people who don't understand teams. Often this is true for some of the smartest, most capable people.

Why?
I think there are many answers.

One is that they have been taught the single-leader team discipline. (This is the phrase that Katzenbach and Smith use for it.) So they assume there is no real team discipline. Ie, they have not been taught it.

So, what is the real team discipline? Many people have talked about it, but Katzenbach and Smith have done a good job of defining it in The Wisdom of Teams.

• Small number
• Complementary skills
• Common purpose, common set of specific performance goals
• Commonly agreed work approach
• Mutually accountable

Another, simpler way of talking about this is to say that the team is smarter than any individual.

This is a little dangerous to say. Yes, teams can be stupider than a single individual, if they let themselves. But Katzenbach and Smith show a number of cases where the team, a real team, was smarter than one individual. Not really surprising to me, since we know the old saying, two heads are better than one.

Why is this so true in our work?

Well....
- we need innovation; generally via basic brainstorming, a small team can be more creative
- our business domains are typically bigger than they used to be
- our technical domains are typically more complex than they used to be
- the speed of change (in all these areas and more) is greater

So a team is better able to keep up. If they are a real team.

More soon....

See The Wisdom of Teams here:
http://bit.ly/9BixGz

JIT Knowledge Creation

This is our business. Just-in-time knowledge creation. (It is not just-in-time knowledge management.)

Why? And why is it so important?

Well, ultimately the answer is because people are important. Or maybe it is better to say we respect the customer. And the firm's shareholders.

What do I mean, you say?

Let's start from the beginning. A long time ago the Lean people discovered that any Work-In-Process waste (WIP) or inventory, is muda. No, they weren't being silly. All Lean firms still have some WIP and inventory, but they have been relentlessly reducing the ratio of WIP and inventory to sales for 50 years now. And now it is a very small fraction of what it used to be. And they are still not satisfied. It must be reduced more.

And why did they do that? Well, in the auto industry they realized that an unsold car in inventory is trouble. It can only get worse, it cannot get better. The sun can spoil the paint job. Rain can cause rust. Hail can damage the exterior. Time can make it go out of the current model year. In other words, they noticed that the car can decay. (There are other reasons too.)

In software development, our business is knowledge. In the form of working code.

How fast can our knowledge decay compared to a car?

And here we mean not only the final knowledge (the working code), but also all the other tacit and explicit knowledge needed in the course of building the working product.

My opinion, and I usually demonstrate this easily in each Scrum class, is that our knowledge decays exponentially faster than a car. And a car's value will only go down a bit at a time. But our knowledge can lose its value as much as 100% in one day.

So, although no one told you, we in the software industry need to be relentlessly reducing our all our work-in-process and inventory. So, WIP is any work we have done that has not resulted in finished inventory. Finished inventory is fully finished software, that is all but deployed and in use by the 'customer'.

Now, we don't mean you should be foolish. For example, there is a minimum marketable feature set concept that does apply. Although we think that the size of the MMFS is much smaller than we almost always want to believe.

Again, a key goal of how we organize things should be to minimize WIP and inventory. And because there are many reasons for that, we can also organize things to minimize the negative impact of the WIP and inventory we 'must' have. (We will talk later about some of the other negative impacts of WIP and inventory.)

We must have a greater percentage reduction in WIP and inventory than the auto industry. We have lots of work to do to make that happen. Lots of impediments to remove. It was hard for the auto industry, and it will be hard for us. And now we have made the first step -- someone has told you that is absolutely key to your job.

Now, you know what your job really is. To know and not to do, is not to know.

BTW, Takeuchi and Nonaka have written many many pages about knowledge creation. They are the godfathers of Scrum. (A hint, for those who want a hint.)