How the waterfall methodology is exhausting your team and weakening your final product.
One action that haunts many software teams is the dreaded “handoff.” It jerks forward like a game of telephone — with one idea given by stakeholders to product managers, product managers to designers, and finally from designers to developers. The result is either (a) different from what was envisioned, (b) a product whose requirements have been rigidly adhered to but never validated, or (c) a total mess. This affliction, let’s call it handoff-itis, and its accompanying symptoms of frustration and confusion often occur on teams that build software according to a waterfall methodology.
The waterfall method has been around since 1956(!), and in a 1970 paper, computer scientist Winston Royce admitted the waterfall method had its flaws, namely that the design iterations didn’t work as they were supposed to (successively and iteratively).
At Pivotal, we approach software differently (we are well past 1956 after all). There is no handoff, there is simply an Agile, balanced team — a small co-located team of stakeholders, and all relevant disciplines, that work together everyday to create a product that provides value. The team bears shared responsibility for building something usable, and we find that alignment results in better user experiences.
We wanted to delve deeper into the relationship between developers and designers, so we enlisted two pairs — designer Jackie Ho and engineer Taavo Smith along with designer Aly Blenkin and engineer Christopher Jobst — to explore the intersection of these two disciplines, and the effect they have on each other.
Note: This interview has been condensed and edited for clarity.
Built to Adapt: What’s a typical “waterfall” relationship like between a designer and developer?
Taavo Smith (Engineer): In other jobs, there is another person who makes up what needs to be built, how it should look, and they send me something like a JPEG of what it is, before I have to carve it up and turn it into HTML. In this method, designers are incentivized to think of engineers as people who are always trying to cut corners and say no to various design flourishes, or say no to various features.
It doesn’t help engineers either, because we’re being held to deliver quickly, but we’re also being told to build things that maybe haven’t been validated or are unnecessarily complex for one reason or another.
Jackie Ho (Designer): I’ve definitely worked in similar environments where as a designer, I feel like I have to “get it right” before I show it to anyone. I’d spend weeks crafting a feature and afterwards would say, “Oh, this is great, it’s brilliant. I’ve thought about every edge case. It’s ready to bring it to developers.” And we’d bring it to a planning meeting and everyone would be confused or not understand why things fit together certain ways, and then I’d have to explain it. Meanwhile, they’re wondering: “Why is this even valuable? This is so complicated.”
It’s this culture where an engineer will say, “Hey Designer, the thing that you bring to this meeting has to be perfect.” And at the same time, the designer has a similar attitude by saying, “Ugh, Engineer, why did you get it wrong? Obviously I drew these ten arrows showing the logic of how this thing works with that thing. Isn’t it clear? Why is it so hard to build it correctly?” I think this frustration happens on both sides when designers and developers don’t talk enough.
Large user stories only make the situation worse. For example, say someone is working on my feature for three weeks with few touch points in between. During the time that they’re working on it, things might change, new insights might be learned, which creates all sorts of problems with a handoff.
BtA: How does this approach differ to one where there is no handoff?
Aly Blenkin (Designer): Instead of starting with the solution, we start with a general understanding of the problem. We try unpacking that problem and understanding it from the user’s perspective and using that as a foundation to start building out our designs and our ideas. Once we have that foundation, it allows us to eliminate risk and we do that through a balanced team: so having designers, product managers, engineers, data scientists come together with a multi-disciplinary approach to the way we build software.
Christopher Jobst (Engineer): I think Aly put it in a really good way. When a company comes in and asks us for our help with a product, we will talk to them about their needs, but then we will also totally switch 180 degrees and say, “What do the users want? How do they want to use this product?” It allows us to have more of an understanding of the user’s needs and empathy for what they’re doing.
Taavo: I love working with designers with this approach. They make me look really smart, because I don’t build things that my users don’t need. That’s the easiest way to go fast.
BtA: Why do you think this handoff process still exists at some organizations?
Chris: I’m not sure why handoffs still exist, but I think that’s partly because that’s how it’s always been done.
“We need to have the authority to really validate with users and say no to stakeholder requests that contradict what will actually solve the user’s problems.” —Taavo Smith
Taavo: A balanced team is kind of a new idea, and it’s really threatening. It says that teams need to be collocated and independent. We need to have the authority to really validate with users and say no to stakeholder requests that contradict what will actually solve the user’s problems. That’s really controversial in a lot of organizations.
BtA: How often do either of you find yourself cross-pairing with a developer or designer? What is that cross discipline pairing like?
Chris: I feel like it is just making our products so much better and so much more usable and user friendly. Having that integration with design rather than some sort of a hand-off, just means we get something into user’s hands quicker.
Aly: Establishing a common vocabulary and communication is way more streamlined when you constantly pair. I think it reduces the amount of issues, or misunderstandings, that you might have if you’re not constantly pairing together. This has really helped me understand and think about the tech stack and also my design decisions. By pairing, you come up with creative ideas together, which are usually better than what you thought of before.
BtA: Does a balanced team approach facilitate communication organically, or does this communication come out in stand ups and then grow from there?
Jackie: I feel like it’s generally pretty organic. If there’s something I think is really exciting, I’m sure we would just talk about it, because we’re just excited people. But definitely if we notice, “Hey it’s been awhile since engineers have seen the prototype,” we’ll schedule a time for everyone to get together. Since it’s expensive to get everyone together, we want to maximize that time as much as possible.
BtA: A balanced team approach gives developers a lot of insight into customers, how do you think that affects developers and their work?
Taavo: It’s really empowering. When there isn’t a balanced approach, I’m just hands for someone else’s brain. A balanced approach is different: my pair and I get to try and come up with the simplest possible way to implement the feature that’s going to solve the problem.
Jackie: To piggyback on top of that, there have been so many times when I’m showing a developer something I’m implementing design wise and they say, “Oh, but didn’t the user say this? Wasn’t this the outcome that the user wanted?” And I’m like, “Oh yeah. I could totally simplify this design.” I love those opportunities where developers are taking on my role and giving me better ways to design something.
Chris: I’ve noticed that I really try to think of my work more from a design perspective. I wouldn’t go so far as to say that I’m a designer, but that becomes part of my process: “What do I think the designer would want or how can I think of this from the user’s perspective?”
BtA: How do you think the balanced team approach has changed the process for designers?
Aly: Having that balanced team opens up the entire process from start to finish. It’s about not being scared to share your ideas that may not be resolved or may not even be a fully thought out, which is better than waiting a week until you have something you feel is ‘perfect.’ I try to ask for feedback earlier in the process, even if it’s just a quick sketch on the board and walk some of the people on my team through it to make sure that what I’m thinking about isn’t technically crazy.
Jackie: Yes, I’m much less afraid to bring unfinished things and get people’s feedback on, which helps me improve my designs. Also, I think developers here are very trusting that I’m not gonna go into the code base and muck stuff up. I think that can be a fear in some companies where developers feel sort of protective of their code base, and they’re like, “Ugh, this designer doesn’t know what they’re doing. They’re gonna screw things up.”
BtA: What does a good product manager do for the relationship of a developer and a designer?
Jackie: I think being able to help us prioritize, and see the bigger picture at all times is definitely very helpful.
“A good PM will show the value and know the value of having stakeholders sit in on user research” —Aly Blenkin
Aly: A good PM also helps demonstrate the value to the client and rest of the team, and defends the need for spending time on things like design/dev pairing. Because there will be people who think “That’s a waste of time,” or “It’s just slowing us down, we don’t really need to spend time doing more chores on tweaking behaviors or interactions.” A good PM will show the value and know the value of having stakeholders sit in on user research because a PM makes sure everyone involved in building a product has a shared understanding of who we’re building this solution for.
BtA: Any parting thoughts on the developer/designer dynamic?
Taavo: I have had this idea chewing around in my brain for a while. I think that even if the problem space is fairly well understood, a designer can produce more results than an additional developer. Take a team of eight people, you’re probably better off allocating one of them as a designer than an engineer, even if all you care about is raw output. There’s something about having someone paying attention to simplicity all of the time that means we write a lot less software. It’s those outcomes that are true speed. It’s not just how many lines of code, it’s how many problems are solved for our users.
Are you a developer or a designer? We’d love to hear about the ways you work together to make meaningful software. Add your story to in a response to this post.
This post is part of our series, Developers at Work, exploring the changing role of developers in today’s workplace.
Curing Handoff-itis was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
