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.
Mon, November 03, 2008
CIO — 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 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.
