Only solutions deliverers

As I was saying earlier, in all my clients there is this divide between Business and Technology. "I'm a business guy, not a technology guy." "Oh, I work in IT; go ask the business folks that."

This is an unhelpful distinction.

The customer does not want business or technology or even a product. The customer just wants a solution to his problem. Now.

So we all are just solutions deliverers.

And it becomes clearer each day that our job is to work together in teams, to create the knowledge needed for the next solution. To create the metaphor of what the problem really is; to envision how it might feel to have it solved. To brainstorm, to see the whole problem, to imagine how alternate solutions might fit, to transcend the constraints, and finally yet quickly to deliver what the customer really needs to solve his problem, not what he said he wanted.

Have Compassion

Today I was in a meeting with Business and Technology folks, and I started talking about Customer Collaboration over Contract Negotiation. (Many will recognize this line from the Agile Manifesto.)

And I talked about how, always, there is distrust and tension and misunderstanding between the Business side and the Technology side. Well, at least on day 1 in every client I walk into. YMMV. With luck, we start building trust right away.

In thinking about this on the plane back home, I wanted to say something to those 12 people. And since they are not with me now, I will say it to you.

Have compassion.

What do I mean by that really?

First, the most important thing is that it is more blessed to give than to receive. More specifically, it is not about you. It is about doing for others, most especially for the end customer.

Let me introduce my second point with a story. When I teach Agile I like to start with the story of the 6 Blind Men and the Elephant. I won’t explain that story now, but one reason I like it is because that story is also related to Buddha. The compassionate Buddha, as he is known. And Buddha had great compassion for us, and our inability to comprehend all the knowledge we needed to know, and to figure out what is really important. And I say, we team members should have compassion for each other and how hard our work it, how much we need to learn. We try to solve the problems if a person who almost always is not there, and do it with a system that is abstracted and non-concrete in the extreme. And all the easy projects have already been done. Difficult work. We need compassion.

My third point is more specific. My experience is that most Technology folks have no conception of how difficult it is for the Business folks to see and be accurate about what the business need to do to satisfy their customers. The customers are changing, the competitors are changing, they don’t have time to understand what is do-able. This is extremely difficult work that only a few are truly insightful about. (In our economy, many are modestly lucky.)

On the other hand, the Business folks need to have more compassion for the technology guys. Technology work is extremely challenging, and offers great opportunities for creativity and discovery for those Business folks willing to travel those uncharted seas. And capable of escaping the dense fogs.

My fourth point starts with Deming, who has many valuable insights. Deming said that all problems in business are caused, in simple terms, by two things: “the system” and the people (vices, true inability, laziness, etc.). The “system” was all the things that were (or were not) there to structure the people and the work to get the work done. Initially he guessed that 80% of problems were caused by the system and 20% by people. As he grew older and learned more he revised that. I think he finally said that 95% of problems are caused by the system and only 5% by the people. And a leader's job is to get the system improved.

My point here is that, while you may be frustrated in some ways with your colleagues, most of your frustration is not about them, but about how “management” (maybe yourselves) have structured the system through and in which you work together (or not together).

Have compassion. Have patience. And start improving it today.

Keeping with the Beat

Where would I go to find the latest information on Agile and Lean? What if I had a question and wanted expert advice?

Try these "boards". Sign up. They are free.

ScrumDev

Extreme Programming

Agile Project Management

Lean Software Development

Industrial XP

I am a particular fan of the last one. It's theme is applying XP in large, enterprise situations. Some very good conversations.

Advice: As with most things in life, you get more by giving more. Dive in, don't just lurk. Receive postings in a Daily Digest (change it at "edit membership").

Caution: There is some "inside baseball" or "inside the beltway" stuff going on. Bring your salt shaker. Sometimes a board or several boards will seem to become obsessed with one topic. There are many reasons for this, but if you need a discussion of a topic, search the history or ask a new question. Ask and it will be answered. Seek and you will find. Be selective. Use common sense.

There are some great people on these boards. Some of the comments are pearls beyond price. (And some are rubbish.) YMMV.

If you are interested in similar boards, tell me. There are others for more specific topics.

Proposed Reading List

For the CSM Class in NYC on Sept 5-6.

A teacher recently told me this: “To know and not to do is not to know.” And we know from many teachers that we learn best by thinking a bit and then practicing some, and then thinking some more and practicing more.

This is embedded, as one example, in the Deming Cycle.

So, I have already suggested that the best way to learn for you, right now, might be to practice for a while. A short while.

Next, one needs to say that each of us is different. So, if we want our learning to be effective, we need to consider our individual needs and abilities. Some of you think in concepts, some in pictures, some with stories, etc., etc. Some of you understand (or have no interest in) User Stories, for example. Others have pressing needs to understand engineering practices.

Also, now that you have been infected with the Agile virus, you can read almost any book from an Agile viewpoint. War and Peace by Tolstoy is one of my personal favorites. This might be the best way for you.

Now, after all these explanations (and you might say, excuses), here are some suggested readings.  I have these books on my website, with direct links to Amazon, so you might want to go there:

User Stories Applied by Mike Cohn. Great book on how to write and use User Stories. And once you feel you get the ideas yourself, go to his site (www.mountaingoatsoftware.com) and download some of the presentations on this subject. To use for your discussions with associates.

Agile Estimating and Planning by Mike Cohn. Here he discusses planning poker, and lots of other subjects around Release Planning and Iteration Planning. Again, he has very useful presentations on this subject as well.

The New New Product Development Game by Takeuchi and Nonaka. Article. This is where Scrum started. To me, it is essential that we view our selves as creating new products. Passing this one around starts to get light bulbs turning on.

Extreme Programming Explained (2^nd Edition) by Kent Beck and Cynthia Andres. Kent Beck, Ron Jeffries and Ward Cunningham are the three guys most responsible for extreme programming. Kent is an excellent writer, and his discussion of values, principles and practices is wonderful. (Be aware that some people prefer the 1st edition (2000), but that is now hard to find.)

The Knowledge-Creating Company by Nonaka. This is a HBR article that summarizes many of the key concepts in the book (of the same name) by Takeuchi and Nonaka.

The Concept of Ba by Nonaka.  This is an article that summarizes some of the key concepts that are discussed in the Hitosubashi on Knowledge Management book, edited by Takeuchi and Nonaka.

Fearless Change by Manns and Rising. This book is about introducing a new idea into any “group” (such as your company). These ladies are actually Agilists, but the book is about introducing any idea (not specifically Agile). The book presents a little theory and lots of patterns on how to influence various people so that Scrum/Agile/Lean will succeed in your group. The majority of these patterns you know, but the reminders, tips and tricks are very valuable. Arguably, this is the most important book for you right now.

The Power of a Positive No by William Ury. Bill co-wrote Getting To Yes. This book, about saying no sometimes, is essential. Almost everyone in Agile that I know is not practicing sustainable work because they can’t say “no” enough. Frankly (although Bill is a friend) the title is a little hokey to me, and the basic idea seems obvious (you have to say “no” before any “yes” can have meaning). Again, in theory there is no difference between theory and practice…in practice, there is. As you read the book, I think you will learn useful ways to say "no" almost as often as you should. Priorities.

Working with Legacy Code by Michael Feathers. This book has lots of ideas about how to deal with legacy systems. Michael is an excellent Agile Coach (a bit more in the XP flavor).

Lean Thinking by Womack and Jones. The first chapter of this book is an excellent introduction to Lean. Some of you will be amused to learn that Ohno, whom many credit with inventing Lean, said that he learned it all from Henry Ford’s book Today and Tomorrow.

Implementing Lean Software Development by Mary and Tom Poppendieck. Excellent source for taking Lean ideas and applying them to software development. This is their second book. Not a bad book for you to read first, in fact.

Godspeed on your journey.