 Agile teams require processes and tools throughout the lifecycle. This does not mean, however, that they must create these environments from scratch. Nor does it mean that the organization’s legacy processes and tools are irrelevant. Rather, as means to achieve short iterations, Agile teams should – selectively – leverage the organization’s software development investments as a means to jumpstart their projects.
In the December 2007 issue of the Agile Journal, I defined four goals that will be key to Agile adoption in 2008: investing in staff, adopting practices incrementally, leveraging existing assets, and publicizing successes. Of these four, the ability to leverage the organization's existing development and management assets is the toughest to achieve. But despite the challenges, schedules and budgets demand that Agile teams take advantage of existing investments.
Is this the same old reuse story? And if it didn't work in the past, why now? There is no question that for years development organizations have talked the reuse talk but rarely walked it. Today's development teams face similar issues: the not invented here (NIH) syndrome still exists, new tools do not align with legacy artifacts, and, when under the gun, developers still take the path of least resistance and create their own code. But a key difference for Agile teams is time. Dates are fixed and so team productivity demands the use of what's already there.
At a minimum, Agile teams should consider leveraging three classes of existing assets:
- - Development artifacts
- - Lifecycle management tools
- - People
It may not be any easier to accomplish than in past decades, but reusing assets on Agile teams can go a long way in helping pilot projects to achieve quick results. In addition, leveraging existing investments can help sell the fact that Agile development can result from incremental rather than radical change.
Some Artifacts Fit
Reuse of existing development artifacts is the easy part. Agile teams typically start with two areas: source code and tests. Teams access internal code housed in software configuration management (SCM) environments, open source projects, hosted on environments such as SourceForge, and test cases and scripts (manual or automated) stored in a variety of tools. There's nothing glamorous here, and this is no different than development for any type of development process. New projects must integrate with legacy applications and infrastructure. Hopefully, the integration and transformation lessons we've learned over the years from object-oriented and other distributed architectures have paved the way.
Reuse of code and tests may seem obvious, yet many organizations initially view Agile practices - particularly test-driven development and continuous integration - as completely different development approaches and don't see the logical fit with the existing development organization. True, these practices require that teams change the ways in which they create code, tests, etc. But many teams have found an easy path from legacy to Agile functional testing and build management processes by incorporating legacy code and testing artifacts.
Some Tools Can Stay
Tools aren't cheap and building the skills to effectively use tools can take years. Legacy development environments include a range of lifecycle management tools, some of which are appropriate for Agile initiatives. Even if the intention is to move to a more modern set of tools, existing investments in software and associated skills can ease Agile adoption. Existing tools should be categorized into three areas: certainly appropriate, maybe appropriate, and unlikely to be appropriate for reuse by an Agile team.
- Certainly. Don't hesitate to use existing SCM, automated testing, build management (if you have it!), and IDEs for your early Agile projects. Newer lightweight products have hit the commercial and open space arenas, but there's no reason to throw out these core development tools for Agile initiatives - especially since they can play an integration role among Agile and legacy projects. Of course, if you have the luxury of adopting newer products, that are designed for Agile practices, then the pricing and ease of use benefits will be obvious. But for those teams that cannot bring in new products, these developer-oriented tools will certainly fit.
- Maybe. Legacy issue tracking tools can be useful, especially for distributed teams, as long as you can create new templates to reflect Agile processes and artifacts. However, don't try to force-fit legacy processes for issue tracking and risk management. The nature of Agile teams' staffing and collaboration demand more flexible processes for managing and tracking issues and risks. When given the choice, Agile teams frequently use simple manual/visual tools (e.g., story cards on boards) for co-located teams and wikis for distributed teams, but the traditional database-oriented tracking tools can suffice.
- Unlikely. Traditional requirements management (RM) and project management (PM) tools have a hard time fitting into Agile projects. Some teams provide behind-the-scenes hooks from their Agile story tracking systems to a traditional RM toolset, so they can address auditing regulations and fit with broader program management office (PMO) standards. Similarly, an Agile PM tool can be configured to provide links to legacy program management tools. When forced to use existing RM and PM tools, Agile teams typically create a transformation (done by supplemental staff) from Agile to legacy tool and format, rather than burden the Agile developers with a bureaucratic environment.
Some "Traditional" Staff Must Participate
Like any other component of the development environment, teams need to evaluate the value in their existing staff. Bringing in outside expertise in new Agile practices is often the only way to get going, but managers need to consider the value that their legacy staff can bring to an Agile project. It's common see over 30 percent of IT budgets go to staff costs (salaries, benefits), not including the costs of training/retraining for new technologies or processes. Newer/younger team members may have superior technical skills, yet more seasoned staff hold the business subject matter expertise that can take years to acquire.
We would like to think that things have evolved in terms of management practices, but that's not necessarily the case! In the fall of 1995, I was part of the initial group of analysts at Giga Information Group (acquired by Forrester Research in 2003). One of my earliest research reports, entitled "Legacy Opportunities," talked about evaluating IT staff as assets and liabilities, as you would any other IT investment.
This report, written almost thirteen years ago, noted that "... the most valuable personnel stand out as those highly motivated and skilled members of the teams leading current development efforts. They take initiative, seek out new assignments and technologies, and their team leadership and communication skills are apparent from prior assignments.... As training costs are one of the largest line items on an IS budget, spend dollars wisely - investment in the top few performers will go much further than for those with weaker skills. Once top performers are trained, they can lead the remaining staff on an accelerated development path."
Not much has changed. We are enticed by skills in open source development and Agile development (most commonly found in external consultants), yet don't always value the skills in house. Agile teams today report that selected legacy staff, most of whom have deep business knowledge and relationships with business partners, are essential components of new teams. As you consider the assets within your IT organization, remember to include your staff. Investing in their expertise can be far more effective than investing in new tools.
Creating an Environment for Best Practices
Existing artifacts, tools, and staff skills will help jumpstart Agile initiatives. Once these projects are underway, the teams' experiences - positive and negative - will be essential input for subsequent initiatives. Here's where IT shops need to take the next step, creating knowledge-based environments similar to leading consulting firms.
Consultants essentially sell two things: skilled staff and past experiences. When you hire a consulting firm, you're not just bringing in smart people to help out on your projects. You're bringing in the firm's wealth of knowledge gained on other clients' projects. Effective consulting firms provide incentives for their staff to collect and share best practices. This is crucial for Agile teams, particularly those running distributed projects. You won't find much value in best practices from legacy projects (even if you've collected them), and so the responsibility must lie with early Agile pilots to establish a shared best practices environment and instill a culture of contribution.
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 earned her B.S. in operations research and industrial engineering at Cornell University.
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
Home 
