Agile Processes in Software Engineering and Extreme Programming- P2

Agile Processes in Software Engineering and Extreme Programming- P2:“The Program Commitee of XP 2000 invites you to participate in this meeting ofsoftware development researchers, professionals, educators, managers, and students.The conference brings together people from industry and academia to shareexperiences and ideas and to provide an archival source for important papers onflexible process-related topics.
Nội dung trích xuất từ tài liệu:
Agile Processes in Software Engineering and Extreme Programming- P218 S. McDowell and N. Dourambeisnew technology companies like Google and Skype. From a strategic view, there islittle alternative than to change the “old ways of working”. But for a company withover 14,000 IT employees, embedded waterfall delivery techniques, large distributedprojects and COTS applications, this a radical shift that requires a unique adoption toagile. The first step in the transformation was the creation of an internal coaching com-munity. The idea was sound; build up a specialist base of experts who could workwith teams to determine which agile practices could be applied in each team, depend-ing on their context. But agile coaching is a skill developed over time, and usuallyonly through a combination of training, mentoring and experience. This communitywas not created quickly and needed the support of seasoned coaches. New “apprentice” coaches were trained to augment the overall amount of agilesupport available. This succeeded in creating a small community of enthusiastic peo-ple, but as they were given only a brief level of training to start, many were soonfaced with the daunting task of educating hundreds of others and pushing their pro-grams to change. These apprentice coaches also faced a genuine fear that applyingnew techniques, even the most well intentioned ones, could disrupt already tight de-livery deadlines. To help, the BT agile community took on a “baby steps” approach,encouraging teams to start using non-disruptive practices such as stand-ups and retro-spectives. The difficulty with this approach has been that such non-disruptive changescannot yield the speed-to-market improvements required. There is one other major obstacle to BT’s transformation—agile is not tool-basedtechnique that can be easily rolled out across an organization. Agile is a values basedapproach that needs buy-in from teams in order for it to succeed. It can be a highlyvulnerable way to work and team members have to want to do it. However, how canBT gain this buy-in in an accelerated fashion on a large-scale?3 Joining the Dots as a Large-Scale Change AgentIt was in this context that Joining the Dots 3 was born. Joining the Dots 1 was originally a series of one day, one hundred person commu-nications events held for all of the IT staff to inform them of changes that had beenmade to the BT strategy in early 2006. The agenda for Joining the Dots 3 is quite different from its predecessor. Whilethe model of reaching one hundred people at a time is leveraged, the objective of theevent has been to do more than communicate new ways of working—participants areinvited to practice using agile techniques as a way of winning their buy-in and creat-ing momentum for change. The target set for the first phase of Joining the Dots 3 is toreach 3000 people across 30 events, leaving an option to extend the reach based onthe success of the events. The event criteria included the following: Don’t just talk about it—do it. Let the event excite people by having them give agile practices a try. Focus on agile values, principles and practices. Ensure that all participants understand the mindset shift required, rather than simply concentrate on British Telecom Experience Report:Agile Intervention 19 specific techniques that they can use. With that said, also give them prac- tical techniques they could start doing immediately with their teams. Have leaders lead the event and ensure participants have a shared context so they can action-plan next steps. This strategy has the added benefit of gaining leader buy-in to using agile, a new framework for many of them too. They also get to witness the challenges and obstacles that their teams may face when they return to their regular roles. Make it fun. If participants enjoy themselves, they’ll be more accepting to trying new things.3.1 Learning Through DoingParticipants should be able to feel the benefits of using agile rather than having totrust that it works. Hence, the bulk of the event is created around a large-scale simu-lation where twelve teams must create contraptions that move a ball across an arena. In it, they face the difficulty of meeting customer requirements as a single compo-nent while having to contribute to a multi-faceted end-to-end solution. This scenariomirrors the complexity of BT’s large scale projects and is a great place to prove thebenefit of using agile. Participants start with an agile teach-in where in a half an hour, agile is raised outof buzz-word status and BT leaders describe their personal experiences with agiledelivery, warts and all. The teach-in emphasizes the scale of the human tran ...