The Core Dev Team's Role in an Agile Project

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


Reference : http://www.pcworld.com/article/153213/core_dev_team_agile.html?tk=rss_news