In my experience the best agile implementations have been ones where all of the groups within the company were involved.  Executive management may be driving the change, or project team members may be initiating the change, but at the end of the day both groups need to support and be involved with the transition to a more agile process.  In this posting I will discuss creating a core team to involve the project team in an agile implementation. 

In 2000 I worked for a small startup company. The Agile Manifesto was in the works, and my team had the good fortune of being trained by one of the creators of the Manifesto, Jim Highsmith. Jim came in and walked us through the principles of adaptive and agile software development.  Jim discussed practices along with the principles, but the main take away for my team was the principles. We took what Jim taught us and looked for ways to apply it to our specific situation.  How could we create a more agile process to deal with our requirements uncertainty and our compressed schedules?  In the end we created a custom agile process that worked for our company.

A few years later I was working for the Seattle Times New Media group, and we had similar issues with our development lifecycle, and once again we had Jim Highsmith come in and train us on Agile.  Afterwards we once again created a custom process for our given situation. We actually gave our process team a formal name this time, labeling them as the “core team”.

I have found core teams to be powerful and influential for three reasons:

1. They aren’t a part of line management. A few members may come from the management ranks, but the majority of the team are doers: people who design, build, create, and test code. This adds to the team’s credibility as you roll out the methodology to the company. Agile isn’t a management initiative being forced on everyone; it’s coming from real people who will be a part of the project teams.
2. Because the team is composed of doers, they know the ins and outs of developing in your environment. This is different than when consultants come in, suggest standard practices, and disregard the realities of a specific company. The core team has experience with your company, and as they develop a methodology they know what to keep and what to discard from existing practices.
3. Having team members from all areas initializes awareness across the company. Imagine a tester going back to the testing team and excitedly telling them what is going on with the new methodology, or a developer doing the same with the development team.

Many companies do not used a core team when rolling out agile. The hot thing to do today is to roll out Scrum with a consulting firm leading the way. I think it is good for a team to learn an agile framework like Scrum, but it is just as important to embrace the agile principles and grow the agile culture and methods from within. I think it is good for a team to get trained and supported by an agile coach, but my preference is coach who uses a Socratic approach. This type of coach asks the team questions that leads them to their own answers.  Now let’s discuss how to select core team members.

Who should be on the core team?

When you start identifying your core team, you may find yourself pursuing the best and brightest people from each area: people with a positive attitude and a pro-agile mentality; people who are open minded to change. These would be excellent attributes to list for a job opening, but do they reflect your current employee mix, the people you want to embrace the new methodology? Probably not.

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

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

You want the makeup of the core team to be similar to the makeup of the company as a whole. This will help you obtain buy-in from all employee types when you begin the agile rollout.

After you determine the types of people for the team, you need to decide on the team size. You want a group that’s large enough to capture a diverse set of perspectives but small enough to collaborate easily. 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 away for a production issue or is out due to vacation or illness.

Orientation for the core team

After your team has been named, you should schedule a kickoff meeting to set expectations and goals. You need to start the meeting by telling the team why the company is moving to agile.

As an example, let’s look at a presentation at a hypothetical company named Acme Media. Steve Winters is the agile sponsor at Acme, and he will lead the introduction to the core team. Steve starts the meeting with the following bullets:

• Acme Media’s web division is no longer a supplemental site to the television station. The websites have their own audiences and advertisers now.
• With the increase in popularity of the websites, 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, Acme’s competitive advantage will be lost.
• Acme’s existing development processes, where they exist, aren’t working well with the tight deadlines or with the evolving requirements.
• Acme needs to identify a better way of dealing with urgent projects.

As you can see, Steve’s message is tailored more to the project team than to an executive group. He speaks indirectly to revenue by saying “lost advantage,” and he mainly targets process improvement. The best thing Steve says is “the websites are no longer supplemental sites to the TV station” and “the websites have increased in popularity.” Steve is telling the team that their work is important. 

You should follow Steve’s example during your migration, especially when it comes to emphasizing the importance of the work the team does and how valuable the custom agile methodology they create can be.

Tough questions at the introduction

Of course, everything won’t 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’re likely to hear during your kickoff:

• We can’t create the methodology. We don’t know anything about agile.
• We need consultants to do this for us.
• We’ve tried to change before and failed.
• What is our role?
• What is the role of the executive sponsor?

The response to the first comment is easy. The team will be trained and soon will have a basic understanding of agile principles. If you’re lucky, a few team members will already be versed in agile.

On the second question, they’re partially correct. You’ll bring in a consultant or an agile guru to train the team on the fundamentals and potentially the Scrum framework. But the consultant won’t create the methodology for you: the team will create the methodology with mentoring along the way.

The third question is a warning sign to you if you don’t know the details of a past failure. Was the failure 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 attempts to change processes.

Assuming the issues related to a previous failure no longer exist, you can explain why the migration should be a success this time:

• The design will be co-created by experts who know the business well: them.
• The team won’t be forced to remove a legacy process if it’s proven and adds value.
• The approach won’t be shotgunned into the organization. The methodology will be built iteratively and will be deployed iteratively to mitigate risk. In addition, the new process will not be used on a mission-critical project until it has been piloted and vetted.

Answering the question about the team’s role is simple. The team will learn about agile and use this information to create the agile methodology. In a quick summary form, they will do the following:

• Train
• Document the existing development process
• Determine what to keep and what to discard from the current process
• Compare the existing process to a pure agile one
• Design a new methodology based on agile principles and the findings from the organizational assessment
• Get feedback on the design, and tweak it
• Pilot the design on a medium-priority project
• Adapt to pilot findings
• 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 (Note that there are multiple scaling methods depending on organization size).

The sponsor will conclude the kickoff by telling the team he will clear roadblocks for the team and to be a liaison to the executive team at large.

Do you really need a core team?

The core-team concept may seem like a lot of work. To some extent, it is; but the return on the investment is worth it.

I have seen other models work, especially in smaller companies. In smaller companies, the managers are often doers, too. In some companies I have worked with, the company owner also writes code.

If you’re in a smaller company, you won’t need this ceremony. You’ll probably have most of your company involved in the migration due to your small size. In effect the whole company will be the core team.

Those of you in medium to large companies should appreciate the core-team approach. Change is difficult to drive through larger organizations, and having a core team makes the road a little easier to travel.

This entry was posted on Sunday, October 18th, 2009 at 10:13 am and is filed under Teams. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.