Mistake No. 5: Failing to Scale the Infrastructure

By Ian Culling  |  Posted 2010-07-08 Print this article Print

Mistake No. 5: Failing to Scale the Infrastructure

Like any software development effort, the selection and implementation of tools and technologies should be driven by business requirements. Failing to consider infrastructure changes that will grow with the business and support future requirements can severely hamper any scaling effort.

With specific respect to agile development initiatives-whether it's integrated development environments (IDEs), source control tools, collaboration tools, testing tools or management tools that are being investigated-teams should consider both their current and upcoming needs and make decisions accordingly. Several factors for consideration include:

1. The volume of source code and teams requiring access,

2. The number of code branches that need to be maintained,

3. The locations of sites, remote teams and stakeholders that will be supported,

4. The number of teams, projects, clients, and/or product portfolios being managed, and

5. The quantity of features, defects, tasks and tests being tracked.

The test for infrastructure and tools quickly becomes how well they scale. The source code management tool, test tool, wiki and Excel spreadsheet a single agile team uses may work extremely well in a localized context. However, the problem domain expands exponentially when scaling across multiple teams, projects, distributed locations and hundreds of team members.

Paradoxically, any management tool has to be powerful enough to aggregate and orchestrate hundreds or thousands of artifacts (that is, stories, defects, tasks, tests, issues, customer requests and goals) as they flow through the product delivery life cycle. At the same time, all stakeholders-executives, product managers, project managers, users, developers, testers and writers-should be helped by the tool rather than bogged down by its complexity. In addition, the tool needs to provide real-time visibility into the big picture view of all projects under development.

Implementing tools that work well within the existing infrastructure and that can be accessed worldwide is critical to broad-based success. As tools and technologies are chosen for the scaling organization, a rule of thumb should be to match the tool to the growing business requirements and select one that will support the organization throughout the entire agile life cycle.

Ian Culling is CTO at VersionOne. Ian brings more than 20 years of broad IT experience to the CTO role. Ian lends tremendous expertise to his areas of responsibility, including software product management, design and development, and enterprise IT. Ian has significant practical experience with the introduction, scaling and adaptive execution of agile methods, having initially implemented strict XP with a single team in 2000. Since that time, Ian has progressed to lead and coach both small and large organizations in their transition to agile methods. Prior to joining VersionOne, Ian led the adoption of agile methods at Alogent Corporation as vice president of development, leveraging aspects of Scrum for scaling across multiple teams and products. This, combined with select XP developer practices and approach for planning and tracking, resulted in a Scrum-wrapped XP implementation (now a fairly common model within the agile community today). He can be reached at ian.culling@versionone.com.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel