Creating an Agile Environment

Gregory S. Smith

This article is based on a chapter from the book "Becoming Agile", www.manning.com/smith, to be published February 2009. It is being reproduced here by permission from Manning Publications. Manning early access books and ebooks are sold exclusively through Manning. Visit the book's page for more information.

A few months ago I was contacted by a friend with a problem. The year was coming to an end and he had let a compliance project slip through the cracks. The compliance deadline was year end which was a mere 5 weeks away. Failure to comply could mean serious government repercussions to his company. My friend asked for help in creating an Agile team and doing an Agile project in the following 5 weeks.

This would be a great time to tout how Agile came in and saved the day but that would be a lie. I did help my friend prioritize his work and make the deadline, and we did follow some Agile principles along the way, but we did not put an Agile team or process in place.

Why didn't we put an Agile team in place and follow an Agile framework? Because it takes time. Teams need time to feel comfortable with Agile processes and they need time to learn how to interact with each other. Managers need time to learn how to lead in an Agile environment. The team needs to use an Agile process for several months, then major benefits will begin to manifest.

Migrating to Agile is more than changing your process. It also requires a change in culture. For most companies changing culture is the most difficult part. I believe this is true for several reasons. Here are a few:

• Whether successful or not, companies get comfortable with their processes.
• Many people still believe requirements change because they are poorly managed. They cannot comprehend a process that embraces change.
• Most managers have been trained to control events. Empowering the development team to deliver and own the project is not intuitive or logical.
• Job protection. In larger companies whole groups are dedicated to regulating and overseeing projects. An Agile team has less need for these services.

There are numerous other reasons but I believe these are at the center of the issue.

These issues should be addressed in two ways. First, you want to address the culture needs of each group head on. We will lay out a game plan for obtaining support from line management, the team, the individual and executive management.

If you work in a smaller company

If you are in a smaller company you may not have all of the organization levels discussed in this article. That is a good thing. You should find it easier to create an Agile culture because you are fighting your competition on a daily basis. You will obtain the most value by reading the sections related to creating an Agile team and addressing the needs of the individual.

Second, you want to address this problem by establishing practices that foster an Agile culture. Practices such as high customer involvement, testing early, and collaborative decision making will promote an Agile mentality throughout the company.

Figure 1. An Agile culture is established when the 3 major groups come together within a company. Executive management endorses the Agile principles, working managers learn to coach instead of direct, and the project team understands and supports Agile principles and practices.

This article will conclude by initiating our case study. We will get to know some of the people at Acme Media and see how they kick off their move to a more Agile process. We will create the Core Team and give them responsibility for learning Agile principles, then applying those principles to the tailoring of an Agile methodology for your Acme. The core team concept also helps with the cultural aspects of migration by involving project team members immediately.

The information in this article establishes the foundation that allows an Agile process to thrive. Similar to software development, if you get a good foundation in place it makes everything else easier to do. If you do not you will fight the foundation with every change you make. Let's look at the skills required of an Agile manager.

The Agile manager - more shepherding less directing

Do you remember a commercial for a company named BASF a few years ago? Their slogan was "We don't make a lot of the products you buy. We make a lot of the products you buy better". This is true of the Agile manager.

An Agile manager will never write a line of code, never document any requirements, or test a feature. What an Agile manager will do is:

• Help the development team track true status
• Encourage the automation of redundant, repeatable tests
• Mentor the team on Agile processes and demonstrate the value.
• Help the team break the work into small chunks that can be delivered quickly.
• Ensure the work being delivered is in tune with the customer need.

An Agile manager provides leadership without using formal power. Instead the manager leverages the respect they earn from the team as they establish a history of working together to successful delivery of projects.

What does a manager need to do to establish a record of successful project delivery? Let's start with the soft skills.

The soft skills

If you look up "soft skills" on the United States Air Force website you will find, "A set of skills that influence how we interact with each other. It includes such abilities as effective communication, creativity, analytical thinking, diplomacy, flexibility, change-readiness, and problem solving, leadership, team building, and listening skills."

This definition is an excellent prescription for the behaviors an Agile manager needs to subscribe to.

• Effective communication to ensure the team is synchronized on information.
• Analytical thinking to help the team brainstorm solutions when a challenge is encountered.
• Diplomacy skills to ensure tactful communications that do not offend or touch upon sensitivities.
• Great listening skills to not only ensure accurate understanding, but also to enhance relationships with others.

In summary, behaving in a way to enhance human relations.

Figure 2. An Agile leader brings their soft skills together to "shepherd" the team versus directing them.

Diane Ehrlich, Ph. D in the Human Resource Development program at the University of Illinois defines soft skills as "The Skills needed to perform jobs where job requirements are defined in terms of expected outcomes, but the process(es) to achieve the outcomes may vary widely." This is a good description for Agile development in general. You have a desired output, a project, and the way to achieve that output varies wildly depending on the specific needs of the project.

Now let's discuss where the soft skills are used.

Working with other managers

A project manager is usually leading a group of people that are not his or her direct reports. As mentioned before, your job is to earn the respect of team so they will follow you regardless of your express authority. In order to do this you also need to have the respect of the line managers who own the resources. The key is to ensure the line managers have bought into Agile concepts before you ask the team to.

Some level of training needs to occur within the line managers before an Agile migration is pursued. This training can come from any resource, internal or external, but during this training managers need to normalize on their support of the principles. You do not want to ask the manager's directs to buy-in to the process before the managers have.

You also need to consider roles when working with other managers. Although everyone is flexible in the tasks they perform in an Agile environment, there will be areas of responsibility for everyone.

Consider the development team. The development manager usually acts as a technical mentor and also assigns tasks to the development team. Historically the development manager may have been in charge of reporting status for the development team.

In an Agile environment there is a 10 minute daily stand-up meeting for the whole team to discuss what they did, what they will do, and any roadblocks they have encountered. This meeting may be facilitated by the project manager or it may be facilitated by a development manager. These types of decisions should be worked out with managers in advance of deploying Agile.

Working with stakeholders

Another group that will be vital to your project success is the stakeholders. Stakeholders are defined as those who have interest or influence on the project. Typical stakeholders include senior management and indirect customers such as: support teams, maintenance teams, help desks, third parties that integrate with the system, and other related product groups within the company.

In effect, stakeholders are another type of customer. They have their own needs that they want addressed by the project. To ensure successful delivery of your project you will need to integrate their requirements into a unified design.

All of the soft skills mentioned earlier are useful when working with stakeholders. The stakeholders may not be the main customers of the project, but you want them to feel valued. You want to demonstrate good listening skills and make sure they know that you understand their needs. You also need to demonstrate diplomacy and not upset the stakeholders by consciously providing information in a way that will inflame or incite them. For example, you do not want to demonstrate good listening skills and then immediately tell them that other stakeholders do not support their needs.

Demonstrate the value

The most important role of the Agile manager is to exemplify the Agile principles and live them daily. If you want the team to follow you, you must provide a strong example. There are numerous principles to emulate and follow. Here are the ones that provide the most impact.

"Just enough" planning

In traditional project management you identify features and then specify their requirements. Typically an analyst wants to answer every question possible in the specification so the development process will not be impeded by a missing requirement.

In Agile planning you want to plan "just enough". Just enough planning to determine which features you want to build. Just enough coding to demonstrate the feature to the customer and verify that you are on track.

This is one of the hardest habits to break with a traditional team and the Agile manager needs to champion this mentality on a daily basis. The manager can also emulate this behavior by creating project plans the same way. A plan that has just enough information to get to the next level of the project, not a complete work breakdown structure before development has even begun.

Always ready to stop, drop, and deliver

Agile development is performed in iterations to enhance urgency and to support early delivery of the most valuable functionality. The project manager needs to infuse this mentality into the project team.

The project manager gets the team to put the same urgency around an iteration as they do with a project deployment deadline.

Unrelenting pursuit of customer value

An Agile manager is always thinking about the customer and their needs. All other measurements of a project are meaningless if the product delivered is of no use to the customer. There are 3 steps to ensuring the customer's needs are addressed:

1. Clearly define the customer(s). Many projects get underway with a light understanding of who their customer is. Make sure your customers are clearly defined and their specific needs are clear.
2. Develop a relationship with the customer. Get to know them well and integrate them into the project team. Use your soft skills to collaborate with the customer frequently and make sure they can be easily accessed by the team.
3. Be an advocate for the customer at all times. When features are being discussed and the customer is not present, put the customer hat on and envision what their response would be to the discussion. Share those thoughts with the team.

Ensuring technical excellence

The technical skill set of Agile managers vary. A manager can come from a classic PMI background, be a former developer, or have worked as a business analyst in the past. Regardless of the technical knowledge all Agile managers can push the team to pursue technical processes that embed Agile beliefs. Here are some of the best practices for obtaining technical excellence:

• Create a process for continuous code integration. As functionality is completed, developers integrate their work into the existing code base. The key is to integrate as small pieces of functionality are completed as opposed to waiting for a complete feature. This practice identifies code issues early and minimizing the complexity of tracing down issues.
• Automate testing wherever possible. Work with the team to automate testing wherever possible. This is usually easiest to do with regression testing. You can also automate daily smoke tests to speed up testing.
• Perform a daily build/smoke test. Related to automated testing, a daily build also helps mitigate risk by identifying code issues early. The daily test focuses on ensuring the critical pieces of the application are still functional.
• Consider scalability. As an application is being developed the team should consider future growth. What will happen if the application is extremely popular and usage exceeds expected volumes? The team can consider scalability as they design and ensure the design can be "scaled" easily if needed.

A great collaborator, communicator, and relationship builder

Agile is as much a team culture as it is a software development methodology. It is a culture of frequent conversation and consensus building. It is face to face interaction on a daily basis. The Agile manager needs to emulate the correct behavior to ensure positive results from the frequent meetings and daily decisions.

The correct behavior begins with checking your ego at the door when you walk into the office. There will be intense discussions in an Agile environment and the process will break down if you take criticism of your ideas as criticism of yourself. Demonstrate this to the team by never getting upset (at least visibly) during subject discussions that you are passionate about. Share your thoughts with passion, but expect and embrace criticism of your ideas. The team will adopt this behavior if you model it consistently.

Another key behavior is how to interact with those outside of the direct project team. These groups can be vendors, stakeholders, other departments, and sometimes customers. If you show respect in your interactions with these groups the team will too.

It is natural to talk poorly about others outside the team. "That stupid department we work with that does not do Agile", "that idiot vendor whose system always goes down", "that dumb customer who can never make up their mind". You will always have this at some level at your work. The goal is to not let it get out of hand, where it exceeds venting and proceeds to a truly poor relationship.

Leading the team to ownership

In 1998 Arthur Andersen published a book by the name of Best Practices, Building Your Business with Customer Focused Solutions. One of the best practices outlined in the book was the ABO Continuum. The continuum identified a vital element in introducing change to an organization, ensuring ownership of the change.

The continuum promotes the belief that organizational change goes through three steps; awareness, buy-in, and ultimately ownership.

In the awareness phase information about the change is shared early and informally. For example, during a team meeting a manager could say "the executives are discussing improvements for our development process". The manager could also add in when he thinks he will hear more and see what the team reaction is.

The value is not so much in what is said, but when it is said. Every individual has their own timeframe for evaluating a change. The earlier you can make a group aware of a potential change the better your chances of getting them to "buy-into" the change when you are ready to roll it out.

The buy-in phase occurs when you roll-out the change and begin implementing it. Awareness has been created and you are looking for the team to consider the change and to use it with your guidance.

In the ownership phase the team has tried the change, begun to believe in it, and adopted it as a standard practice. They do not need management to encourage them to use it. They believe in it and will use it without being prodded.

The ABO Continuum is a great approach for rolling out an Agile methodology. Partner with your executive team during rollout and process to minimize pain in your migration.

"The Scrummaster"

Scrum has become one of the most popular Agile packaged methods. The Scrummaster is at the heart of Scrum. This individual is not a manager but more of a process facilitator and guide. A Scrummaster:

• Helps the team develop practices that support Agile principles
• Acts as a guide in training the team on how to be Agile and use Scrum
• Removes impediments that prevent the team from delivering software
• Shields the team from corporate bureaucracy and activities that do not add value to software development
• Champions engineering excellence and processes that support the creation of shippable software
• Ensures the team has direct access to the customer

I believe Scrum is a good Agile method, especially when there is urgency to establish a development process quickly in an immature organization. However, I struggle with the depth of responsibilities assigned to the Scrummaster.

My opinion is driven by something I learned when I became certified as a Scrummaster. My Scrum teacher told me that Scrummasters are the key to Scrum's ability to transform the organization. He also told me that Scrummasters are responsible for team health. Initially I liked this thought. It is great to know I have an expert holding my hand and coaching me along the way as I go down the Scrum path to an Agile process.

Over time I have started disliking the thought of one person with so much responsibility. In my experience there has been shared ownership across the leads and managers when we migrated to Agile. There were definite Agile experts on my teams, and we frequently asked those experts for guidance, but we never asked the experts to own the process or team health. We did this collaboratively as a leadership team.

I have found this method successful because we do get expert opinion, but we do not relinquish ownership of the process to one person. In my experience this co-ownership leads to an Agile process that is better adhered to because it was created together.

Now that we have outlined a process for obtaining management support, let's discuss a process for getting the team to buy into Agile.

The project team

An Agile team is different from the average development group. Team members come across as poised and ready for where ever the project may lead them. An Agile team member does not fear uncertainty. They look forward to the challenge and they know they will succeed.

Where does this air of self-assurance come from? Is the attitude reflective of the type of people that were hired? Or is it reflective of the processes that are being used? Is the attitude a byproduct of executive support? Does the confidence come for a history of successful deliveries?

The answer to all of the questions above is yes. Each of the items described above supports the effectiveness and self-reliance that is inherent in an Agile team. In some ways creating an Agile team is like baking a cake. You can obtain the ingredients exactly as the recipe requests. You can bake at the suggested temperature. You can let the cake cool the specified time before applying the icing. But what happens if you are at high altitude and you forget to make the necessary adjustments? The cake rises too quickly and then turns out too dry. Or what if someone jumps up and down in the kitchen while the cake is baking? The cake collapses and never rises.

Next I will give you the ingredients for creating your Agile team.

Culture and roles

I find it hard to describe Agile team culture in a sentence, but I can easily describe it with several words. The words that come to mind are: collaborative, open, passionate, courageous, honest, light-hearted, driven, synchronized, customer focused, funny, responsible, innovative, and successful.

The culture is one of low politics and high transparency. Words are honest but not abrasive. Status is discussed in matter-of-fact terms. The team focuses on the situation, not the person.

Estimates are honest. There is no padding to make the work easier to do. There is no lying about how long it will take to appease management.

Another nuance of an Agile environment is the roles that team members play. Except for the use of Scrum, Agile does not specify what team member roles should be. In my experience this has not been an issue. The teams I have worked with did not change their roles after they migrated to Agile. We still had developers, testers, project managers, product managers, customers, DBAs, and Operations.

What did change for those teams was attitude. After we migrated to Agile I rarely heard a team member saying something like "development is not responsible for that" or "quality determines when the code is acceptable". I saw many more team decisions and I saw much more collaboration around problem solving. A problem was not tied to an area, and they had to solve it. It was tied to the project and the team had to solve it. The team focuses on the goal, not their job description.

The last item related to culture is diversity. If you do not have a diverse team your Agile process can lead to groupthink. Groupthink happens when a team wants to get along with each other so desperately they will not voice their opinion when they disagree with an idea. This is a definite danger with Agile. People assume collaboration means harmony and always getting along. They think if they start agreeing with each other all of the time they are being collaborative.

A classic groupthink example is the space shuttle disaster on January 28th, 1986. The space shuttle Challenger was preparing to launch on a cold day, colder than any other space shuttle had been launched on. One of the engineers from a company that supplied parts to the space shuttle warned that there could be risk in launching. He was concerned that the O-ring seals his company provided may fail in the low temperatures since they had never been tested below 53 degrees Fahrenheit. The engineer shared this concern during a teleconference with NASA and NASA urged him to reconsider his recommendation to not launch. The pressure from NASA persuaded the company to acquiesce to the request and overrule their engineer's warning. Subsequently the O-rings failed just after launch, leading to the death of the entire Challenger crew (Griffin 1997).

The reciprocal of groupthink is diverse opinion that is spoken freely. This is what you want in your Agile environment. A good example of this is occurred during the Apollo 13 space mission. In this instance there was an explosion aboard the spaceship on its way to the moon. The ship and crew were salvageable with a little luck and some spectacular collaboration.

As the crew experienced various issues in trying to return to earth, the support team on the ground went through days of brainstorming and collaborating to solve the problems. No one team member had more influence than another in suggesting a solution, and "getting along" was not a requirement. As problems were discovered ideas were discussed passionately until the group reached consensus.

Culture is not an optional ingredient in your Agile recipe. The majority of the team must embrace the Agile culture else you will not be Agile. You will just be a team that calls your self Agile and you will go about business as before.

Let's take a moment to look at the building block of the team, the individual.

Characteristics that influence individual performance

Everyone on your team does not need to be competent and mature, but you want to put a system in place that breeds competency and helps the entire team get there over time.

Just like in traditional development, competency alone does not guarantee team success. There are several factors that affect the productivity of an individual. Let's review a few of them.

Motivation and reward structure

A talented, mature individual will not stick around to work on your Agile projects if his efforts are not rewarded. A person who is talented can frequently choose where they want to work. It is up to the company to create an environment that attracts and retains talented individuals.

In simplest terms, behavior reflects incentives. What are the incentives you will provide to attract talented individuals to your Agile team?

Consider the following items related to motivating and rewarding the individual:

Is the mission of your company clear? Has it been clearly communicated to each individual? Employees will want to know where the company is going and how their projects tie to the vision.

How is health of your company? Are you doing well financially? Are you a start-up fighting to survive? Company health can tie to motivation on in two ways. First, if you are healthy and growing, you can convey this message to employees and tell them that there is stability, growth opportunity, raises, and potentially equity. If you are struggling to survive the message is the importance of their project and how it affects the destiny of the company. Everyone wants to work on projects that are important.

The Agile environment is going to stress the value of the employee beyond their job title. They will make management decisions and they will be responsible for proactive communication. Talented individuals will welcome this environment. Employee evaluations should recognize and evaluate collaboration skills.

Career stage

As you migrate to Agile you will need to consider various approaches to migrating your employees to an Agile mindset. To help you determine the approach, consider where each employee is in regards to their career. Here are the main stages and suggested approaches.

The New employee: These employees are in a stage of rapid learning and trying to understand the company and processes around them. They are dependent on others to get things done, and they are working to become independent from support. These employees will enjoy learning Agile because it will level the playing field for them. They will be at ground zero, just like senior employees, and they will be comforted by the fact that everyone is learning Agile together. They should also do very well using the methodology because they do not have a lot of previous experience to bias them.

You do not have to do anything special with these folks. Just ensure they get the same training as everyone else, and that they are offered the same opportunities as other team members.

The Individual contributor: These employees will make up the bulk of your teams. They are not new and they are not supervisors or managers. They have a medium to large amount of experience, and they may have chosen to not become managers, but to become a guru in their area.

These folks require the most management and you need to address their needs individually mentor. Some general tips for motivating these employees are:

• Give them an area to own and be responsible for in your migration.
• Give them an opportunity to use and share their expertise.
• Give them a chance to be innovative and unique.

A lot of these folks are looking for growth and will embrace Agile. Some of these folks will just be getting comfortable with the way things have always been done and they will resent having to learn another new thing. Be patient with the "resenters" and remember them when the time comes criticize the Agile design. Their feedback will be valuable.

The Coach: Employees at this stage are motivated by sharing their experience and mentoring others. They are also looking for an opportunity to renew and revitalize them self. An Agile migration project is just what the doctor ordered for these employees.

Give these folks leadership opportunities during the migration, such as resolving design issues or leading the team to consensus. They can also be on the forefront of receiving Agile training and they can mentor novice employees on the process.

Now that we have a process for getting management and the team on board, let's discuss the most important foundational piece, executive support.

Obtaining executive support

Ralph Waldo Emerson said "Nothing great was ever achieved without enthusiasm". For those of you with significant business experience, you know that "Nothing great was ever achieved without executive support". This is not true because of executive team impact; rather, it is true because executive teams will stop anything they have not endorsed. They will want details, justification, meetings and more meetings if they are caught by surprise on a major initiative they have not endorsed. A migration to Agile would be considered a major initiative in most companies.

If you surprise the executive team that may allow you to still go forward but energy and momentum will be lost if you get sidetracked by not involving them at the start.

In this section we will show you how to obtain executive support by addressing the specific needs of the group.

Figure 3. The five key steps in preparing for your Agile migration. Executive support will provide a foundation for the migration and clear roadblocks for the team along the way.

A few things are guaranteed when you meet with your executive team. They will want answers to the following questions:

• Why you are pursuing this initiative?
• What is the value?
• What are the costs?
• What are the risks?
• What will it do for me?

Let's look at some potential answers to these questions and determine which ones best fit your situation.

Why pursue agile?

There are a variety of reasons why you are pursuing Agile and what the value is. Here are the ones that resonate with executives:

• There is no methodology. You really do not have any processes or framework in place and you do projects different every time with varying results. You are pursuing consistent, successful delivery of projects.
• Your current methodology is struggling to keep up with the volume and volatility of your work. You are looking for a way to deal with projects that need quick turn around, but have minimum requirements definition.
• Your customer is not happy. The customer feels disconnected from the process and they feel their needs are not being met. You are looking for a way to get the customer more involved in the development process and improve their satisfaction. (Important to note here - If you involve the customer more in the process their satisfaction rating will improve even if your deliveries do not. They will have more empathy for what it takes to create value for them and in turn they will have a more positive feel about your company and the development group. In this instance there is truth in the saying that perception equals reality.)

The items above are solid reasons for migrating to Agile. However, your executives may be concerned that the migration is inspired by something else such as boredom or trying to become cutting edge. Perhaps team members are looking for a good resume bullet. There is nothing wrong with migrating to Agile for a resume bullet or to modernize your processes, but these need to be secondary benefits. Migrating to Agile is not free and it should only be pursued if it benefits the company.

One last note on value. This book includes many statistics related to the value of Agile. These statistics relate to business satisfaction after migration, cost reduction, and improved quality. These statistics are good for appeasing the Agile detractors in your company and the employees who try to measure everything in terms of probabilities. You can use these statistics to justify your migration to Agile and, for lack of better words; your backside will be covered if the migration goes awry.

But what statistic will show you how much effort a company put into their migration? What statistic will show you how passionate the employees were that brought Agile into these companies? Where is the statistic that measures how much executive support was obtained before the migration started? How much training did employees receive? In effect, the statistics only prove that Agile is not a fad because enough people have used it to create statistics for it.

There are so many intangibles in a migration to Agile that I would feel guilty if I recommended it based solely on statistics. I recommend Agile because I have seen it work in several environments. I recommend Agile because I have enough experience to know what the common issues are related to software development. I know Agile principles address these issues and ensure my probability of successfully delivering projects.

The cost of migrating

What will you say when the executives ask about cost? In the model proposed your main expense will be having a knowledgeable Agile person or company come in to train the team. This is usually 2 to 10 days of training, with a several phone calls and one-off consulting sessions post training. A ballpark number for the consulting/training assistance is $5,000 - $10,000.

The other expenses are less tangible. They are frequently labeled as "soft" expenses because they do not add to company expenses but reallocate existing resources. This will be true of the Agile Core Team. Over a 3 month period the Agile Core Team may spend 10% of their time working on the new Agile methodology. Other costs are relatively minor, such as printing out materials to support training.

The last "expense" of note is slower delivery. You can expect the first few projects to be slower as the team gets comfortable with the new processes and each other. After an acclimation period the team will gel around the process and you will deliver high priority features sooner than before, but patience is necessary with the first few projects.

An analogy that comes to mind is auto reviews. I frequently read car magazines and I enjoy the road test reviews on new vehicles. Almost every review will lament the position of the shifter, the strange angle of the seats, or the lack of cup holders.

I will buy the same magazine 6 months later and it will contain the long term road test results for the same vehicle. Frequently the extended review will say "Although initially quirky, the position of the shifter becomes intuitive with long term use and simplifies the shifting process. We also found the seating position to be excellent for long distance road trips." Your migration to Agile will be similar. Once you get comfortable with how it works you will find it "becomes intuitive with long term use and simplifies the development process."

While discussing the cost of migrating to Agile we should also consider the cost of not migrating. If you reflect on the items listed in section 4.1.1, the reasons for why you are pursuing Agile, what happens if you do not address those issues? The consequences can include:

• Declining customer satisfaction
• Loss of key employees
• Missed deadlines for compliance related projects
• Lost sales
• Lost opportunity

Whether you like Dr. Phil or not, there is a question that he frequently asks his guests that relates to migrating to Agile. The question is "How is your current process working for you?" This is Dr. Phil's subtle way of saying what you are doing is not working, period. You need to make a change.

The risks in migrating

The next question is "what are the risks?" If done correctly I believe the risks are minimal, but I will list some that can occur with poor management of the migration process:

• You can fail on a critical project if you pilot your Agile methodology on it. The first few Agile projects should not be mission critical. You need to start and test on projects with medium priority and work your way up to critical ones.
• The migration can fail if it is executive driven and there is disregard for pursuing employee buy-in.
• There can be impact to projects if employees hear about the work the core team is doing and decide to experiment without guidance. I have seen this happen, where a team will take one Agile practice and try it with disregard for how it needs to dovetail into the upstream and downstream processes.
• With improper training the methodology can foster cowboy coding and insufficient documentation.

Rewards for the executives

The last question is "What will the Agile migration do for me?" There is nothing wrong with this question. We all have career needs and no one likes to undertake a venture that puts their career at risk. It is fair to ask what Agile will do for me on a personal level.

The answer to this question is usually unique. More than likely the executives will never tell you the answer to this question directly. You will have to deduce the best way to make them look good. Here are a few ways I have seen an Agile migration make executives look good.

• Agile allows executives to acquire new skills and knowledge which will increase their value to the company and increase their chances for promotion.
• The move to Agile provides an opportunity to demonstrate leadership skills by leading a major organizational change. The executive sponsor will reap this reward.
• The migration to Agile will lead to more wealth. Like most of us, executives care about their compensation. Migrating to Agile will lower costs and increase revenues, which should also lead to an increase in stock value, or if you are a small company, survival.
• Fewer people issues. All managers dislike dealing with people issues. The Agile work environment is more satisfying and the executives will find themselves dealing with fewer employee issues. They will also be pleased to see employee retention rates increase.
• Fewer customer issues. As mentioned earlier, customer satisfaction increases with Agile. A happier customer leads to more pleasant discussions with the executives.

Communicate frequently

You need to communicate frequently with the executive team and keep them abreast of the progress the core team is making. Although it may sound a bit anti-Agile, you may want to publish a weekly status report that provides an overview of progress made, status related to projected schedule, risks being managed, and issues encountered.

You should also schedule a recurring meeting with the executive team to interact with them face to face. The meeting will allow you to add more depth to status and continue with the Agile education of the executives. I believe you should meet with the executives about every two weeks. This timeframe works well with their busy schedules and also allows you to spend more time managing the migration and less time reporting on it.

You should also encourage informal interaction with the executives. Some executives may like a one on one session with the core team. Welcome them with open arms.

You may also have executives who like to drop in during core team meetings to listen in on activities. This is a positive too, just make sure the presence of an executive does not intimidate the team and they can stay on course with the task at hand.

All of the items above are great ways to communicate with the executives, but the best way is to have someone within their ranks directly tied to the migration. You need an executive sponsor.

The role of the sponsor

Your executive sponsor will be the liaison to the executive team and help clear hurdles for the team as they develop the new methodology. The most logical path is to find the executive most closely related to software development. Frequently this is the VP of Development, or potentially the VP of Product Management.

If your desire to migrate to Agile is being driven from the "doers", that is not at the executive management level, it is best to work your way up the ladder to obtain executive support. For example, if you are the project manager and you are proposing the change, you could discuss it with the director of software development. If he buys in, you could ask him to help you take it to his superior, perhaps the CIO. You could do a dual presentation to convince the CIO of the need.

Once you obtain your sponsor should you expect them to play three major roles.

In their first role they will keep the executive team up to speed on the migration outside of the scheduled status meetings, and they will act as a champion for the migration. They will help your team acquire funding for the migration and remove roadblocks at the executive level.

In their second role they will represent the organization, ensuring that the Agile migration project is in line with the organizations goals and strategic objectives. They will help the Agile team ensure success and minimize risk to protect the organizations investment in the change.

In their third role they will provide leadership for managing the organizational change that needs to occur with a shift to Agile. This would include working with the executive team to create a rewards structure that encourages Agile behaviors.

These three roles can manifest themselves in many ways. Here are some typical activities of a project sponsor.

• Help the team define success for the migration.
• Help the team obtain outside help when needed.
• Ensure that the new methodology works within the organization culture.
• Help with migration team morale and recognize successes along the way.

Lastly, help your executive sponsor if they do not have a technical background. Train them on how software development works and the intricacies of Agile. Be patient if they need time to digest how it all works.

Now that we have a feel for the cultural needs of the executives, let's take a moment to discuss working managers.

The role of the core team-ensuring company buy-in

The key to a successful Agile migration is having the change driven from within. The change needs to be driven by key players throughout the company. Once this team is created they will be evangelists to the entire company.

The role of this group, which I call the Agile Core Team, is to learn as much as they can about Agile and use this knowledge to outline a custom Agile methodology for the company. The team will collaborate and reach consensus on new processes, then mentor project teams as they use the Agile techniques.

This core team is powerful and influential for three reasons:

• They are not a part of line management. There will be very few members from the management ranks but the majority of the team will be "doers". The people that actually design, build, create, and test the code. This will add to the credibility as the methodology is rolled out to the company. It is not a management initiative being forced upon everyone; it is coming from real people who will be a part of the project teams.
• Since the team is composed of doers they actually know the ins and outs of developing in your environment. This is different than when consultants come in suggesting standard practices and disregarding the realities of a specific company. The Agile Core Team has experience with your company and they will use that experience to develop a methodology that knows what to keep and what to discard within the existing practices.
• Remember our earlier discussion of awareness, buy-in, and ownership? What better way to create awareness than to have Agile Core Team members come from each functional area. Imagine a member being from quality and going back to the quality team and telling them what is going on with the new methodology, or a developer doing the same with the development team. Having team members from all areas will initialize awareness across the company.

Many companies use outside consulting to get their methodology going. I have seen several companies choose to go with Agile methods such as Scrum, and then have a 3^rd party come in and train, design, and deploy the methodology. In my opinion this approach is not as effective as growing the methodology from within. Creating it from within the organization addresses all of the issues with ownership. It is hard to get a team to buy into a process that was forced upon them. Note that there are occasions when an organization is so dysfunctional that it needs to have a methodology forced upon it. This is the exception, not the norm.

Obtaining team members from all areas

Once you obtain executive support you can pursue creation of the Agile Core Team. Your sponsor will probably suggest managers for the team, but you need to remind him that part of the power and influence of the core team is they are "doers". You might also find yourself pursuing the best and brightest people from each area. People with a positive attitude and a pro-Agile mentality. People that are open minded to change. These would be excellent attributes to list on a job opening, but would they be reflective of your current employee mix, the people that you want to embrace the new methodology? Probably not.

If your company is like most you probably have some mix of the following:

• Brilliant and collaborative people
• People that are brilliant but difficult to work with
• People who challenge ever initiative
• People who loathe change and avoid it at all costs

You need to make sure the makeup of the core team is similar to the makeup of the company. This will help you obtain buy-in from all types when you begin roll-out.

After determining types of folks for the team, you need to determine team size. A group large enough to capture a diverse set of perspectives but small enough to be, yes, "Agile". I suggest a number somewhere between 5 and 10 people. Note that if the team is larger you can still make progress when a team member is pulled for a production issue or is out due to vacation or illness.

To give you a feel for creating your own team, let's return to Acme Media. We find that Wendy Johnson has obtained the CIO, Steve Winters, as the executive sponsor for the Agile migration. Amazingly Steve has asked to be on the core team and he says he can participate in the 6 hours per week requested of team members.

Wendy and Steve have also identified their Agile Core Team and they have received approval from the managers of the people selected. Wendy and Steve worked hard to get a diverse group of people on the team to allow many perspectives to be considered in creation of the methodology. Their team member list is can be seen in table 4.1. You will notice that members are from various functional areas and they all have different points of view on what a methodology should do, just like your team will.

Table 1 Acme Media's Core Team. Core teams are composed of cross functional team members with various levels of Agile knowledge. The diversity of the team works well for scrutinizing the new process.

Functional Area/Role	Name	Background
Sponsor/CIO	Steve Winters	Six Sigma enthusiast. Does not believe in change for the sake of change. Willing to pilot Agile and see if the benefits manifest.
Project Management	Wendy Johnson	Frustrated with the status quo. Lately quoting Dr. Phil "If it ain't working you got to try something else". Wants a methodology that reflects the reality of how software is developed.
Development	Roy Williams	Familiar with XP development techniques, but very comfortable with the waterfall process that Acme has used the last few years.
Quality Assurance	Vijay Kumar	Concerned that Agile will bypass or minimize the need for testing. Experience working in an ISO environment. Frequently says "document what you do, do what you document".
Operations	Matt Shiler	Lives in a stressful world of managing production issues and deployment of new functionality. Worried that he will not have enough time to work with the core team.
Requirements	Wes Hunter	An Agile zealot. Been looking forward to this day for a long time. Dedicated to making Agile work at Acme. Works with Product Management to refine feature design for customers.
Architecture	Keith Gastaneau	Wants to make sure that an Agile methodology does not bypass good architecture practices, and there is enough time to build the infrastructure needed for projects.
Product Management	Peggy Romani	Unfamiliar with Agile but excited of the promise to embrace the customer and changing requirements. Identifies target markets and strategic needs of the products.

Just like Acme, you will need to get manager approval for the employees you select for your team. The managers will probably be looking for a time estimate from you. The firs few weeks I like to see the core team meet twice a week for 2 hours each meeting. You can also assume each team member will get a couple of hours of Agile homework a week (researching existing development methods, etc.) A good number to give the managers is 6 hours a week for 3 months. The duration will decrease over the 3 months. You may see the weekly meetings reduced to one hour, but to be safe still ask for 6 hours per week for 3 months. Better to promise late and deliver early.

After team selection you need to meet with the members and set expectations.

First meeting of the core team

Once your team has been named you should schedule a kickoff meeting to set expectations and goals. Similar to meeting with your executive sponsor, you will need to start the meeting by telling the team why the company is migrating to Agile. The verbiage will be slightly different with the core team, with less focus on financials and a more focus on process.

The kickoff meeting

To see an example, let's look at the presentation Steve Winters is using at Acme's kickoff meeting. Steve starts the meeting with the following bullets:

• Acme Media's web division was no longer a supplemental site to the television station. The web sites had their own audiences and advertisers.
• With the increase in popularity of the web sites, the backlog of new features and application requests has increased by 70%.
• Many of the feature requests are time sensitive. If the requests cannot be completed soon our competitive advantage will be lost.
• Our existing development processes, where we have them, are not working well with our tight deadlines or with the evolving requirements.
• We need to research a better way of dealing with urgent projects.

As you can see, Steve's message was tailored more to the project team than it was to an executive group. He spoke indirectly to revenue by saying "lost advantage" and he mainly targeted process improvement. The best thing Steve said was "the web sites are no longer supplemental sites to the TV station" and "the web sites have increased in popularity." Steve was telling the team that their work was important.

You should follow Steve's example during your migration, especially emphasizing the importance of the work the team does and how valuable the methodology they develop can be.

Tough questions

Of course everything will not be roses at your kickoff. You can expect difficult questions and perhaps "attitude" from some of the core team members. Here are a few of the questions and comments you are likely to hear during your kickoff:

• We cannot create the methodology. We don't know anything about Agile.
• We need consultants to do this for us.
• We have tried to change before and it failed.
• What is our role?
• What is the role of the executive sponsor?

The answer to the first question is easy. The team will get trained and soon they will have a good working knowledge of Agile. If you are lucky, a few team members are already versed on Agile to help bring the team knowledge level up.

On the second question they are half right. You will bring in a consultant or Agile guru to train the team on the fundamentals, and perhaps discuss what other companies have done with their methodologies. But the consultant will not create the methodology for them. They will do that and later they will be glad they did.

The third question is a warning sign to you if you do not know the details of a past failure. Was it due to a methodology being forced on the team? Was it due to waning executive support for the change? Do your homework if you learn of a past failure and make sure your plan covers the lessons learned from previous ventures.

Assuming the issues related to a previous failure do not exist anymore, you can explain to the core team why the migration should be a success this time:

• The design will be created by experts who know the business well - them.
• They will not be forced to remove a legacy process if it is proven and adds value. If this is true there is a good chance it is already an Agile process.
• The approach will not be shotgun. The methodology will be built iteratively and it will be deployed iteratively to mitigate risk. In addition it will not be beta tested on a mission critical process.

Answering the question about their role is simple and clear. The team will learn about Agile and use this information to create the Agile methodology. In quick summary they will:

• Train
• Document the existing project and development processes.
• Determine what to keep and what to discard with the current processes.
• Compare the existing process to a pure Agile one.
• Design a new methodology based on Agile principles and the reality of the work performed.
• Get feedback on the design and tweak it.
• Take the design for a test run on a low to medium level priority project.
• Learn from the test run.
• Continue refining and testing until the methodology is solid enough to be used on all projects and the team is comfortable with the processes being used.

As mentioned earlier, the role of the executive sponsor is to clear roadblocks for the team and to be the liaison to the executive team at large.

Your role in the migration

Another question not listed but potentially asked is what is your role? Assuming you, the reader, are the leader of the core team, there will probably be questions about your role. If you are a manager you want to make it clear that you are all equals during team meetings. Titles and status will be left at the door including your own. As leader you will help organize the meetings and report status to the sponsor. You will also act as facilitator and help the team reach consensus on design ideas.

Training the core team

Training needs to happen within a few days of the kickoff with the core team. Determining the level of training is tricky. You want to provide enough information so the team understands the Agile principles and their value. You do not want to train to a point where you have handed them a methodology - especially somebody else's. You want them to combine Agile principles with their knowledge of your business to create a methodology that is effective for your company.

You will need to use your own judgment on how deep to train depending on how well the principles are being digested and how creative you perceive the team to be. Here is a suggested outline for training

1. Explain to the team where Agile came from, what makes it works, places where it is working, and why it has not faded away. This training should take 4 to 8 hours.
2. Give the team a few days to absorb the principles then train them on the phases of Agile. We have chosen phase names that map well to names used in traditional software development, which helps with the training process.
3. Once training is complete the team will begin the design process by reverse engineering the existing processes.

Keep the energy flowing - goals and milestones

As mentioned earlier, you need to have regularly scheduled meetings of the core team to maintain momentum. You also need to create a list of milestones for the team and time-box their work. This is critical because a team can easily spend a year working on the creation of a methodology. Just like Agile development, time-boxing the design process will force decisions and allow for early demonstration of the methodology to validate it. The methodology will be a living thing that is refined continually. The first priority is to bring it to life quickly.

To get a feel for time-boxing the redesign, let's look at the plan that Acme Corporation has outlined. In this example the total duration is two months to reach the point of being able to test the methodology on a project:

• Train the team on Agile principles, phases and optionally with a real world example. - 1 week
• Document the existing development process. - 2 weeks
• Review the existing process for deficiencies and identify areas to change to make them more Agile - 1 week
• Outline a new Agile process with the proposed changes - 2 weeks
• Get feedback from non-team members on the proposed design - 1 week
• Refine the design based on the feedback. - 1 week
• Pick a test project to try the new methodology on. - 1 week

You should estimate your design work to take anywhere from four weeks to eight weeks, depending on core team availability, business model complexity, and the dynamics of the team. Some teams reach decisions quickly, some will debate for a while before reaching consensus. Use your design milestones to push the team to decisions if they get stuck along the way. Remind them that the design is not permanent and will be refined as you all learn.

Developing a communication plan

In the process we have outlined so far, the core team knows what is going on and their managers have a high level idea of what their employees are doing. Outside of these people, the Agile migration project has not been communicated to all of the employees of the company.

A question that Acme Corporation has to answer, and you do too, is how to communicate the migration to the development group at large. There are two approaches that can be taken depending on how you categorize your company.

A category one company is progressive and somewhat cutting edge. A good portion of the employees may have already heard about Agile and they are curious about it. The culture embraces change and they take pride in their open mindedness. The culture probably embraces innovation. Some companies that come to mind are Apple, Google, and Yahoo.

If your company falls into this category you can communicate freely on the status of the migration, including issues encountered and adjustments you are making along the way. You may want to post a weekly update to your intranet or email one to the development group at large as you progress.

A category two company has limited knowledge of Agile. The culture may struggle with change and there could be historical issues in trusting executive management. These companies may have limited success in being innovative.

If your company has any of these characteristics, I suggest the following ideas for your communication plan and method:

• Get the executive team on board as soon as possible. Keep them up to speed on the progress and findings as you progress. This group will help you when you officially announce the methodology to everyone.
• Outside of the executive group, maintain a low profile as the core team is developing the methodology.
• Allow the core team to communicate to their peers and their team informally about their work. Someone once said the best way to spread information is to label it as a secret. Don't label the migration as a secret, but don't spend too much time communicating about it before you know what it is. The informal communication will also kick-off the awareness phase.

There is probably fear of the word "Agile" in your environment, so do not use the word when communicating with others. You should also consider labeling your methodology in a way that has no connections to Agile. Your goal is to get the company to adopt your new methodology. You do not care what they call it. So consider a name like ACDC, Acme Corporation Development Cycle versus ADLC, the Agile Development Lifecycle.

Most Agile migrations will have issues with skeptics and people who are resistive to change. As you get closer to testing your methodology you need to embrace these people and give them the floor with the core team. Let them discuss their concerns and critique the proposed design. The value in this is twofold. First, a good deal of the time they will identify a weakness in your process. Second, they will be converted to advocates if you listen to them and you are able to make some of the changes they suggest.

Summary

Establishing an Agile culture is just as important as establishing an Agile process. An Agile culture must be supported by management or the team will struggle to succeed. Train your management team on Agile concepts and establish their support before asking your team to.

Train your managers on the soft skills that support an Agile environment such as listening and team building skills. Teach your managers to shepherd the team and to teach the team how to manage themselves.

An Agile team is successful because it is honest and project status is transparent. Reward your team for demonstrating these values.

Assess your project team member needs and give them a migration role that supports their unique needs.

Kick start your migration by establishing support at the executive level of your company. Be ready to quantify the value of the migration to the executive group.

Create a core team that is composed of employees throughout the development process. This group will tailor an Agile process to your environment and drive the migration to Agile from within. Make sure your core team is diverse and represents many skill sets and perspectives. Make sure the core team is clear on the value of Agile before asking them to engage in the migration process.

Establishing your first pass at an Agile process can become a run away train if you do not time box the effort. Limit the time you spend creating your lifecycle and remember that you can, and will, improve it over time.

Once you have initialized your culture and established a core team you will be ready to create your custom lifecycle.

---

Related Methods & Tools articles

Agile, Multidisciplinary Teamwork

Going round and round and getting nowhere eXtremely fast?

Opening Communication within a Scrum Team

More Scrum Knoweldge

Scrum Open Source Tools

Scrum Expert

Agile Videos And Tutorials

---

Click here to view the complete list of archived articles

This article was originally published in the Spring 2008 issue of Methods & Tools