In 2014, developers at Alley were frustrated. When tasked with implementing a client’s new design, large stacks of files would be lobbed over the digital fence, landing with a thud on our engineers’ desks. Developers were left to sift through the bespoke pages, identify patterns, and modularize the designs such that they could be built as templates. This work was lengthy and costly.
Meanwhile, before joining Alley, I worked in a design studio and had experienced life on the other side of the table. Designs were thoughtfully crafted and sent off to external developers who we sometimes barely knew, let alone those with whom we had a trusted working relationship. Our work entered what felt like a black box, sometimes emerging sloppy or incomplete.
The experiences of Alley’s developers and designers I worked with were hardly unique — Google “designers versus developers cartoons” and you can see the playful animosity illustrated. It was against this backdrop that I was invited to join Alley to establish an in-house UX practice that would integrate design with our well-established development services. For design to be successful at Alley, I knew we needed to build a culture of collaboration where each respective group would see the other as true partners instead of adversaries.
At the time we hired our first designers, I made certain that these folks were at the table during project kickoffs and that they, in turn, looped developers in early as they began crafting wireframes and style tiles. Thanks to this approach, we put some serious dents in the wall between designers and developers. Yet at times, problematic us versus them sentiments persisted. Each time a new project came in to Alley, we formed a multidisciplinary team specially assembled for the engagement. When the project included design, a designer would join the collective. Those assigned to work together may or may not have collaborated before, and just as the two sides began to develop a working relationship, the team would dissolve, its members moving on to other various engagements. We were locked in a loop of people gathering and learning to understand one another and work together, only to disband. It was akin to a repeating cycle of what the American psychological researcher Bruce Wayne Tuckerman described as forming and storming. We needed a new approach to really bust through the design versus development wall.
We found our breakthrough unexpectedly when we adopted Agile and began executing it through Scrum. Here’s why:
Teams are now “persistent.” Once we began working with Scrum, we quickly realized that designers needed to be embedded in a stable team. On our Scrum teams, designers and developers stand shoulder-to-shoulder, working on product after product, learning about one another’s work and communication styles, skills, and strengths. They develop team agreements together, feel stress together, and laugh together. They go beyond forming and storming to norming and performing. Team members build psychological safety where individuals are comfortable asking hard questions, offering honest critique, admitting mistakes, and learning from one another. This translates into better products for our clients and ever-smoother launches. Permanent teams of people with differing core skill sets removes the “them” entirely. There is only “us.”
Scrum rituals promote visibility and understanding. Daily, our teams have Daily Scrum meetings where team members report on work progress and raise “blockers.” Weekly, team members demo what they have accomplished and plan their collective work for the coming Sprint (we work within one-week cycles). At this regular touch point, developers can readily see a designer’s work output like wireframes, style tiles, or interactive prototypes and offer suggestions or ask questions. In turn, designers can provide feedback on design implementation before work is presented to the client. Scrum rituals encourage deep listening and learning about one another’s craft. As designers and developers understand how they each work and why they make the decisions they do, trust builds. No black boxes here!
Scrum promotes the team, not the individual. At Alley, people have official designer and developer titles that signal their core skills. But in Scrum, there are only three roles: Scrum Master, Product Owner, and member of the Development Team. Put another way, everyone on a team is responsible for the delivery of the product, regardless of their main skill set. Everyone is incentivized to think about how their work impacts the team and ultimately brings business value to clients. A designer supports the team when they think about the development implications of their design choices. Likewise, a developer supports the team when they seek novel or efficient ways to bring innovative design to life. Both parties are not only seeking to do their best work but to elevate the work of their team members.
At Alley, our ultimate goal is to deliver business value to our clients through top-notch design and development services. To do that, we need all team members to pull in the same direction and to work in sync. For our designers and developers, Agile has made this more possible than ever. If you’d like to learn more about our design process, reach out on Twitter or subscribe for updates using the form at the bottom of this page – we’ll be sharing more design posts in the near future.