I was talking with a friend the other day about Agile and her response was “we’re so crazy busy these days, I can’t imagine trying a new method of work”. We talked about this for a bit and I think it got her interested. With the current economic crisis, I think it is a perfect time to pause and reflect on how you develop your products. Are you getting what you want? Are your cycle times short enough that you can get new products to market fast enough to capture the limited money that people or companies are willing to spend? Are your employees turned on and engaged? Are you able to react effectively to the volumes of new legislation being written to respond to the crisis? Are you able to say that you have your portfolio of investments under control and you are investing in the right things?
A crisis is often one of the easiest times to make an organizational change. People know that something must be done and are less likely to cling to the status quo. Yes, it does take an investment to make a change, but perhaps less of an investment than it does during good economic times. In good economic times, people say “hey, we’re making a lot of money, we must be doing something right, why change”? In that environment, change can be very difficult.
Perhaps some our business results over the past few years have been good because there was so much capital being dumped into the marketplace due to the artificial inflation of property values. Maybe there was so much money, it was simpler to be successful. Well that isn’t the case today. It is difficult to succeed. And maybe it is time to retool some of those processes we thought looked so good when making money wasn’t as hard.
Agile is a resilient and rigorous process for building products that accommodates learning and changes as you go. It give you the ability to build high performance teams who focus on building the highest-value product features. It cuts cycle time and it cuts waste.
The sections that follow discuss the current conditions in more detail and expand on why now might be the time to start using Agile in your organization.
New Products are Needed to Capture Market Share
Hammered by the recession, some of the nation’s biggest retailers are seizing the moment to reinvent their business strategies. And the impact will mean both sweeping changes in the merchandise on their shelves and subtler alterations… Stephanie Rosenbloom, New York Times, June 19, 2009
It is a tough time to be in business. If you sell something that that was nice-to-have, you’ve probably noticed you customers deciding to do without it. High-end products and services are being passed over for lower-cost alternatives, or simply not being purchased at all. Perhaps your Software as a Service product was doing well at $49 per seat per month, but now it isn’t. You could simply offer the service at a lower price to see if that helps, or you could introduce a new product, with less functionality, at a lower monthly cost. Some experimentation might be needed to find the right mix of products that retains customers who were leaving your platform while continuing to capture the premium price from customers who want and are willing to pay for the full offering.
Experimentation to find out what sells is essential and Agile is a process that is conducive to experimentation. An Agile principle is to build working software in iterations lasting from one to four weeks. Since you regularly have working software, it is easier to put potential products in front of potential buyers to get feedback. Not prototypes or mock-ups, but real working products. Waterfall processes typically result in working software near the end of the project life-cycle and showing changes to customers on a regular basis, and making changes based on their feedback, is simply harder to do.
If you want to outmaneuver your competition, you need to have a shorter cycle time bringing products to market, and Agile is an ideal method for cutting cycle time.
The Need to do More with Less
Companies are reducing their staff. According to the Bureau of Labor Statistics,
The national unemployment rate in May was 9.1 percent, not seasonally adjusted, up from 5.2 percent a year earlier.” There are fewer people to do the work, and there are often skill gaps brought about by layoffs.
In many companies there is the desire to make progress on many fronts leads to too many projects simultaneously underway without the critical mass necessary to make meaningful progress on any. The problem is worsened by the silos of work, and the complexity of handing work between silos that requires complex and comprehensive documentation. The waterfall method of product development, as traditionally practiced, wastes people’s time.
Agile teams, on the other hand, are cross-disciplanary, with full-time staff. The waste associated with handoffs is limited because people are working side by side, not in silos, without the need for elaborate documentation.
In our experience, dedicated product teams do no need to be nearly as large as traditional managers would predict, and the smaller they can be kept the better all around. A host of narrowly skilled specialists are not needed because most marketing, engineering, purchasing and production professionals actually have much broader skills than they (1) ever realized, (2) ever admitted, or (3) have ever been allowed to use. When a small team is given the mandate to “just do it,” we always find that the professionals suddenly discover that each can successfully cover a much broader scope of tasks than they have ever been allowed to previously. They do the job well and enjoy doing it. (Womack, James P., and Daniel T. Jones. Lean Thinking, Banish Waste and Create Wealth in Your Corporation. 2003 ed. New York: Free Press, 2003. Print.)
While it is culturally very challenging for companies to commit to working on fewer simultaneous project with dedicated staff, it is a much more efficient way of working. Companies who make the change will get more done with less.
You Need to Invest Your Limited Funds Wisely
Agile enables you, iteration by iteration, to determine how you want to use your capital and your people’s time.
When you have to full specify all of your requirements up-front, it is likely you’ll be investing in writing requirements, designing and building things that should never be developed. Some ideas for the new product will be the most important ideas, the ones that will capture new customers or meet a regulatory need. Others will be less valuable, some a complete waste of money. The problem is that at the beginning of a project is when you know the least about what you want – you learn a lot when people get hands-on with working software.
In a waterfall project, once the requirements are agreed-upon, the most important and least important features are handled in a similar manner. Contrast this with Agile – the most important ideas, the most valuable ideas – receive the earliest attention of the product development team. At any point in the life cycle, you can discard requirements that are no longer considered valuable or add in requirements that you didn’t know or think about at the beginning of the project.
With the limited amount of money you have to invest in product development, Agile is a good method for making the most of your investment.
New Legislation Demands new Products and Product Upgrades
When there’s a crisis people expect their elected officials to do something about it. That something is usually in the form of new legislation, programs and funding. Right now, there are a lot of things going on that people would like fixed, including unemployment, affordable health insurance, foreclosures, the credit crisis, corporate abuse, terrorism and wars.
When legislation comes out, business have to respond in accordance with the legislative timeline. In organizations following a traditional waterfall product development process, legislation often leads to tiger teams, formed by pulling people off of existing strategic projects. The rapid switching between strategic initiatives and tactical response to legislation can sap an organizations capacity for work. When people are pulled off of a strategic initiative, the remaining staff often lack the critical mass to be effective.
For a Agile teams, legislated changes can simply be though of as changes to the product backlog. Instead of working on features from the product roadmap, stories associated with the legislation are added to the backlog near the top of the list, depending on the timeframes required. The team stays intact. Critical mass is maintained.
Your Employees are Scared
Lack of direction and the fear of being laid-off are both sources of anxiety. Anxious employees spend time speculating which people, products, project and business units are going to be cut. It is a natural reaction, but it doesn’t add a lot of value to the company. When LinkedIn becomes a top destination site for employees, there’s probably not much great product being built.
Prior to the current recession most companies had a strategy in place for how they planned to grow the business, address competitive pressures, manage costs and introduce new products. The strategy certainly wasn’t static, but it had a reasonable shelf-life. With the recession many companies have been forced to go through a radical rethinking of their strategy, discarding significant pieces and undergoing significant reinvention.
To an employee, the way that looks is that the senior team and many of their reports disappear for days, weeks or even months of re-planning. Normal meetings are canceled. Communication flow drops. Project sponsors say “keep going, what you are doing is important”, but they are not making their time available to the project team, sending the message that the project may not be all that important.
Reorganization during these times are common. Layers of managers are eliminated. Staff is eliminated. Often the reorganizations are incomplete, having been hastily through through and executed, leaving the normal flow of work in disarray.
Face it: your employees are probably scared, demotivated, uncertain about their job, their career, their future and the company’s future.
Adopting Agile is a way to reinvigorate your employees and get them focused on doing something that may enable them to retain their jobs – building products that customers will buy. In my experience, teams adopting agile rediscover their interest in their work. I’ve hear a number of people say “I’m excited to come to work every day”.
Instability Enables More Rapid Change
When you try to make an organizational change during ordinary times, when there isn’t a crisis, you have to work through the all of the structures the organization has put in place to maintain the way things are done.
Bureaucracy exists for a purpose. They are a conservative force in the sense that its job is to conserve, or reenforce, the values, structures, processes and standards that are perceived as enabling your company to survive. Bureaucrats’ job is to support the bureaucracy – your company hired them for that. Bureaucrats, because they are human, are also concerned about maintaining the status quo because it helps keep their jobs intact. When you try introducing change into an organization, you are challenging both the bureaucrats themselves and the institutions they were hired to support.
In his book Presence Based Coaching: Cultivating Self-Generative Leaders Through Mind, Body and Heart, Doug Silsbee writes:
The deep biological needs for self-preservation, adaptation, and conformity tend to habituate us, rather than accelerate the development of ways of being that are responsive to the emerging political, economic, social, and natural environment.
The value of a crisis is that it makes it somewhat easier to introduce new behaviors than it would be normally, when it becomes clear to people in the organization that survival is not guaranteed by following the well-established path. Note that motivation to change (in this case, fear of survival) is a necessary condition for change but it isn’t the whole story.
Your organization will respond to the economic crisis one way or another. For those that view this time of crisis and an opportunity, introducing Agile may help you build new products faster, better meet customer needs, increase your revenue, respond rapidly to changes and empower your employees.
I’m in a quandary and I could use the help of other Agile consultants to think it through.
I have a personal statement that I use to guide my actions. Here it is:
“I’m committed to people experiencing joy, self-expression, partnership and accomplishment in their work”.
When I’m trying to decide what I’m going to work on and who I’m going to work with, that statement of purpose is the filter I use to help me determine the best way to proceed. The reason I got started with Agile is that I believe that work is dramatically better for people in organizations where Agile is practiced. I think Agile holds the possibility of transforming the nature of work.
Here’s the quandary. If I fully operate consistently with this commitment, I’d offer all of my material up for other consultants to use in their client engagement. Assuming I have something to offer, that would help the spread of Agile. On the other hand, I feel like I need something to distinguish myself. I’m new to the external consulting world and hardly anyone knows who I am (I was an internal Agile consultant previously). If I give out everything else for others to reuse, am I going to give up some specific value I might add that could lead to work?
There’s another part to the quandary. I know I’m a lot smarter when I’m thinking together with others, so the more I work by myself, the slower I go. Is this a case of the “rising tide lifting all boats”? Will aggressive, open sharing enable a more rapid pace of Agile deployment?
So what about Open Agile? Would it work to have a place where people could share and improve upon each other’s work? Who would put their materials there? Why would they? What virtuous cycles would cause this idea to grow? Alternatively, what cycles would cause this idea to simply die?
How about you? Would you contribute? If yes, under what conditions? What would keep you from contributing? Would you give your leading edge stuff, or only things that were pretty much common practice?
Your feedback would be very much appreciated.
If you’re an Agile evangelist within your company, you’ll need the help from a diverse group of people across the organization to have your Agile deployment be a success. If they don’t see the value of Agile, and how it connects to them personally, they won’t help you. With the volume of things competing for their time, you need a compelling, tailored, message at the organizational and individual level to get heard. Having a generic “why Agile is great” presentation won’t likely get you the level of buy-in you need.
This post discusses how to go about tailoring that message.
Connect Agile’s Benefits to your Company’s Priorities
Most good company have published priorities that are periodically reviewed and updated.
Showing someone an Agile presentation and talking about the benefits without referencing the overall company strategic and tactical priorities will simply make it harder to get support. Saying that Agile is “better, faster, cheaper” may not be enough to cause a company to be willing to go through the often-painful process of cultural and process change. You could implement Agile, but you could also try Six Sigma or Lean. Saying that Agile is a general get-better remedy puts it in line with many other get-better methods.
If you can refer to a specific business issue and show the linkage, you are much more likely to get a receptive audience. Here’s an example.
“We’ve been losing market share on our social media platform. Frankly, our last two releases have looked like me-too updates, where we are just barely keeping up with our competitors. People who’ve been committed to our platform have started to lose confidence and are looking at other vendors. If they don’t see a meaningful update from us, at least once a quarter, we’re going to get kicked out of the game. We’ve all acknowledged that as we’ve gotten bigger, our processes have become more cumbersome and now is the time to do something about it. Agile will give us the ability to regain that rapid pace of delivering innovations to market that we were know for in our early days.”
The focus isn’t on Agile, its on business, as it should be.
If you want to be an effective change agent, you need to have a thorough understanding of the company’s priorities and speak to your audience from there.
Use Focused Messages for Key Individuals or Groups
At the organizational level you need a certain volume of people who are enrolled in the idea of Agile before you’ll see adoption start to accelerate, but you primarily need to connect with individuals and groups of similar people (e.g. developers, product managers). When you need a dedicated test environment for your project, the whole organization isn’t going to build it; someone in the environments group will. If they don’t personally understand what your are trying to do and support it, you are just another person with a request that will increase their work load and possibly increase their department’s costs.
People have specific needs in their role and they want to understand how Agile will affect and benefit them directly.
For example, the CFO wants to make sure that the company is spending money on the right things and getting good return for the money spent. He or she also wants an effective mechanism for managing risk: if a project is going awry they want it to be fixed or eliminated before it wastes too much of the companies money.
Developers, on the other hand, probably wants to know if they will have interesting work, the opportunity to learn new things and the ability to make an impact on the company’s products.
And a QA manager is probably interested in hearing how Agile helps enrich the QA profession.
The CFO, developer and QA manager have different roles in the organization and their needs are different. If you want to enlist their support, be sure you know who you are talking to and what they value.
The easiest way to find out what interests someone is to ask them. When you meet, leave plenty of time for talk. Motoring through a well-rehearsed Agile presentation usually doesn’t work. A lot of times I’ll have slides with me, but they are a backdrop for the conversation. I’ll refer to slides when it helps move the conversation along, but otherwise don’t use them. You might want to forget slides altogether and just draw things on a whiteboard as necessary. This technique is particularly useful with an individual or a small group.
Take it One Step Further: Collect Data to Gain Insight
When you are going to be transitioning a large group or an entire organization to Agile, you’ll be most effective tailoring your message if you invest some time conducting data through a series of structured interviews. This is a fair amount of work, but well worth doing.
First, you’ll need a small set of questions prepared for the interviews. Here are some examples.
- What is working with our current methodology?
- What’s not working with our current methodology?
- How do you think Agile would help our organization?
- What concerns do you have about Agile?
Send the questions in advance to the people you are planning to interview so that they have time to think about them.
Interview a wide range of people: developers, testers, business analysts, managers, product managers, senior management, project managers and someone from finance. To really understand the company, it helps to view it from many varied perspectives.
When you conduct the interviews, it is good to have one interviewer who has the primary responsibility for talking and the other person who has the primary job of taking notes. You can switch off roles each interview so no one person gets stuck in either role. Here’s how I typically start off.
“Thank you very much for taking the time to meet with us. We’re trying to understand how Agile will fit in this organization, so Greg and I are doing a series of interviews. For this interview I’ll be doing most of the talking and Greg will primarily be taking notes. We want to make sure we do a good job capturing what you have to say. The interview is confidential and we won’t connect you to any of the comments when we compile and share them later. We’re trying to identify common themes across the organization. Is that all OK with you? Do you have any questions before we get started?”
Remember that this session is intended for information gathering. If questions about Agile come up, certainly answer them, but don’t forget to gather the data.
Pay particular attention to the stories that people tell about the organization and make sure you write them down. Which of the following two statements do you find more compelling?
“Developers have a hard time getting the information they need.”
“One developer was trying to get the right set of items for a list of values. He was forbidden from talking with the business person who knew the answer and had to go through both a systems analyst and a business analyst. It took him two attempts and three weeks of elapsed time before he had his answer.”
For me, it is certainly the second one. People will give you real, specific examples in the interviews. Write them down with as much detail as you can.
Once you’ve gotten all of the data from the interviews, organize it to look for common themes. There are several ways you can do this. I put all of the information we’d gathered into a mind-mapping program (Mindjet) and grouped like things together. You could do a similar exercise with post-its. Be careful not to lose the unique character of the information you’ve gathered by over-summarizing. Make sure you keep interesting stories intact. Specifics will help you make your cases
Using the Data
The purpose of the interviews are to gain a general understanding of the issues being faced by the organization today with the current development methodology and how Agile might help. Use the information as you design your presentations. I generally have numerical data behind my presentations, but usually leave it off of the slides. When there’s numerical data, people engage with a presentation in an entirely different way than they do when there are stories. I find stories more effective, but do what works for you.
Here are a couple of sample slides I had to put together for a presentation. I had interviewed over 20 people, complied all of the data into a big affinity diagram and pondered it for hours with colleagues, but this is all I put in the slide deck. The heart of the presentation were the stories I told based on the interviews, not just on these slides but elsewhere through the presentation.
Note: I don’t say “these are the problems we face as an organization” because the people I interviewed my not completely reflect the views of the audience, and I don’t want to get into a debate early-on in my presentation. Instead I say “this is what we heard from the people we interviewed.” If we’ve done a good job selecting the interviewees, the message should resonate with the audience.
In the late 70s hitchhiking was my primary form of long-distance transportation (including a trip form Albany, NY to Champaign, IL in the winter). When you’re hitchhiking, the goal is to get to your destination with the fewest number of rides and the least amount of waiting and discomfort. I learned I got better rides if I talked about things that were of interest to the person who picked me up. Instead of dropping me off on an unlit stretch of road, they’d go out of their way to leave me in a better position for my next ride.
As an Agile evangelist, you job is to get Agile deployed effectively. Along the way there are many people will be willing to go out of their way to help if you effectively speak to their interests and concerns.
Many companies who have had formal Software Development Life Cycle processes are now making the transition to Agile software development methods. Because these organizations are used to a great deal of process formality, they may be tempted to define a rigid process for Agile, but to do that is to miss the point. Agile is inherently a learning process where experimenting and improving process is a core principle. Being agile vs following a rigidly prescribed Agile Process will enable a company to be be more resilient in the face of change, and in today’s environment change is happening at a very rapid pace.
What Does it Mean to be Agile?
Let’s start with the Wiktionary definition:
So what’s an agile organization? First, there is the ability to quickly notice and respond to something, be it an opportunity or a threat. But I think think the definition of organizational agility needs a little more, because a reactive organization can respond quickly, but often inappropriately. So how about this?
Organizational agility is the systemic ability to rapidly notice and effectively respond to emerging ideas and situations.
I added the word “systemic” because I think an agile organization, is agile at all levels of the organization, from front-line worker to CEO. Consider the Ritz-Carlton hotel.
The Baldridge Award-winning Ritz-Carlton hotel chain empowers (and even encourages) any employee at any of its properties to “fix” any guest problem on the spot. Employees are empowered to implement or create any customer satisfaction solution that will cost under $2,000. Ever stayed at a Ritz-Carlton? The commitment to customer service radiates from every employee.
The top management team can’t be everywhere, seeing everything and responding to everything. It takes the whole organization to be agile.
Why Do Companies Want to Become Agile?
Companies often become interested in becoming more agile when they notice that they aren’t getting what they want out of their current processes. They find that it takes too long to get an new idea funded and too long to get a product to market. They are over budget and under delivering.
Agile product development practices are seen as a way to become more agile, so they are brought into the company, usually using a pilot project to see how they work. Often the pilot will be quite successful. The team is excited, the market folks are pleased with the fast turnaround, silos are broken down and collaboration rises.
And then someone says “this is great”, let’s write the process document for exactly how Agile works, and have everyone follow it”. Unfortunately, that way of thinking can take the company away from the agility they were trying to achieve by bringing Agile into the company in the first place.
The Inherent Conflict Between Agile and Rigid Process
Human beings design processes based on their experience.
“Hmm. The last guy that went into the woods over there got mauled by a bear. Maybe I won’t go that way.”
“We need to keep people from getting killed by the bear. Let’s put up a sign to keep people from going on that path.”
We figure out things that work and don’t work and try to make use of that knowledge productively in the future. Nothing wrong with that. Particularly if we keep using new evidence to modify the process over time.
“OK, so Bill, Mary and Yoko all sneak down the path every day, ignoring the sign. It has been five years since someone got mauled by a bear going that way. Maybe the bear died or went somewhere else. The path is, frankly, the fastest way to go. It is probably OK to take down the sign and let people walk that way again.”
When we start to believe in a process and no longer pay attention to reality and adjust the process when it needs adjusting, we get into trouble. Most of the stifling processes we force our employes to follow originally had a good reason for being created, but the processes weren’t updated when there was new information.
So the intent of building a rigid process – to reliably and repeatably get a good result – is fine, but in reality, it doesn’t always work. In fact, Meg Wheatley and Myron Kellner-Rogers argue that stability arises when an organization has the freedom to regularly experiment to find what works.
If we do not exercise that freedom to change, the organization cannot maintain its stability. … Stability is found in freedom – not in conformity and compliance. We may have thought that our organization’s survival was guaranteed by finding the right form and insisting that everyone fits into it. But sameness is not stability. It is individual freedom that creates stables systems. It is differentness that enables us to thrive.
This need for flexibility might be particularly true today, with the incredible rate of change brought about by the severe recession and the rapid introduction of new legislation intended to combat that recession.
Why do People Follow Bad or Out-of-Date Processes?
The simplest reason is because the organization they are a part of reenforces and rewards following the process. People are asked to write status reports based on the process, show process documents to get approval to the next stage of funding. Additionally there may be formal process audits. Doing something other than following the process is difficult.
Note: people sometimes take actions that make it seem like they are following the process, while following a different, often more effective, process in the background. This is obviously wasteful. But when processes don’t work, or work very poorly, it is often the only way to get things done.
Is this Empowerment Thing Real?
Having been managed to a set of formal processes for years, people are usually hesitant to try new behaviors. After years of being to what to do, the idea of being a self-organizing Agile team is pretty unusual. People will be watching the management team to see if this newly-granted empowerment is real. The slightest hint that it isn’t for real is likely to drive people back to the familiar ground of following instructions.
If the agile culture change is successful, you’ll notice that people being agile – observing what’s going on and rapidly adapting to the changing circumstances.
Advice for Companies who Like Formal Processes
My advice is to do the least amount of standardization of the Agile practices as possible, trust your people, and to adapt the existing organization to support Agile instead of having Agile adapt to the organization. If you really want an agile organization, you’ll have to let go of some of the formality that you’ve had in the past. If you try to standardize too much, you risk losing the benefits that had you adopt Agile practices in the first place.
There are a few areas that commonly require a little adjustment, status reporting and project funding are two common ones.
Take status reporting as an example. Organizations that follow a waterfall methodology will typically report progress against each of the phases of the project (requirements, design, development, test etc.). To ask an Agile project to report against these milestones doesn’t make sense, and it sends a very strange message to the team. “We want you to be curious and resilient if the face of change. We have no plans, however, to do that ourselves”.
Let Agile teams report using standard Agile means (e.g. a burndown chart) and waterfall teams report using their normal means. It may take a bit of explaining for a company president or product manager to understand what they are looking at, but only a bit. Once people understand Agile, they’ll realize they have very high-quality information on the status of projects.
Funding is another place where there may be a need for new process. Some organizations require approved documents to move from one stage of funding to another. Instead, consider having your unit of funding be for three-month releases, where something is delivered into production. That’s really pay for performance.
If you’ve decided to become an agile organization and adopt Agile practices, give the new culture the care it needs to flourish. Live with the discomfort and uncertainty of looser processes than you are used to. Standardize on the least number of new processes you possibly can. You’ve hired great people. Give them room to breathe. Let them be great.
If you’ve made it this far, thank you! If you have a moment would please leave a comment? I’d like my blog to be as helpful as possible.
If you are an Agile evangelist within a company, you probably spend (or will spend) a fair amount of time talking with people across you organization about Agile and its benefits. When I was in this role I ran into a full range of responses from heated skepticism to full embrace. Having the opportunity to talk with hundreds of people provided me with a wonderful laboratory to see what worked and what didn’t. Here are some of the thing I learned.
Understand and Speak to your Audience’s Frame of Reference
I found that I was significantly more successful, unsurprisingly, when I put more of my attention on my audience’s perspective than my own.
When you are talking with a group about Agile, the people in you audience have probably worked hard to get where they are, and they have a level of pride and attachment to who they’ve become. Almost involuntarily, they are comparing what you’re telling them to their view of the world to see if it fits. If you are not speaking to them with an understanding of their issues and values, you may not be very successful.
You’ll be particularly unsuccessful if you directly threaten their position in the organization and the things that they value.
Here’s another example. Imagine you are speaking to a group of mid-level managers about Agile and you say:
“With Agile, it’s all about the team. Self organizing teams who determine their own work process. We break down the rigid silos and get much better results.”
My guess is they’d be threatened, think you are dangerous and would trying to figure out how to get you escorted out the door. You’ve practically said “sorry, what you do isn’t valued, there’s a new way that’s better.” Not the result you were looking for.
Here’s an alternate approach.
“Organizing work in a complex organization is a challenge. As a group we’ve risen to that challenge effectively in the past. Yet we’re in a recession and we’re being asked to respond even more rapidly to a constantly changing world. There’s enough evidence to indicate that Agile may be a powerful new process for our company. It is an uncertain path. We don’t know if it will work for us and what the long term implications are for our structure. But we’ll take one step at a time. We’ll experiment thoughtfully, discuss the results together and collectively decide how to proceed.”
There are a few important things here:
- You are acknowledging them for what they’ve contributed to the company.
- You are honest about the uncertainty.
- You’ve let them know that they will have a role deciding how to proceed in the future.
Before you make your pitch, think of the people who will be in the audience an how your message might be received. Do your homework first. Figure out in advance which people in the audience are most likely to help or hinder your cause, and set up some time to meet with them individually whenever possible. In these individual meetings, listen a lot and talk very little. Find out what is important to them, what they know about Agile, what they think it might offer and what concerns them. Use that to shape how you talk with the group.
When something comes out of someone’s mouth that sounds like an objection, consider this important data. If you don’t effectively address the concern, you might not get the opportunity to proceed.
Cognitive scientists have demonstrated that 20% of what you hear comes from the other person and 80% is what you fill in with things from your own perspective. You are at an enormous disadvantage when you are really trying to understand what another person has to say. But understand you must if you want to be an effective change agent.
Have Room For Your Audience to Say Yes or No to your Proposition
My preferred approach to discussing Agile with a new group is to let them know clearly that they are in charge and that any decision they make is up to them. I describe the challenges that other organization have seen that have led them towards Agile, and then ask if they face the same challenges.
If some items resonate, they’ll usually want to talk more. If a lot of things resonate, they may ask how they can proceed.
This I found to be far more effective than attempting to sell Agile. When the only answer I’ll accept is “yes”, my audience’s instinctive reaction has be to try to protect themselves and we end up in a tussle.
For this process to be effective, I have to OK if the groups says “no thank you, this isn’t for us”.
I also have to be clear about what will work and will not work. If a group wants to try Agile without product owner, or without a full-time team, I simply let them know it won’t work, why it won’t work and suggest they not try.
The Connection to Pigs and Singing
In the early 80s, I was given a rubber stamp as a “present” from my boss and a peer. On the stamp was a quote from Robert Heinlein: “Never try to teach a pig to sing; it wastes your time and it annoys the pig.”
Their point was that I was wasting time trying to change people into something they weren’t and had no interest in becoming. These days I try to avoid the temptation (although it is still there), put the attention on my clients, on their issues and let them choose.
If pigs are singing around me, it’s because they want to.
There are two Kristyns. The first worked at a large, well-respected firm, did her job competently, but nothing extraordinary. The second Kristyn is extraordinary. She is unemployed, and a volunteer Producer/Director of “The New England Job Show”. It is a new cable program to help people find work, produced, directed and run buy people out of work. Articles have been been written about the show and carried by the Associated Press. Good Morning America, Chronicle and Fox are planning to do pieces on the show. There is interest in expanding the program to help more people statewide. Kristyn is a masterful networker, connecting people everywhere she goes, always looking for new possibilities.
They are both the same Kristyns, only separated by about 5 months.
So what’s different? If she were to get a job tomorrow, would Kristyn go back to her cube, keep her head down and do her job?
I doubt it. I don’t think you’ll ever see Kristyn in a position where she’s unable to make a difference in the world again. Ever.
I asked her what was different. In her previous job, she’d tried to make things better, but never got much support to make the changes she wanted to make. There was a lot of talk about change, but nothing changed. When she was laid off, she realized she had to do something special to get noticed. And she did.
How many of the keep-your-head-down-and-do-your-job Kristyns do you have in your organization who would do extraordinary things with only a bit of nurturing?
For an organization to be truly agile, it is critical to have people who are enabled to give their best. The next product idea, the killer customer-service model and the next great marketing campaign are probably out there. You just need to give them room to come out.
In their book a simpler way, Margaret J. Wheatley and Myron Kellner-Rogers write:
Fuzzy, messy, continuously exploring systems bent on discovering what works are far more practical and successful than our attempts at efficiency … They slosh around in the mess, involve many individuals, encourage discoveries, and move quickly past the mistakes The are learning all the time, engaging everyone in finding what works. The system succeeds because it involves many tinkerers focused on figuring out what’s possible.
Go find your Kristyns and let them loose. They are everywhere. And they will make your organization great.
I’m committed to people experiencing joy, self-expression, partnership and accomplishment in their work. That statement is my guiding principle. It helps me decide where I’m going to focus my time, my effort and my education. So how did I get interested in Agile and how does it connect to my personal statement of purpose?
The first Agile project I encountered was far from ideal. The QA team didn’t understand how they fit into the Agile process. They attended daily stand-ups (on the phone) waiting patiently for requirements so they could start testing at the end of development. There was no team room; everyone worked at their desks. Shortly after the software was deployed, it had to be pulled out of production and reworked because its downstream effects hadn’t been fully considered. Somewhat messy, as first tries can often be.
I was curious to find out what people thought about the project on the business side and gave several of them a call.
The overall business owner considered it the best project he’d ever worked on with IT. He loved knowing what was happening every day, and the close collaboration between the developers and the business people. Someone on the team told me he appreciated talking about ideas for a feature with a developer in the morning and often seeing it work that same day. A user said how happy she was with the software; that it gave her an easy and intuitive way to do something that had been hard before.
I knew that there was something really right about Agile if a project with this many challenges had left such a positive impression. There was a rare level of enthusiasm. Joy, self-expression, partnership and accomplishment were present.
These conversations flipped me from being interested in Agile to being an evangelist for Agile.
In some companies it’s possible to try Agile software development on a small out-of-the way project. This is one of the easiest ways to get started. You try something, show results and then move up to a larger-scale project. But in some companies, there isn’t anyplace out-of-the way, and every project must engage with complex organizational structures and processes. In these companies the best strategy for success may be to choose the opposite kind of project: one that is critical to the company and visible.
Your first Agile project will probably be one of your most difficult.
- A dedicated, full-time team is critical for success. Most organizations who are not structured for Agile, have their people spread across many projects. This will be one of the most difficult obstacles to overcome.
- A strong Product Owner, with deep understanding of what a customer needs, is critical for the project’s success, yet it may be difficult to find someone to fill this role.
- A dedicated team room works best for Agile projects. This might be difficult to secure.
- The role of testers changes dramatically in Agile. Testers are part of the Agile team. Instead of testing at the end of the project, they are testing regularly, alongside the developers.
- The team needs the ability to regularly test new software in an integrated environment. In many companies that is difficult to arrange or the controls around the test environment make it very difficult to test multiple times per day.
- It is likely that the management team will have a format for status reports intended for waterfall projects. Agile teams usually can’t complete these reports since their measures of progress are entirely different. The management team will have to learn a new status reporting methodology.
- There is documentation, but it will most likely not be the same documentation that has been produced in the past. It will take a while for the rest of the organization to get used to the changes.
- Functional managers have been accustomed to moving team members between projects like interchangeable parts, but this will really hamper progress on an Agile team. This will be a challenge for the functional managers to accommodate.
- People are probably used to having a comprehensive set of requirements up-front. Not having this will likely make them uncomfortable.
- Even though project plans are often wildly inaccurate, people are used to having them and will be may be uncomfortable without one until they learn how things are managed on an Agile project.
With all of these challenges you’ll benefit from strong senior management support. You won’t get that level of support if you’re working on a low-visibility project; the burden for solving most the the challenges outlined will fall to the team.
My recommendation is to find a project that is critical to the company and get the management team on board. Let them know what the challenges will be and enlist their support. If possible, have them communicate what you are doing and why you are doing it to the rest of the organization. Use the management support when you need it.
It takes work to change an organization, but if you choose the right project and get the right support, you are more likely to be successful.
Agile is particularly good for managing projects where you have significant uncertainty about what you want to build and how you plan to build it. It can help you cut time-to-market and costs while increasing customer satisfaction.
Here’s an example. Imagine you want to enter the market with an analytics product that provides your customers with insight into patterns and trends within their employee population. You have various sources of data available (payroll, performance management, organization structure, industry pay ranges, state and region demographics) and a general idea of the things your potential customers might be interested in learning. This is a perfect project for Agile.
Agile is an iterative process. You build a little, you show results, and you use that feedback to guide what you build next. Your potential customers probably have some general ideas of what they would like to see, but won’t really know until they get their hands on a system they can play with. It would be pointless to try to get all of the requirements right up-front, because your potential customers won’t be fully able to articulate what “right” is until they see something. Much of the time you’d spend putting together a comprehensive requirements document would be wasted, since the requirements will change significantly as the project progresses.
Similarly, trying to fully understand the architecture and data requirements up front is also going to be difficult. You certainly will have some idea of what data you’ll want and how you’ll want to structure it, but you will probably have to evolve this architecture as the business requirements evolve.
You would be less likely to choose Agile for a project where you were performing a set of tasks very similar to one you have done in the past. For example, if you have call centers in five locations, and you are adding a sixth, it probably makes sense to update the project plan you’ve used for the other call center build-outs. You have a really good idea of the requirements up front and how to execute against those requirements. Limited iteration is needed.
If you have a project where you have significant uncertainty about what you are building and how you are building it, Agile is likely the right way to go. Using a waterfall approach on these types of projects will typically lead to excessive effort defining up-front requirements, significant rework, decreased customer satisfaction, higher costs, longer time to market, and decreased sales (if it doesn’t do what the customers need, they won’t buy it).
I want to thank Ken Schwaber for providing me with the core idea for this post in his ScrumMaster course.
My wife got a book called The 100 Best Business Books of All Time, by Jack Covert and Todd Sattersten. Moneyball: The Art of Winning an Unfair Game, by Michael Lewis, is one of the 100. Instead of reading the synopsis, I decided to read the whole book.
The Oakland Athletics managed to have success in Baseball while having one of the lowest overall budgets. They did this by identifying the characteristics that were the most important for winning baseball games and hiring people with those talents, many of whom lacked other, less important, skills. Other teams overlooked these players either because they undervalued the critical skill, overvalued the less important skills or simply because they didn’t fit the teams’ image of what constituted a “real” baseball player.
Now that I’ve read the book, I’m wondering how much companies overpay to get skills that don’t make a significant difference in their overall throughput.
It might be interesting for a manager to ask the question “if I had 20% less to spend on my team’s salaries, how would I do that”.
What are the core skills you think critical to your team’s success? What characteristics or skills are less important? Where are you missing skills you need? Where do you have an overabundance of skills? What skills are you willing to pay a premium to get? What skills are you paying to much for?
How do you know what skills are really worth paying for? Do you have any quantitative information to back up your decision?
Would the most important people on the team be the ones who were best able to train and develop others, so you could bring more college new-hires onto the team?
If you had to cut 20% of the total salary (not people) across your team (assuming you had total freedom to move people in and out of your organization) do you think you could do it? Could you be spending you money more effectively?
Note: I’m not suggesting you cut your team’s salary by 20%. I think it is a worthwhile exercise to get you thinking about who you hire, how much you pay and why.
I don’t follow baseball, but found this book interesting and provocative. I’d definitely recommend it to someone thinking about how to staff their teams effectively. If having a big bank account was the critical deciding factor in being a good baseball team, Oakland would never have made the playoffs. But they did.
The amount you have to spend on your team may not be as large as it has been in the past, but by rigorously looking at what you really need, can you still be as effective?