If your company has meaning, write it down!

At first glance it may look as if most organizations do very well without having their values written down. However, this is only a surface impression, because all organizations are based on values. The most important concern how the organization views its customers and subcontractors – and how it treats its members.
– From Kolindkuren, by Lars Kolind (English version)

Lars Kolind was CEO of Oticon, a formerly successful manufacturer of hearing aids. The company eventually became a victim of its own success, and went into a seemingly unstoppable downwards spiral. Lars Kolind reorganized the company radically, turning traditional views about how a company should work on its head. His book, Kolindkuren, is a great example of a corporate guide: It is about meaning and values, yet contains a lot of practical advice useful to everyone.

The ability to care and play nice is becoming an increasingly important success factor for business organizations. The reason is simple: The Internet has enabled customers to communicate.

Twenty years ago, dissatisfied customers rarely could or did get in touch with each other. Today, it’s easy. If a customer is dissatisfied, she may tweet or blog, or just look for other dissatisfied customers, and connecting is easy.

Of course, other groups can connect just as easily, for example employees, ex-employees, and sub-contractors. And all these groups will cross-connect, and share information with each other.

For a traditional we-are-all-about-short-term-profits-for-our-shareholders company the environment looks more and more like a PR mine-field. When these organizations attempt to take control over the situation, they almost inevitably make it worse. 

On the other hand, a company that shows genuine care, and behaves responsibly towards not just customers, but towards everyone it interacts with, has got the same factor, easy communications, working for them. When people like what you do, they will talk about it, and the word will spread.

People will like what you do, if what you do has meaning. Assuming that you are a high level executive, ideally a CEO or equivalent, and you want your organization to stand for something, what do you do? I am going to assume that you belong to the select group of high level executives who are prepared to do battle for their beliefs.

Ricardo Semler's Semco is arguably the world leader in management and leadership innovation. Semler is a great writer, but for the purpose of this article, one of the appendices is the most interesting part of the book. It contains a corporate guide written in the form of a comic strip. Easy to understand, and the focus is on practical behaviors.

You do need to spread your beliefs and values throughout the organization. An important part of this is direct interaction: You must behave in a manner consistent with your values and principles in your daily work.

Unfortunately, if your organization is larger than just a handful of people, you can't spend as much time with everyone in your company as you need. Still, there are lots of things you can do. For example, you can make sure that the people you do meet frequently do share the organizations goal and values. That is important, but it is probably not enough. You need something that allows you to communicate more directly with the people in your organization.

For starters, I’d suggest that you write the meaning, values, principles, and desired behaviors down!

Writing your ideas down is one of the best ways to share them. You do not need to write a best-seller like Sir Richard Branson, or Ricardo Semler, but you should create something that will inspire the members of your organization.

Most corporate manuals are abominable: Command & Control style do-this and don’t-do-that lists. They are boring, and, all to often, insulting to the people who are supposed to read them (but usually don’t). They do of course tell the few people who actually read them about company principles and values. It is usually not the story top management intended to tell.

Givers Gain by Dr. Ivan Meisner explains the basic philosophy of Business Network International, BNI, and tells entertaining stories about how BNI evolved to be the world's largest business referral network. Every new BNI member gets a copy of the book.

Good corporate guides are quite different. They speak about the meaning of the company, the difference it wants to do in the world. They speak about the values of the organization, and how to apply them. In particular, they tell stories about how to apply the organizational values in difficult situations. Such a guide says: this is what we believe, and this is how we live up to it when the going gets tough!

Here is a simple test for a corporate guide: Is the guide something that you yourself want to go back and read now and then? If it isn’t, throw it out! Why inflict something on other people that you do not like to read yourself?

Dave Stewart and Mark Simmons wrote The Business Playground partially to inspire other business people to dare be more creative, and partially to show off their company Weapons of Mass Entertainment, and the creative abilities that power it.

A guide that uses real life examples can be particularly powerful: When Anna found herself in [a particularly difficult situation] she did [solution consistent with organizational values].

In order to do that you need to:

• Find stories that are applicable and true, preferably in your own organization. However, if you are faced with a dearth of engaging stories, it is better to go for true stories from outside your organization than to invent stories about people in the organization. Writing fiction, as fiction, is OK, but trying to pass fiction off as something that really happened is a no-no. First of all, it is dishonest. Second, you’ll get caught. The first reason ought to be enough.
• Write the stuff down! I am using write a bit loosely. You could make a set of videocasts, or presentations. (No bullet points! 99% of corporate presentations are c**p. If you present about this, make sure you are in the remaining 1%. Your audience deserves it.) If you write a book, make it available in both print and eBook formats. Print-On-Demand makes it really cheap to print good quality books. Make eBooks for the convenience of the reader, not because you are cheap. Believe me, readers can tell the difference!

The Virgin Group is a very large business organization. Sir Richard Branson writes to ensure that the company values remain strong throughout the organization. And he does it well, in a very entertaining manner.

Here is an important bit: If you bring in a consultant, like me, to create a corporate guide, make sure the project is still by people in your organization, for people in your organization. When the project is done, there must be people in your organization who can say, with pride: We made this!

If you happen to be a CEO, you might think “Great idea, but I can’t write a book to save my life, and I can barely videotape my children’s birthdays.” This may be true, but so what? You can still collaborate with with a writer/editor, and a videocast director.

If you have something to contribute, do it! I wrote Tempo! to be the guide I wish I had read before starting my own business seventeen years ago. It was a lot of work, but seeing Tempo! in print made it well worth the effort. Now, of course, I want to write more...

The only reason for not writing down the reason for a company to exist is if there is no reason for the company to exist!

Otherwise, in one way or another, you should make sure everyone knows what makes your organization special. It is well worth the effort.

How Shahin Khoshnood made great leadership easy

Shahin Khoshnood is a remarkable manager and leader. She was recently promoted to a higher position, but for the past few years, as area manager, she has transformed eldercare in Linnéstaden, a district in Gothenburg.

To give you a small taste: Personnel turnover is in Shahin’s district is 0%. Her unit has always managed to keep within budget. When there was not enough money for a training budget, Shahin and her people turned the problem into an opportunity, and began packaging and selling courses to raise more money.

I met with Shahin last Friday to interview her for my next book. (Please do not hold your breath while waiting for it. It is a long time project.) A friend of mine, Per Dosenius, had recommended that I should talk to her. I am very glad I did.

When I arrived, Shahin showed me to her office. The office is quite spartan. Shahin has developed a very cost conscious organization, and she leads by example.

The secret to Shahin’s success isn’t very secret. She has put the essentials on the walls of her room: Four sheets of paper that expresses her management philosophy very concisely.

The first sheet of paper is the one you see above. The text reads Never give up.

The picture struck a chord. If you have a goal worth striving for, I mean really worth striving for, you will get into difficult situations. It will happen not just once, but over and over again. If you fight back, you will, like the frog, always have hope.

I’ll save describing the other three illustrations for the book, but I’ll tell you a little bit about Shahin’s recipe for success:

At the core is an unshakable faith in people. Since the beginning, Shahin has worked to encourage her people to take initiative and responsibility for their situation. She encourages them to think and to act, and lets them know that she is there to support them if they need it.

Shahin works by setting clear goals, and by working out intermediate objectives. That way, she says, when circumstances change, adapting plans is fairly easy.

Shahin views power as a means to an end, not a goal in itself. She makes a clear distinction between power and control. To achieve her goals, she delegates. Control over detail is traded in for power to achieve important objectives.

Shahin used to be responsible for about 50 people. There were no intermediate managers between her and people in her area. This is possible because the people who work for her know what the objectives are, and they have the skills, authority and confidence necessary to solve most problems for themselves.

With her recent promotion, the number of people working for her has doubled. Starting the 1st of January, she will have two or three unit managers. Shahin was careful to stress that they must be willing and able to work the same way she does.

As Shahin points out, when things are set up so that people are encouraged to take initiative and solve problems, managing and leading is much easier than you’d think. It is not easy in the sense that all problems disappear, far from it. But, her management style allows Shahin to focus on the things that are really important, instead of getting caught up in firefighting.

Shahin has the brainpower of her entire organization working on solving problems that would otherwise land on her table. Having goals aligned with moral convictions is also a source of tremendous strength for her, and for the entire organization.

As I listened to Shahin, I noticed the strong similarities with the philosophies of people like Ricardo Semler, Tony Hseih and Richard Branson. What they all have in common is a deep rooted faith in people and the courage to follow through on their convictions.

It was easy to understand the effect Shahin has had on her people, because when I left, I could feel it myself: A lot of energy and a desire to get going with the really important stuff.

Which is why I’ll end this blog post here. I have lots of fun things to do.

Be seeing you!

Five Day Jonah Workshop with Bill Dettmer

Bill Dettmer will be in Linz again to hold a workshop on The Logical Thinking Process. The workshop will be held March 9-15 in Linz, Austria.

The embarrassing thing is that Christoph Steindl of Catalysts emailed me about it months ago, and I forgot to blog about it. A Do-Not-Forget-note surfaced yesterday when I made a long-overdue clean-up of a list of Interesting Stuff.

How values drive HiQ

I saw an interesting presentation about how to build and manage a value-driven organization last Friday. The presentation was a collaboration between HiQ, a Swedish IT-consultancy, and Kevin Ryan, owner of the management consultancy Thread.

The evening started off with,  Jerker Lindsten, CEO of HiQ Gothenburg, doing a Guitar Hero performance.

I am definitely no Guitar Hero. I sometimes whistle a little bit, but that’s it! As you can see in the picture above, the performance was greatly appreciated the rest of the audience.

When the audience was warmed up, Kevin Ryan took the podium. Kevin has worked closely with Lars Stugemo, CEO of HiQ International and one of the original founders, to articulate the company values and instill them in the HiQ organization.

Kevin began by talking about the conceptual differences between a traditional maximize-the-profit business and a value-driven business. Kevin built the explanation up in stages and I believe the audience got it.

When I talk about value-driven organizations (whether presenting, writing or just ranting) I often talk about how a value-driven organization can bring costs down in ways a traditional business organization cannot do. Kevin did something smarter, he talked about how the cost of evil is going up.

He is right of course. Thanks to the Internet a single dissatisfied customer can easily tell the entire world exactly why she/he is dissatisfied. Companies that get this have a strong incentive to be on their very best behavior. Those that don’t get it will eventually be forced out of business. Their customers will just walk away to somewhere where they feel welcome and appreciated.

Thus, the cost of indifference and evil is way up from what it used to be, and as customers become used to their new power, will rise even more in the near future.

Building organizations that truly care requires a different kind of leadership from what we are used to seeing. Kevin used George Bush and Barrack Obama as examples.

Obama is an empowering leader, and proved himself a very good systems thinker during his presidential campaign. Kevin did point out that Obama may have done just one too many deals with the devil in order to get the health insurance bill through. Nevertheless, the idea stands: Empowering leadership a la Obama is way more effective in our highly interconnected world than the Command & Control style represented by Bush in Kevin’s presentation.

I think the last slide in Kevin’s presentation sums up the profit-driven and the value-driven views very well.

Lars Stugemo, one of the founders of HiQ took over, and talked about how the focus on values affect HiQ.

Lars mentioned that the core values of the company haven’t changed much since 1995, although the way of expressing them has evolved.

In 2009 HiQ put their core values right on the front of their annual report. I think the move was an excellent one, and I do hope it inspires leaders of other companies to think seriously about their own values, and about how to use their business organizations to express and promote them.

Kevin and Lars did provide a very good high altitude fly-by. I think it was the right amount of information for the audience to absorb. It left me hungry for more though.

The expressed values of an organization are effective when they affect every day behavior of the people belonging to or interacting with the organization. Figuring out the link between a value and a behavior can be very difficult though.

What Lars did not talk about is the systemic changes necessary to make the behaviors stick, and how difficult it can be to connect the dots. That would have been overkill for the evening.

Since it is in my area of interest, I’ll give you an example anyway. Note that it is my own example. Neither Kevin, nor Lars went into details, so I have no idea how HiQ encourages developers to write simple code. There are usually several different but valid solutions for how to achieve simplicity in any particular situation:

For a programmer, valuing simplicity may be interpreted (a bit oversimplified) as “take care to refactor code”. Pair-programming is a practice that can reinforce refactoring behavior, so a company that wants to produce simple code might promote pair-programming as a way to do it.

On the other hand, MS Project, because of the Critical Path algorithm it uses to calculate task buffers, can easily discourage refactoring, so a company striving for simple code might either elect not to use MS Project, or complement it with some product like CCPM+, that replaces the Critical Path algorithm with a better one. Or, they may elect to take the hit from the Critical Path algorithm, and compensate in some other way.

I will skip the details about how a commonly used task scheduling algorithm can drive behavior that reduces the quality of work, not just for programming tasks, but also for other types of work. It is beside the point here. The point is that translating values into behavior will require systemic changes that may be far from obvious. (Besides, I have written about the shortcomings of the Critical Path algorithm elsewhere. No use kicking an algorithm that is already down.)

Also worth noting: Simplicity from the point of view of a customer is very different from simplicity from the point-of-view of a programmer, which is different from simplicity from the point-of-view of a project manager, and so on.

Going for simplicity involves achieving the optimum balance. Usually the balance should be weighted heavily in favor of the customer, but most organizations are designed to assign greater weight to internal considerations. That means you must consider large scale organizational design, rules for promotion, Key Performance Indicators, leadership training, and a host of other things, just to achieve simplicity.

Figuring things like these out requires both a lot of work, and the courage to experiment. Both Kevin and Lars touched on the enormous amount of work necessary, but they, very wisely I think, chose to preserve the sanity of their audience by omitting the gory details.

I cornered them both right after the presentation and asked a few questions. Though we spoke very briefly, I got the impression that they both have put not only a lot of effort, but also a lot of thought into what they are doing. I have no doubt they could tell a lot of stories about how counter-intuitive and challenging designing a value-driven organization can be.

Even though more and more organizations strive to become value-driven, and a new generation of value-driven organizations is cropping up, going value-driven still requires a lot of trail-blazing.

In a way, running a value-driven company will always require a lot of exploration and a spirit of adventure. Business leaders cannot just copy & paste values from some successful organization and expect this to work in their own. (Though I am certain many will try.)

In other ways though, having examples to draw from is incredibly useful, just like climbing Mount Everest became easier once Sir Edmund Hillary and Tenzing Norgay had done it in 1953.

Today, there are plenty of examples of value-driven organizations to draw from, like Gore & Associates who have been value-driven since the sixties, Semco who is renowned for pushing its principles well into places where no business has ventured before, Whole Foods, BNI, Branson’s Virgin Group, and many others.

Unfortunately the link between the success of these companies and their focus on core values is poorly understood outside the companies themselves. It is as if if Sir Edmund and Tenzing came back from their Mount Everest expedition, told the world about it, and everyone was too busy falling off cliffs to listen to their story.

For every company that goes seriously value-driven, the link between core values and long-term success as an organization will be understood a little bit better. And, truth to tell, even though we have a reputation for empowerment and employee participation in decision making in Sweden, I think we are in great danger of lagging behind. Therefore, I do hope Kevin and Lars will keep telling the HiQ story.

Anatomy-Based Planning workshop with Erik Lundh

Erik Lundh of Compelcon held a workshop on Anatomy-Based planning. Erik was kind enough to invite me. I jumped on an early morning train from Gothenburg, just barely made it off the train at the station in Lund, and found my way to the Lund Institute of Technology where the workshop was held.

The workshop was well worth getting up early for. Anatomy-based planning offers a neat way of coordinating large projects involving several agile teams. The method is designed to get all stakeholders onboard with an overall plan before going into detailed iteration planning.

It is a very fast planning method. All stakeholders are brought together, write the desired capabilities, or "money-making features" on Post-It notes, and build a network diagram showing "in order to have Y, we must first have X" type dependencies between the features.

Anatomies are an implementation of the Blackboard Strategy pattern, an approach to collaborative problem solving. Because it is a very fast planning method, it fits with agile software development very well.

Anatomy-based planning was originally developed by Jack Järkvik at Ericsson in the 1980s. Jack was understandably annoyed with large projects that fell to pieces due to a lack of coordination between stakeholders and because features were introduced in not-so-logical order, making the systems both expensive and fragile.

One of the projects that prompted an early version of Anatomy-Based Planning was the development of a weapons system for a corvette class warship. The system often crashed when the power was turned on. If it survived the startup procedure, it crashed whenever anyone touched a trackball...

I won't go into detail about how to create anatomies (but do ask Erik). I will mention a feature that I particularly like: Anatomies have expiration dates!

In all its simplicity, this is a brilliant feature. Plans tend to go stale, and it is easy to skip updating a plan. By putting an expiration date on an anatomy, you ensure that the stakeholders must meet again to update it. At the same time, the simplicity, speed, and not to forget, the fun, of the planning process, makes this one kind of meeting people can actually look forward too. Just make sure someone brings snacks.

I am very glad I went to the workshop. I learned something new, met some great people, and had a thoroughly enjoyable day.

Erik and I keep in touch, so expect more articles on Anatomy-based planning in the near future.

Callisto on creativity

Callisto Utriainen

I was at a very interesting talk last Thursday. Callisto Utriainen, a creativity coach, talked about creativity, how it works, and how to find creative solutions to irksome problems.

Callisto started off by talking about a great creativity killer: Too deeply rooted habits.

Habits are not bad per sé. Habits free brain capacity up to do new things, like finding creative solutions to problems, but there is a flip side. When we get too deeply entrenched in following the same patterns every day, we may lose the most important habit of all, the habit of thinking and doing new things.

When we get creative, we physically change the brain by creating new connections between neurons.

Callisto also talked about what habits look like from a neurological perspective: Pathways in the brain where synapses (junctions between neurons) have grown strong because they are used a lot.

She talked about how we can induce the brain to create new pathways by deliberately exposing ourselves to a state of confusion, like when someone tells us a joke. First, when you hear a joke, you get confused, then, when you get it, you laugh. Do a lot of this, and the brain will create new synapses, and you will actually get smarter and more creative. (Even if you don't, you'll have a happier and more interesting life.)

Solve problems by deliberately looking for bad solutions, then figure out the opposite.

It is a good thing to get the audience involved when you do a talk. Callisto took us through a problem solving exercise where we began by trying to find the worst possible solution to a problem. As I am sure you have noticed, finding solutions that suck is pretty easy. Usually it is the first solution that comes to mind...

What most people miss is the next step Callisto took us through, that of finding the opposites of the solutions we just came up with. That is where the good solutions are. There are several ways to do this.

The method Callisto showed us is very useful both when solving problems alone and in groups. Business design thinking company XPlane uses a similar exercise they call Anti-Problem to get people unstuck during creative dry spells. Similar techniques are used in other problem solving methods, like the Thinking Process that I work with.

I like the simplicity of the method Callisto used, so I'll include it in my own repertoire of problem solving techniques. If you follow this blog, you know that I work a lot with The Logical Thinking Process, which is rather left-brainish. It is very useful to mix that with more right-brain oriented techniques. Keeps my brain from getting too lopsided. (My brain may already be irrevocably "loopsided" due to my preoccupation with iterative processes.)

The talk was a success. It was also fairly short. Afterwards I heard people speaking about how they wished it had been a bit longer. From a speaker perspective, I think that is great: Leave the audience hungry for more, and they will turn up again.

I had the opportunity to talk a bit with Callisto before her presentation, and it was very interesting. She is a dancer and an avowed right-brainer. I am a management consultant with a strong left-brain bias in how I think. She is interested in creativity in individuals. I am interested in building creative and innovative organizations.

In other words, Callisto's approach is a bit different from mine, and that made her talk all the more interesting. It got both halves of my brain going. As Callisto pointed out, it is important to deliberately break habits and seek new perspectives.

The audience was quite small, about ten people. That did not matter to us who were there to listen, but it does mean a lot of people missed out on an interesting and thought-provoking evening.

The talk was arranged by a business relation network, Framgångsrika Relationer (Successful Relations), and held at First Hotel G in central Gothenburg.

As for me, I intend to spend the rest of the day doing something creative.

Be seeing you!

30 presentations in 90 minutes: A visit to BNI Gamla Ullevi

I visited a BNI team, BNI Gamla Ullevi on Wednesday the 29th. I was invited by Per Johansson of the Skooter advertising agency. Gamla Ullevi (Old Ullevi - there is also a New Ullevi) is a sports arena in central Gothenburg.

BNI Gamla Ullevi has 27 members. The team meets for lunch every Wednesday. If you visit on a day when all members are there, you'll hear 27 one minute presentations and two six minute presentations from team members. In addition, guests, like me, get 30 seconds to present themselves and their company. I did not count the exact number, but I think I heard about 30 business presentations at the meeting.

This may sound like a lot, but BNI teams are very well organized. (Self-organized, I might add, in case you are interested in Agile software development or management.) Meetings take 90 minutes. It is a tight schedule, but I have never seen a BNI meeting that feels hurried. The trick is to keep everything flowing smoothly.

If you observe carefully, practice, and experiment a bit, a BNI team is not just a place to get business referrals, it is also a great place to hone your presentation skills.

There is more happening at a BNI meeting than business presentations. However, I'll focus on the presentations this time around. BNI Gamla Ullevi does have some good presenters.

Jakob Ståhle is a professional magician and entertainer.

All armies prefer high ground to low and sunny places to dark.

-The Art of War, Sun Tzu

Jakob Ståhle, a professional magician and entertainer, made his 60 seconds memorable. It looked like Jakob had taken Sun Tzu to heart. He literally gained the high ground by stepping up on a chair, showed a folder with pictures taken during performances, and read aloud from a very favorable review. High ground and sunny all the way through.

There are several key points worth noting: Jakob showed examples of his work, he provided independent verification saying that he is very good at it, he made the presentation memorable by being a bit different.

A key feature of 60 second presentations at BNI is searching. The presenter tells the team about a person he is interested in getting a business referral to, and why that person might be interested in talking to the presenter. Obviously, good searches require a bit of preparation. I won't go into that in this post. I'll save it for a post on the BNI World Trade Center web site instead. The BNI WTC site is under development, but it will be up and running in a week or two.

Fiorenzo Bertolozzi brought a massage chair and showed how it works.

BNI Lilla Ullevi, like my own BNI team, BNI World Trade Center, has two six minute presentations at each meeting. Fiorenzo Bertolozzi from Lilla Hälsobutiken put those minutes to good use. He had brought a prop: a massage chair. With a bit of help from a friend in the team, he demonstrated how it works, and talked about massage.

Fiorenzo did use presentation slides, but it was his very engaged presentation style and use of props that caught my attention.

I talked a bit with Fiorenzo afterwards, and he told me he had spent a lot of time rehearsing. This is an important point. Rehearsal is necessary. A good presenter must know the material well enough to make it seem effortless and natural to talk about it.

Jan Berndtsson from Trust Security did the other 6 minute presentation. Jan did not use slides at all, but it was an effective presentation. Jan talked about burglar alarms, and he focused on three features that are important to users.

The first was simplicity. As you may have experienced, switching alarms on or off can be a bit more complicated than necessary. Jan talked about how the procedure can be simplified, and how his company's product does just that.

The second key feature was reliability. The alarm can communicate over the mobile phone network if the phone lines are cut.

The third feature he talked about was fast response time. The main benefit of having an alarm is that it may deter burglars from breaking in in the first place, but if they do, fast response is of course important.

Note how the main points of Jan's presentation stuck in my, usually teflon-coated, memory? If Jan had used presentation slides with bullet lists describing every feature of every product and service his company provides, I would not have remembered a thing. By keeping it simple, focusing on one product and three features important to customers, Jan made his message stick.

Jakob, Fiorenzo and Jan used different styles of presentation, but they all got their messages across very effectively. All three kept the audience focused on what they were saying, they kept their messages simple, and they talked about things the audience can relate to.

This picture was taken at BNI WTC while I held the 60 second version of the presentation I held at BNI Gamla Ullevi. I did not use a prop at Gamla Ullevi though. 

As I mentioned, guests get 30 seconds to present themselves. What can you do in 30 seconds? My presentation went something like this:

Hello! My name is Henrik Mårtensson, I am a management consultant, writer, and presenter. For example, I talk about business, and how a train accident back in 1848 had consequences that contributed to companies crashing during the financial crisis of 2008. And, about how the worlds best fighter pilot, ever, had an idea that is important to how BNI does business today.

So, I picked a topic I know my audience and I have in common. All BNI members hold presentations. I created a bit of tension by describing the end points of a 160 year old chain of events, and nothing in between. I also related an interesting, highly romanticized topic, fighter pilots, with BNI. What is the simplest way to resolve the tension? To invite me to hold a talk.

Of course, when you claim there are links between things that are very separate in nature, or in time, like I do in my 60 and 30 second teaser presentations, you must be prepared to back it up with strong evidence in the main presentation. At the end of the main presentation, the tension must be resolved. Ideally, in such a way that the audience is still hungry for more.

I invited a couple of people to visit BNI World Trade Center. I am going to write more about that over at the BNI WTC web site as soon as it is officially up and running.

Passionate about presentations

From a presentation teaser I held this morning. Note the absence of presentation software. I showed an example of long term effects of cause-and-effect chains: A train crash in 1848 has had repercussions that made companies unnecessarily vulnerable to the financial crisis and recession in 2008. I show the complete cause and effect chain in the full talk.

I am going into the presentation business. (Just so you know: I am not leaving the management consultant business, just adding a related and much needed service.) I hold at least one presentation every week, and I hear at least 16-18 presentations per week, sometimes twice that.

Some of the presentations I see are very good, but many are not. The ability to make a good business presentation is important. I have seen companies with superior sales offers getting blown out of the competition because of poor presentations. I have seen strategy presentations which could not be understood by anyone, including the presenter.

In one survey, fear of presenting ranked higher than fear of dying. (Please don't hold me to the accuracy of this. I can't remember the source at the moment.) I do hope this is an exaggeration, but judging from reactions I see, it might not be.

And yet, Garr Reynolds, one of the worlds best presenters, hit it right on the nail when he said that most people can present. Everyone is interesting to someone. Think about it: You have friends. You may have a significant other. To get either, you must be able to present yourself, one way or another. It usually does not involve PowerPointless, but that is beside the, err, point.

You are the presenter. The presentation software is just the support. At least, it is supposed to be the support. Far too often, the presentation software is a big part of what is keeping you from presenting well.

I am running a bit short of time. Got to go and present myself, so, no presentation advice this time around, but there will be. See you soon!

Visiting the Gothenburg Book Fair with Erik Lundh

Erik Lundh at the Gothenburg Book Fair 2010.

 I visited the 2010 Gothenburg Book Fair last Sunday. It was partly because of the books. I really, really, like books.

Mostly, it was to meet Erik Lundh. Erik is a well known agile coach. When Erik told me he, his family, and a friend of his were coming to the fair, it tipped the scale in favor of a visit.

While Erik and I were talking, which we did a lot of, I mentioned a problem I had with finding a good hook for a presentation I am working on. Erik offered to help. I accepted, and he dug into my brains to see if there was usable story in there somewhere.

There was, though we had to do a lot of hands on sifting to find it. Afterwards I scooped up the wrangled remains of my brains from the table, put it back where it belongs and screwed the lid back on.

The funny thing is that once my writer's block, well, presenter's block, had been removed, several other ideas that had been fluttering about in my head, searching for a context to live in, suddenly found a home.

I think the presentation will work out very well. Too early to give you any details, but watch this blog for more.

Oh, yes, Erik asked me if I could autograph his copy of my business strategy book Tempo!, which I of course did. It was a close call, because it nearly brought back my writer's block. I felt very un-authorlike.  I even tried to weasel out by claiming my handwriting is so poor it would reduce the value of the book. As you can see, I finally did pull myself together and write.

I wonder if any other authors find it as difficult to write dedications and autographs as I do. The problem is that I want to do it just right. I want to hit the right feeling with just a sentence or very short paragraph, and that is difficult.

I think the autograph writing business went well in the end. I probably didn't devalue the book too much.

Stephen Kovacs on understanding the nature of Agile

I got a very thoughtful email from Stephen Kovacs on how to develop a deep understanding of Agile and Lean. I asked him if he would allow me to publish it. He did, so here it is:

This may just be throwing a half baked idea out. That said.... I was looking around on the net for some discussion of "lean", since people seemed to be talking about it as an alternative to Agile, and my sense of Lean was not an alternative. Perhaps a less structured version of Agile? (it seems to me Agile has become an umbrella under which Lean and others congregate).

I looked at a link to Wiki about Lean development, and from there to several links down into underlying theories (psychology, etc etc).. I keep coming up with the same thing: that Agile is an effort to pull together more humanistic theories of motivation and, perhaps, communication, into a working model.

And I keep coming to the same conclusion. The more effort put into creating the model (the rules?) , the more explicit the working model, the further away people seem to get from understanding and using the concepts.

This circles back to your description of systems. I wonder though if it also points to a weakness in a straight systems approach. Ie, is describing a system technically also another way to provide more detail about the model, where you lose understanding buried in the details?

For example. If you look at theories of motivation (intrinsic vs extrinsic)..... there a decent (I think) summary of those in wiki here http://en.wikipedia.org/wiki/Motivation . If as you read through these you start highlighting elements that seem obvious within Agile.... I think there's an aha moment in the effort. There's clearly a strong leaning (pun intended) towards a Maslow, even Rogers, approach. Maybe combined with some social interaction theory.

If you look at Measurements.... for example here http://en.wikipedia.org/wiki/Measurements and scroll down to Definitions and Theories.... the concept of story points etc., seem to be based, to a high degree, on "Representational Theory"... perhaps using representational theory to get to Information theory (??). Ie, accept the uncertainty of measurements, use ranges and relativity in what you're measuring, to evolve a more accurate measurement (estimate)

Imperfect, not fully refined, examples. But in my mind these are the things that Agile, Lean, etc all seem to scream out. But people dont seem to "get" that?

I dont see how people can implement Agile successfully until they understand that. Going through the motions of the detail will always run into problems. Perhaps will always fail ?? because no two projects, no two companies, no two teams of people, will be exactly the same. The variables in the differences will respond to the underlying theories, but not necessarily implementation "rules".

Ie how can so many people spend so much time talking about specific rules, or practice, without understanding those underlying theories. Or, at least at some point, going "aha, all this "stuff" we've been talking about all relates to these theories"..... then issues like arguing for months and years over "face to face" become true Waste (in the Lean terminology)... as an example.

I have to wonder if the weakness in applying Agile, in many instances, is the result of the mind set of the people trying to implement it. That is, the developer's, or the technicians, mind set ? If many of these discussions, even books about different methodologies, are 1) missing the point entirely because the people writing them have the same mind set or 2) trying to describe the concepts in a way that mind set hears it , rather than shifting that mind set so it can understand the concepts.

#2 is not ideally said but I'm thinking back to simplistic psychotherapy concepts like : dont just look at what the world does to you, look at how you cause the world to do things to you. Ie, change, or add, to your perspective.

So maybe looking at systems helps people suspend their specific mind set to see another perspective. hmm.... interesting, if I run with the ideas, I keep ending up with a conflict between what I think of as a technical, vs humanistic, approach to things. Hard science vs intuition. Pavlov vs Rogers/Maslow. Quant vs Chaos theory. (holding head)

I agree with Stephen. Focusing too much on the details of Agile, the practices, can easily make us loose sight of the purpose of those practices. We can also loose the connection with the underlying attitudes that are fundamental to Agile. This has happened before, with TQM, with Lean, with SPC, and many other methodologies. The practices get separated from their paradigm, and retrofitted into the old paradigm. It may work, after a fashion, but most of the benefits are lost.

What about you? Do you agree? If not, why? If you do, is there a way out? What can we do to educe an understanding of the Agile paradigm?

Re-Imagining Agile part 2: Designing from the outside in

A business that makes nothing but money is a poor business.

– Henry Ford

In the first part of the Re-Imagining Agile series I wrote about some of the ideas Agile is based on. The most basic one is a theory about human behavior and motivation, Theory Y.

I wrote that most business organizations are designed based on a different set of assumptions, Theory X. Moving to Agile therefore represents a paradigm shift, a change in how we think.

Fig 10: The paradigm shift.

Figure 10 illustrates the shift in paradigms. As you can see, the shift is much more extensive than switching from Theory X to Theory Y. You might wish to compare this figure with the reading map in Figure 1 (in Part 1 of this series).

While it is difficult to make the transition, it is quite possible. One organization that has made this shift is the U.S. Marine Corps. They did something really sneaky: They kept the name Command & Control, but they changed the definition of the word control!

...decentralized control works from the bottom up. Command is the exercise of authority and guidance, and control is felt as feedback about the effects of the action taken because thinking is required at all levels.

Tactics, MDCP 1-3 - The U.S. Marine Corps manual on Tactics

It is my belief that what has enabled the Marines to make the paradigm shift was that they had pretty strong Theory Y leanings even before.

For now, I am going to leave the question of how to make an organization, even a large organization, make the basic paradigm shift. Instead, I will focus on what we want to achieve. As Dee Hock, who created VISA, put it, we must imagine what ought to be!

Decisions - the Power of the OODA Loop

We began by defining the paradigm, the system of thought, we need to re-imagine Agile. What is the next layer? We know that we want to build a system based on Theory Y. We know we want to design from the perspective of the customer, but it is not quite that easy. A business organization must make some pretty complicated decisions, like who the customers are, and what particular needs the company should satisfy, the nature of their relationship with customers, how to organize to utilize their resources as well as possible...

Decisions, decisions! Everyone in a business organization must make a lot of decisions, every day. What if we could have a common framework for all decisions throughout the organization? What if the CEO, a software developer, an accountant, and sales person, everyone in the company, including the people who empty the waste baskets, all had a common framework for making decisions?

The purpose of such a framework would be to improve the quality of decisions throughout the organization. Thus, the framework must make it easy to make good decisions, and make them quickly.

As it turns out, there is such a framework. It was developed by U.S Air Force Colonel John Boyd. Originally it was used to describe the decision processes of fighter pilots, but it soon gained traction as a generic model for decision making. The model is called the OODA Loop, and it is at the core of John Boyd's strategy meta-framework, Maneuver Conflict.

Fig. 11: The OODA Loop - An effective decision model

Figure 11 reveals the OODA Loop in all its gory glory. When I first saw it I thought, "What the #%&@ is that?" so don't be taken aback if it looks a bit complex at first.

I will not go into details about how to use the OODA Loop, but I will mention that an important facet is the ability to change speed and direction very quickly. In other words, to be Agile!

Few companies have strategy cycles shorter than a year. Using the Strategic Navigation framework, a business implementation of Maneuver Conflict, strategic cycles for large companies can be as short as a week.

Just like Agile methodologies allow development teams to use short iterations and short delivery cycles, so can business strategists compress strategy cycles with Strategic Navigation.

Just to illustrate the advantages fast strategy cycles can bring:

One company that is very good at compressing their strategy cycles is Apple. First they launched the iPod, then they used the popularity of the iPod to launch iTunes. iTunes, with the addition of the AppStore, became major incentive for customers to buy the iPhone. iTunes and the AppStore, with the addition of the new Bookstore greatly enhance the attractiveness of the iPad. Concurrently, they use Mac computers to increase the value of iPod/iPhone/iPad/iTunes, and iPod/iPhone/iPad/iTunes to increase the value of Mac computers. For example, the video capabilities of iPhone 4 fits neatly with the iMovie program included with all Macs. Most of the competition is far behind, trying to copy the iPhone/iTunes combination, while Apple continuously shapes and reshapes the market.

Since we have a spiffy new paradigm at our disposal, let's use it. We switch from Maneuver Conflict, where we found the OODA Loop, to Queueing Theory, where we find Little's Law:

t = I/T

Where:

t is lead time
I is the number of items in a process
T is the rate at which items are completed

As you probably know, Little's Law is fundamental to Agile software development. It is a natural law, and if Little's Law didn't work, Agile wouldn't work either. (Suggested reading: Lean Software Development and Implementing Lean Software Development by Tom and Mary Poppendieck; Product Development Flow by Donald Reinertsen.)

When I became interested in Maneuver Conflict, and saw the OODA Loop , something went BANG!!! in my head, and the lights turned on.

I suddenly realized that Little's Law is vitally important to the OODA Loop too. The arrows in the OODA Loop diagram show how information flows when we make decisions. The Post-It notes on a kanban board also show how information flows. They are both governed by the same basic law, Little's Law!

We need to make good decisions fast. Little's Law gives us an idea about how to accomplish that: We can either reduce I, or increase T. How do we do that?

We can reduce I in top levels of an organization by making as many decisions as possible at lower levels of the organization. At the same time we engage more people in thinking, and thus increase T.

Quick switch to our Systems Thinking hat: When we decentralize decision-making we shorten information feedback loops, which shortens delay in the loops, which increases the effect and reliability of the feedback. If you look at Figure 4 in Part 1, you can see that we can improve two high impact leverage points, the information flow structure, and the system structure, in one fell swoop.

Looks like Maneuver Conflict, Queueing Theory, and Systems Thinking all lead to the same conclusion. Great!

Here is one implication: If the CEO of your company understands the OODA Loop, and you, a software developer, understand the OODA Loop, you know have a common frame of reference.

Because everyone in the organization can use the OODA Loop as a frame of reference for how they make decisions, everyone in the organization has a shared frame of reference for understanding each other.

Once again, when I write "the OODA Loop", I do not mean just the diagram. I mean the whole package that goes with it.

We now have a starting point for developing an organization designed to take full advantage not just of of Agile software development, but also of modern ideas about how to organize, modern economic ideas, modern ideas about product development...

Figure 9 (in Part 1) showed some of the implications of Theory Y:

• Workers must be encouraged to communicate vertically and laterally. (No organizational silos.)
• There is no need for elaborate hierarchies of control and authority
• Workers should have a say in decisions that affect them.
• Failures that result in learning should be rewarded. (No fear culture! For brevity's sake, I will not go into this point any further.)

We can use the OODA Loop, Little's Law, and the list above to begin designing an agile organization.

We need to design the organization so that it consists of small, autonomous units. That way, the organization can grow without overloading the OODA Loops of top management. At the same time, the organization can quickly reconfigure itself when it needs to do so.

We need to weigh economy of scale against economy of speed. When we are the slightest bit uncertain, we'll choose speed. Speed is very important when the environment changes quickly. And we want to do more than to be able to respond quickly, we want to actually shape the environment. That requires the ability to go fast, and to change speed and direction very quickly for the whole organization!

Judging from our sample companies in Figure 1, we want to keep the main organizational units no larger than 100-200 people. Beyond that, we will loose to much agility. Of course, this is a very general guideline. For example, if your company is an industrial company, you may need to have some very large main units, like a large factory. Still, the principle holds, and even within a large factory, we can strive to make value streams interfere with each other as little as possible. (This is what Lean does with takt time. When variability in demand is high, as in software development, it can be better to separate the value streams as much as possible.)

What would this look like? Well, there is no absolutely fixed structure. You can't have a fixed organization chart, because the structure keeps changing. (I am not joking. For example, Semco, one of the model organizations in Figure 1, does not have organization charts for precisely this reason.) But you can show the basic principle.

Fig 12: Simplified network structure

Figure 12 shows the principle. Keep two things in mind: The figure shows a snapshot in time, and it is highly simplified.

We are designing from the outside in, so let's begin at the point where the business organization has contact with the customer. I am going to assume that the organization builds custom software of some kind. The particulars are different for other kinds of organizations, but the principles of designing from the outside in and designing against demand, i.e. from the need of the customer, remain the same.

I am also going to push the principles of Theory Y, pull and self-organization to the max here. Remember, we are designing what ought to be, not trying to make minor improvements to what already is. Agile is not faster waterfall, so why limit ourselves when we are designing an organization ideal for taking advantage of Agile?

Teams are built around value streams

The modern industrial organization is a vast complex of interdependent relationships, up, down, across, and even "diagonally." In fact, the system is so complex that only collaborative team efforts can make the system work effectively. It is probable that one day we shall begin to draw organization charts as a series of linked groups rather than as a hierarchical structure of individual "reporting" relationships.

The Human Side of Enterprise by Douglas McGregor

Let's assume initial contact is between the customer and a sales-person. The sales-person would be trained in a sales method compatible with Agile software development, for example the Prime Process. The Prime Process has roots in Systems Thinking, and just as important, it is an explicitly ethical sales method with focus on delivering business value to the customer. (See Mastering the Complex Sale by Jeff Thull.)

If you are an Agilist, you and a Prime Process sales person do have a lot in common: shared goals, and shared assumptions about how to achieve them.

The sales person posts the status of negotiations with the customer. Skills needed for a sales team will also be publicly posted. This will most likely include people with design skill and technical skills. People interested in the job can sign up to work on the sales team.

Because people sign up, instead of having someone assign them, we reduce management work. We also eliminate the need for costly systems to track which people are available. Sales people must know whether people are available to do work, so the company will probably have a kanban-like system to ensure that sales people don't over-commit.

Signing up might be as easy as moving a kanban card representing you, the developer, from a resource pool area on a whiteboard, to a project team area on a different board. Put the boards in the cafeteria, and everyone will be able to track what everyone else is doing at all times.

If the sales team does not make the sale, everyone just moves their cards back to the pool. If a sale is made, the team continues to work with the customer. The sales person may remove himself from the team in order to continue selling, but some of the people will remain, which provides continuity for the customer, and for the team itself. If more diverse skills, or more manpower, is needed, a message about the open positions are posted on the board.

You might ask what happens if people don't want to sign up. That, I am afraid, is a Theory X question. Ask instead: Given that people want to work, and want to do good work, what could prevent them from signing up? If you come up with a real obstacle, fix it. If something is preventing you from fixing it, fix that first!

What if there isn't enough people, or anyone with the right skills, available within the company? Post the job openings to a computerized version of the board that is available to the entire business organization. The team can also contact other companies in the same organization directly, or through Power Groups. (A bit more about those later.)

Note that the team does not necessarily have to bring people from other parts of the organization in. If it is advantageous to do so, the team can temporarily move itself to another company for the duration of the project. Profit sharing schemes for handling this are pre-arranged, so no complicated negotiations between business units are necessary.

By this time you probably think I am off my rocker, but there are real organizations that exhibit precisely this kind of flexibility. A couple of examples:

A U.S. Marine Corps team can decide to move from one chain of command to another if it makes it easier for the team to accomplish its mission.

I am a member of Business Network International (BNI), a business referral network. BNI has about 125,000 members. I belong to a team named Gothia Towers. Today, I had lunch with two BNI members from a different team. They invited me to visit their BNI team next Friday, when they have their weekly business meeting. I accepted. In effect, we took a lateral contact, and even temporarily rearranged the team structures.

If you had suggested to the team members who invited me that they should check with the team management first, they would look at you as if you were a bit funny in the head. They would be right. Their team leaders would be justifiably annoyed if they did. (So I am very glad the thought never crossed your mind.)

If the right people cannot be found within the organization, the team can decide to hire people temporarily. They can do this because:

• They have an economic model to guide them (See Product Development Flow by Donald Reinertsen)
• They are not constrained by a pre-determined budget (See Beyond Budgeting by Jeremy hope and Robin Fraser)
• They are self-organizing

A team pulls resources if and when it needs them. If the team grows too large, it restructures itself into sub-teams.

Fig 13: Linked team structure and communications pathways

As figure 13 shows, each person with leadership responsibilities is a member of two teams. This is different from managers in a hierarchical organization having meetings together. The leaders in Figure 13 work together, ensure that the teams they lead collaborate effectively, and make trade-offs where necessary.

As I have already mentioned, anyone in a team is free to contact any other team without going through a vertical hierarchy. There is a strong emphasis on lateral communication.

A third thing that is different, and once again borrowed from the U.S. Marine Corps, is the idea of the Directed Telescope, or pull communications.

In a hierarchical structure, information is usually pushed upwards, through standardized reporting procedures. A network structure will have similar procedures for pushing information inwards. (Though the type of information, and the amount of information, is very different because the paradigm governing what is considered important information is different.)

There is another way to get information: Pulling it. That means someone at the center actively goes out and looks at the situation in order to understand it. This is sometimes known as Management-by-Walking-Around. Lean folks call it genchi genbutsu, “actual place, actual thing”, to go and observe in order to fully grasp a situation. ("Grokking", if you have read Robert Heinlein's Stranger In A Strange Land.)

One reason why pull communications are under-used in hierarchical organizations is that managers are already swamped by information pushed at them. In the network structure we are designing, we do not push nearly as much information to managers. We also present information in different ways, for example by using process behavior charts or TLTP diagrams. This makes it easier for centrally located managers to pull information when needed.

Note that the structure in Figure 13 allows both independent action and close collaboration. The same linked team structure is used throughout the entire organization.

Depending on what they do, some teams last only a short time, other teams may be very long-lived. For example, a team responsible for the grocery section in a supermarket would never disband, even though membership would change over time. (Remember, we are talking about a general structure for business organizations, not just a structure for software development teams.)

In some business organizations, like Semco and W.L. Gore & Associates, team leaders are elected by their teams. It might be a good idea to require elected leaders to take advanced training in the leadership skills mandated by the basic paradigm. Of course, everyone in the organization should have basic training, and plenty of opportunity to learn on their own if they so choose. It might look like Figure 14.

Fig 14: Mandatory training of elected leaders

Companies

For the purpose of the model, I have assumed that the organization is fairly large, and that the basic business unit is an independent company. A structure like this provides economic protection. If one company fails, other companies will be affected as little as possible.

It is also possible to have other companies absorb people from the failed companies, or use the freed manpower to start new businesses. This is a strategy that the Virgin Group has used successfully for many years. (See Business Stripped Bare, by Sir Richard Branson.)

A company is responsible for one or more value streams. Figure 15 shows the principle.

Fig 15: A company is a linked team structure with the responsibility for managing one or more value streams

I mentioned a size limit on companies. Keeping companies small keeps information loads under control. The exact size limit depends on what business the company is in.

When a company grows to its limit, part of it is split off to form a new company. The Virgin Group employs a strategy where the new company must find a market for itself that is different from the markets of all other companies in the network. That is why Virgin is so diversified: Music, hotels, spaceflight, soft drinks, etc. This prevents different companies in the network from competing with each other.

Traditional enterprises also divide themselves into companies, but they do it in a different manner. It is quite common for an enterprise to start a new company for the purpose of executing one step in a process. The result is a chain of tightly interdependent companies. If one company fails, so does the process, and the other companies in the chain can't get the revenue they need to survive. This makes all companies in the chain very vulnerable. To make it worse, the companies usually use Cost Accounting practices, which means they all strive to be as profitable as possible, which means they have to fight each other.

It is very important to avoid this trap, and set companies up so that they really are built around end-to-end value streams.

Power Groups

As I showed in the section about teams, it is quite likely that these companies have opportunities to collaborate now and then.

Sometimes team level collaboration is not enough. For example, companies might share information on a continuous basis, or work together to execute major operations.

When a company believes it can benefit from formal collaboration with one or more other companies, it can attach itself to a Power Group. Power Groups share information, and may help each other in other ways, as they see fit. Note that a company decides for itself which power group, or groups, it wishes to apply to. The power group then decides whether to accept the application. A power group may of course elect to invite a company.

The Core

There is no "up" in a network organization of this type, and thus no "top management". However, at the center, there is a core, and a core team. The core team is responsible for the system as a whole. Following the same structural pattern as before, most members of the core team will also be leaders of companies, service units, or power groups.

The core team ensures that the organization moves towards the overall system goal. Depending on the organization, they may be the people setting the systemic goal, or not. For example, at the Virgin Group, this is the people ensuring that the brand values are adhered to throughout the organization. Using Maneuver Conflict terminology, they are responsible for the organization's Noble Vision.

The Noble Vision is an idea that unites not only the people within the organization, but also the organization and its customers. Think about Apple brand loyalty, a football team and its fans, and you'll get the basic idea. There is also a moral dimension to the Noble Vision concept, but I will not go into detail here. Suffice to say that the Noble Vision must be something that you and your team mates believe is worth striving for.

One very important service that should be handled by the core in most organizations is basic management training. Every leader in the organization, whether a Scrum Master or the CEO, must have the same basic training. Look at the Orientation step in Figure 11. There must be a shared base here, or it will be impossible to develop the trust and understanding necessary for decentralized command.

A related service that might benefit from centralization is management consulting. For example, the Virgin Group has an internal management consultant organization for the purpose of helping to solve thorny management problems.

A basic rule is to centralize services that benefit from economy of scale, and decentralize services that benefit from economy of speed.

IOHAI

I have mentioned the need for leadership training a couple of times in this article series. When John Boyd developed Maneuver Conflict and the idea of a Noble Vision, he also conceived a leadership model, IOHAI. The IOHAI model is a framework for training leaders that can help move an organization towards a Noble Vision.

Boyd considered IOHAI to be the key to enabling vitality and growth. It is certainly not the only management or leadership framework that can be used, but it is a very useful one. It incorporates ideas of paradigm transcendence and continuous learning.

Fig 16: IOHAI - Theme for vitality and growth

I wrote my book Tempo! so that it can be used as an IOHAI training manual for leaders at all levels in a business organization. Once again, I will not go into details here, but when you dig down into IOHAI, it becomes very practical and action oriented.

Design notes and useful Intermediate Objective Maps

We can summarize our design goal for the organization, and the necessary conditions that must be satisfied in order to achieve the goal. Figure 17 shows what that might look like.

Fig 17: A generic organizational IO Map

Though I did not write about it, I used Self-Determination Theory (SDT) as a guide when developing the organizational structure. Figure 18 shows how, according to SDT, intrinsic motivation can be stimulated.

Fig 18: Self-Determination Theory - The building blocks of intrinsic motivation

As it turns out, most processes have a lot in common. We don't need a template specifically for how to construct software development methodologies. We can construct a generic template for process design, and use that to design every process in the organization. Figure 19 shows what such a template might look like.

Fig 19: An IO Map for process development

Using the same basic ideas for designing all processes is very important. If you have a mismatch in design philosophy, the processes will not match each other very well, which will lead to a lot of waste of effort and time, and reduce the quality of the end result.

Agile principles re-imagined

This article series was inspired about a discussion in a LinkedIn forum about Agile principles. Given what has been done so far, what about the current Agile principles? Will they stand as is, or can they be improved upon? Yes, I believe they can. (As you may recall from part 1, I answered the question "should they be changed?" with "No!". But I answered "can they be changed?" with "Yes!")

Let's begin by defining the word "principle". It was clear from the LinkedIn forum that the word means different things to different people. I will go with the definition in my dictionary:

principle - a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning

There are 12 Agile principles, which I think is a bit much. The principles themselves are not simple. In addition to being too many, several are unnecessarily wordy.

Ironically, principle 10 is:

Simplicity--the art of maximizing the amount of work not done--is essential.

Some of the principles are best described as opinion, plausible on the surface, but unsubstantiated:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The above sparked a lot of conversation in the LinkedIn thread. It is clear that it leaves many considerations out of the picture, and that face-to-face conversation is not always the best alternative. For example, if the information conveyed is very complex, it may be necessary to write it down in addition to talking about it. In many situations, face-to-face conversation is not possible.

Finally, some things are just wrong:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Why not reflect and fix immediately when a problem crops up? I am for regular introspections, but I believe it should complement immediate stop-and-fix, not replace it. Lean companies have andon and kaizen, not one or the other.

Here is my attempt at Re-imagining the Agile principles:

• Study and apply the paradigm!
• Be curious!
• Be tenacious!
• Design from the outside in!
• Design from demand!

As you can see, a bit different from the original list. Still a bit long for my taste. The last two could, and perhaps should, be subsumed into the first. On the other hand, they are pretty important in their own right.

The re-imagined principles have important implications for methodology development. Here is a small collection of things that might become different if Agile was re-imagined using the principles above:

• More focus on building the right thing. Most Agile methods today, with the notable exception of Crystal, are primarily focused on building things the right way. User interaction design would become more important with this the re-imagined version of the principles. Systems Thinking would play an important role in designing solutions for customers.
• Studying and training would become more important. In some organizations it would become a regular part of the working life.
• Systems Thinking would be applied to software methodology design to a higher degree than it is right now.
• The idea that there are practices who are "best practices" regardless of context would be abandoned.
• Studying, measuring, and experimenting with work methods would become more common.
• Team structure and composition would change. We would probably move towards "solution development teams" rather than "software development teams".
• It is likely that software frameworks would become less popular, and reusable software modules and libraries would gain in popularity. If this trend is strong, it might affect which programming languages that are used.
• Widespread education in Systems Thinking might lead to an increased interest in functional programming languages.
• Many network organizations would have Intranet-based social networks. This would increase lateral interactions in the organizations.
• Some organizations would have software library repositories similar to CPAN and RubyForge. Though probably for other languages...
• Some organizations might go for Wikipedia style knowledge repositories. These would contain information about everything of interest to the business organization.

Or, something entirely different might happen...

Whether you agree with the ideas I have presented here or not, by reading this far, you have certainly exhibited a great deal of curiosity and tenacity.

Thank you!