The Air Force Academy Gets Lean

Capstone course embraces customer-centric approach

I can always tell when one of my students has been in the military. They’re focused, they’re world-wise past their years, and they don’t break a sweat in the fast pace and chaotic nature of the class and entrepreneurship. Todd Branchflower took my Lean LaunchPad class having been entrepreneurial enough to convince the Air Force send him to Stanford to get his graduate engineering degree.

In class I teased Todd that while the Navy had me present my Secret History of Silicon Valley talk in front of 4,000 cadets at the Naval Post Graduate School, I had yet to hear from the Air Force Academy.  He promised that one day he would fix that.

True to his word, fast-forward three years and Todd is now Captain Todd Branchflower, teaching computer engineering at the Air Force Academy.  He extended an invitation to me to come out to the Air Force Academy to address the cadets and meet the faculty. Besides the talk I brainstormed with Todd and other faculty on how to integrate the Lean LaunchPad into the Air Force Academy Capstone engineering class (a Capstone class puts together all the pieces that a students has learned in his or her major.)

Here’s Todd’s story of how we got there and progress to date.

——-

Not That Long Ago
In 2007, I graduated United States Air Force Academy as a computer engineer and entered the Air Force’s acquisition corps, excited and confident about my ability to bring technology to bear for our airmen.

Graduation day with classmate Joseph Helton (right), killed in action in Iraq in 2009

And I couldn’t have been put in a better place: testing the Air Force’s newest network security acquisitions. I was their technical man on the inside – making sure big defense contractors delivered on their promises. We were modernizing datacenters, buying vulnerability-scanning software, and adding intrusion detection appliances – all things typical of anyone running an enterprise-scale network..

I was in the thick of it – chairing telecons, tracking action items, and drafting test plans. I could recite requirements and concepts of operations from memory. I was jetsetting to team meetings and conferences across the country. I was busy.

Sure, I wasn’t working very closely with the airmen who were going to use the equipment.  But they called into the weekly telecons, right? And they were the ones who had given the program office the requirements from the outset. (Well, their bosses had.) And I’d distilled those requirements into system characteristics we could measure. Well, more measurable versions of the original requirements. And meeting the requirements was the most important thing, right?

Doing it Wrong
Here’s what I learned: I was doing it wrong. The way our process worked, customers were just a stakeholder that provided input – not drivers of the process. That meant that program offices were only accountable to a list of requirements, which were locked early. Success only consisted of passing tests against these requirements, not delighting our airmen. I began to wonder – how could we learn about user needs earlier?  How could we deliver them solutions more quickly?  More cheaply?

It was only after returning to Stanford and taking the Lean Launchpad class that I became convinced that a radically different, customer-centric approach was the solution. I returned to the Air Force Academy as an instructor in the Electrical and Computer Engineering Department, intent on spreading the gospel of Customer Development and Lean.

Our existing Capstone senior engineering design course followed the defense acquisition process; the focus of defense acquisition is to “nail down requirements” early and manage customer expectations to “avoid requirements creep”. I saw this as counter to the joint, iterative discovery process between entrepreneurs and customers I had experienced on my Lean Launchpad team.

I kept in touch with Steve as I started teaching. We discussed how the Lean Launchpad approach might find a place in our curriculum, and how it might be adapted to fit the unique Air Force Academy / military environment. We grew excited about how showing success here might prove a good model for how it could be done in the broader Air Force; how exposing future officers to the Lean philosophy might bring about change from within.

So when I invited Steve out to the Air Force Academy to speak last spring, there was more at stake than the talk.  We set up a meeting with our department head, Col Jeff Butler, and Capstone course director, LtCol Charlie Gaona, to pitch the idea.  They shared our enthusiasm about the impact it could have on our future design projects and how it might bring a change in perspective to our acquisition corps. They gave the go-ahead to send a pilot team through the program in the Fall semester, with the potential for it to be applied across the entire course if we delivered results.

I found a willing co-conspirator in Capt Ryan Silva, a star instructor who mentors a project named Neumimic, using technology to aid in the rehabilitation of patients with chronic loss of limb motion.  In the first year, they had developed a proof of concept around the Xbox Kinect – and Ryan had high hopes for the future. But he found some elements of the traditional systems engineering process cumbersome and frustrating to cadets. Ryan signed on to lead our test class.

V-Model of Systems Engineering
The current Capstone class follows the V-Model of Systems Engineering, with teams creating a detailed system design throughout the Fall semester and building their design in the Spring.

There are a series of formal reviews throughout the two semesters, in line with the Air Force acquisitions process.  Requirements and a concept of operations are presented at the first, the System Requirements Review.  Cadets receive instruction on the process in about a quarter of the course lessons.

What we decided to do instead was have semi-weekly informal reviews Lean Launchpad style, focusing on product hypotheses, customer interactions, learning, and validation / refinement.  We emphasize customer interaction via “getting out of the building” and rapid iteration through “cheap hacks”.  We’ve removed most of the structure and firm requirements from the original course in favor of a “whatever it takes” philosophy.  Instruction is presented in tandem with the reviews, focusing on areas we see as problematic.

Last year’s team meeting with Dr. Glen House at Penrose-St. Francis Hospital

Back to the Present
We’re about a quarter of the way through the fall semester. Team Neumimic consists of nine sharp cadets across multiple academic disciplines. Based on initial customer interactions, they divided themselves into two complementary but standalone teams. One will focus on design, execution, and measurement of therapy sessions – building on the original Xbox Kinect work.  The other will work on adjustable restriction of patient motion – forcing patients to use the proper muscles for each movement.

Here’s Ryan on the impact of the process change:

“Last year the team found themselves handcuffed to a process that required a 100% design solution on paper before we could even think about touching hardware…crazy right?! We spent the entire first semester nailing down requirements for a system that was supposed to meet the needs of stroke and traumatic brain injury patients as prescribed by their occupational therapists. For five months we slogged our way through the process emerged with a complete design for our system, custom-built to meet the needs of patients and doctors alike. Our design was flawless. We had nuts-and-bolts details all the way down to the schematic level. We were ready to build! The fact that we had yet to even see a patient or spend any real time with an occupational therapist had not even registered to us as a problem, until we were invited to watch a therapy session.

Our entire team walked out of the hospital ashen-faced and silent. We knew we had just wasted half the course designing a system that wouldn’t work. We were back to square one. The remainder of the course was spent in a frenzy of phone calls with doctors and therapists paired with many design reviews, but this time with our customers in the room. We were able to iterate a few solutions before we ran out of time, but the customers were thrilled with what they saw. I could only imagine what we could have accomplished if we didn’t waste the first half of the course on a solution that ultimately wasn’t what the customers wanted. I was fired up when Todd approached me with his idea to fundamentally change the way we did business.

So far the results have been incredible compared to last year. The team has learned more about the problem in a month than last year’s team learned in an entire semester. I’m not saying this year’s cadets are any more capable than last year’s; just that I believe this year’s team has been given a better chance to succeed.  They’re freed of a lot of stifling overhead and are embracing a process where requirements are derived from those who will actually use the system…imagine that! I’m excited to see what the team does with their remaining eight months.”

Current team members observing Dr. House conduct a therapy session

But we have experienced challenges in implementing this approach. Here’s what we’ve noticed so far:

In typical Lean Launchpad classes, students apply as teams with their own idea.  There’s also the potential for teams to pursue the opportunity beyond the class if they’re successful. In our Capstone, projects are predetermined and cadets are assigned based on preference and skill set.  Cadets will graduate and be commissioned as officers, doing various jobs throughout the Air Force. It’s highly unlikely they’ll be able to continue their project. These factors might make the initial motivation of our team less than that of other Lean Launchpad teams.  We found that early interactions with customers excited about their work went a long way to remedy this.

We’re offering cadets much less structure than they’re used to. Some cadets are uncomfortable with the ambiguity of the requirements (“What are you looking for?  What do I have to do to get an A?”).  I’d imagine this is typical of most high-performing students.

We’re trusting cadets with more freedom and less oversight than they’re used to.  There’s the potential for our trust to be abused.  I’m hopeful that our cadets rise to this challenge.  I think they’ll feel ownership of the project and empowerment, rather than see an opportunity to shirk responsibilities.

Since this course is a senior design experience, cadets expect to be “using their major”.  There’s the tendency for some to sit on the sideline if the pressing work isn’t directly related to their area of expertise.  It has taken some prodding for cadets to embrace the “hustler” mindset – to take any job necessary to move the team forward.

These are challenges we can overcome.  I know we’re moving in the right direction.  I know we have the right team and project to be successful.  I know our cadets will make us proud.

Up the hill!