The Role of the Core Development Team in an Agile Project

This excerpt from the upcoming book, Becoming Agile, discusses a necessity in ensuring corporate buy-in for Agile development: creating a collaborative team that can evangelize Agile in the company and shepherd the software engineering methodology through enterprise software development projects.

Current Job Listings

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.

MORE ON AGILE

Cargo Cult Methodology: How Agile Can Go Terribly, Terribly Wrong

7 Agile Leadership Lessons for the Suits

OppenheimerFunds Gets Return on Investment from Agile and SOA

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:

  1. 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.

  2. 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.

  3. 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 third 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.

Obtain 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 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've 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 Gastineau 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 first few weeks I like to see the core team meet twice a week for two 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 three months. The duration will decrease over the three months. You may see the weekly meetings reduced to one hour, but to be safe still ask for 6 hours per week for three months. Better to promise late and deliver early. After team selection you need to meet with the members and set expectations.

This article is based on Becoming Agile... in an imperfect world by Greg Smith and Ahmed Sidky, to be published in 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.

Copyright © 2008 IDG Communications, Inc.

How do you compare to your peers? Find out in our 2019 State of the CIO report