Salesforce.com recently completed an agile transformation involving a two-hundred person team in a three month window. Wow, that’s the big bang approach to be certain. My friend Pete Behrens was involved in this work, so you know it’s good work and you can can find the case study at:
As is often the case, the “lessons learned” are the pithiest part. In short, Salesforce recommends:
1) have executive commitment to the change
2) create a dedicated rollout team to facilitate the change
3) focus on principles over mechanics
4) focus early on automation and continuous integration
5) provide radical transparency
6) leverage external agile training and coaching.
Paul Beavers is a Senior Director of Engineering at BMC Software, and since he was one of the lead executives in their agile transformation, we’ve been encouraging to him to share his experiences. He just started his new blog at http://every2weeks.wordpress.com/. Check it out and get a glimpse of the passion that drives so many of us to continue to improve our software outcomes.
In my ongoing discussions with companies contemplating agile transformation, I make the point that “Enterprise Software Agility” is indeed different than basic agility as taught and practiced at the team level (different practices, different stakeholders, different impediments, different scope – See Parts II and III of the book). However, for those in the process of conversion, they often want to immediately achieve the substantive benefits that enterprise agility provides. In other words, once convinced that agile can scale for their enterprise, many would like to immediately start implementing the enterprise practices of Part III of my book. Then, of course, I am forced to reveal that there can be no enterprise agility without a significant number of teams having first achieved basic team agility. (As with all things agile, it all starts with the development team.)
Recently, I was challenged with the question as to what is Enterprise Agility, so I posited the following definitions.