What does Continuous Delivery have to do with assembling bikes?

A key part of successful DevOps transformation is culture. Bringing together groups across the organization to work seamlessly together is one of the biggest challenges. Operations, dev, QA, and the business have different perspectives and approach their tasks differently. Their KPIs are different, and the context in which they work and the tools they use vary greatly. In the Continuous Delivery business unit at CA, we know this. We talk to our customers and we understand the challenges they face. But rarely (other than a DevOps simulation) do we get to live it in person.

This month, teams like ours, participated in CA Together in Action, the company’s worldwide volunteer initiative whereby employees can take time out of their workday to participate in a variety of community-based activities. During a cross-departmental meeting that brought together both technical and business-focused employees ranging from sales to developers, we got the opportunity to participate in a truly unique team building event, while giving back to our local community.

In an exercise designed to improve teamwork and help us understand what it takes to efficiently build products, we were asked to assemble kids’ bikes for a local charity. We broke into small teams, were given bike parts and a bag of tools, and set loose to do our best. The effort had a set time limit. If we finished early, we could add “enhancements” to the bikes (streamers, bells, etc.) Then, we “marketed” the bikes to the room to see who could produce and sell their product best.

This project, just like any other project, had major challenges. No one on my team was handy with tools, and we struggled with the instructions and basic assembly. We had to turn to other teams for guidance and hands-on help. They were also under a deadline and helped as much as they could, without impacting their own delivery schedule. Sound familiar? Our team also had very different working styles and goals. Some wanted to read the instructions and come up with a plan, some wanted to just dive in and start assembling.

Some wanted to move directly to the enhancement stage, and some wanted to do methodical testing on each assembled part. We had a common mission, but that’s about all. What we needed was a common framework to align our work. We needed a consistent work stream to provide a model for success. By not having that governance/management/orchestration, we struggled and it impacted the final product.

When the time ran out, we found that our bike had some issues. (We cut out testing due to time.) The product wasn’t quite “correct” – the wheels were on backwards. But we did our best, marketing the best features and working behind the scenes to do a “hot fix” on the discovered issues. Had we discovered these problems earlier, when were actually doing the work (shifting left) the problems would have been much easier to solve. But here we were, frantically doing rework while “marketing” was selling our product to the room.

And then we got a big surprise! After we marketed the products and the best bike was chosen, we got to actually meet our customers. The event planners, Odyssey Teams, brought in the group of children who would be receiving our bikes. In a very emotional moment, we were face to face with our end users: disadvantaged children who had never owned a bike and could barely contain their excitement about receiving the product we built.

We learned a bit about them: that they participated in sports activities at the local Y, that they were from East Palo Alto, and that this was probably the first time for many of them to be in a huge office building. We spent some time with our customers, adjusted their new bikes, and talked about their specific use cases (where they planned to ride the bike, how much fun they were going to have).

This brings up another point. Would it have changed our effort to know our end customer while we were doing the work? What if we understood their use cases better? Maybe the kid who was receiving our bike planned to do more trail riding that road riding: we could have chosen different tires. Or, if we knew that the girl receiving our final product really liked Star Wars we could have decorated the bike with appropriate stickers. And what if we knew that the recipient would be relying on the bike we built to get them to school every day? Would we have taken the time to make continuous testing part of our delivery flow rather than just rushing to deliver on time?

Meeting the kids created a notable shift – and that shift of understanding translates directly to a shift in culture. Teams who were “too busy to help” other teams because of the tight deadlines were able to make time to help once we understood who would be relying on our products. People who were visiting with other colleagues doubled down to get the bikes in the best possible shape for delivery. Teams came together in a whole new way.

Some comments from the event

“Knowing who we were doing this for, if we would have known in the beginning, it would have ultimately changed how we did a lot of things. We would have certainly tested these bikes extensively!” [1]

“You realize that what you do has such an impact on other people. Simple things matter. Details matter.”

“It really drives home the importance of everyone understanding who their end customer is, their use cases, and working to a common vision.”

“We get so into the grind to meet deadlines, but when you think about the end customer, it reminds you why we’re here and what we’re doing and how we’re going to help our end customers achieve their goals.”

Team building in your own organization

It was a very worthwhile exercise. For more information about these types of events, visit Odyssey Teams.