eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Through a process of continuous planning and feedback, the agile methodology ensures that value continues to be maximized throughout an organization’s software development process. Though these benefits may compel businesses to implement agile, the transition and subsequent scaling within the organization can introduce some challenges and growing pains.
While there is no perfect formula to guarantee success, there are several common mistakes that companies should avoid when making the transition to agile. These common mistakes can derail even the most carefully prepared strategy. The following are the five mistakes, followed by the corrective steps that project managers can take to avoid them in the first place.
Mistake No. 1: Skimping on training and education
Perhaps the most common mistake companies make relates to training and education. Training can obviously be time-consuming and expensive. But, when changing a fundamental business process, ensuring that team members truly embrace the hows and whys of agile is critical.
While much emphasis is placed on training pilot teams, many organizations assume that these pilot team members have all the information they need to bring the rest of the organization up to speed. This assumption fails to take into account not only the value of extensive experience and broad expertise that a professional agile coach can bring, but also the limited bandwidth of internal team members whose primary responsibility is developing code.
In the end, there is no substitute for experienced agile coaching and consulting. Most teams scaling agile face similar challenges, so bringing in experts who have already successfully proliferated agile across organizations can make all the difference in the speed and ultimate success of deployment.
A relatively small, upfront investment in planning, on-site coaching and ongoing mentoring can keep teams from spinning out of control and wasting time in their attempt to overcome challenges that many experts have faced on previous projects.
Mistake No. 2: Practicing Agile in Silos
Mistake No. 2: Practicing agile in silos
Because agile is often a grassroots-driven phenomenon, processes and practices sometimes evolve out of sync. Different teams within the same organization try different methodologies, follow separate standards or even implement specific practices in dissimilar ways.
These teams often operate in silos, unaware of what others in the organization may be doing in terms of agile. As a result, they may have developed their own working methodology with their own preferred practices and tracking and reporting systems. This works in small environments but can be disadvantageous as agile methods spread through the organization. Even small inconsistencies can lead to significant difficulties in integration, tracking and productivity.
To combat this “silo syndrome,” a majority of companies that have succeeded in scaling agile have leveraged an internal, service-oriented team dedicated to the consolidation, promotion and dissemination of agile knowledge and practices. Since every company tailors agile methodologies and processes to work within their specific business model and constraints, it falls to this core team to spread the word and act as a resource to new teams as they transition to agile development methods.
With in-house access to their company’s unique brand of agile, customized to their specific needs and culture, new teams can obtain best practices, recommendations and strategies from this readily available repository. Having this reference team and centralized body of knowledge also provides a significant leverage point from which the entire company can learn and grow.
Mistake No. 3: Ignoring Other Areas of the Business
Mistake No. 3: Ignoring other areas of the business
A mistake many organizations make when scaling is to focus all of their efforts on their technology teams. Yes, agile is a software development methodology, but successful scaling of agile methodologies is also generally accompanied by a shift in corporate culture and infrastructure for the entire company.
A manager’s focus shifts from allocating human resources to the right task for the appropriate amount of time to ensure that teams are cohesive and collaborative. Similarly, cross-departmental coordination will likely need to be extended and optimized to facilitate more robust communication and ongoing collaboration.
Managers need to pay close attention to the cultural changes that are part of moving to agile software development and allow time for them to become the new standard. This is a shift that will need to happen not just on agile teams but across teams, departments and even in the executive offices. Before long, the changes it brings will affect multiple areas of the business. Be prepared to both facilitate and allow the time necessary for it to infiltrate every level of the organization.
Mistake No. 4: Encouraging Organizational Complexity
Mistake No. 4: Encouraging organizational complexity
The natural inclination when scaling almost anything is to introduce management layers, new policies, additional processes and other unnecessary checkpoints. Not surprisingly, this kind of overhead and complexity typically has an inverse relationship to adoption speed.
In an effort to maintain consistency and control, it is natural to want to add excess management oversight and require unnecessary documentation. Don’t do it. Or, at least make every effort to minimize these tendencies. Simplicity is both one of the primary values of and critical success factors for scaling agile. Maintaining a commitment to simplicity when scaling agile processes and practices can drastically accelerate the internal rate of adoption. Adding needless complication is an invitation for failure.
Let the managers closest to the teams guide them toward the goals that have been set. Don’t confuse day-to-day project visibility with knowing the rationale for every decision the team makes. Recognizing that teams are achieving positive results overall and understanding what teams can deliver on an incremental basis is a much better use of time. This insight will provide improved forecasting for future projects and allow for much quicker response time to changing business demands.
Mistake No. 5: Failing to Scale the Infrastructure
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.
Scaling Agile Throughout All Development Teams
Scaling agile throughout all development teams
After proving the value of agile through a successful pilot project, the next step for many organizations is scaling agile throughout all development teams. While there is no silver bullet for quickly and easily spreading agile adoption, there are some common mistakes that can stand in the way. Given the broad process, engineering and management impact that agile can have on an organization, the agile rollout needs to be viewed holistically.
Without significant consideration given to appropriate training, cross-department communication, modified management practices, process consistency, organizational simplicity and adequate infrastructure, the spread of agile in your organization can be slowed, if not prevented. Start small, keep it simple, and choose processes and tools that can help you scale smart to meet your changing needs.
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.