Why is the C-Suite Clueless?

How many middle managers and agile coaches have asked themselves this question: Why is the C-Suite clueless? We try so hard to get their attention, but they just won't listen.  I think I am connecting the dots on why they don't listen.

Overwork is surely part of the problem, but it's deeper than that. Management has always been accustomed to communication by broadcast; listening and reacting have not been its strong suit. Before globalization, that wasn't much of a problem, because the customer didn't have many alternatives. But today, customers can easily go elsewhere, the complexity has risen, and the job of management has gotten much harder.

Today, I believe Management is in denial. It is in denial because it is being told by the marketplace: "you suck." Management focuses on improving the quarterly results, lowering the cost, and with it the quality to the point where lemonade doesn't have any lemon juice in it. And then they wonder why people chose to buy elsewhere.

Denial is a grief response, a normal response to bad news that you cannot change. You don't like the message, so you try to ignore it, until the message is so strong, like a lost lawsuit or impending doom, that it cannot be ignored.

Today, management needs to get out of denial and get on with fixing what's broken. An interesting case came to light at the Scrum Gathering in Atlanta: Domino's Pizza.

Domino's Pizza was (and is again) a successful fast food chain. They became famous for delivering you a pizza within 30 minutes. 10 years after being sold to a holding company, they had fallen to last place in customer approval ratings and were threatened with extinction. Their crust "tasted like cardboard" and the sauce "like ketchup." Their share price hit a low of $3/share. Whether management noticed what their pizza tasted like is unclear, but they did notice their share price: they had come to the brink of disaster and realized that they had change. So step 1 was to admit that "we suck" and step two was to do something about it (watch this 4 minute video to see this in action):

What did they do? They created a clear line of sight from all levels of the the organization to the customer. They reacted by listening to their customers and creating products that were dramatically better than before. They admitted their mistakes in public and promised to get better. They did it quickly.

They were successful. I stopped by Domino's at ATL Atlanta Airport and found the pizza to be quite OK. (OK, it's still fast food. The Pizza DOC at Molino Frascati in Zurich is still among the greatest pizza I've ever had, followed closely by the pizza at Northlake Tavern in Seattle's U-District, but that's like comparing F1 racers to anything off the production line.) In any case, their stock price has also more than recovered, having just set a 7 year high around $40.

So if your organization is having problems, how can you fix it?

1. Admit that you suck. Once you've admitted it, you can move on and start getting better. 
2. Recognize that you and everyone in your organization is doing a good job. The best they can, under the circumstances. This isn't about blame, it's about getting better.
3. Do something about it! Start right away.

What should you do for step 3? That depends! Here are some places to start:

1. Within your management team figure out what your priorities are and what they should be. Radical Management can help here. So can a Temenos Retreat.
2. Understand what your customers are telling you: Create a clear line of sight to your customers at all levels of the organization.
3. Start implementing improvement immediately. Figure out what your biggest impediments are to customer satisfaction and start fixing them. Scrum can help here, even if you are not doing IT.

Many years ago, Ken Schwaber, the co-inventor of Scrum, became famous for telling people, especially top management, 'You suck, and that makes me sad.' It's a challenge to get better. It's a challenge, but you can do it if you want to.

Joe Justice, CEO of WIKISPEED to participate in next monthly mash-up

Joe Justice, CEO of WIKISPEED will participate in Steve and Peter's next monthly mashup.

Both Steve and I have written about Wikispeed (The Car the Scrum Built, Wikispeed: How A 100 mpg Car Was Developed In 3 Months). I think Wikispeed is the harbinger of dramatic changes in how we do business!

You can sign up here! And be sure to include your questions for Joe, Steve or myself when you sign up! We look forward to talking to you!

Does Your Agile Transition Provoke a Grief Response?

Radical Management principle number 4 says that communication must change from top-down directives to adult-to-adult discussions. Why is this so important? And how can you tell if your agile transition is really transitioning "agile-ly"?

Glen Alleman, author of the Herding Cats blog, recommended that I look at Peter de Jäger's webinar on The Art of Communicating Change. Given Alleman's critical perspective on Agile and Stoos,  I wondered, could there be something about Management in general and Change Management in particular that I've missed?

De Jäger starts by explaining that people react to change differently depending on whether change is voluntary or involuntary. Examples of voluntary change include deciding to learn a skill, getting married, or accepting a new job. People change like this all the time. Although it takes time to learn the skill or adjust to being married, most people do it willingly.

An involuntary change is a completely different matter. This change comes from outside: examples include getting laid off, being diagnosed with cancer, having people pulled off your project or the deadline being moved up; somehow they all feel like death. Involuntary changes provoke a grief response. This response can, in turn, provoke severe resistance to the idea or change under discussion.

According to Kübler-Ross, a grieving person goes through 5 steps on the road of acceptance:

1. Denial
2. Anger
3. Negotiation
4. Depression
5. Acceptance

de Jäger proposes 7 questions to help organizations get through these 5 stages. What he does not do is challenge the notion that top-down communication is the best/only way to effect change. Top-down communication causes the grief responses, because people are hit with changes without being consulted.

Is your Agile transition provoking grief responses? Look for signs of denial, anger, depression or passive resistance. Are participants trying to negotiate away key pieces of your agile framework? This is a sign that your roll-out is too top-down. You need to get people on board. You need to get more buy-in.

The AIDAA Approach

de Jäger does hint at a better approach during the Q and A session (around 47:20 into the Webinar). The best change agents give people the problem and let them come up with the solution. What does this sound like? It sounds like Scrum. The product owner comes to his team with a problem and the team solves the problem.

The big difference between this approach and a command-and-control approach is, when and how is the change discussed? Top-down means, management communicates a decision and people have to deal with it. Adult-to-adult means, you discuss a problem together to find an optimal solution.

In the last year, I have coached three separate agile transitions. In each case, we followed a pattern of building awareness and interest (and hopefully desire). In each case the transition moved forward without the passive resistance so typical of Agile transitions is large companies. Why?

The decision on whether to move forward was pushed one level down from the person asking me to introduce Scrum. In two cases they said yes, in one case they said no.  In that case, the middle management team proposed a way forward that they believed in, so this too has been a successful transition to a happier, more productive constellation.

Applied to change leadership, I call it the AIDAA approach. AIDA is a term from marketing: Awareness - Interest - Desire - Action. A purchase decision requires a step-by-step build up. Action (purchase) is the final step when buying a product. When implementing a new process, Ability is also required, so I add an extra "A": AIDAA.

By delaying the decision until after everyone understands answers to Why, What-does-it-mean-for-me, and 6 other questions that de Jäger raises, you transform the change from an involuntary change to an voluntary change. So you do not provoke a grief reaction (or just very small one). This completely changes the dynamics of the situation and increases your chances of a successful transition.


Want to talk about this some more? Join Steve Denning and myself at our next free monthly mashup webinar, e.g. Steve and Peter's Monthly Mashup, May 17.

Three Simple Hacks to Improve Management

Why doesn't the C-Suite understand Agile? Agile improves performance, profitability and customer delight. Why don't they get it? Why won't they even take the time to look at it? This dilemma has puzzled Agilists for as long as there has been Agile. Software developers have long been confronted with a similar problem. Here is a look a their solution and three simple hacks which may help managers improve their performance and their company's competitiveness.

I think there is a simple explanation for this: Top managers simply don't have time to think deeply -- about Agile, or anything else. They are overwhelmed, overworked and under extreme pressure to perform. They have no time or energy for creative thought. And since they have to deliver results every quarter, they can't risk doing anything new. If they were software developers, they would be doing death march releases every three months.

To understand the problem, let's look at the act of getting a meeting to discuss Agile with a top manager. You're the Agile coach; how does it go?

1. Schedule the meeting

You (with the brilliant new idea): I'd like a meeting with you to discuss an awesome new approach to software development.
Manager: How does that affect me? I'm responsible for finances, not software. Besides, I'm totally booked! No time.
You: I understand, but this is really important. It's about the future of our company.
Manager: Well, in that case, I can squeeze you in for an hour on Friday.
You: Thanks!

2. At the meeting

Your Manager has invited six additional people, mostly his direct reports, to the meeting.  They all come and you all wait for him to arrive - about 10 minutes late. In the meantime, the other six people have all opened their laptops, and now are working on their emails and things. Of course they stop when the top manager arrives, but as soon as the meeting begins, their attention is divided between what is being discussed and what is happening on their computers.

The first thing the top managers says is, "I have to focus on our financial results for this quarter, so cut the chase. What do I absolutely have to know?' Now you are flabbergasted and not quite sure what to say, but your try to deliver your points faster to the assembled notebook-readers. Five minutes before the end of the meeting, the manager has to leave for the next meeting...

Everywhere the same pattern!

Sound familiar? Of course it does. We've all been there. This could be a Dilbert cartoon. But it is daily life. Of those 7 people, five of them should not have come. All these people are seriously overloaded. They are taking on more work than they can accomplish, and trying to multitask as a means of working harder. So they are not doing anything well.

We've hit the limits on our ability to work harder. Management multitasking is evil. It kills performance. It kills the ability to innovate. And this eventually kills even the biggest companies.

I've been in the computer business long enough to remember working on the first timesharing minicomputers and mainframes. Back in those days, multi-tasking seemed like a great invention. The machine had lots more capacity than needed (or so we thought), so it could share that capacity among many users. Great in theory, but the users needed far more, which slowed performance dramatically down to a crawl. The same thing is happening in every large organization that I have come in contact with.

We have to do less.

Today, multitasking is used on lightly loaded notebooks, PCs and tablets to give their single user great performance: Dazzling graphics, snappy interfaces, sound and video are all possible because the devices can now do far more than is required of them. Does this sound like Apple? Apple works this way. What would it be like if your company gave your customers great performance?

Unfortunately, we cannot upgrade our brains with a faster processor. Would be nice, but I don't think I'd do it even if some doctor offered it to me. So we have to do less and make that which we do count more.

So the alternative is to get rid of all the bloatware that is occupying your brains and focus on what really matters!

We need slack.

If you are working towards a new product release, how far before the deadline are you willing to try out something new? My experience is that 3 months is a pretty typical answer. If there are more than three months left, people are willing to try things out. Less than three months, people want to focus on the release. How is management like delivering products?

We need to get better at delivering results to Wall Street.

If a software team is not doing well with a monthly iteration, what should you do? Shorten the iteration. Ron Jeffries popularized this approach and any agile coach will tell you it's true.

Management of public companies have to publish financial results every three months. They are always three months away from a release, so they are always under pressure to perform. Always frozen by the release which is three months in the future. What should management do?

How to get better management?

Here are three simple hacks to improve management:

1. Meeting-free afternoons. Give yourself some slack. Just block the afternoons, leaving you available for short term issues and deep thinking.
2. No notebooks at meetings. If the agenda isn't worth 100% of your attention, then you shouldn't go.
3. Publish financial results monthly instead of quarterly. By doing it more often, a) You get better at it, so it becomes easier to do. b) You increase transparency, which increases trust between you and your investors. c) The consequences of a bad month are smaller than a bad quarter, so you decrease the need to manage the expectations, and your own stress level will be lower and more constant, giving your mind more freedom to consider new things.

OK, this last one seems counter-intuitive and might not qualify as a simple hack. Simple means, it does not require legislative approval, because three monthly reports can easily be consolidated into a quarterly report.

However it is very consistent with the experience of software teams - they are better able to manage the stress of releases when they release more often. They are also better able to improve their quality when they release more often. They have a more trusting relationship with their stakeholders. They have better releases.

As a manager, improvement starts with you. What would it be like if you could get your level of stress under control, so you could really focus on making your company a better place?

My Experience Building Deep Trust

How would a company function if its top leadership trusted each other deeply and truly shared a common vision for the future? This question burns in my mind as I ponder the impact of the retreat I attended last weekend.

I met Siraj while making contact with the Washington DC Agile/Scrum scene. I had offered to help him make high quality photographs of his collection of "influence maps." Having just moved to the DC area, and having time on my hands, I thought that some small acts of service would be a good way to get to know and integrate into the Agile community here.

An influence map is both a discovery tool and an information radiator for reflecting on and telling the story of your life. It was fascinating what I could learn about people I had never met just by looking at their maps.

There was always something mysterious about Siraj. As his name suggests, he is of Indian origin, but he grew up in Middle East and studied in a Jesuit school. His life has always been driven by the questions, 'Why am I here?' and 'Whats next for us?' So when he invited me to attend a weekend retreat on change leadership based on these influence maps, I was intrigued and just had to come.

His model for influencing change is called The Influencers Mantra, and the monthly retreat to learn this model is called Temenos, which is the Greek word for "container." Just as you can't control your heartbeat, you can't control the container. But you can influence your heartbeat (and many other reactions) by controlling your breathing. Temenos is about how to influence containers of people like a marriage, a partnership, or a company.

A Temenos has a simple format:

• Warm-up on Friday evening - a fancy word for dinner (and maybe some wine) and otherwise getting to know each other. 
• Saturday and Sunday were the formally defined parts of the workshop, 
• Cool-down Sunday night - another fancy word for dinner (and maybe some wine) and enjoying the afterglow of an intense weekend together
• Monday morning departure 

Siraj's model of influencing change is based on simple premises:

1. Any group of people, like a company, a partnership, a team or a marriage is a container.
2. A container is not a soldier to be commanded, it is a woman to be wooed. It is also a raging fire which will will burn you if you take the wrong approach. Having been burned several times and having wooed an organization once or twice, I recognize the truth of this statement!
3. Listening and Observing are the keys to influencing the container.

So most of the time in the workshop is spent listening and observing: 1) Understand yourself and each other by creating and sharing influence maps. 2) Create a clean slate to start afresh. 3) Understand your and each others' Personal Vision. 4) Working as a group, create a compelling shared vision for moving forward. 5) Supplication.

Influence maps and Mandalas are both visual representations (or information radiators, as Agilists would call them). The Influence map represents your life to date, and the Mandala represents either your personal vision or the shared vision of your container.

The workshop follows this approach:

• Check-in
• Introduction to The Influencers Mantra + Temenos
• Influence Maps - draw and share the story of your life 
• Clean Slate - recognize and forgive the failures of the system and your own failures to the system
• Personal Vision - draw a Mandala and share your vision for moving forward at a personal level. 
• Compelling Shared Vision - create a Mandala for the container / organization / group
• Supplication 
• Theory - Personalities of Influencers or Archetypes and Forces of the container or patterns in the change process
• Check-out

By the end of the Personal Vision exercise, we understood ourselves and each other so well, that we could talk to each other about anything, without fear or insult! I call this state Deep Trust. It's amazing. It is the perfect state for creating a compelling shared vision for the future.

Supplication was perhaps the hardest to grasp. "Supplication" is the process of bowing down in prayer. It represents a humble attitude towards the organization. I use the analogy of wooing a woman. I remember the night I met my future mother-in-law. There were only two chairs in the room, one for her and one for my future wife, so I literally sat at their feet! It seemed a bit a odd at the time, but it helped create a lasting, positive impression. In the successful change initiatives that I have coached, I have taken a similar approach, offering information, while encouraging those doing the change to figure out the best direction without telling them what the answer should be.

I came home exhausted, but full of energy and enthusiasm for this approach (and for my own future vision). I started making changes right away in my life and in how I deal with people; these were also noticed immediately. The approach seems to resonate. Everybody I talk to about it seems to get really excited: Connecting with your friends, colleagues, co-workers and even family members seems to be a deep need for many people. And I still ponder the question, what would your company be like if your top leadership deeply trusted each other and truly shared a common vision for the future?

Agile is the Vanguard of the Transformation of Management

Recently I wrote on ScrumDevelopment:

Agile is the vanguard of a general change in management, beyond "just" software. At the moment, it is seldom on the radar screens of today's MBA trained managers.

Two responses arrived almost simultaneously:

"No. People like Deming, Goldratt, Ohno, (and several others...) are the vanguards of general change in management (to the extent that there is yet much of a change)" - Kurt Häusler

"Well said Peter!" - Srinivas Chillara

I really do believe Agile is the vanguard in the transformation of management.

There are two levels to Agile - one is about engineering practices, the other is about values. Let's leave the engineering practices aside for a moment. In this context I am referring to Agile as a management framework.

What management principles does Agile implement? Servant leadership, delegation, intrinsic motivation, high trust cultures, PDCA, and much more. These are all things that one routinely encounters in an Agile project and exactly what the management gurus have been saying we should do. It is not that Agile invented these things, but Agile is where these things are being systematically applied, where there is a large body of knowledge on how to do it, and where there is a lot of experience on what happens when you do it.

Agile represents the one of the few communities where these principles are systematically applied. Take Scrum, for example: Product Owners and Scrum Masters are servant leaders. Sprint Planning operates at level 6 (of 7) on Jurgen Appelo's authority scale. The framework implements PDCA in two to four week cyles.

What other framework could qualify? Maybe Lean. Kanban I think has a strong claim. It leads you away from command-and-control, even though it can co-exist with it. But many people consider Kanban to be as much an agile framework as a lean one. Is there any other framework which can a) make this claim, and b) is widely applied?

All these modern management ideas are being implemented right under the noses of and often in the face of apathy or active resistance from classically trained managers. Steve Denning documented this thoroughly in his recent post. If you read a college textbook on management, you don't learn about Agile, or Scrum, or Kanban. Maybe a little bit about Lean. This has to change.

So yes Agile is on the vanguard. Not by talking or teaching at prestigious business schools, but by actually doing all the things management gurus have been saying managers should do for the last 50 years. Rod Collins, former CEO of Blue Cross Federal Employees Division and author of Leadership in a Wiki World believes the next generation of top managers will come from the agile ranks, simply because these are the people who 'get it':

• Agile, Lean, Scrum, Kanban - all are examples effective approaches to organization in a complex, networked world. None of them are compatible with the hierarchical, command-and-control management approach that was perfected by General Motors in the 20's. More fundamentally, thinking is not compatible with following orders.
  
• Beyond Budgeting - rethinking finances as the guiding instrument of corporate planning and control. BTW Professor Franz Röösli, Chair of the BB Roundtable, was an initiator of the Stoos Gathering.
  
• Radical Management - a rethinking of management based on agile principles. Strongly influenced by Scrum, The Ultimate Question (delighting the customer as the ultimate goal of an organization), and the Innovators Dilemma (why established companies often fail to respond to disruptive innovations). RM adds storytelling as a change leadership tool (which, when I started employing it, has done wonders for the acceptance of Scrum in the agile transitions I have coached).
• Stoos - a movement to catalyze a widespread change in management by building a common identity and networking between compatible approaches. People who identify themselves with Agile, Scrum, Kanban, Radical Management, Beyond Budgeting and others were all present at the first Stoos gathering.
  

Where do we go from here? A number of Stoos events are planned, most notably the Stoos Stampede and the StoosXchange. A number of Stoos Satellites have formed around the world to build local communities. Having said this, most of the resonance is coming from the Agile community. Franz Röösli and I will attend Gary Hamel's MIX Mashup. Our immediate goal is to get Agile on management's radar screen.

If you're not already a member, I'd encourage you to join the Stoos network. Summon the future! Catalyze a change for the better.

[Update 20.Apr/11:44 EDT]: I expanded the section on agile principles to give some examples of what management principles Agile implement. Also invited people to suggest other frameworks which might qualify. ]

[Update 20.Apr/12:10 EDT]: ...and I updated the section again to be more inclusive of Lean and especially Kanban. Stoos is about what compatible frameworks have in common, not about the rivalries between them. ]

Surviving Disruptive Innovation

Steve Denning recently wrote that disruptive innovation is a disease which has destroyed company after company. A number of comments challenged his use of the word "disease." What is a disruptive innovation? Is it a disease, are you getting it, and what can you do about it?

The term disruptive innovation was coined by Clayton Christensen in his book 'The Innovator's Dilemma.' A disruptive innovation occurs when a new technology is developed that is lower cost and qualitatively inferior to existing approaches -- measured along the criteria of the existing market -- but offers other unique advantages to a new market. The new technology innovates faster than the established technology and eventually replaces the old technology at a lower cost, destroying the established players.

So calling the problem a "disease" is pretty close to the mark. The disease is not disruptive innovation per se, but the inability of established companies to react to it properly. Perhaps calling the "Disruptive Innovation Syndrome" would be a better word.

I have been in the IT business long enough to remember:

• Minicomputers displacing mainframes to the stratosphere
• Unix Workstations displacing minicomputers and forcing them out of existence
• Intel PCs doing the same to UNIX workstations
• Linux/Intel Servers doing the same to UNIX servers

and the list goes on. Today were can observe

• SSDs are starting to displace hard disk drives
• Tablets are displacing netbooks

For an established player, there are many challenges to adopting a disruptive technology:

1. Innovative ideas originate at the lowest levels of the organization. Without an innovation culture, these ideas do not filter up to the top-level decision makers.
2. New, low-cost technologies do not have an obvious market. Getting a go from top management to invest is difficult due to the risk and uncertainty of a small, new market.
3. The new technology is unlikely to contribute significantly to the bottom line or growth of a large organization in the first years after introduction.
4. Investment decisions are not made just once at the top, but on a daily basis by middle management over the life of the project. It's called 'allocating resources' and established customers with well known needs are a lower risk than uncertain new markets. So products for established customers get the best resources.
5. The company's marketing "value network", i.e. its sales channels, marketing approach, and cost-structure are oriented toward existing customers. A company often literally does not know how to identify new customers or how to sell to new markets. Because margins and volumes are low, it is not financially interesting to do so.

So most companies simply choose not enter disruptive markets. The task is too daunting! And in the few cases that they do, it is very difficult road and most attempts are not successful.

What does it take to combat this syndrome?

Christensen argues that the technology itself is not the problem. It's the value network around the company which traps the company into its business model. The most successful approach he has observed is creating new business units which are independent of the existing business units and proportional in size to the target markets. IBM took this approach launching their PC business -- and went on to lose the market when it brought the PC division back into the fold, building closed, IBM-only devices which were slower and more expensive than their competition.

Apple takes a variation of this approach due to the extreme secrecy within the organization. Apple behaves like multiple start-ups which are in many ways unaware of each other, preventing much politics between the departments.

Steve Denning argues that companies need to have much more room for innovation. They need to adopt a culture of continuous innovation. The focus on the bottom line is counterproductive in the face of disruptive innovation.

What should you do? I don't believe these approaches are mutually exclusive. If you emphasize creating happy customers over the bottom line, then you know there are times to develop new customers and that a short term drop in profitability is a small price to pay for the long term survival and growth of the the company.

You need to create space to explore disruptive technologies. You need to recognize that much learning is involved and some attempts may fail. You need to identify new markets and new marketing approaches. You need to accept that the new approach will initially have lower volumes and probably always will have lower margins than your mature, existing products.

Once you decide that one product is a potential winner, you need to ensure focus. This means shielding the people and budgets from the pressures of your mature high-volume products. If you say 'A', and expect to get to 'Z', then you need to say, B, C, D, etc. until you get to Z. So if you are going to develop a disruptive product, you need to have top people working on it and you may not pull them off the new product development to support your cash cow.

Does the new venture have to be a separate business unit? A priori no, but there is a lot of practical experience which suggests this is a good idea.