I began working with Agile teams in early 2000, as an analyst with Giga Information Group (acquired by Forrester Research in 2003). At that time, the use of Agile processes was limited to small projects in fairly sophisticated, "type A" corporate development shops and to leading-edge product development companies. However,  even the broader software development community at that time recognized the pragmatism inherent in Agile approaches. Our research stressed that to be successful, software delivery processes needed to:

• Implement iterative and flexible cycles.
• Support the increasing diversity inherent in the development community.
• Retain outside expertise for process transition and best practices.
• Leverage predefined deliverables and experiences.   

What has changed in that past seven years? Not much. For some companies, this list could have been created today. But the means by which these requirements are achieved using Agile processes differs from the waterfall and iterative processes used in the past.

By definition, Agile teams adopt incremental development and short, frequent release cycles. Short release cycles don't make a team Agile in and of themselves, but they do provide the framework by which value can be measured and changes can be evaluated. Regarding team roles, there's no question that the composition of an Agile team has grown to include business customers, partners, and other external organizations. Without participation from those outside of the core development team, Agile projects would not achieve the necessary customer collaboration and responsiveness to change. In addition, the market for Agile software development consulting and mentoring services has taken off, acknowledging the demand for Agile skills. In fact, new entrants from Eastern Europe and South America are threatening the success of U.S. and Asian offshore firms with their Agile expertise and increased flexibility due to lack of language and time zone barriers.

However, the fourth requirement noted above is still a problem: it is rare to see an Agile team leveraging the organization's past experiences and deliverables. I have long argued that firms need to build incentives for teams and team members to collect best practices and discrete deliverables from past projects and make them available to future initiatives. Consulting firms are adept at this, as leveraged work directly impacts profitability. But few IT shops really have made this investment - "reuse" is still a bad word, connoting costs and bureaucracy rather than productivity and quality benefits. So as we consider goals for 2008, this legacy requirement really must remain on the list.

Call to Action for 2008
Can making changes in a few areas make an Agile project successful? Of course not, but I would argue that these incremental steps on the path to Agile adoption are truly the most important.   

1. Invest in your staff. Organizations are still clamoring to build internal expertise rather than relying on third-party resources. We continue to receive positive feedback from Agile developers who cite the benefits of working on Agile teams and the importance they place on their own skills development. Companies don't need to do this on their own. For example, the Agile University is offering a wide range of classes and events, addressing both development and management topics.  Perhaps this is also a role that the Agile Alliance can play in 2008 - spearheading training and mentoring initiatives that are process- and vendor-neutral.
   
   
2. Take small steps, but keep moving. Most teams have gotten past the religious issues of whether they should follow an Agile approach such as XP, Scrum, or DSDM, or stick with a legacy process. Yet there is still debate as to whether the selective use of Agile practices within a more traditional methodology is really agile. Who cares? I would challenge developers and project managers to share their transitional approaches with the broader Agile community, particularly at the Agile 2008 conference, and demonstrate the benefits of incremental Agile adoption.
   
   
3. Don't start from scratch. We learned the benefits of reuse years ago. Agile teams must also build environments to collect, collaborate upon, and share "assets" for development teams. These assets can include specific project deliverables (e.g., code, tests) or more qualitative best practices for specific tasks in the Agile lifecycle. Call it a knowledge base, repository, or whatever term will work in your organization!
   
   
4. Publicize all that you can. Sorry if this sounds like a broken record, but few teams have made progress in the area of metrics and visibility. We demand visibility into our contractors' projects, yet we don't seem to have the same level of scrutiny into internal projects. A Business Scorecard model can be one of the most effective ways to communicate a variety of metrics including operational status (e.g., quality, budget, schedule), contribution to business goals, customer satisfaction, and even staff development - all of which contribute to the success of an Agile (or any) initiative.

Note that each of these four areas addresses individual and team collaboration issue far above any technology issues. It's not a simple list, but it's certainly a reasonable set of goals for savvy Agile organizations. Good luck in 2008!

About the Author
Liz Barnett is the Editor in Chief of the Agile Journal and Principal Analyst at EZ Insight Inc. Previously Liz spent 10 years as a Vice President and Research Analyst at Forrester Research, joining Forrester as a result of its acquisition of Giga Information Group. Liz held management positions at Accenture, PepsiCo, and Atelier Research. She also was the Research Director for the advanced software development and advanced network computing research services at New Science Associates, prior to its acquisition by Gartner Group. Liz holds a patent for developing a distributed application development/CASE tool. Liz earned her B.S. in operations research and industrial engineering at Cornell University.