Partnerships Build Spacecraft

SpaceX-rocket-ship
SpaceX-rocket-ship

It wasn’t the launch (or lack thereof) of SpaceX’s first American commercial crewed rocketed spacecraft on May 27th that got me giddy about the future of space travel and beyond. Launch Day was an exciting one for my family (people are actually getting launched into SPACE!), but it was an interview with SpaceX founder Elon Musk and NASA Administrator Jim Bridenstine that sent me flying over the moon. (Sorry, I couldn’t help myself). I’m going to insert here that I know very little about spacecraft, so go easy on me if I get the shred the terminology.

Interspersed in the live stream of the launch preparations on NASA Live– fueling the spacecraft, readying the astronauts, the voices of mission control– was an interview with Musk and Bridenstine. Bridenstine’s passion about the public-private partnership of NASA and SpaceX was palpable:   

Here's what he said:

“NASA used to give the contractors the designs and the contractors would go and build it. [Now] we are not purchasing, owning, and operating the hardware.  We did not tell industry what to build; we gave them top-level requirements. We said, Here is the requirement for payload.  Here is the requirement for safety, and then we let the innovators–commercial industry, American commercial industry– innovate.  And they came up with solutions that had never been dreamed of before, and that’s the success of this program. We’re revolutionizing how we do space flight, and I think when we look into the future we’re going to see these models of doing business with public-private partnerships supply not just to low earth orbit–which is what we’re seeing today–but we’re taking this model to the moon and even on to mars.”

Did you catch that? “We did not tell the industry what to build; we gave them top-level requirements.”  The future of the public-private business model is creating partnerships. Why did this get me so excited? My answer is three-fold.

Hard Requirements Kill Innovation

Innovation in the government space can be an exceedingly tricky thing. The client wants to know what it’s going to get for its money before it buys it. Fair enough. They almost always want every little detail of the plan outlined ahead of time and want it delivered on schedule. Outlining hard requirements ahead of time can greatly hinder creativity and innovation. . If Henry Ford had asked his customers what they wanted, they would have said a faster horse. It’s been quoted a million times, and I’ve said it a million times myself, if Henry Ford had asked his customers what they wanted, they would have said a faster horse.

Think instead of what NASA did. They gave SpaceX a $400,000,000 initial investment (apparently in spacecraft sums, 400 mil is an infinitesimal drop in the bucket) and high-level requirements. In return they got the first version of the Dragon spacecraft (the reusable Falcon 9 rocket AND the Dragon cargo capsule, which paved the way for the Crew Dragon capsule). Nobody was sure it could be done. Not even Musk himself. But they did it. The highly motivated and supremely talented folks at NASA and SpaceX partnered and innovated. Which brings me to my next two points: 

Partnerships Send Spacecraft into Space

The future is in public-private partnerships, like Bridenstine said. I’d like to emphatically state that partnership is tremendously important whether it’s a public-private, private-private, public-public, or simply human to human relationship. Partnerships exist between organizations and its external and internal customers. Partnerships also exist between teams and programs. It’s no longer acceptable to purchase a product (even within your own organization) and sit back and wait a few years for it to be delivered.

Now, the buyer should state the desired outcome to the program or the team or the private-sector company and be an active participant in the product delivery process. They should work with the teams doing the work–testing products, giving feedback, failing, pivoting, and embracing changing requirements– to innovate and create unimagined business value, and with any hope, under budget.

Here’s Bridenstine on the benefit of partnering with SpaceX:

“SpaceX brings a very unique capability to the mix that NASA has been lacking, quite frankly. SpaceX is really good at flying, and testing, even being willing to fail, then fix. Fly, test, fail, fix. They can reiterate that over and over and over again very fast… The willingness to fail is something NASA has lacked for a very long time, but it’s what enables SpaceX to move so fast, to rapidly iterate and improve. NASA has this history of qualifying every component and then every sub-component…and everything has to be perfect and go perfect on every launch, and that slows us down… SpaceX has been a great partner. Make no mistake, they have pushed NASA, but I hope NASA has also come along and pushed them in a way that is unique as well [to which Musk agreed]. This partnership has been fantastic.”

By the way, the innovative product being built doesn’t have to be a manned rocketed spacecraft. It could be a case tracking system or a financial budgeting system or as simple as a COTS document management system (I wrote this blog in Google Drive). Maybe the innovation is in the simplicity of quality, reusable code or in the way governance is built into a product or it’s a beautiful customer-centric user experience.

Fly, Test, Fly , Fix, Repeat

Bridenstine outlined exactly why the partnership with SpaceX is so important to NASA: SpaceX’s ability to fly, test, fail, fix, and rapidly iterate because they’re not bogged down by the need for perfection. They operate with an experimentation and continuous learning (beginner’s mindset)  mindset. It is the very essence of the company. You cannot have innovation without experimentation and failure.  But private-sector companies shouldn’t be the only ones that fly, test, fail, and fix. With a little–in some cases, a lot– of tweaking, the government can do that, too. Experiment. Build your vision, refine your need (the what), and give your delivery partners the space (I did it again) to be creative and innovate for the how.

If NASA and SpaceX can figure out how to launch human beings into space, a matter of life and death, by establishing relationships, setting high-level requirements that leave room for innovation, and creating a culture of failing fast and often, then your federal organization and its partners can figure it out how to deliver any kind of non-life-threatening amazing product. It’s mission critical (sorry, I’ll try to stop) that you are NOT AFRAID to fly, test, fail, and fix. You will eventually fly farther, faster, and with more grace.

So, be brave. Set your trajectory, and shoot for the moon. (That’s the last one. I swear.)

I’ll leave you with these words by Elon Musk:​

“This is a dream come true….something that I thought would ever actually happen.  If someone told me in 2002….that we’d be standing here with a rocketed spacecraft on Pad 39A, I would have thought, No way this could come true. I didn’t even dream this would come true. It’s a culmination of an incredible amount of work by SpaceX, NASA, and other partners…working incredibly hard to make this day happen.”

Don’t wait for the perfect time. Start by visualizing the work.

Funny retro swimmer by the lake, at the sunset with copy space
Funny retro swimmer by the lake, at the sunset with copy space

If You Wait to Start Your Agile Initiative, You May Never Actually Start.

If you’re waiting for the perfect time to start an agile initiative or to launch a pilot program, you may be waiting quite for a while.  You won’t always have the time/space/support or even all the “right people” for big kickoffs or to “officially start” for your program. When waiting on the “boat dock of perfect,” oftentimes opportunity sails right by, piña coladas in the blender.

Such was the case with a team I’m working with at a large government organization.  They are one of the first agile pilots in the organization, and interestingly enough, they’re not IT.  The start date kept getting pushed back because someone was on vacation. Then a new job posting was waiting to be filled. Then we were onboarding a new contractor. Then it bled into the 4th of July holiday.  Then. Then. Then. You get the picture. We came to realize there would never be a perfect time to have an official kick off, training, or baseline assessment. This group of five incredibly capable individuals was eager to start and didn’t want to wait.  So, we started.  

Make Sense of the Chaos

In realizing there may never be a perfect time to start your agile initiative (hell, you may not even give a damn about an agile initiative, but know in your gut that your team can perform better), accept the fact that starting could be a little messy.  There may not be an opportunity for the team to take a Fundamentals of Agile class or make a formal transition plan. You’re just going to jump in and start untangling the hairball of workstreams, roles, and Work in Progress (WIP).

One of the best ways–not the only way– to untangle the hairball is to start visualizing the work.   A physical visualization creates the ability for a team to become aware of their norms,  processes, and communication patterns. It’s also a powerful step toward self awareness, team awareness, and team empowerment.  Often times, just understanding the team’s workflow, group dynamics, communication channels, and current team “norms” helps to level set “current state.” It creates a single lens that everyone can look through and forms a common ground.  In other words, a baseline for perspective.

In short, visualization creates data points, data points create awareness, and awareness creates the ability to make educated, data-driven decisions from a similar perspective.

1. Document the Doing

Throw a Scrum or Kanban board on the wall.Have each team member write on a Post-it each individual task they’re doing and put it in the DOING column.  (Don’t worry about the TO DO or DONE columns at this point.) Pretty soon, each team member will have a pretty good picture of all the things they’re juggling, as well as a good idea of what everyone else is doing, too. 

PostIt-with-Individual-Task-and-Workstream
Kanban-Board-DOING-column-e1574178366666

For the team that I am currently working with, there wasn’t a huge “documentation of DOING event.”  We just started by having daily stand- ups. Each day, as people talked about what they were doing, we would put Post-Its on the board, and pretty soon we were able to visualize all the work the team was doing.  

This visualization exercise was especially beneficial because we knew the team was doing work, but we didn’t necessarily know WHO did WHAT work. As the Post-Its piled up, the WHAT and the WHO became clear. (Naturally, new stuff started popping up, so we started filling in the TO DO column.)

2. Understand the Process

Seeing this big picture–actually seeing it physically in front of you– will give you some very, very powerful information.  Early on, through visualizing the work, our team was able to understand the workflow. We were able to understand the different workstreams (where the work was coming from), how work was distributed (by a single person hub spoke model), and how people got pigeonholed into work types (skill-centric roles).

It immediately became apparent that Work in Progress (WIP) was off the charts, and context switching (switching from one type of work to another) was out of control. One team member was switching across 8 workstreams on a daily basis! (How can someone focus with constant change?!) Having a better idea of workflow also allowed us to see who was making decisions and have informed conversations about work prioritization.

3. Make the Change

You’ve talked about it.  You’ve visualized it. Now, armed with your newfound knowledge, start making hard decisions and incremental changes.

Incremental Change #1

As a team, we knew we wanted to eliminate the hub and spoke model of work distribution. Our goal was two fold: to create an environment where people committed to work they are interested in and capable of, and to take the administrative duties of assigning work away for anyone individual.   We adopted Kanban, a pull system for workflow optimization.  

Incremental Change #2

In implementing the pull system, we quickly learned that when someone became available, due to their respective specialized skill set, they were not always equipped to take the next highest-priority piece of work.  We knew we couldn’t completely eliminate this from happening, but we knew we could make it a whole lot better than it was. This lead to the cross-training, “paired programming” initiative. As a non-IT department, we weren’t programming, but the idea remains the same: work in pairs to not only get the job done, but to create a cross-training learning experience.  

Incremental Change #3

Similarly, we strove to greatly reduce WIP and find the sweet spot of what we could handle as a team. We found it helpful to document WIP at every stand-up.  Dropping what we had already started wasn’t an option. So, our goal was to continue to shrink the amount of work in the DOING column. Simultaneously, we were creating disciplined behaviors. If something wasn’t ready to be worked on, we were to leave in the TO DO column until the last (ir)responsible moment.  

Incremental Change #4

To help with understanding the workstreams (some being more important or time sensitive than others), we chose a color for each one and created a legend in the top right corner of our board .  For example, blue for Quarterly Report, yellow for Data Science work. Each of our workflows and all its associated tasks would match the color of workstream they were related to. This not only served as a reminder for the team, but also provided at-a-glance information for anyone walking by outside of the delivery team.  

Kanban-Board-with-Workstream-Legend

On the same note, another trick we adopted was showing our workstream legend with the highest priority workstream on top. This would help keep us honest on our day to day decisions. When the team was prioritizing their work we could constantly compare our decisions to the workstream prioritization and make sure we were spending our time on the right things.

Don’t wait. Just start!

If you’re waiting for the perfect moment to launch your agile initiative, don’t.  Just jump in. Your team should find it immensely helpful to visualize the work and harness the power of awareness. The picture that emerges will spark conversation, and more importantly, data-based decisions for change. Your team will feel informed and empowered to create a better way of working together. Plus, they’ll create a better delivery model for your customers.  (And it’s all about the customer!)

If our team had waited for the perfect time to start, we’d still be waiting.  Since we did the very first stand-up, a person changed positions within the team; we added a contractor to the team; and we’re in the process of onboarding one more person.  Though not the ideal situation, we’ve improved by leaps and bounds. Now, when we onboard new people there will be a new baseline instead of the old way of doing things. Onward bound!