My Dad was a ScrumMaster

Thursday, April 17, 2008 9:49:56 AM (Mountain Daylight Time, UTC-06:00)

PanAm 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.  We 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 others 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.

Thursday, April 17, 2008 10:51:53 AM (Mountain Daylight Time, UTC-06:00)
Great Story of the success in agile. I would love to hear more from you and your Dad. - "Nothing New Under the Sun" is true but our 21 Century and information-centered context is very different than Pan-Am. Software is harder to put your hands-on and more fungible. Many software failures are not life and death. I would love to see you talk to your Dad again and highlight the difference in context and what we can learn / do-better in our context. Maybe where does your dad see a difference in emphasis. Did it scale further in PanAm than the maintenance team? Why not? A good story breeds more questions - congratulations on a good story!
Thursday, April 17, 2008 2:08:19 PM (Mountain Daylight Time, UTC-06:00)
Hey Chris...good post I am glad we had that little talk. So Iam a scrummaster!
Popa Spags
Thursday, April 17, 2008 3:40:53 PM (Mountain Daylight Time, UTC-06:00)
Thanks Ryan. It was really interesting speaking with my Dad about this topic. It's kind of funny, I spent a good number of years of my childhood hanging around aircraft at Pan Am. I always knew what my Dad did for a living, but I never knew how he did it. This was a really great chance to connect on a level we never did before. My Dad loves to talk about his days at Pan Am, so I'll definitely pass your questions on to him and will provide more info on this. I love your questions and think digging deeper might yield more interesting conversations.
Thursday, April 17, 2008 3:42:05 PM (Mountain Daylight Time, UTC-06:00)
At Dad: I'm glad we talked too. It was really interesting learning how you guys did the work that made Pan Am so great.
Monday, April 21, 2008 4:35:32 PM (Mountain Daylight Time, UTC-06:00)


I agree that there is nothing new in scrum, but i take exception to the comment that an interior light bulb is a minor failing that doesnt need fixed.

In the case of SwissAir 111 it was a vcr that didnt work. It failed the power lines to it recieved to much voltage and melted the sheathing on the wires, bare cables started sparks, and the airliner crashed into the ocean.

TWA 800. In this case it was Reading lamps. If anybody had checked why the reading lamps werent working they would have discovered the short circuit that ignited the (nearly) empty middle tank.

The simple fact is that when human lives are at stake, every issue is life threatening. Dont forget that your software could be used in these systems, and engineer your code as if it is.
Anonymous voxel
Tuesday, April 22, 2008 9:36:01 AM (Mountain Daylight Time, UTC-06:00)
Thanks anonymous. Wasn't implying that lightbulbs were unimportant. It was just an analogy of prioritized items. And you are correct, even small things can gunk up the works.
Tuesday, April 22, 2008 9:36:54 AM (Mountain Daylight Time, UTC-06:00)
This one is really good example to explain what is mean bu SCRUM.
Nice article.
Prashant M.
Comments are closed.