BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

An Agile Blue Angels Team

| by Chris Sims on May 11, 2009. Estimated reading time: 1 minute |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT