Mistake #1: Skimp on Training and Education
Perhaps the most common mistake companies make when scalingagile is to skimp on internal training and education. When ﬁrstbeginning agile, pilot project teams typically are encouraged in theirpursuit of agile training. Often the entire pilot team is sent to a classto learn about the processes and/or the practices of various agiledevelopment methodologies.Teams may be trained in test-driven development, agileplanning and estimation,Scrum, automated testing,and more. As a follow-upto these training activities,many early adopters alsobring in agile coaches andconsultants to reinforce theirtraining. The teams oftenwork with these expertsuntil the new practices orprocesses are establishedhabits that can deliverreliable results.Unfortunately, these introductory educational strategies andactivities tend to dissipate as organizations scale. As more andmore teams transition to agile, cost-conscious managers attemptto “make do” with internal resources. Never having experiencedan agile transformation on a broader scale, these early adoptersoften rationalize that the pilot project team members who havereceived special training and coaching will be able to roll out agiledevelopment to the rest of the organization. However, even agileexperts, those with at least ﬁve years of agile experience, admit theycontinue to learn every day, so imagine the disadvantage of a smallteam with less than six months experience attempting to lead an agilescaling project.In the end, there is no substitute for experienced agile coachingand consulting. Most teams scaling agile face similar challenges,so bringing in experts who have already successfully proliferatedagile across enterprises can make all the difference in the speed andultimate success of deployment. A relatively small upfront investmentin planning, onsite coaching, and on-going mentoring can keepteams from spinning out of control and wasting time attemptingto overcome challenges that many experts have faced on previousprojects. In addition, whether we want to admit it or not, internalcolleagues – even trained ones – often don’t carry the same weightas outside consultants who may have quite literally written the bookon an agile methodology. When an industry authority offers advice,teams are signiﬁcantly more likely to follow it because it’s objectiveand based on broad experience.Instead of placing the burden of scaling agile on those internalmanagers and developers who have been part of a successful pilotproject, a more potent recipe for continued success would be toselect those team members who could make the transition to goodteachers and pair them with external coaches. These internal coachescan become crucial agile champions who will carry the agile torchonce the external consultants leave and can serve as the ultimatedifference between long-term success and failure. Nurturing andpromoting these motivated team members can help institutionalizeboth the practices and values of agile development for lasting change.
Mistake #2: Practice Agile In Silos
Because agile isoften a grassroots-driven phenomenon,processes andpractices sometimesevolve out ofsync. Differentteams within thesame organizationtry different methodologies, follow separate standards, or evenimplement speciﬁc practices in dissimilar ways. These teams oftenoperate in silos, unaware of what others in the organization may bedoing in terms of agile. As a result, they may have developed theirown working methodology, with their own preferred practices andtracking and reporting systems. This works in small environmentsbut can be disadvantageous as agile methods spread through theorganization. Even small inconsistencies can lead to signiﬁcantdifﬁculties in integration, tracking, and productivity. They can alsolimit a company’s ability to build an adaptable organization that isable to leverage consistence training and education, project team andteam member reassignment, and enterprise planning and reporting.To combat this “silo syndrome,” a majority of companies that havesucceeded in scaling agile have leveraged an internal service-orientedteam dedicated to the consolidation, promotion and dissemination ofagile knowledge and practices. Often emanating from early adoptersand pilot team members, this reference team has some of thecharacteristics of prior process groups in terms of maintaining a bodyof knowledge, but philosophically operates in much more of a servicerole. Since every company tailors agile methodologies and processesto work within their speciﬁc business model and constraints, it fallsto this core team to spread the word and act as a resource to newteams as they transition to agile development methods. With in-house access to their company’s unique brand of agile, customized totheir speciﬁc needs and culture, new teams can obtain best practices,recommendations, and strategies from this readily available repository.