Friday, November 30, 2007

Carnival of the Agilists - 11/29

Once again we are pleased and humbled to be included within the Carnival of the Agilists collection of blog posts. See here: http://trailridgeconsulting.com/blog/?p=104

For all the prior Carnival of the Agilists selections, see here: http://www.agilealliance.org/show/1670

Enjoy. These are recommended.

This is not to say that I would agree with every word of every post, but "two heads are better than one" is an key idea in Agile. The team is wiser than any one individual. (Yes, I know there are exceptions, and a good team knows when to follow the leader.)

Wednesday, November 28, 2007

"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.)

Thursday, November 22, 2007

Top Enterprise Impediments - Part 2

This post is a continuation of the previous post on Top Enterprise Impediments. Here we add 3 more impediments.

No or minimal Business commitment

This problem recurs and recurs. It derives in part from the Business people viewing Lean-Agile as a Technology initiative. It also derives from the Business people believing in magic. Not understanding what Technologists really do, they “give up” and just hand off stuff to Technology to “just go do it”.
First, we need to recognize that the Business side is unlikely to commit to something unless someone asks them to, and points out the value of committing. Like everyone, they are busy and they need to be convinced that the Lean-Agile initiative needs to be on their plate.
The problem also derives from the Business people having a lack of focus, or being driven by their managers from one thing to another, so that they must lack focus. Example: One business person is not able to be a consistent Product Owner to a small team due to his manager’s lack of focus.
The Business people who really understand, who understand the problem the team needs to address and the real needs of the customers, are extraordinarily valuable. If the value of them playing with the Technology team members is not continually made visible, they or their managers will often forget. (I am reminded of the Dylan song "What was it you wanted?", covered by Willie Nelson.)
And, based solely on experience, we know that teams with active business side Product Owners, who are participating roughly half of each day with the Team, these teams are the most successful, and are most productive in producing business value quickly. This is not just my personal experience, but the experience of many many people using Lean-Agile in many firms and situations.
Lack of appreciation of the change effort
Many managers seem to think that once something is “decided” it naturally sticks and happens. But the facts are that Lean-Agile is a major mind shift for everyone, and particularly for some people. These people think they get it, but they do not, and every other word betrays that they do not, even as they say that they do.
Lean-Agile is also a big change for the culture of all firms that I have worked with (and this is confirmed in discussions with all the coaches I meet). Each culture wants to revert to some “natural” state, and that state is not Lean-Agile. I will guess at the main cause: Lean-Agile is just a little bit too transparent for comfort. There are other causes as well.
Moving the waterfall mindset and replacing it are extremely difficult. Many key tenets of waterfall thinking are deeply embedded in all of us, and, as with smoking, those old habits do not go away just because we “decided” to stop. Toyota has gotten good acceptance of Lean after decades of work in changing its culture. And that work continues.
So changing people’s core habits is an enormous struggle. What is delightful is that even a minimal change (and the use of some core practices) almost immediately enables most teams to be more effective than they were before. How remarkable!
Perhaps more to the point, every culture will contain people who will seriously resist the change. They will nod their heads, but subconsciously or even consciously, they will resist. There are many reasons for this and many types of games that are played. This is normal, expectable, and in some ways not to be blamed. Arguably the struggle at the level of the middle managers’ (between the advocates and the resisters) is the key “event” that will determine whether an enterprise will really “go” Lean-Agile or not.
No or minimal embedded culture for managing impediments incrementally
All firms have some de facto approach to dealing with problems. While some of the approaches may not be official or even very effective, some problems must at least be addressed. So, in some sense, every firm has some kind of impediments management approach.
Lean-Agile asks the firm to go to a higher level. First, it asks the firm to focus on improving the fast delivery of business value, and specifically the velocity of its Lean-Agile teams. Anything that is slowing that stuff down is an impediment. Anything!
So, Lean-Agile demands a relentless honesty about all of our problems. In fact, our biggest problems. Some managers want to blame people as soon as they hear of a problem, so you immediately see that this does not breed a good impediment management culture. ("My system is perfect, but it's those darn workers who aren't doing it right.")
Beyond the identification of impediments (typically by the Lean-Agile teams), managers (and the culture) need to learn more rigorous ways of prioritizing and taking action on the impediments. This is often a significant shift.
And not an easy one. Impediments come in all shapes and sizes. People issues, compensation issues, training issues, Corporate Real Estate issues, Build issues, Testing issues, etc, etc. Some of these require significant investment. An investment that is only justified if the problem is big enough, which might be proved, for example, if many teams are experiencing the same problem. Getting the visibility into how many teams are affected by a given problem often requires a culture shift in the way impediments are handled.
Another part of the culture shift is the approach of continuous improvement. Many firms start with an attitude of “I want to fix it once and for all”. Classic waterfall thinking. So they do not take the opportunity to fix an impediment partially, and then look and see if it remains the biggest impediment after the smaller, quicker fix.
* * *

If we only had these 6 impediments fixed, Lean-Agile adoption might be easy sailing. But, easy or hard, it's worth the effort.

Thursday, November 15, 2007

Some Top Enterprise Impediments

I have had several conversations on this topic lately, so I thought I would post some thoughts. Actually, this will take several posts. (And one could argue that many earlier posts are also about this topic.)
My aim in the comments below is to identify and describe the main impediments that are most typical in a large enterprise. Occasionally I will speculate or comment on the source of the problem in my experience. While the descriptions may suggest ways of addressing these impediments, proposing a full course of action is not a goal here. First one must identify the real problem.
Word of caution: These may not be your top impediments. The way I look at it, nothing is perfect and everything is an impediment to some degree. But you need to identify your top impediments today...so you can improve them now. So, use the comments below with caution.

Top Management

Top Management itself can be the top impediment. What do we mean by this? Several things. First, top management may in effect oppose the change. Ex: Proclamations that imply a waterfall approach to work.
Does top management clearly support the change? This may be at least a point of confusion to middle managers and performers. In most firms, some people have more courage if they know they are doing things that are generally in the flow of top management’s direction. Ex: Statements that repeatedly mention the core benefits of Lean-Agile will enable greater courage.
Next, does Top Management really understand the change? Well? Surprisingly perhaps, the first two points do not require that top management really understand Lean-Agile well at all. This point means they understand it, they ideally have executed some work using the core methods. And therefore they have a chance of accurately coaching wayward participants in the new approaches.
There are other related issues addressed later.

Command & Control Culture

It continues to surprise me that “management” does not understand that Lean-Agile does not take a “command & control” view of people. To me, the choice is very simple: are people free or are they slaves? If they are free, then one must lead them, pull them, respect them. And not push them, boss them, and micro-manage them. If they should be slaves, then clearly workers need to be bossed and micro-managed.
Often, whether Top Management is aware or not, “management” (I am thinking of middle managers here) are using a command and control culture to run the shop to a large degree. And these power dynamics can cripple the Lean-Agile adoption.
Now, I do not mean to propose a full laissez-faire view of people. “They are good and I don’t need to manage them at all.” To me, this also is a silly notion. One must be adult and realistic. We lead, we ask, and we pull. But occasionally we must decide a person is not making it. Occasionally we must keep asking questions about why work is not done. (There can be lots of reasons, and a small share of them are about the person, not just “the system”, as Deming has said.)
Culture and attitudes of thinking take time to move and change. Top Management, who is always ultimately responsible for a successful change, must expect these movements to take time. This particularly applies to a Command-and-Control culture; this will not change (and stay changed) based on one top management declaration. (Yes, "I command that a command-and-control culture end immediately" does seem almost laughable.)
Lean-Agile viewed as a Technology initiative
Lean-Agile is really not about delivering software. There are no “technical successes”. Business Value is delivered or not. The customer’s problem is solved (or partially solved) or it is not.
So, every time someone thinks of Lean-Agile as a Technology initiative, that is an impediment to their proper thinking. And their proper execution. This manifests itself in many ways.
Delivering business value of course requires daily interaction between Business and Technology people. If Business people hear that Lean-Agile is a Technology initiative, they immediately assume that their role in it is minor.
Perhaps more to the point, solving problems requires the creation of knowledge in some combination of business and technology domains. So, almost by definition, half of the problems in creating this knowledge have to do with the business side. If the Business people do not own Lean-Agile as a means to solving business problems, then many of the most meaningful productivity increases are unlikely to occur.
In any case, Lean-Agile is trying to help solve the Business problem of how to deliver more business value. So, by definition, it should be a Business initiative.
More impediments to follow. Your comments on these are welcome.

Tuesday, November 13, 2007

lean

Jim York will lead a CSM course in Charlotte on Dec 4-5. See here for details:
http://wiki.kittyhawkconsulting.com/Jim+York+CSM+Course+in+Charlotte

Or contact me.

Tuesday, November 6, 2007

Reading List for CSM Course Nov 5-6

The following are some suggested readings for people in this course. Others may enjoy also.

Again, as always, I recommend that you learn as fast as you can. And that you mix learning with action. To know and not to do is not to know. Thus, your real knowledge becomes known in how well you can act. Then you see your...opportunities for improvement, and are ready to learn some more, and then to act again. So, read what you will learn from and what you need to learn now. These needs will differ for each person.

For some of these books and more, see http://www.kittyhawkconsulting.com/id15.html In this case, I have made the entries graphical, which some may enjoy. Click on an entry, and you will go to Amazon.com, where you can read more about the book.





And three articles:
The New New Product Development Game by Taeuchi and Nonaka. Where the Scrum name came from.

The Knowledge-Creating Company by Nonaka. This article is a very short version of their book of the same name.

The Concept of Ba by Nonaka and Konno. In Scrum, the team room is the "Ba" (the place or context in which knowledge is created). So, this will help you understand what kinds of things should be going on in the Team Room or other Ba's.

See also this earlier post titled Prioritized Reading List.

Scrum and Agile are simple. At the same time, all the different reasons you follow these Scrum practices are many. And people are...involved. So, there is always more to learn.

Saturday, November 3, 2007

Carnival of the Agilistas - 10/30

We are pleased to modestly report that our blog has been included again in the Carnival of the Agilists, this time the 10/30 edition. See here: http://www.notesfromatooluser.com/2007/10/carnival-of-the.html

This listing of "the best Agile blog posts" is quite interesting. See here for the fuller listing:
http://www.agilealliance.org/show/1670

Enjoy!