1. The ecosystem and the power of connections
2. A culture of the hivemind towards greater collaboration
3. Dynamic, not static, communication, and
4. Clear signals in your content

1. Innovation
2. Improved collaborative processes
3. Adaptable business process and of course
4. Customer growth, retention and sustainability.

Most people associate improv with acting or comedy. But, you don’t have to be an actor or a comedian to apply improvisation to your work. In fact, I think there is more opportunity for improvisation in the professional world than most people think. Gary LaBranche of the Association Forum of Chicagoland says:

“Board meetings and committee meetings, dialogue with colleagues and other everyday situations give professionals plenty of opportunities for improvisational responses. Improv is all about adapting to constant change and unexpected situations, which is familiar territory for most professionals.”

I think Gary’s statement is right on the money. We have more opportunities to use improv as professionals than we realize. In fact, a few weeks ago, I wrote about Pixar and their use of improv in their creative process. Pixar boils down their use of improv to two essential principles:

1. Accept every offer. You don’t know where that offer is going to go. But one thing is for sure: If you don’t accept that offer, it’s going nowhere! So you have a sure thing on one hand: a dead end. And you have possibility on the other.

2. Make you partner look good. That means that everybody on your team is going to try to make you look good and vice versa. It’s about saying “Here’s where I’m starting. What can I do with this?”.

I think Pixar was able to break down their use of Improv into these two principles because of their long, shared experience with improv. I like these two essentials principles of improvisation for innovation, but wanted to expand on a few other principles for teams and organizations that are just starting to experiment or have never used improv before. So, to add to Pixar’s principles, I would advise those new at improv think about these as well:

1. Keep questioning what works. Good is the enemy of great. When something is really awful, we know we need to fix it, and we usually do. But when something is good, we settle. We don’t necessarily think about how we can make it better. So, take a look at what you do everyday. Consider the things that are good and ask yourself or your team “Can this be better?”

2. Be a risk taker and take chances. Sure, you can do things the way you’ve always done it. And you’ll probably get predictable results and that might be good enough for you. But if you want to be innovative, you need to break through barriers, take risks, take chances. You may not always be successful when you take chances, but if you don’t, you won’t ever have the chance to really innovate. The most innovative companies and creative people have failed more than they have succeeded. But, when they did succeed, it’s been with market-changing and world-changing innovations.

3. Always be changed by what is said and what happens. Innovative people and innovative teams always uncover new information. But more than uncovering new information, they learn to react to that new information. Instead of locking up when change comes along, these innovative people let that change inspire new ideas and let what unfolds next guide them on. They welcome and thrive on change. And they allow themselves to be changed. They have the beginner’s mind and are always able to learn and change.

4. Create shared, dynamic plans and agendas. The best laid plans of mice and men often go awry right? We’ve all heard that a thousand times before. So, why stick to a plan that is going awry? The answer…DON’T. Abandon them to serve the reality of what is right there in front of you. That’s right, ABANDON them. Let your plans and agendas emerge in real-time in response to what’s right there in front of you.

5. Be fully present and engaged. So, you get your team to abandon static, concrete plans. You’ve gotten out of planning and into being. But, this comes with a caveat. To do this, your team has to be completely engaged and have their attention completely focussed. You have to always be ready and able to ask the question “Yes and?“. You have to be engaged and present to always be asking this question. 

6. Keep moving forward. When you’re constantly in the flow of improv and innovation, you can’t stop to analyze. It slows you down and stifles creativity. When something unexpected happens, take advantage of this new situation and move forward with it. If something goes wrong, learn the lesson and move forward. The whole idea is to keep moving forward. The road behind you is not the road that leads to innovation. Keep moving forward.

7. Understand the good of the whole. When you personally understand what is good for the whole, you have a deeper understanding of when to hang back, when to grab the reigns and how to grab them, and how to support the other members of your team. When the whole team has this attitude and understanding, it creates a truly collaborative, improvisational environment.

8. Lose control. We don’t want anyone on our team to be the star or orchestrator. We want to make sure that no one gets into the “controlling mind“. As soon as one person assumes control or seeks the spotlight, the creativity, improv, and innovation of the team suffers. We need to lose the control aspect of the team and allow everyone to respond to the moment.

9. Self-organize. Creativity is naturally a self organizing system. Teams that allow themselves to explore and play find this self-organization with ease. The team may set some very basic guidelines of play, but once they do, their roles and organization emerge naturally and creativity flourishes. This type of self-organization allows all kinds of things to be possible.

From my own personal experience, the most innovative teams I’ve ever worked on embraced these basic principles of improv. In fact, a few years ago, I worked on a truly creative, innovative team. That team always asked the question “What else can we do with this?”. We opened our minds to all possibilities. There were many times we said, “We’ve never done this before”. Often, we had no idea how the idea would play out. But we always accepted the offer to see where it would go. Sometimes we failed. But, we learned and moved on. And, when we were successful, we produced some of the most innovative software the mapping world had ever seen. I don’t think we ever tried to be improvisational or purposely forced these improv principles. It emerged naturally on a team full of incredible talent with no egos, and I think that made all the difference in the world.

I recently had the opportunity to speak with Greg Lee, the Chief Financial Officer of the Lance Armstrong Foundation and Livestrong, about the design and buildout of the new Livestrong world headquarters in Austin, Texas. Livestrong is in the process of converting a 30,000 square-foot, 1950′s-era industrial building into a modern, green, collaborative workspace for their foundation’s efforts to combat cancer. You may have seen some video clips of Lance Armstrong touring the new facility yesterday here on EdgeHopper. In this interview, Greg gives us a more detailed look at all of the sustainable design elements of the new building and discusses the long-term financial savings they will provide. He also delves into the collaborative nature of the space and the teams at the foundation. I was going to turn the interview into a blog post, but Greg provided so much great information in such a passionate way that I wanted to have you hear it from Greg himself. To that end, this blog post is also about introducing the first edition of the new EdgeHopper podcast series. As I do more interviews in the future, I’ll try to include them as podcasts here on EdgeHopper and through iTunes as well. Hmmm…launching a new venture on Friday the 13th, gutsy eh? Anyway, I hope you enjoy this first interview with a fantastic person from an amazing organization.

Click to SUBSCRIBE to the EdgeHopper Podcast in:

At the Lance Armstrong Foundation, we fight for the more than 28 million people around the world living with cancer today. There can be – and should be – life after cancer for more people. That’s why we kick in at the moment of diagnosis, giving people the resources and support they need to fight cancer head-on. We find innovative ways to raise awareness, fund research and end the stigma about cancer that many survivors face. We connect people and communities to drive social change, and we call for state, national and world leaders to help fight this disease. Anyone, anywhere can join our fight against cancer. Join us at LIVESTRONG.org.

About the LIVESTRONG Global Cancer Campaign

Lance made the decision to return to cycling because he thrives on competition. For his Foundation, the competition is the global threat of cancer. Cancer is poised to become the world’s leading cause of death by 2012. The Global Cancer Campaign is a worldwide initiative uniting everyone from survivors like Lance to world leaders and policymakers who must commit to the effort to avoid a public health catastrophe. To put it simply, we’re going to build a global movement against cancer, and we’re going to win.

And those aren’t just some words slapped on a hotel brochure. The Benjamin has gone to extraordinary lengths to back up the guarantee of a good night’s rest in New York, “the city that never sleeps.”

Andy told me “The Benjamin sells a good night’s sleep, and we guarantee each guest’s comfort by providing anticipatory services, such as remembering a pillow preference and having it waiting in the room upon check-in. We’ve also implemented a number of innovative initiatives, including our Sleep Concierge, a 12-choice pillow menu, our sleep guarantee and a variety of other sleep-inducing amenities through room service and our Wellness Spa. We always provide caring and genuine service with an innkeeper’s mentality to make every guest feel like their comfort and needs are our top priority, and we center everything the hotel does around following through on these expectations.”

In fact, three days before a guest is scheduled to arrive, the staff advises him or her of the pillow menu so that the pillow will be in the room when the guest arrives. The menu is amazing. It offers guests a selection of 12 different types of pillows from which to choose: down, upper body, buckwheat, satin, hypo-allergenic, water-filled, Swedish memory, magnetic therapy, a jelly neckroll, a five-foot body cushion, sound, maternity and a special anti-snore pillow. In addition to the pillows, the hotel features The Benjamin Bed: a Serta mattress created exclusively for The Benjamin, covered with 100% Egyptian Cotton 400-plus thread count sheets by Anichini and a down-filled comforter with luxurious triple sheeting. (The pillows, sheets, and mattresses have become so popular that they are now offered for sale for guests who want to sleep as well at home as they do at The Benjamin!) Aromatherapy bathroom amenities help guests relax and prepare for bed. In addition to the luxurious sleep amenities, The Benjamin’s windows are double-glazed with argon gas between the panes to help keep rooms quiet and restful. If you’ve ever slept in a midtown Manhattan hotel, you know how important that is!

When I asked Andy about The Benjamin’s edgecrafted marketing strategy, he told me “We realized that the number one productivity tool for today’s travelers wasn’t a laptop or Blackberry – it’s a good night’s sleep. The Benjamin is an innovator in the hospitality industry by recognizing that niche and being the first hotel to offer a 12-choice pillow menu and an on-staff Sleep Concierge to satisfy guest’s needs for a perfect night’s sleep.” He went on to say that “We are continually educating our staff so all associates know the latest sleep tips and breaking research in the sleep industry. Sleep intertwines throughout the whole culture at The Benjamin – from the sleep-inducing food we serve to the in-room soothing amenities and services we offer to the soothing sounds and smells that are infused throughout the property.”

I love that Andy said “Sleep intertwines throughout the whole culture at The Benjamin”. Culture, in addition to the unique services offered, is what seems to set The Benjamin apart. And that culture includes listening not only to their guests, but to their staff as well. “As an organization, it’s our culture to include our staff in all new ideas and innovations that we bring into The Benjamin,” Andy said. “We talk to our associates about what ideas they might have that we could implement so everyone is involved in the continuing development of the hotel and shares the responsibility to make sure it comes to fruition. As an example, when we introduce a new pillow, everyone has a chance to test it so they learn what the benefits are in case a guest asks them to recommend something for a specific ailment The Benjamin staff prides itself on the satisfaction scores we receive from past guests, and we are always working as a team to make sure we are continuing to raise those scores across the board.” Key point: Continuous improvement through teamwork and collaboration.

The Benjamin also actively collects feedback from their guests through one-on-one discussions and by hosting weekly managers’ receptions. No “How did we do?” cards here. They also put outside focus groups together for new ideas, and have staff meetings twice a month to talk about the future of The Benjamin. They discuss not only what’s happening inside The Benjamin, but also what other hotel companies are doing and how the hospitality industry is developing overall.

Now that’s edgecraft! That’s setting yourself up to be remarkable. A lot of hotels offer a “100% Satisfaction Guarantee”, but how many go to the lengths that The Benjamin does to actually make sure that their guests are satisfied. If you’re going to offer a 100% Satisfaction Guarantee to your customers, think about what The Benjamin does and ask yourself “Am I offering just words and hoping for the best, or am I actively doing something to make sure my customers are satisfied 100%?”

Guest Post by Jurgen Appelo:

I once read that “managing is harder than programming, because making people do what is needed is far more difficult than making computers do what is needed”. (Don’t flame me if you don’t agree. I’m quoting from an unknown source here.)

This quote kept running through my mind when I recently encountered a number of, well… let’s call them disciplinary challenges, like…

• Not being at a meeting, without notice, despite having accepted the request,
• Not keeping systems or task boards up-to-date with latest task/story statuses,
• Not linking code or time registration to issues or user story numbers,
• Not actively checking if there’s overrun on a budget,
• Not responding to a show stopper problem within promised response time,
• Not storing project documents in the shared repository,
• Etc…

Is this a case of hanging out the dirty laundry? Not really. We’re all people, employees and managers alike. We’re not computers, we all make mistakes. If you don’t have similar problems in your organization then I will assume you’re working with robots, not with human beings.

Still, they are problems nonetheless. If my computers were this unreliable I would throw them out the window. No, actually I would carry them all the way up to the tea room in our office building, and then throw them out the window. But we don’t do that with employees anymore these days. That’s because managers have discovered how to be humans themselves, and they can understand the reasons for people’s non-disciplined behavior, with excuses like: I-Didn’t-Know-This-Was-A-Rule, Sorry-I-Forgot, There-Was-Too-Much-On-My-Mind, I-Was-Kept-Busy-With-Some-Major-Problem, I-Was-Sick, My-Dog-Was-Sick, My-Dog-Ate-My-Agenda, My-Dog-Ran-Away, and of course My-Dog-Died.

So, we all understand being human. But what to do about the problems?

One solution that people often come up with is that some supervisor should be made responsible to inspect everything. This is of course step 1 on The Road To Bureaucracy, and it is a direction that agile and lean people fervently argue against. However, other people argue that some of those steps are nevertheless very useful.

For example: Mary and Tom Poppendieck, famous for their books on Lean Software Development, argue that inspection to find defects is waste, and they call for zero-inspection. They claim that resources should be spent on preventing problems instead of fixing them, because it’s cheaper.

On the other hand: Tom and Kai Gilb, famous for their work on Software Inspection (among other things), teach people how to inspect documents to find and measure defects. They even have certificates for inspection, like Inspection Leaders and Inspection Process Owners!

What’s going on here?

Can these different viewpoints be aligned? Can I earn myself a certificate for doing zero inspections? Or do we have a chance of witnessing a clash between the two most celebrated family duos in software development? An epic battle between father and son Gilb against husband and wife Poppendieck?

Well, I admit that would be a sight to see, but my guess is that their viewpoints are simply two sides of one and the same coin. Yes, preventing problems is cheaper than fixing problems, but only for 95% of the problems. In fact, it has been noted before that zero defects is the wrong approach, because preventing those last few problems is far too expensive. Which means that we have to allow some problems to flow to the next phase in the process, where detecting and fixing them can be cheaper. I discussed the staged approach to discipline in one of my earlier articles:

1. People have to show a high level of self-discipline;
2. They have a coach to help them in becoming more disciplined;
3. Their discipline must be subjected to peer pressure;
4. There should be tools to assist in mistake-proofing the process;
5. Last of all, there might be some supervisor doing regular inspections;
6. And if everything fails, the dirt will land on the manager’s desk.

It is almost always cheaper to solve problems higher up in this stack. Supervising and inspecting is the final gate where problems can be detected and prevented from ending up at the manager’s desk, or worse… the customer’s desk. Fewer inspections are better. But zero-inspection is like full code coverage. It is a lofty goal that, in practice, is unattainable because of its exponential costs. There will always be some work left for some supervisor to inspect, certified or not.

So, in solving the problems I mentioned earlier, before giving work to a supervisor, I will try and make sure that I have done all I can to prevent needing him in the first place!

And of course, the principles of discipline apply to my own work as a blog writer as well… juicy title: check… teasing opening paragraph: check… re-reading ten times: check… silly jokes: check… spell-checking: check… hyperlinks and mark-up: check… great pictures: check… making fun of celebrities: check… conclusion: check… OK, ready for the next phase… Chris, will you inspect this post please?

About Jurgen Appelo

Jurgen is the Chief Information Officer at ISM eCompany, rated (a while ago) as the #1 fastest growing technology company in The Netherlands. As a manager, he leads a horde of 100 software developers, development managers, project managers, business consultants, quality managers, service managers and kangaroos, some of which he hired accidentally.  He also write a blog called NOOP.NL: A Guide to Development, Management, Things & Stuff.

There was an amazing interview on CNN recently with Haruka Nishimatsu, the CEO of JAL, Japan Airlines. The interview could have been a primer on how to be an ethical CEO who cares about his people and his company more than he cares about his own compensation. According to the report, when JAL slashed jobs and asked older employees to retire early, Nishimatsu cut every single one of his corporate perks, and then for three years running slashed his own pay. In 2007, he made about $90,000 U.S., less than what his pilots earn. In Japan, says Nishimatsu, there’s less of a pay gap between the top and the bottom. “We in Japan learned during the bubble economy that businesses who pursue money first fail. The business world has lost sight of this basic tenet of business ethics.”

The report also details Nishmatsu’s daily routine: “After his morning commute on the city bus, Haruka Nishimatsu heads into the office and gets busy at his desk with the rest of his Japan Airlines coworkers. At lunch, he lines up in the cafeteria and hopes lunch doesn’t get too cold as he waits to pay. Not exactly the glamorous life you’d expect from the CEO of one of the world’s top ten international airlines. ‘Is it so strange?’, asks Nishimatsu.”

Glenn Tilton

Now, consider Glenn Tilton, CEO of United Airlines. Tilton’s total compensation package is the highest in the airlines industry. In 2006, Tilton’s compensation alone exceeded $39.7 million ($38 million in stock and options) in a year the company emerged from bankruptcy and employees were forced to accept painful cuts. In 2007 Tilton was rewarded with $10.3 million and United has an additional plan called the “2008 Incentive Compensation Plan” to again lavishly reward failed decision making. Tilton’s compensation seem pretty excessive in light of his company’s poor performance and the impact of extreme inequity on the morale of the workforce.

Consider this too: Until recently, soaring oil prices were the alleged reason United decided to impose a $15 fee to check your first bag and a $25 fee to check a second bag on domestic flights. Even though oil prices have come back down, United’s baggage fees remain because they are boosting the airline’s dismal finances and moving customers to “a la carte” pricing — passengers pay for the services they use, whether it’s a sandwich bought on board, a checked bag or assistance from a telephone reservationist. United has said it expects to collect $275 million annually from the first- and second-bag fees.

As United Airlines is losing money, cutting their services, and asking you, the flying public, to pay for standard services, or a fee for 5 inches of leg room, Tilton is raking in a seriously inflated compensation package based on a poor performance record. Aside from the basic ethical and moral issues that this raises, on a deeper level think about what this does to morale at United Airlines. I mean, really, who would you rather work for: Nishimatsu or Tilton? Or better yet, who would respect more and work harder for?

The fact that Nishimatsu makes less than his employees is significant. That he takes the bus to work, has a simple office, eats lunch with his employees in the cafeteria, and has cut everyone of his executive perks is really significant. He’s one of them. He cares more about his employees than he does about money. How many CEO’s can say that? He’s also not a top down kind of manager. In his 2008 Greeting on the JAL website, Nishmatsu said:

Strengthening workplaces is not something that can be done entirely from the top down. Currently, an employee-proposed and led initiative called “JAL Tomorrow” is being carried out in order to create a vision for JAL’s future. By the end of fiscal 2007, Group employees had submitted 11,596 proposals and comments concerning the kind of company they want JAL to become, the kind of airline they want to work for. I was very surprised by the number of responses. It is fantastic that employees created their own initiative to help JAL become a company that will be more trusted by customers. The management team and I will continue to support this initiative in every way possible.

Compare that to United performance statistics since Tilton took over as CEO of United in 2002. Here are some stats from the US Department of Transportation’s Air Travel Consumer Report:

• Capping their steady decline, United tied US Airways in calendar year 2006 for the highest number of complaints per passengers flown (1.36 per 100,000 system-wide enplanements).
• In the category of customer service problems, which the DOT defines as “rude or unhelpful employees, inadequate meals or cabin service, treatment of delayed passengers“, United holds the distinction of being the worst among the top-10 US carriers for 2004, 9th place in 2003 (Continental took 10th), tied America West for 9th place in 2002 (American took 10th).

And Tilton’s pilots aren’t in love with him either. This year, they went on an all out offensive to remove him from his position. Their main complaint: His excessive compensation package in light of his poor performance. They’ve started a website called Glenn Tilton Must Go. And this was the message they flew around United’s Chicago headquarters this past Labor Day:

United’s Pilots to Tilton: “Glenn’s Gotta Go!”

Hmmm, not so great for United and Tilton. Nishimatsu is, in my mind, what a true leader should be. Inspiring, caring, fair, and most important, ethical. I’d work for him tomorrow.

Not to be on too big of a Japan vs. U.S. kick these days, but what do Japanese companies understand that American companies don’t? Last month I wrote about Toyota and their commitment to their employees. Now this interview with the JAL CEO surfaces a similar sentiment. If more executives would show more respect and caring for their employees and their companies like Nishimatsu has, maybe they wouldn’t be in the bad shape they’re in today.

If you missed the interview, here’s the complete video:

The catch was that all of the participants except one were confederates of Dr. Asch. The confederates gave the correct answer for the first few trials, but then all began to give the incorrect answer in subsequent trials. Amazingly, the test subject began giving the same incorrect answers as the confederates. In fact, overall, after 18 trials, 36.8% of the answers given by the ‘real’ participants were incorrect, effectively conforming to the wrong answers given by the unanimous confederates. Only 25% never gave a false answer, therefore showing that 75% conformed at least once. The results show a surprisingly strong tendency to conform under group pressure, even in cases when the answer is clear.

How does this inform us? When we’re working on teams, we need to be cognizant of this study. We need to be vigilant against conformity and group steering. It can be extremely detrimental to continuous improvement. If one person on a team has an opinion that is different from every other team member, this tendency towards conformity may have a chilling effect on their ability to communicate a problem with the team. This applies to estimating as well. If teams estimate in an open manner, differing opinions can potentially be quashed. That’s why I believe planning poker is such an effective method for estimating with teams.

But, there is hope. Asch was very disturbed by the results of his experiment. He said, “That we have found the tendency to conformity in our society so strong… is a matter of concern. It raises questions about our ways of education and about the values that guide our conduct.” Some time later, Asch conducted his experiments again. This time, when every one of the confederates voted for the wrong answer, one stood up and said “That’s wrong!”. The test subject then easily identified the correct answer. Adding one supporting partner greatly diminished the power of the majority. Hope!

One voice of dissent enabled another to be heard. Is that all it takes on our teams, in our society to make a difference? One voice to say “That’s wrong”? I believe so. But I also believe that on a deeper level, we need to create environments on our teams, in our organizations, and in our society where people do not have to feel pressured to conform. People should be able to think freely and express their views without being hindered by the majority rule. This freedom to disagree is where all progress, creativity, and innovation comes from. I love the fact that the results show that the 25% of subjects who never gave wrong answers were not susceptible to conformity. That makes me very happy. There is hope that not everyone around us is likely to conform to the majority opinion.

I believe that the qualities that I described above for startups are what make many of them successful. And almost more importantly, I think it’s what makes them fun and exciting to work at. So many startups have charismatic leaders who have a really clear and focused vision for the company. They need to; they can’t afford to waste time working on things that don’t get them to their goal quickly. And energy. There is is so much energy at a startup because everyone is really committed to making this thing work. They wouldn’t be there otherwise. Many talented people who work at startups could easily work at a big corporation making better salaries. But there is a certain energy at startups that really bright people seem to thrive on. Maybe it’s the thrill of survival?

But, aside from the obvious two differentiators I’ve mentioned above, I think that small teams, Beginner’s Mind, and the Art of the Possible are really the driving forces behind the energy and excitement at most successful startups. Small teams are essential as they take the focus off of process and put it on teams delivering value quickly. And within small teams, without bureaucratic processes to bog down innovation, the Beginner’s Mind can really thrive.

Garr Reynolds of Presentation Zen fame says “like a child, one who approaches life with a beginner’s mind is fresh, enthusiastic, and open to the vast possibilities of ideas and solutions before them”. Garr goes on to expound that “when you approach a new challenge as a true beginner (even if you’re a seasoned adult), you need not be saddled with fear of failure or of making mistakes.” I believe that large corporations really struggle with this. They’re afraid to fail and thus, they close off the Beginners Mind and start to stifle innovation with processes that discourage and avoid failure. Startups, however, thrive on the possibility of failure. Most people who are serial entrepreneurs have failed numerous times before they had that big breakthrough success. Successful startups allow for failure as a learning tool. If it didn’t work this time around, let’s fix it and try again. Inspect and adapt doesn’t work if you don’t allow for failures.

The Art of the Possible is the other critical component that I think successful startups understand. Anything is possible. They are not constrained by preconceived notions, processes or policies. If something isn’t working well in the organization, they can change it. No worries. No issues. They believe anything is possible and embrace the change that this kind of thinking encourages. Without an acceptance of the Art of the Possible, organizations stagnate and do things because “That’s the way we’ve always done it, we can’t change that!”.

So my advice to you is this: Act like a startup! It’s not as hard as you think it is. Adopting agile practices helps get you there quickly. But you don’t need to use agile to get there. Make an effort to have a clear established vision that everyone in your organization understands and works towards. In fact, let the vision come from the organization and it’ll be even more powerful! Use the buy-in to that vision to promote and sustain energetic employees. Do everything you can to treat people right and keep that energy level high. Break your organization into small teams so that they can focus on the work at hand and can easily discover and tackle organizational challenges without big overarching policies, processes, or hierarchies getting in the way. And more than anything, approach everything you do with the Beginner’s Mind and always, always, always implore the Art of the Possible!

Do you know how many hourly jobs GM has laid off from 2006 to July 2008? Take a guess. How about 34,000? And now, they’re talking about another 5,500 layoffs. And now they’re asking you and your government for a bailout to end their troubled, outdated, low quality, wasteful production system. But, let’s not focus on fixing GM’s problems with an infusion of cash. There’s something even deeper going on here that’s really wrong.

OK, here’s a better question. How many hourly jobs has Toyota’s American production system laid off in the same time frame? Zero. That’s right. ZERO. How? Isn’t Toyota experiencing the same slow down in auto sales as GM is? Yes, it is. And yes, Toyota has halted production at its Texas and Indiana plants for the past 3 months. But the 4,500 people who work at those plants have not been laid off. What!?!?! How? Why?

The answer: Toyota has a special culture, deep-rooted values, and respect for their workforce. Toyota’s tradition is to NOT lay off employees during hard times. This tradition hasn’t really been put to the test until now. And Toyota has stuck to its guns and its values.

“This was the first chance we’ve really had to live out our values,” says Latondra Newton, general manager of Toyota’s Team Member Development Center in Erlanger, Ky. “We’re not just keeping people on the payroll because we’re nice. At the end of all this, our hope is that we’ll end up with a more skilled North American workforce.”

Interesting. But what does that last line mean? “At the end of all this, our hope is that we’ll end up with a more skilled North American workforce.” It means that while these employees were not manufacturing automobiles, they were in training. They were doing safety drills, participating in productivity improvement exercises, attending presentations on material handling and workplace hazards, taking diversity and ethics classes, attending maintenance education and taking a stream of online tests to measure and record their skill improvements. Toyota is shifted the Texas and Indiana workers temporarily to Toyota plants whose assembly lines were moving at full speed, such as the Camry assembly plant in Georgetown, Ky. In addition to all of this, the workers also spent some time painting the plants and even helped build Habitat for Humanity homes. And they were getting paid.

Wow! So what is this costing Toyota? The estimate is at least $50 million dollars, plus the loss of revenue of shutting down production. Why is this value and tradition worth so much to Toyota? Why would they be willing to spend $50 million rather than lay people off? It’s because Toyota believes that its people, yes, its PEOPLE are its greatest investment and its greatest asset. You hear so many companies say that, but would they really put their money where their mouths are when the rubber hits the road (no pun intended)? In Toyota’s case, the answer is yes they would.

So what does Toyota get out of this? When, not if, the plants return to full production, Toyota will have well trained employees on the front line, ready and able to meet the demand for their vehicles. And not only will they be well trained, they’ll be happy and motivated to work. Because Toyota is willing to go to the mat for their people, their people will be willing to do the same for Toyota.

The lesson here: Unlike their counterparts GM and Ford, Toyota has always taken a long-term strategic view about their employees. Toyota understands that laying off thousands of employees for slowdowns or plant retooling is counter productive. They wisely utilize the time to redistribute their workforce to understaffed plants, provide additional training for the new products, and leverage their workforce to speed the transition for newer products. Their philosophy has avoided labor disputes and staffing shortages. It has kept the company as a leader in quality and profitability over its shortsighted competitors.

So, the message for you in all of this: Really commit to upholding the value that your people, let me repeat that, your PEOPLE are your greatest asset. Treat them with respect and dignity. Do everything in your power and your imagination to keep them on the payroll during the rough times. If you don’t, you may not find those people again on the upside of the downturn. And if you do, you’ll have hyper-productive, motivated teams delivering quality because they’re committed on a deeper level to your company.

Note 1: If you really want to understand why the Big 3 are losing big time compared to Toyota in terms of market share, take a listen this excerpt from Public Radio International’s “The World” report from last Friday (Nov. 14, 2008) describing why Toyota and other Japanese manufacturers seem to have a leg up on their American counterparts (for the complete report, from The World, click here).  After reading this post, you might not be so surprised when you hear that the employees being laid off by the Big 3 are now working at Toyota.  Click here to listen to the excerpted report.

Note 2: From Forbes online: At American companies, finance guys and marketers rise to the top.  Not at Honda.  Read the whole article here.

Note 3: Another Japanese leader shows the way to be a true leader: When Japan Airlines JAL slashed jobs and asked older employees to retire early, their CEO cut every single one of his corporate perks, and then for three years running slashed his own pay. In 2007, he made about $90,000 U.S., less than what his pilots earn.  Compare that to United Airlines CEO Glenn Tilton: In 2006, Tilton’s compensation alone exceeded $39.7 million ($38 million in stock and options) in a year the company emerged from bankruptcy and employees were forced to accept painful cuts!  Read the rest of the story about JAL and United here.

First, why did Borland go agile? High-profile strategic projects were sending up some serious signal flares. They were being developed using the traditional waterfall methodology. Borland’s development was living in a reactive environment and the reaction time was SLOW. To rescue the sinking ship, they needed rapid discovery and resolution of problems.

The Pilot Project

Find a low risk project…AKA, one that was failing so badly, there was only one way to go…up. They found one. The project had 4 dev teams spread across 4 countries. 10 months later, delivered product on schedule and under budget. They proved that agile worked. Now to sell it to the C-level. They needed to articulate how agile practices achieved business goals.

The sell:

More frequent release cycles —-> better market timing

Involve customer in the development process —> boost quality

OK, the execs were sold. Now, how did Borland do the rollout of agile throughout the organization?

THE APPROACH

Managed roll out by geography

1. Create agile baseline in Austin.

2. Rollout culture and practices throughout company to other domestic and international offices

3. Organizational change to occur in pragmatic stepwise approach

Step 1: Herding the converted. Solidify with a common Agile culture. Established the foundation with executive sponsorship. Established baseline process development. Iterative rollout with early success

Step 2: Guiding the curious. Organization wants to go agile but how? Baseline process serves as guide to expand the process. Get teams comfortable with owning projects. Early success builds confidence within team.

Step 3: Winning over the skeptics. “Software process mandates usually fail”. This required a socializing change. Focused on development culture. Provided guidance and support to teams. The plan was to develop buy-in not mandate compliance. Break down the walls and barriers to collaboration and communication. Build collaboration and trust.

Where are they today?

65% of teams are agile. 9 products under agile development including 4 new products. Continuing migration by geography. 100% agile is not the goal.

Built and agile-purposed working environment. Cubes —> teams rooms. No more separation. QA, devs, tester, BA’s all sit together now in Austin. Whiteboards everywhere. Furniture on wheels. Everything is reconfigurable. Really awesome example of how to build a purpose driven workspace!

But, the workspace wasn’t the only thing that changed. Time management is now controlled solely by the team. Schedules, working hours…everything! Management let go of command and control and is now in true servant leadership mode. The teams have been enabled to be self-managing and self-organizing.

What they learned.

Lesson 1: Requirements and roadmaps are essential. Cannot be unilateral. Needed to ensure internal and external roadmap sharing as well as roadmap flexibility. The roadmap rules were simple. The roadmap had to be easy to say, hard to do and everybody has an equal voice in the roadmap. To make everyone’s voice heard, they went low-tech. Low-tech sped u collaboration. Lots of sticky notes with ideas!

Lesson 2: News is just news. But, getting the news early and acting on the news is the important practice for success. Avoid reacting to everything as a fire drill. Embrace the change that the news makes necessary.

Lesson 3: Change is an advantage. Don’t assume we know everything up front. Change is apart, not an exception of the process. Allows the team to rapidly adapt to changing business needs.

Lesson 4: It’s Agile, not chaos! There are ground rules.

Lesson 5: Understand organizational impact. Agile is a disruptive force.

What they gained

Quality, visibility and predictability. No surprises here!

100% improvement in on time delivery of products by Agile teams.

Smaller product teams.

Increased confidence in teams’ ability to deliver.

Exponential improvement in team morale.

I think that sometimes, we try to set too many goals for ourselves or our projects and that is what gets us into trouble. So, whether you’re setting personal goals or goals for your team’s next iteration, keep it simple. In that way, you can really focus on achieving a single simple goal. If you’re on an agile team and trying to set goals for your next release or iteration, here are a few simple ways to set your goals and achieve them without the use of software. And if you’re not on an agile team, my guess is, these little tactics may help you with whatever goals you have as well.

1. Brainstorm: Get together with your team and discuss of all of the things you’d like to accomplish. Write them on big Post-It notes and stick them on a wall for everyone to see. Don’t worry how many you put up there. You don’t want to miss anything.

2. What’s Relevant Now: From the items posted on your wall, select a goal to focus on in either your next iteration or release. This should be a goal that furthers one of your primary business objectives. If you don’t know what these are or how to arrive at them, check out this post on How to Decide What to Build.

3. Create a Mantra: Guy Kawasaki highly recommends mantras as effective ways to keep focus. Mantras are just 2-3 words that capture the essence of your goal. Forget about long wordy statements to describe what you’re after. Get to the heart of it. Give your team or yourself something easy to remember when you set out to begin working toward your goal everyday. Put the mantra on Post-It’s around the office. Have a Mantra Board where you can write it big and bold for everyone to see. It really does help.

4. What can you do in this iteration or release to make it happen: When you and your team get together to plan your release or iterations, keep the mantra and the goal in mind. Select tasking that will make it happen. Select tasking that is focussed on achieving the goal. Anything else is extraneous.

5. What can you do today to make it happen: When you hold your daily stand up meetings and commit to what you are working on today, think about your mantra and goal and commit to tasking that you’ll work on today to achieve the iteration goal. Keep it very focussed on the goal and you won’t go astray.

Self-discipline refers to the training that one gives one’s self to accomplish a certain task or to adopt a particular pattern of behaviour, even though one would really rather be doing something else.

Now, I don’t know about you, but applying that type of discipline to anything, be it agile practices or riding your bike, doesn’t seem like a way to ensure long-term success.

Actually, what I think makes agile teams successful in the long-term is motivation. Motivation is very different from discipline. Organizations try so many different tactics to motivate others and themselves and continually fail. I think it’s because they overcomplicate what motivation is. I think if you boil it down to it’s essentials, in order to truly motivate yourself or others, you can do two simple things:

1. Make it enjoyable
2. Use positive public pressure

I believe that at its core, agile practices embrace and promote both of these tactics. First, make it enjoyable. In life, and in agile, find the enjoyable parts of what you are doing and focus on those. If you’re on an agile team doing iteration planning, agile encourages you to select your own tasking for the next iteration. People will naturally gravitate toward tasks they enjoy. Take advantage of this natural tendency to ensure that your entire team is enjoying what they are doing over the next iteration…and the next…and the next. Continuous enjoyment. When was the last time you thought about your work that way. You can make it happen.

Second, use positive public pressure. Many people see pressure as a bad thing, and it is when used incorrectly. Positive public pressure is a good thing. It’s committing publicly to achieve a goal. But this public pressure of commitment has to be tempered so as not to become harmful to the team or the individuals. The pressure and commitment has to be kept at a high enough intensity level to motivate but low enough not to burn anyone out. In addition to inviting public pressure, regularly reporting on your progress toward your public commitment keeps others updated on your progress and keeps your commitment at the top of your thinking. These practices enforce positive public pressure and really help motivate. Agile embraces this concept wholeheartedly. Teams publicly commit to each other and their organizations and stakeholders to complete a set amount of work in a short iteration. Then, on a daily basis, they report to each other on their progress. They also have the additional public pressure of having to demonstrate their completed work to their organization and stakeholders at the completion of each iteration.

I believe that when used together, enjoyment and positive public pressure can be used to motivate teams into becoming highly productive. People are enjoying their work and making their own public commitments that they can sustain iteration over iteration. They are not relegating themselves to someone else’s tasking or commitments, and that, I think, is the key to this motivational strategy. The result is happier, more productive teams with a very low burnout rate.

"Right now I’m aiming at increasing the distance I run, so speed is less of an issue. As long as I can run a certain distance, that’s all I care about. Sometimes I run fast when I feel like it, but if I increase the pace I shorten the amount of time I run, the point being to let the exhilaration I feel at the end of each run carry over to the next day. This is the same tack I find necessary when writing a novel. I stop every day right at the point where I feel I can write no more. Do that, and the next day’s work goes surprisingly smoothly. I think Ernest Hemmingway did something like that. To keep on going, you have to keep up the rhythm. This is the important thing for long term projects. Once you set the pace, the rest will follow. The problem is getting the flywheel to spin at a set speed – and to get to that point takes as much concentration and effort as you can manage."

He also hit on one of the topics that I really think is an issue in software management today and that is the difference between effectiveness and efficiency in software development.  I have written about this before and feel very passionate about it, and it’s worth mentioning again.  Cooper provided a quote from Peter Drucker that I think really summarizes this argument very well:

Effectiveness is more important that efficiency.  Business can decline and even fail at the same time that process reform is dramatically improving efficiency by saving money for the company.

I would agree and would argue along with Cooper that ignoring effectiveness to focus on cost reduction is a primary cause of software construction failures.

Cooper also made some great analogies to describe the way software is developed.  He doesn’t see software development as an industrial activity.  He believes it’s more like a pre-industrial craft in that things are made one at a time, they’re not formulaic, and they are complicated and nuanced.  But, he also see’s it as a post-industrial craft with more pieces, built by disparate teams, with abstracted notions and massive interaction between the parts.  He described the post-industrial craft of software development as existing in a brittle environment with invisible or intangible products, and working in a world of rapidly evolving tools.  I agree with most of that, except I’d like to believe that the products we produce aren’t invisible to our end users.

I really liked the points discussed above.  However, I found the remainder of his talk to be a little off-base and very biased to a waterfall or modified waterfall approach to software development.  In addition to promoting a waterfall approach, he made several misstatements about how agile teams work and plan.  His first comment was about planning.  He advocated that to successfully manage software projects, you must have detailed written plans.  He also claimed that contrary to engineers’ claims, requirements don’t change.  He went on to slam agile practices by saying that agile practitioners say that “We shouldn’t plan because things change so rapidly”.  Anyone who has managed a software project using agile practices knows this is a huge waterfallacy (a fallacy about agile spread around by waterfall advocates).  Agile teams do plan at many different levels.  In fact, studies show that over the life of a project, agile teams do more planning that traditional development teams…they just do it iteratively.

Where Cooper really began to diverge from an agile approach to software development was in his description of what he called The Software Construction Blueprint.  Here are the required elements of Cooper’s “blueprint”:

1. A narrative description of user personas and scenarios
2. A behavioral overview in narrative form
3. Detailed form and behavior specifications document
4. Detailed code examples showing how software will work
5. Detailed schedule and test plan

According to Cooper, by definition, blueprints are buildable and biddable.  If you build the blueprint described above, Cooper wholeheartedly believes that you can give a fixed price bid that you are confident in.  Now, I don’t know about you, but I’ve worked on many projects that produced blueprints or whatever you want to call it, but it was heavy up-front requirements analyses.  They were not successful!  On top of that, our customers are not paying us for all of these narratives and specifications…they’re paying us for working software.  Now, according to Cooper, an interaction designer builds this entire blueprint and distills everything anyone needs to know about building the software and hands off the design to a production team that actually builds the software.  Because the interaction designer does his job and divine’s every requirement exactly, there should be no questions or problems negotiating the software development minefield on the part of the production team.

I have several issues with this line of thinking.  First and foremost, I believe this sets up serious silos within the development organization.  It says that the production team has no input on design and design has no real input on production beyond initial design.  I really believe that teams shouldn’t have different titles and divided responsibilities.  The team is the team, period. Break down these silos and strive for more cross-functional teams.  It builds a better understanding of the various project roles and makes for more effective teams.

A side issue I have to throw out there is the fact that Cooper is an interaction designer and really came across as selling his services in the keynote (something I found rather distasteful).  Afterward, someone asked Cooper if he or his organization ever builds what they’ve designed.  He answered “No, we don’t”.  I won’t elaborate here, but I’m pretty sure you’re thinking what I’m thinking.

The bigger issue with his line of thinking is that all requirements can be defined up front and that they don’t change over time.  We’ve all worked software projects before and we all know this isn’t true.  Customers essentially have some idea of what they want, but as the software is developed and demonstrated, they begin to understand what they really want.  In agile, we can address those new ideas or changes without any worry that our big upfront design and planning would have been wasted.  But, after asking Mr. Cooper about customer involvement in the production phase of his development model, I completely understood why he believes that requirements don’t change.  My question was simple, “Where in the production process do you share completed functionality with the customer and how do you manage the change that is inherent when a client begins looking at what has been developed?”  Aside from the relative hostility with which he answered this question, it was evident that in his model, there is no communication or collaboration with the customer in the production phase.  Apparently, it is possible for an interaction designer to not only define every last requirement up front, but they also have the innate capability to anticipate every change the client would make and addresses them in the blueprint. I guess it would stand to reason that if you ignore your customers and not allow their voice to be heard in the production phase, you’d think requirements don’t change too!

What really perturbed me was that Cooper said he doesn’t believe that the customer even knows what they want, and that the interaction designer knows better than anyone what they need.  I take real umbrage with this assertion.  Essentially, his opinion was ignore your customers, you know what they need.  This to me is a real problem in the software industry.  This kind of thinking is exactly what leads to the 65% of features in most software that are rarely or never used (Check out the Standish Group’s CHAOS Report).  Having someone of Cooper’s stature stand up and advocate this is not going to do anything good for the software development industry.  And, considering the already low rate of agile adoption in the GIS development world, the last thing that we needed to hear in a keynote session were these toxic, old-school notions of software development.  I’ve been searching for a term to describe this way of thinking and thanks to the keynote speech at the Dev Summit this week, I think I have one now…The Cooper Syndrome.  Maybe at next year’s Dev Summit, Dave Bouwman, myself, or someone else can give the agile counterpoint to the Cooper Syndrome.

If you want some more insight on the keynote, check out Jeff Certain’s blog post on the keynote.

Our other option is to do iteration based bonuses.  This idea came to me from my friend Bruce Scott who works at a Silicon Valley company called ParAccel.  Bruce ran a few “experiments” with agile teams and iteration based bonuses.  Before I just launch into the results of Bruce’s experiments you should know who Bruce is.

Bruce has more than 25 years of experience building successful and profitable IT enterprises.  He has been responsible for product management and engineering, research, services and support at SenSage. As VP of Engineering, he improved the product strategy and engineering process, leading to strategic partnerships with EMC, IBM, HP and Tokyo Electron. He also founded and served as CEO of PointBase, a Java-based embedded database provider. Building the company from the ground up, his licensing savvy and strategic partnerships led to its successful sale to DataMirror.  Back in 1984, Bruce co-founded Gupta Corp. As VP of Database and Connectivity R&D, he developed its first database product, SQLBase, the first database server to run on a PC LAN and support the client-server architecture. Prior to Gupta, Bruce was one of four co-founders of Oracle Corp., serving as the principle engineer and architect of Oracle database’s first three versions. Hundreds of thousands of Oracle users know Bruce by the product’s default username and password “Scott/Tiger.” So, Bruce has credibility if know what I mean.

Bruce’s experiment was simple.  In the middle of an iteration that appeared stagnant or not very likely to conclude successfully, he announced that if his development team burned down the iteration to zero by then end of the iteration, each team member would receive a $1000 bonus.  Here’s what the burndown chart looked like for that iteration:

>

What looked to be a failing iteration was rescued by providing an incentive to burn down the iteration successfully.  The burndown rate following the bonus announcement is staggering.

The second experiment Bruce ran was to announce a $1000 bonus at the start of the next iteration.  Here’s what the burndown chart looked like for that iteration:

According to Bruce, the team stayed below the ideal burndown line until 1/30 where they added another significant story. The story wasn’t completed and was removed at the end of the sprint. This was a 31 point sprint, which was the highest this team had ever done. The sprint velocity before this was 23.5!

So, judging from Bruce’s experiments, I’d say iteration based bonuses look like pretty good incentives to keep agile teams going.  And, when it comes to project based bonuses, here’s Bruce’s take on the subject:

On the topic of bonuses per sprint or per project, I had the identical discussion with my CEO. I convinced him to do it per sprint for the following reasons:

1) A project bonus is un-Agile like. What if the scope of the project changes? This is easier and more realistic to manage on a sprint than a project basis.

2) There is a backpackers saying in regards to minimizing the weight of a backpack that says “watch the ounces and the pounds will take care of themselves.”

3) Per sprint bonuses provide more immediate rewards and have a more likely impact on velocity than a long term reward.

I’m not sure which we’ll finally implement at DTS, but I’m leaning heavily toward iteration based bonuses based on Bruce’s results.  If you have any opinions on the topic, or have any metrics you’d like share based on bonuses or incentives, I’d love to hear them.

An interesting solution may be to assemble an agile fire fighting team.  Essentially, the team would be composed of developers from different project teams.  The fire fighting team would be assembled for two-week iterations (synchronized with your project iterations) and team members would rotate in and out of the team.  One team member would be the fire captain.  The fire captain is responsible for handling fire drill requests, triaging them, prioritizing them, and working with the fire fighting team to task them out. During their rotation on the fire fighting team, team members respond to urgent requests and work on them the same way they would any other task in an iteration, committing to address them by the conclusion of the iteration.  What if there are no fires to fight?  Well, don’t get too excited…it’s not off to the beach for the fire fighting team.  If there are no fires, team members can address defects that may exist on their current project backlogs, they can work on documentation tasks (I knew you’d love that), or they can use the time as part of their hackathon innovation allowance.

My personal preference is that organizations work as hard as they can to move beyond the fire drill mode.  I think it is harmful to your development teams, reduces overall quality and value you are delivering to your customers, and ultimately it will impact you organization in a negative way. That said, if you can’t wean yourself off the fire drill mentality, consider putting together a fire fighting team.

We can do very well on our agile teams if we  approach our development tasks with the beginner’s mind.  Developers are, believe it or not, creative people.  If we all decided to think with a beginner’s mind about the solutions we develop, we might be able to create extraordinary software.  OK, maybe not always extraordinary, but we might provide innovative solutions that were unexpected.

We can learn even more by adopting the beginner’s mind when we approach how we work.  We should always be open to different ways of doing things and not be afraid to make mistakes.  In our agile practices, in our planning meetings, and in our retrospectives we should think like beginners about ways we can do things differently.  If we use the beginner’s mind, we can stop constraining ourselves to the “rules” of agile and really think about creative ways we can work better, smarter, and faster.

The opposite of the beginner’s mind is the expert’s mind.  If we approach things with the expert’s mind, we think we have all the answers and know the ways things ought to be done.  I believe the expert mind leads to “methodologies” and “processes” instead of practices.  The expert mind assumes that if we know the way things should be done, we can follow the stepwise recipe for success.  I think there is a contingent out there today in the development world that works using the expert mind.  They approach projects with a methodology and try to enforce strict processes to achieve success.  Follow the logical steps and you’ll deliver the product at the end.  You know what I’m referring to…we call it waterfall.  It comes from the expert mind that says that the path to success is predefined by years of experience.

I personally believe that success depends on each agile team’s particular situation and the creative solutions those teams devise to complete their tasks and improve the way they work.  And, as I said earlier, this creativity relies upon adopting the beginner’s mind.  So go ahead…let go.  Let the child inside you help you and your team be the best (and most creative) you can be.

This all came to mind this morning when I was calling our local communications provider Qwest.  I went to their website to find the phone number for their customer service line.  You’d think this would be right there on their main page.  Nope.  Not even a customer service link!  It took me 5 clicks to get me to an overly complicated customer service page that still didn’t provide a phone number.  Instead it gave several different “Contact Us” links depending on your request type. My point here is not about website design, but about what this says about Qwest’s commitment to customer service.  To me it says “We really don’t want to talk to you if we don’t have to”.

In addition to our difficulty in locating the correct number, we have received quite a run around trying to set up our T1 lines, our static IP block, and our phone lines at our new office.  We have received so much conflicting and confusing information from Qwest that after two months, we still don’t have our T1 lines in.  After today’s call to Qwest, it looks like we’re finally on the right track.  But all of this poor interaction with Qwest has left us pretty disappointed in both their company and their product.

Unfortunately, due to semi-monopolistic telecom policies in the U.S., we have to work with Qwest to get what we need (although Skype is a pretty good alternative these days).  But your clients and customers probably don’t have to deal with you or your company if you do a lousy job communicating.  So remember, every interaction you have with clients and customers is a marketing opportunity.  Every person on your agile Scrum team, from the senior project manager to the intern developer is a marketing agent.  We need to realize that to keep our customers and clients satisfied, to keep them coming back to us for more work or providing good word of mouth about our organizations, we all need to be effective communicators and marketers.  We need to constantly go that extra mile to provide the best customer service possible.

By the way, the main Qwest customer service line is 1-800-603-6000…but expect to be bounced around quite a bit depending on your request…my record is 8 transfers in a single call!

“You must always work not just within but below your means. If you can handle three elements, handle only two. If you can handle ten, then handle five. In that way the ones you do handle, you handle with more ease, more mastery and you create a feeling of strength in reserve.”

This is a really interesting quote in light of some of the reading I’ve been doing lately on multi-tasking, context switching and work interruptions.  Multi-tasking, context-switching and interruptions can be the biggest killers to the effectiveness and efficiency of agile teams.  According to David E. Mayer, who is a cognitive scientist and director of the Brain, Cognition and Action Laboratory at the University of Michigan, “Multitasking is going to slow you down, increasing the chances of mistakes.  Disruptions and interruptions are a bad deal from the standpoint of our ability to process information.”

Unfortunately for most of us in the software development world (and the “new” world at large), we have a plethora of technology at our disposal that we heavily rely upon to “manage” our multi-tasked lives.  We firmly believe that Outlook, our Blackberries, iPods, Instant Messaging, multiple monitors and other cool things will help us get through our days more effectively.  The truth is, they don’t.  They provide too many distractions from what we get paid to do…develop software.

A recent context switching study conducted by Microsoft Research and the University of Illinois examined diaries of the daily tasks performed by a variety of users.  What they found was that 45% of the reported tasks in the diaries were project-related or routine tasks that were part of the users jobs.  That figure would be astounding on its own, but when considered along with the tasks that comprise the other 55%, you’ll really be amazed.  23% of the daily tasks were related to e-mail and 13% were related to tracking their multiple tasks.  That’s 36% of time spent managing email and tasks!  The remainder of the tasks were pretty evenly split between phone calls (8%), meetings (6%), and personal time (5%).

I have personally fallen prey to this same pattern, especially with regard to emails.  I’ve tried several solutions to the issue including e-mail free Fridays, closing Outlook, disabling my IM client, turning off my cell phone, etc.  They’ve all been somewhat effective in creating more focus on my work.  However, the most effective solution I have found to my email “problem” came from Tim Ferriss’ book The 4-Hour Work Week.  It’s very simple.  Check your email twice a day.  I check mine at around noon and 4:00 (I don’t check it first thing in the morning).  If you’re going to do this, set up an email auto-response in your email client that says something like mine does (thanks to Tim for the “template”):

“Due to my high current workload, I am checking and responding to my e-mails twice a day at 12:00 P.M. MST and 4:00 MST.  If you have an urgent request that cannot wait until those times, please call me on my office phone at (123) 987-6543. Thank you for understanding this move to more efficiency and effectiveness.  It helps me accomplish more to serve you better.”

It sounds a bit extreme, and I received more than my share of concerned comments when I first implemented my lean e-mail diet plan, but over time it worked.  You may not be able to use this idea, but the general advice I’m trying to get out there is, don’t rely on technology to manage your multi-tasking.  It never works.  Instead, focus on managing those technologies so that they don’t interfere with your effectiveness and efficiency.

We didn’t know it at the time, but we were following Esther’s recipe for creating a micro-culture.  Essentially, we examined how we were working, how our organizational patterns, systems, and structures enforced the way we were working, and what our beliefs and values were.  Then we discussed how we wanted to work and what we needed to change to get there.  We decided that, in general, we were acting in ways that were definitely counter to what our entire team believed and valued, which is one of Esther’s indicators that you may need to change the way you are working.  We also decided that our organizational patterns and behaviors weren’t working for us as a team.  So we began to create a micro-culture within our satellite office.

We may have had an easier time creating this micro-culture because we were an isolated development group.  By isolated, I mean both geographically from our corporate headquarters, as well as on projects.  We shared no project work with other development groups within our company.  We were essentially free to operate under the corporate radar.  However, over time, our new micro-culture popped up on the corporate radar and we were asked to speak about agile practices with the rest of our organization.  Although it seemed that there was interest amongst the developers, the organization seemed (at least to us) very unlikely to change it’s corporate culture to be truly supportive of agile practices.

If you are a regular reader of my blog, you already know that our team decided not to fight the uphill battle of changing our organization and left for greener pastures.  However, if you are in an organization that seems even slightly receptive to change, you can work to make a difference in your organization.  Esther believes that small teams often have much more control than they think they do.  However, to be most effective, she recommends that teams understand what she calls “The Soup”…the stuff you can’t influence.  Once a team has that basic understanding, they can focus on the things that they can influence.

So if you’re starting on your own agile journey and it hasn’t received the corporate blessing, look around you and understand how your organization works.  Try to find ways to build your own agile micro-culture.  Then find ways to help your organization help you move agile practices into your corporate mainstream.  It may be that you need to take baby steps at first…little “agile experiments” that can help you show the successes and benefits of agile practices.  Take it slow, be patient, and do what Esther Derby says…”fan those tiny flames of agile hope you find in your organization and help then grow into agile bonfires.”

I refuse to be drawn into the debate about neography versus real GIS because it is a non-issue.  Technology is taking us to lots of new places and I think broadening our horizons and sharing GIS with “the rest of the world” is a great thing.  Those who want to draw divisions about whether or not something is “real” GIS are falling into what I call the High Priest Syndrome.  They want to use semantics, strict definitions, and a dogmatic view of their area of expertise to separate themselves from the “commoners”.  I find this highly divisive and extremely counter productive.  Sharing and expanding horizons with newcomers to our field often brings exciting insight and fresh ideas to sometimes stagnant viewpoints about what’s possible.  (OK, so maybe I finally gave an opinion on this matter and have indeed been drawn into the argument…but that’s the end of that!).

I think we see this in the agile world as well.  I believe that many individuals get so hung up on using the “correct” terminology for certain agile practices (especially in Scrum) that they alienate newcomers to the agile world.  There are many people who believe that you have to keep to a strict adherence of Scrum definitions to be “doing Scrum”: if you’re not doing everything Scrum says to do, you’re not doing Scrum.  I think this too falls under the High Priest Syndrome category.

The beauty of agile practices like Scrum is their flexibility…you know…inspect and adapt.  We need to constantly inspect and adapt our practices to make our team as efficient and effective as possible.  I say this with one caveat: Don’t inspect and adapt back to waterfall, or as Jean Tabaka calls it “Reverting to form”.

I was very glad to hear many of the speakers at the recent Agile Development Practices Conference last week echo this sentiment.  From Mary Poppendieck, Esther Derby, James Coplien and especially Andy Hunt, the message was clear: “Don’t be dogmatic about your agile practices”.  Andy said it very bluntly in his closing keynote and Mary said it in her opening keynote.  Mary really hammered it home by saying “Stop following best practices!  Create your own best practices and become a leader”.

So, before I ramble and rant too much more on this topic, let me say this: The next time you see blog posts or articles that draw you into counter productive arguments about whether or not you are agile, or whether or not you are doing Scrum, do what Dave Bouwman has recommended…IGNORE THEM.  Use your own judgement…you know what’s best for your team.  My best advice is to inspect and adapt frequently…to the situation at hand.  And remember, what worked for you last time may not work in the future, so don’t rely on what may become your own agile dogma.

What was so interesting about Ridgway was his vision of leadership.  At the time, the model of military leadership in Korea was General Douglas MacArthur.  MacArthur believed that great commanders could impose their will on their troops, and because of the greatness of the commander, the troops would be victorious.  But, by 1950, the troops had lost morale and were losing the war under MacArthur’s command.  When Ridgway arrived, his leadership model was far more egalitarian.  He wanted his men to find something special within themselves that made them effective as soldiers.  He felt that it would be the ability of the troops to find ways to be better soldiers that would make them effective, not their faith in him.  He truly believed that it was his job to help his men find that something within to make them the best that they can be.

So, how does any of this relate to Scrum and agile?  While I personally find Ridgway’s end goal distasteful, his leadership model as mentor and teacher, not commander, is a good model for agile leaders.  As ScrumMasters and agile leaders, it is not our job to mandate or command our teams to perform work.  It’s been demonstrated time and again that this is not effective, and can even be detrimental to otherwise productive teams.  Instead, it is our job to help our teams become the best that they can be.  We are there to help them find the qualities and practices that suit them best as a team.  We are not responsible for solving our team’s problems.  But we are responsible for teaching them how to solve their problems.  We’re responsible for giving them whatever they need to become self-managing, effective teams.  We need to become true servant leaders.

`

This chart doesn’t need a whole lot of explanation (and that’s why I like it so much). I think this chart can apply to every aspect of your life if you want it to. However, I see it as particularly useful for development teams on their agile journeys. When our team first started out, we hit home runs on our first two Sprints. We delivered everything we committed to. But on our third Sprint, we missed the boat big time! We could easily have said “We suck at this! We give up!” We could have become frustrated, dropped out and decided, we can’t do this agile stuff, it just doesn’t work. In that case, we’d have fallen below the Suck Threshold and probably have gone back to doing things the way we use to do them…waterfall.

However, after our third Sprint, we had a very thorough Sprint Retrospective to find out what was different. What did we do wrong in Sprint 3? What did we do right in Sprints 1 and 2? What did we need to change? Inspect and adapt…always. So, with our new found knowledge, we went on to a relatively successful Sprint 4. We continued on for another 6 Sprints, pretty much hitting our mark, but missing slightly on occasion. At this point, we could very easily have decided “Now that we can do it, we’ll just keep doing it the same way.” We’d have risen above the Suck Threshold and we’d probably keep completing our Sprints with relative success. But, if you’ve read my posts before, you know that our team doesn’t particularly like settling for mediocrity. I firmly believe, and so does our team, that we should always be striving to become better at what we do.

As a relatively young agile team, we’re still learning a lot about each other and how we work. But I love the fact that our team is constantly trying to push us to that next level…as a team. We’re always asking the question “Is there a better way to do this?” We are constantly inspecting and adapting. I think we’re getting closer to that Kicking Ass Threshold and becoming experts. But if I know our team, even when we cross that line, we’ll still be asking ourselves, “Can we do this better?” and I think we’ll always answer with a resounding “Yes!”.

There are plenty of large companies out there practicing agile in many different forms.  They all have components of what most would consider an agile organizational culture.  I’ve blogged about Netflix, whose CEO describes a culture of “freedom and responsibility” within their organization.  I’ve also discussed the strides Microsoft has made in terms of supporting their Patterns & Practices lab in their efforts to become agile.

Ken Schwaber points out the example of Google in his book Agile Project Management with Scrum.  Google sets aside time for Team members to pursue activities that are outside of their current Scrum Teams and that benefit the Google enterprise. Google gives team members 20% of their time to coalesce into interest groups where they can work together. This time can be spent working with peers in sustaining and enhancing their functional expertise, or researching and prototyping new ideas. Google developed Gmail this way.

An agile organizational culture has helped in successfully scaling agile practices across large distributed teams at Yahoo!.  Yahoo! is now 2 ½ years into its adoption of Scrum, and has upwards of 100 teams and 1200 people (and steadily growing) using Scrum in the US, Europe, and India. Scrum is being used successfully for projects ranging from new product development such as Yahoo! Podcasts, which was built by a distributed team split between the U.S. and India and won a Webby Award, to heavy-duty infrastructure work on Yahoo! Mail, which serves 250 million users each month around the globe. Most (but not all) of the teams using Scrum at Yahoo! are doing it by the book, with active support from inside and outside coaches.

The reason I’m listing these case studies is because they are remarkable companies, doing remarkable things by organizationally and culturally supporting agile practices.  I used them a few weeks ago at a company offsite meeting. I was trying to illustrate what agility looks like from a cultural and organizational perspective.  I was trying to demonstrate what it would take for our company to truly adopt agility and provide a supportive environment in which it could thrive.  However, a comment I received from one of my colleagues stopped me in my tracks.  “Sure it works for them,” he said, “they’re huge.  They can do anything they want to.  We can’t do that here.  We’re not Microsoft or Google!“  I was flabbergasted and didn’t know how to respond at first.  I am a firm believer that you can do anything if you put your mind to it.  I feel that way personally, and I feel that organizations should think that way as well.

I think that a fundamental failing of organizations today is a self-limiting attitude of complacency that seems to exist at many companies.  Striving for mediocrity.  “Accepting” our limitations.  “We can’t do that because we’re not Google”.  It’s easy for companies today to live in the middle ground.  Average companies, with average organizational cultures, producing average products.  As Seth Godin says, most companies “…smooth out the edges and go for the center“.  I can’t accept that.

My question back to the naysayers is “WHY NOT?“  Why not do something remarkable?  Why not change our organizational culture to become remarkable? Google, Microsoft, Netflix, Yahoo!… they all became successful precisely because of their ability to say “Why not?”.  They became successful because they understood the value of organizational culture. They provided an atmosphere for free thought and forward progress.  The decided not to live in the corporate middle-ground.  I’m not saying that every company can do what Google, or Yahoo, or Netflix has done, but we can certainly learn from them. We can learn to change our culture to support agile teams.  We can decide to do something different…we can become agile organizations.  If one of the key criteria for the success of agile adoptions is an agile organizational culture, then I’d like to propose its antithesis: One of the main reasons for the failure of agile adoption is organizational complacency.

We can learn a great deal from these brief statements, especially as it relates to implementing agile practices.  Although agile practices allow us to become very efficient, we must be sure to reap the true benefit of these practices by becoming extremely effective.  Scrum, by its very nature promotes effectiveness.  When we continually prioritize backlog items at the start of each iteration, we are increasing our effectiveness.  We are continually working on the most important items that get us closer to reaching our goal.    Backlog items that are unimportant or no longer relevant are eliminated, further increasing our effectiveness.  In addition, the inspect and adapt mantra of Scrum helps us become more effective (and efficient) as well.  By constantly reflecting on our practices and adapting them as necessary, we identify our inefficiencies and eliminate them.  By the same means we discover our strengths and exploit them to become even more efficient and effective.  Ferriss sums it up best by writing “What you do is infinitely more important than how you do it.  Efficiency is still important, but it is useless unless it is applied to the right things.”

On Wednesday, Dave Bouwman and I tuned in to a Webex presentation that Guy Kawasaki was giving entitled The Art of Evangelism. Guy is one of my favorite people to turn to when I need inspiration these days. He is the former chief evangelist of Apple and is currently the co-founder of Truemors and the managing director of Garage Technology Ventures. Guy’s message was so upbeat and inspiring. It made me want to get back into the saddle and start evangelizing Scrum in our organization again.

What did Guy say to make me snap back into reality? “The most important thing about evangelism is to make meaning. It’s easy to evangelize and get others to evangelize things that are meaningful…things that change the world, make the world a better place.“ I’d been so entrenched in making Scrum work for the sake of Scrum that I’d forgotten to make it meaningful to everyone in our organization. To make things meaningful, Guy suggests that we:

- Perpetuate good things

- Create good things

- End bad things

I needed to step back and start living those words. They fall right in line with Scrum practices and I needed to hear them again. I needed to get back to affiliating, creating, and associating myself and others with the good things that Scrum promotes. As Guy says “Great stuff is easy to evangelize. Crap is hard to evangelize.“ I sincerely believe Scrum falls under the great stuff category. Time to start evangelizing again…

If you want to watch the Webex of Guy’s presentation, it was recorded and is available at http://www.webex.com/web-seminars/view_recording/662851581.

One of the things I love about Scrum is that it treats team members like adults. Teams, not managers, decide what work they do in each Sprint and how to estimate it. Teams decide how to adapt their processes to maximize their efforts. Teams decide who the best person is to accept a task. Teams decide what the common goal is and they stay focused on it until it is achieved. We all get to act like grown-ups again. We all have a stake in the outcome of our process and we all have input into how we achieve our goals.  However, along with this flexibility comes responsibility; responsibility to the Team and to the Product Owner to deliver value and quality. For all of this to occur, an organization must have a culture that not only supports this kind of thinking, but also thrives on it.  The organization must foster a culture that respects individuals as intelligent adults who have a valuable set of skills.

I was reading an article in Business Week today about Netflix. Netflix has a very interesting culture that not only promotes innovation in the way people rent movies, but also in the way its managers and its staff work. The founder and CEO of Netflix, Reed Hastings, describes the culture there as “freedom and responsibility”. Netflix believes its culture is a fully formed adult culture. To that end, Netflix employees are paid above average salaries, have unlimited vacation, and can determine how to structure their compensation packages. In exchange for these luxuries, the folks at Netflix are expected to be über performers. The level of responsibility is very high for individuals within the company. The marketing director at Netflix says “There is no place to hide”. If you think this sounds a lot like a place that would embrace Agile practices, you’d be correct. Netflix has successfully employed Agile practices to create a website that has been rated by independent researchers as number one in the world for customer satisfaction for two consecutive years.

The whole Netflix culture is properly geared to not only support Agile software development practices, but also to recruit the best talent to produce the highest value and quality for its customers. While most companies go to great lengths to pay their best talent the least amount possible, Netflix does the exact opposite. They believe in building what their CEO calls “talent density” by allowing their talent hunters to recruit top managers, developers, etc., with the mantra “Money is no object”. In addition, annual salary increases are tied to the current job market; Netflix constantly amps up salaries to retain their best talent. H.L. Arledge at Decade Software has stated that “sometimes employees become dissatisfied because they fear they are not getting what they are worth or someone led them to believe that the grass is greener somewhere else.” Netflix has effectively removed this variable from their talent retention equation.

So, with an adult culture and a highly paid workforce, it’s almost inevitable that innovation, quality, and value stream forward from Netflix. One of the developers at Netflix describes the culture there as very much like the team in Ocean’s Eleven: They recruit the best of the best, everyone gets a good cut of the take, there is the flexibility for individuals to do what they do best, and the whole team stays focused and united on a common goal. So maybe that’s the key: every organization striving to be truly Agile needs a Danny Ocean at the helm. It could very well be that Ocean’s Eleven is the perfect Agile model.

Recently, our Scrum Team had an otherwise productive Sprint interrupted by just such a meeting. We were halfway through our Sprint when we received a Friday afternoon email about a mandatory all-hands offsite meeting of our entire group. Our V.P. had decided that the next Wednesday, we would all gather in Denver to discuss business strategy for the upcoming year. Yes…our development team was ecstatic to attend, knowing full well it was going to be chock-full of endless PowerPoints with lots of charts and numbers.

We decided to raise our voices a bit and protest. “It’s interrupting our Sprint” was the battle cry. No luck, that didn’t resonate. So I tried a different tack. “If you’re going to interrupt our work make it productive. If you’re not going to cancel the meeting, make it interesting.” Our V.P. perked up. He couldn’t fathom the fact that our development team wasn’t interested in charts, projections, revenues, etc. He immediately visited our office to find out why we were so upset. We gave a few reasons and suggested that the group offsite meeting should be about the great things his teams were doing. Make it a motivational meeting. Get the teams excited about their work. He left our office agreeing and made a change to the agenda. He even asked us to give a talk about the power of agile and our success with Scrum. We still didn’t want to interrupt our Sprint, but at least we thought this wouldn’t be a complete waste of time. We worked very hard for the next few days preparing a killer presentation about Scrum and how it could benefit the whole organization, not just our team.

We arrived in Denver at noon. We were sixth on the “revised” agenda. The offsite meeting started late. The first speaker was our HR rep. Not very inspirational, but she kept it short and sweet. Next up was our V.P. He talked for about an hour and a half about things that he thought were very important (he was slated for only 30 minutes on the agenda). Lots of charts, numbers, and broad, sweeping statements. Next up was one of our senior product managers. Lots more charts, lots of numbers and all completely meaningless. In fact (and I must share this classic Dilbert moment with you) at one point, someone asked where his numbers had come from. His answer was literally (and I quote) “Ummm…from a matrix…in my head”. After an hour of this babble (slated for 30 minutes on the agenda) he finally sat down. The R&D pitch was next. It was a little confusing as our R&D guy had started his job about 1 week prior to the meeting. He ran over time as well. At 3:50 PM in a meeting scheduled to end at 4:00, our CEO strolls in and delivers the most lackluster presentation of the day which ends promptly at 4:20. The meeting is called to an end and we never got to deliver our Scrum presentation. The team was incredibly disappointed and couldn’t believe we spent a whole day in a useless meeting.

When we sat down for our Sprint Retrospective, I asked how disruptive this offsite meeting was to the Team. Aside from the obvious waste of valuable time, the Team agreed that the meeting was indeed disruptive to their work. Some of our developers were deep into solving some complex problems and had to divert their attention to attend the offsite meeting. Our lead architect and I were also distracted as we had to entertain our V.P. for the entire time he visited our office, and we had to work on preparing our presentation (which of course we never got to give). The day following the offsite was difficult as well as most of the Team struggled to get back into the flow of their work. We were tight on time and some of the developers put in time on the weekend just to finish their coding for the Sprint. The morale of the office was down as well. Team members couldn’t believe that so much time was wasted with such flippancy. In the end, we ran out of time in our Sprint and weren’t able to adequately test what was developed. We had sacrificed quality for the sake of a useless meeting!

The takeaway message here is really for those who manage Scrum teams and it is very simple: Don’t disturb your Scrum Team mid-Sprint unless it is absolutely essential. The work of the Sprint is very important and it is providing value to your customers. If you are going to disturb your Scrum teams, you had better have a very good reason to do so. If at all possible, schedule your disruption well in advance so your Teams can plan their Sprint tasks around your activity. From the story above, it should be evident that unproductive interruptions can have a negative impact on performance, quality, and morale.

The message for ScrumMasters is equally important: If managers cannot justify the importance of these time-wasting activities, don’t interrupt your Scrum Team during a Sprint. This is easier said than done. Our managers can exert undue pressure on us to mandate participation in these activities. The best thing to do is to make them very aware of the consequences of their actions. In fact, if they insist on disturbing the Team, it is probably beneficial to demonstrate the impact of their actions post-Sprint with hard facts so they have tangible evidence of their impact on quality and performance. As a last resort, you may want to give them a gift-wrapped copy of Scott Adams’ excellent book Always Postpone Meetings with Time-Wasting Morons.

A chicken was talking with a pig about how good their farmer was to them in the way he provided shelter, food, and protected them from danger. The chicken thought it would be a nice gesture to show their gratitude to the farmer by serving him a breakfast of bacon and eggs the next morning. The pig thought about it for a while and then commented, “Let me see if I have this right. We are going to provide the good farmer with a breakfast of bacon and eggs. I think I’ll pass on the gesture.  As I see it, you will only be  involved in the project, while I will be committed to it!”

The Pigs are the members of the team that are committed to the project at a very high level.  The Chickens are anyone outside the Team who have somewhat of an interest, but are not committed to making things actually work.  It’s alright to have Chickens involved, but they must do so more as observers to the process than as active participants.  They can muddy the waters and sometimes even obscure the voice of the Product Owner.

Case in point:  We recently held a Sprint Review Meeting with one of our Product Owners.  We decided to invite some other folks from our organization and from a subcontractor’s organization…a few Chickens.  We thought it would provide insight into what we were developing during that iteration.  We generally timebox our intermediate Sprint Reviews to no more than 1 hour (we do 2-week Sprints).  As the development team began demonstrating our new functionality, numerous questions and comments began to fly…not from the Product Owner, but from our Chickens.  The questions involved some misunderstandings about the functionality that was developed, and then degenerated into a criticism of the demonstration itself, all with the Product Owner in the background.  As the ScrumMaster, I tried very hard to reduce these comments, explain the purpose of the Sprint Review and get back to the demos and client feedback.  No such luck.  The questions and comments kept coming.  It was nearly the end of the hour and we still didn’t have a chance to really hear from the Product Owner.  When I finally asked the Product Owner for feedback on what was demoed, he was very quiet and offered minimal feedback.  The clucking Chickens had derailed our Sprint Review.

Now, some of the points the Chickens were clucking about were good ones.  Other points indicated a general lack of understanding of the Scrum process in varying degrees.  The day after the review, I tried to help them understand what had happened.  Of course, most of the Chickens agreed that the other Chickens needed to stop clucking so loudly.  I made the point again, stating that all of the Chickens needed to stop clucking. I put some ground rules into effect for our upcoming Sprint Reviews.  While the Chickens’ comments were welcomed, they would have to wait until after the Sprint Review to express them.  The Sprint Review meeting was to focus on demonstrating the new functionality and soliciting feedback from the Product Owner.

As ScrumMasters, we must ensure that the simple Scrum rules are followed.  We must ensure that free, open, undisturbed, and unadulterated communication occurs between the Team and the Product Owner.  Sometimes this means that we need to step up and quiet things down if the noise from the Chickens begins to overwhelm the Product Owner’s voice in the project.  Remember, when it comes down to it, the Product Owner and the Team are the ones getting the work done.  They know where the project needs to go.  They know that it’s up to them to maximize the return on investment and produce valuable products.  The Chickens (as good as their intentions may be) can be a distraction.  Their clucking can sometimes guide us down the wrong path and lead to wasteful development efforts.

I recently attended a short-list interview for a large county government GIS contract. We were in the top three vendors selected to compete for the contract. Dave Bouwman (our lead architect) and I were asked to provide input on our software development practices. We had a few slides about our development environment, a few on our relevant project work, and one slide on Scrum. The Scrum slide had no text, just a diagram illustrating the Scrum process that we borrowed from Mike Cohn at Mountain Goat Software (we like being lean and like to talk more about processes than try to put them on great big slide presentations). When I got to the pre-interview walk through of the team’s presentation, the Scrum slide was conspicuously absent from the main presentation. In its place was a very impressive looking program and software development workflow diagram. Lots of boxes with labels like initial concept discovery, statement of work, draft work order, kickoff, work execution, testing, acceptance, and closeout. They were all lined up with nice little arrows connecting them in the traditional waterfall fashion. At punctuated, pre-determined points along the waterfall, there were other boxes representing where we would have contact with the client. The only contact prescribed for the client during the work execution was for program financial status and schedule status.

I asked where in this melee of boxes on the flowchart our Scrum process fit. The answer I got was “Oh, in the work execution box of course’. Wow!!! I couldn’t believe what I had heard. The whole thought process was that Scrum was just a little development process that worked inside the larger project management framework…just another little cascade in the larger waterfall. This program would have multiple projects running at one time, all working in a waterfall framework, with only the work execution “boxes” utilizing Scrum to develop software. For all of our hard work, we still hadn’t convinced the management team that Scrum was an entire project management process. We had been talking about Scrum as an overarching process for everything for months now. We had been emphasizing not only client communication, but very active client participation in the Scrum process, not just project financial/schedule status reports.

Fortunately for us, we had a set of backup slides with our Scrum process diagrammed out. The interview panel asked how we would manage our projects and I was able to show the slide and give them the Scrum elevator speech. They were interested in how Scrum would provide them valuable, useable software in a relatively short period of time. They asked several follow up questions and were genuinely interested in the process. Our senior manager on the interview team backed our Scrum play and added some good insight into how our GIS development team was effectively using Scrum on other large scale projects as well. However, he took the default position of saying that whatever suited the client, be it Scrum or a more traditional waterfall approach, we would provide it. He wasn’t being a jerk. He was just trying to sell our services and I understand that.

The point of all this is that it is very difficult to break the almost institutionalized acceptance of the waterfall approach to project management. Agile methodologies and Scrum in particular are scary to most people. Some mistake its relative simplicity for inadequacy in terms of project reporting and project management. Some underestimate the value of the iterative approach and the inherent increase in client communication and satisfaction that it provides. Most are just pre-conditioned to believe that if we don’t understand everything up front, we can’t run a successful project. So, I’m not upset with our management team. I know why our Scrum slide turned into a little box on the larger waterfall slide. They believe Scrum is truly just a software development methodology that fits neatly into one of their waterfall boxes. However, Scrum is a powerful project management process that works for many types of projects. I know of people in other industries using Scrum for anything but software development. I met a woman at a training class a few weeks ago who is using Scrum on real world construction projects for large hospitals. I’ve even heard of people using Scrum to plan their weddings.

So, keep selling Scrum to your management teams. Keep educating them. Keep correcting them when they get it wrong. But do it in a manner that helps them to understand and accept Scrum over time. It’s our job as practitioners of Scrum to help others understand the process as more than just a software development methodology. We need to become Scrum evangelists of sorts, bringing the real message of the efficiency and value of Scrum to the non-believers.

On our flight home after the short-list interview, I referred our manager to Ken Schwaber’s book Agile Project Management with Scrum. I also handed him a whitepaper called A CIO’s Playbook for Implementing Scrum by Rebecca Traeger (available from the Scrum Alliance website). He’s coming around slowly. Before we took off, he commented that he see’s the value in Scrum, “It’s basic common sense. How could it not work?” In my head I thought, “It’s basic common sense, how could you still not get it?” Instead, I just smiled and said “Yup, you’re right!” and kept my hope up that he’d actually read the whitepaper and the book someday.