Agile Software Development

In light of the recent news about American Airline's maintenance problems, I sat down and talked with my Dad about aircraft maintenance. You see, my Dad was a maintenance Crew Chief for Pan American Airlines for nearly 30 years and I wanted to understand how things got so bad for American. My Dad explained the inner workings of Pan Am's maintenance program to me. The program dated back to late 1960's and early 1970's and was remarkably agile-sounding. Here's the program in a nutshell.

Aircraft are regularly called in for routine servicing. The servicing was usually scheduled for about 3 days. A QA specialist (or several QA specialists) examined the aircraft and used a set of cards to write up work orders for each item that required servicing. The QA specialist then sorted the cards by theme (interior, engines, avionics, etc.), estimated how many items could be completed in 3 days based on historical data, and slotted them on a task board. The crew chief for each "theme" area would pick up the cards for his team. The crew chief and his team would triage the work items and prioritize them. Then, the team members would select the work items they would work on and provided the crew chief with time estimates to complete each of the tasks they selected. This allowed the mechanics doing the work to actually estimate the duration of their tasks. The team would then commit to completing the tasks within the 3 day service period. Each day, they'd check in with each other to make sure things were on track. During the service period, the crew chief worked on some maintenance tasks, but he also made sure that everyone on his team had what they needed to get their job done. At the completion of the service period, the QA specialist would come back and inspect each maintenance item and either accept or reject them (and FAA inspectors checked things as well). Team members were also encouraged to think about how they did their job and suggested new or better ways to do things (in fact, they received monetary incentives for coming up with innovative ideas).

Now, I don't know about you, but this sounds very much like Scrum to me. If you think about it, we have a highly complex piece of equipment with multiple integrated systems. You have a mission critical maintenance program. We have high priority items that need to be completed...you know done done...to keep the aircraft safe and airworthy (and other that are lower piority like a reading lamp that isn't working). You can't mess up here. So how do you do it effectively and efficiently: Scrum. Here's how I see it:

We have a time boxed iteration (the 3-day service period). We have a product owner (the QA specialist), a ScrumMaster (the Crew Chief) and a team (the mechanics). We have a prioritized backlog (the task board and task cards) and team members selecting their tasks, providing task estimates, and committing to a team goal of having the aircraft ready to roll in 3 days. We have a daily stand up (checking in to make sure they're on track). We have a servant leader ensuring his team has what it needs to meet their goal and we have a product owner review at the end of an iteration. And most importantly, we have retrospection and continuous improvement. Seems like Scrum to me.

So, maybe Scrum is just a repackaging of things we already knew that worked well. It's just being applied to software development now instead of aircraft. Toyota picked up on much of this and Taichi Ohno implemented lean manufacturing there in the early 90's with a lot of similar tactics. Maybe we shouldn't be too proud of ourselves for discovering something new...we really just rediscovered something old that worked and there's nothing wrong with that. So, let's file this one under "Nothing New Under the Sun". Or better yet, let's file it under "My Dad Was a ScrumMaster", he just didn't know it.