I recently finished taking part in a great collaboration between IDEO and Pivotal Labs. For those of you who don’t know, Pivotal Labs is one of the leading software development firms in the world and is largely responsible for the popularity of agile development. Since the app we were building is still confidential, I won’t be able to talk much about it, but there’s a bunch of interesting things I’d like to share about the agile process and how it relates to IDEO’s own process.
1. Creative execution, like software production, requires a focused process.
A typical day at Pivotal looked like this: develop—lunch—develop (with the occasional ping pong break). We had two meetings a week. The day at Pivotal was really structured around one activity, and that was developing the product we wanted to deliver. This made both design and development highly productive.
At IDEO, we design in an extremely collaborative environment where ideas are openly shared and discussed; this unstructured space facilitates thinking in a generative manner and pushing at the edges of what’s possible.
At Pivotal, the environment is almost the opposite. Days have a clear structure and each person on the team has a specific role on the project. Using Pivotal Tracker, their custom tool (which IDEO uses as well), we started the day knowing exactly what features we needed to work on. This structure was great, because from the very beginning of the project, we had clarity around the design challenges we wanted to solve. We knew we were building an app, and we knew the core features that we wanted to deliver. Pivotal’s process helped us focus in on these core features by forcing us to ask the question, “If we didn’t have this, would the experience still work?” If the feature was essential, it was at the top of the list; if not, we saved it for a later iteration. As a result, we were always designing the features we absolutely needed to get right.
While the experience of working in such a different environment was pretty jarring at first, it allowed us to design effectively once we got the hang of it. Comparing IDEO’s typical process to Pivotal’s, I see them both as important tools: IDEO’s process helps teams be generative and handle ambiguity creatively, while Pivotal’s helps teams execute and refine a more resolved vision.
2. Pair programming, when done in a space that allows both developers to evenly contribute, creates an environment of open collaboration and dialogue.
Pivotal Labs is known for pair programming in all projects, so by being at Pivotal, I had the privilege of seeing it done right. I’ve done pair programming in the past, but the small details in their practice really affected how collaborative the process was. The best example to illustrate this is the structure of programming workstations at Pivotal. When I’ve paired in the past, we’ve usually just used one computer and passed the keyboard and mouse when alternating who is typing code. At Pivotal, each pair has one computer but two pairs of mice and keyboards. This made a huge difference—not only did it reduce distractions, but since either developer could jump in and code at any time, it helped facilitate open discussions and seamless collaboration. Line by line, we were literally building on each other’s thinking.
3. Designing in code at key points allowed designers to be inspired by what was possible and also made the final design a lot easier to execute.
Occasionally, we had design/developer pairing sessions where we sat side by side, alternating between working in code and evaluating design mocks on a shared computer. These one- to two-hour sessions were especially useful for giving our designers a sense of the constraints and opportunities when it came to designing in code. For example, when designing certain animations, it’s really helpful to think a bit more programmatically about what will happen, especially for options such as easing and keyframes. By designing with code first, we could quickly explore different options by coding, trying them on a device, and refining the interaction. As tools (such as Swift playgrounds, which I’m particularly excited about) make this loop progressively quicker, I think that pairing will become even more useful and result in better design.
4. Pivotal’s approach can be applied to more than code.
Pivotal’s process changes the way I think about problems. The process of decomposing and prioritizing the project is useful not only in code, but also when thinking about a design problem. It helps you articulate tradeoffs and decide between them. At IDEO, our process is very generative: lots of ideas, lots of possibilities. It’s important to our ability to innovate. But when the time comes to begin making choices, applying Pivotal’s approach to the design process is a really useful tool for being reductive, and it’s a nice complement to how we work at IDEO.
Imagery courtesy of Pivotal Labs.