An Agile Blue Angels Team

Posted by Chris Sims on May 11, 2009

Sections

Process & Practices

Topics

Agile ,

Agile in the Enterprise

Tags

Continuous Improvement ,

Coaching and Mentoring ,

Scaling Agile

Promoting, sustaining, and evolving agile practices in an organization requires expertise and experience. Initially, many companies bring in outside experts to help get things started. Laura Moore has described a model, based on the Blue Angels, which companies can use to develop and deploy internal experts.

Laura explains the Blue Angels' model this way:

• Anyone can apply to become a Blue Angel, but the existing team has complete say in who joins. It's clear that they pick the best of the best and require not only ace skills but also the ability to represent the team and the Navy in the best light.
   
• You serve only three years as a member of the team. One year to learn your stuff. One year to do it best. The last year is dedicated to training your replacement.
   
• After your stint, you return to real life. This opens spots for the next crop of team members and ensures that everything you've learned about being the best is carried back out to the Navy at large to help the whole organization improve.
   

Laura goes on to describe how such a model could be adopted in a software organization. She looks at the idea's impact on various people in the organization, including: a star developer, the CIO, the manager of a developer who is accepted into the program, and even a non-star developer. In each case, she finds benefit.

Would such a program work in your environment? Leave a comment and share the reasons why, or why not.

1. Back to top

   Blue Angel Model from 1980s

   by Scott Duncan

   When I was at Bellcore (now Telcordia) and doing some studies of industry quality and productivity, a large insurance firm had something like this.
   
   Programmers, being inclined to want to "fix" or "cleanup" code, would make these refactorings (today's term) but not formally account for the changes (in time or testing). This was a problem, but the firm did not want to discourage the idea of making such imporovements. So they set up a special group in their IT organization staffed by ~1% of their total headcount. The group's job was to look into code not currently in formal production enhancement/maintenance and make improvements. (Keeping the focus on code not in mainstream work meant schedule and quality of existing work was not impacted.)
   
   I do not recall how they bootstrapped the group to start, but there was ~1 year limit on being in the group. They way you "qualified" to be in the group was by pointing out, while doing the mainstream work, modules that you felt needed the refactoring attention. This was documented in a DB used by the refactoring group to decide where to focus their attention. Also, back then, McCabe complexity analysis (including Battlemap, not just the number) was popular in large IT shops, so they used this approach to highlight possible code that could use refactoring as well.
   
   When it came time for a person to rotate off the group and go back to the main IT development/maintenance "pool," those in the group, with input from management, would look at the suggestions in the DB to see who seemed to have been making the best suggestions for where improvements were needed.
   
   Not sure how long this lasted as I moved on to other activities in Bellcore and was not able to do any follow-up on my industry "interviews"/studies a few years later. But the idea has stuck with me since and I have suggested it to folks over the years in traditional, phase-based development areas.
   
   Agile's iterative/incremental approach and the formal recognition of refactoring make this specific approach to code improvements less meaningful. But, for those in a more traditional IT development/maintenance structure, this still seems to have some merit. I know developers did aspire to get into the special group, so it was viewed as a "reward," of sorts, and recognition for development ability.

   Reply

• Older >