Reducing Silos and Improving Communication Between Development & Design on Your Agile Team

Ah, development and design – two practices that are so different, yet so complementary to and dependent on one another. When these two practices are siloed from each other, it can quickly become a breeding ground for miscommunication and wasted work. But, when they can collaborate with free-flowing communication, they can become a truly dynamic duo.

We know breaking down silos between development and design can be challenging. From expectation setting to documenting project requirements, there’s a lot of room for things to go wrong. Here at Zenhub, we aim to foster a process that allows design and development to work closely. We’ve seen great success in the way our teams work together by leveraging a variety of check-ins, meetings, requirement gathering processes, and other techniques (yes, even our product in some cases!).

In this blog, we’ll walk you through tried and true ways our team breaks down silos between development and design throughout different stages of a project. The coolest part? You’ll learn from the perspectives of two of our very own team members – Brian Leung, Product Design Lead, and Andrew Nickerson, Engineering Manager. These two work together on a regular basis, so everything you’re about to read is straight from their real-life experience making Zenhub!

Product definition ensures dev and design are working towards a common goal

At Zenhub, the first step to breaking down silos between development and design is to create alignment as early as possible. One notable method we use is a ‘3 In the box’ meeting. We’ll run a 3 In the Box meeting at the start of a project. This involves making sure we have technical (development), user (designers), and business (product managers) perspectives when discussing our upcoming feature or project.

The first meeting is used to discuss goals and understand the project’s complexity from different perspectives. Discussing feasibility and complexity as early as possible helps us set realistic expectations. The goal is to optimize the product development process to avoid wasting cycles and to help us conduct spikes or validation as early as possible. Following the initial 3 In the Box meetings, we’ll have check-ins about once a week to prevent silos and improve visibility across the product development process. As these conversations continue, the scope of the project starts to take shape.

Designer’s perspective on product definition

Using 3 in the Box meetings, our design team can start identifying complexity as early as possible. Typically this would happen before any design work has been started, so that development can leverage an unbiased opinion on feasibility. Our design team may sometimes facilitate workshops during the starting phases of a project, this may include things like design sprints or affinity mapping to gain customer empathy and build a collaborative process across functions. For designers, 3 In the Box meetings are a chance to showcase artifacts from different design phases (user research or usability results), allowing us to drive the conversation from a user perspective. The ultimate goal is to ensure the team feels confident moving forward with the project.

Developer’s perspective on product definition

At the product definition stage, our development team here at Zenhub is looking to identify any potential technical challenges, so that we can break down work into actionable steps. Any functionality that’s not already in the product and has some complexity needs to be identified as needing a spike, so we can work through the details before we commit to any work.

As a team, we focus on shipping as early as possible. During product definition, our developers will offer alternatives to address the business and user needs. For example, instead of building our own notification system, we might consider leveraging the Github platform, as it already exists and may help us ship faster and bring improvements to our users more quickly.

Technical breakdowns help with scoping and story pointing

As the project comes together, design and development work together to identify implementation challenges and to collaborate on feasible solutions that satisfy the use case. The technical breakdown allows us to prioritize the core experience first. Once it’s finished, we re-evaluate if any of the out-of-scope issues are worth finishing before our initial release. The project spec outlines these core experience features and will have been broken down into user stories and design specs. Once the dev and design team feel like they have enough definition on the spec document, we break them up into GitHub issues and estimate them. Building alignment throughout the product development process helps us simplify the estimation process and creates better approximation for scope and deadlines.

Designer’s perspective on technical breakdowns

When building out a project spec document, we’ll create an epic in Zenhub and document all relevant information there. It will then be broken down into individual issues as they become ready to be worked on. Designers use the squad’s Workspace, as well as the Product and Design Workspace, to keep track of work being completed per squad and per function. We’ve configured workflows in Zenhub so that as issues and epics move across pipelines, there’s visibility for both the product team and the squad team on what’s in progress.

Developer’s perspective on technical breakdowns

Developers will take the epic put together by design and translate that into individual units of work, which can be split up across team members. In the spirit of shipping fast, we usually create multiple sub-epics representing the phases of release, with the MVP being the first. As we’re interrogating the requirements, we slot issues into the MVP epic and a later phase two.

At this stage, there’s a lot of back and forth between the disciplines to decide what’s absolutely necessary to deliver customer value. The ideal outcome of these conversations is the smallest backlog to get us to an initial release. The phased epics give us a logical place to keep track of additional work we discover during the project, which we evaluate after the initial release. The goal is to keep the dev team laser focused on the work at hand without forgetting all the nice to haves we think of along the way.

Getting alignment between design & development

Once the project spec is in place, we use agile events to understand what’s achievable in our bi-weekly sprints. Developers, project managers and designers working on the project will attend the backlog refinement, sprint planning, and daily standup meetings. The goal is to discuss the finer details and build a reliable estimate of stories. We find detailed questions around designs, edge cases, or missing spec details tend to surface.

After everyone understands the spec, developers will use planning poker to collaboratively estimate on each story. This lets the developers have additional discussions on execution and will ultimately provide a reliable estimate and accurate sprint prediction.

Designer’s perspective on getting aligned with development

Having designers attend the backlog refinement meeting has helped remove silos and fill gaps of information that may be missing with the project spec. Specs could be updated or reduced while the refinement process is happening to ensure a timely sprint. As we move into sprint planning, designers get a good idea of what customer-facing improvements we’ll be shipping and what assets are necessary.

Developer’s perspective on getting aligned with design

In standard agile fashion, the dev team estimates issues in the MVP epic so we can identify any gaps in understanding across team members. Planning poker in Zenhub makes this process a lot more asynchronous for more trivial issues, but we still need to get together with designers to hash out the details on any complicated issues.

We’ve been experimenting with moving most of our discussion around requirements into the comments section of GitHub issues before grooming meetings, so we can have more focused backlog refinement sessions. We’ve been finding that it helps us have better conversations when the team has more time to think about the requirements instead of trying to decide synchronously in a meeting.

Workflows allow for better information sharing between designers and developers

Our workflow once the project scope is agreed upon and organized into issues is pretty standard Scrum, but with some handy automations to cut out the boring stuff. Sprints are organized and built via the Zenhub sprint feature, which automatically creates the next sprint and moves over any uncompleted issues into the next sprint at the close of the current sprint. Issues are assigned and pulled into the ‘in progress’ pipeline manually, but once a pull request is pushed and associated with the issue, it automatically tracks the completion status of the PR so our issue is completed as soon as the work is merged. When we experience scope creep or missed requirements along the way, we’ll generate new tickets and decide as a group if the additional scope belongs in the current epic or in phase two.

Designer POV

Clear definition of pipelines allows for visibility across teams to understand what’s being worked on and what needs attention. When there are designs or assets that are being worked on in parallel with development, developers can easily tag a designer or mark an issue as blocked.

Dev POV

In the Zenhub repos, we rely on PR templates to help us automate some tasks and keep the developers in sync with the definition of done. Our template prompts the developer to use a `Closes` keyword so that Zenhub will automatically associate the PR’s with their issue. We also identify what kind of review we expect, if the change is user facing, does it require any special testing, etc..

Design review and code review in one place

All of our work needs to be code reviewed, QA’d, and approved by the product owner. We use additional pipelines on the Zenhub board to indicate these statuses, so we can visualize the bottlenecks in our workflows, and talk about them in our daily standups.

Designer POV

Screenshots or videos provide a history of changes and are a quick way for designers to do asynchronous review. Oftentimes, designers, QA, or developers can jump onto a call after the release of a PR or if an issue is tagged requiring design review. Having designers directly in GitHub means there is less context switching and we can leverage the reviewing features inside of GitHub

Dev POV

We’ve been leveraging the Github code commenting interface to provide threaded and resolvable feedback on PRs as they move through our workflow. QA and designers can drop comments into code and the developers can resolve them one by one, so we can see the progress, and have some history of the long-running reviews.

Rough edges

Zenhub is a tool for collaboration and works great in many ways. However, we humbly know we do have some areas where we could improve. Since we use this tool internally, we feel those pains on the development and design teams as well.  We sometimes reach for additional tools to help us keep track of changing requirements.

Designer POV

One thing we’d like to optimize is the spec writing abilities in a Zenhub epic. While today using markdown provides a lot of customization on the document, there’s a lack of integration to enhance the connectivity between development tools and design tools. Integration directly with our metrics or with platforms like Figma would create a powerful, well-rounded view of project specifications.

Dev POV

Depending on the size of the project, keeping track of changing requirements can be difficult. Because we’re based on GitHub issues, it’s harder to keep track of changes over time (as opposed to editing interfaces like Notion, Google Docs, or Dropbox Paper.  GitHub markdown is fine, but not being able to comment specific lines of AC and thread discussions can make long-running projects get messy.

With that said, we’re always working on improving Zenhub. If you’d like to see what’s coming down the pipe, check out our Product Board or see what’s new on our Changelog.

Conclusion

There’s no one answer that will help you completely remove silos from your teams. However, through consistency, open communication, and some of the techniques we’ve shared above, we believe you can unlock new levels of productivity for your design and development teams. Not only that, they’ll be much happier working together – and that, to us, is the true win!

Want to learn more about creating high performing technical teams? Check out our free guide Focused Teams: A Field Guide to Focus-Driven Development.