The Four in a box Model

Aligning UX, UI, PM, Backend teams

Brian Mireles
VMware Design
5 min readJun 13, 2018

--

Getting people on the same page can be a challenge in any scenario, whether it’s deciding what to have for dinner or what park to camp at over the summer. Everyone coming to the table with ideas and ultimately agreeing has never been easy. Getting people to align on what and how to build products in a enterprise company is no different.

VMware Cloud on AWS (VMC) is the flagship offering in the new VMware Cloud Services. It integrates products from across the VMware portfolio into a single solution for our customers. With the need to incorporate all of these capabilities into the product, the VMC team is bombarded with requirements and dependencies from every direction.

As projects and requirements grew, we quickly realized how out of sync we were with other teams. In a SaaS offering like VMC, customers expect continuous delivery of new features and improvements to user experience. If we aren’t aligned, our products will suffer — and so will our customers. The misalignment of teams was a critical problem we needed to solve.

What were the problems?

VMC integrates many teams, which increases the chance of misalignment. The Four in a Box model helps restore alignment.

Misalignment across teams

In the early stages of VMC development, misalignments between teams became a threat to the team’s ability to deliver on time. Teams from multiple business units had been working towards their own product releases. They sometimes worked separately on the same problem, resulting in designs arriving late, backend services not supporting designs and preventing the UI team from implementing the designs due to misalignment.

The groups involved worked in separate scrum teams, on different sprint cycles and often used different project management tools such as Bugzilla, Jira and Pivotal Tracker. As a result, the teams did not have good visibility into one another’s backlog grooming and sprint planning, and subsequently dependencies were often overlooked and schedules were not aligned.

Keeping the priorities communicated across teams was difficult and too often happened late, disrupting work in progress for one team or another.

Design team frustrations

With these problems, the design team suffered to deliver quality solutions. There was no central source of truth for us to rely on. We had to work hard to ensure we understood the priorities from every team and make sure our designs aligned with the different perspectives and roadmaps. Working to align teams took away time for us to design. We struggled to complete designs in a given sprint. These issues cascaded into other problems which lead us to put or foot down an get everyone on the same page.

Coordination between teams

Four in a box model

To align teams and keep everyone in sync, we developed a model called “Four in a box”. The goal of this collaboration model was to maintain constant alignment between PM, UX , UI and Engineering teams with clear communication and milestones. As we progressed designs through the process, a reviewer from each team provided feedback to help us iterate each story.

Alignment across teams

Alignment of disciplines.

Now that we had our model, we identified what areas we needed to align on. We focused on aligning the team on priorities, ownership and workflow.

Aligning on priorities meant we all were working towards the same goals. This discipline was the responsibility of our PMs. We introduced the notion of global stack ranking of epics and stories to allow us to identify dependencies across teams. With priorities identified, we then needed to make everyone accountable.

The next discipline was to assign ownership to identify who is responsible for epics and stories. PM maintained responsibility for the overall epics, but each team had to create their own stories and interlink them with other team stories. The linkage between stories helped us understand dependencies and who was responsible for what part of the project.

Once we outlined priority and ownership responsibilities, we focused on creating a product workflow that reinforces the four in a box model. Our workflow relies on reviewers from each discipline to progress stories from one stage to another. We mandated that stories cannot progress from “In Review” to “Resolved” unless reviewers provide their feedback and ultimately approve our design stories. This ensures everyone is aligned on the proposed designs and provides the team with a vision to help scope the work.

Source of truth

Once we developed our process, the picture became clear. We needed a single source of truth for planning, prioritization, and tracking across the teams. We identified Jira as the tool to help us manage our projects. It allows us to link stories together from one backlog to another and keep everyone on the same page.

This provided teams with a central place to manage their workloads. Regardless of their toolset and individual process, teams would use Jira as their central source of truth and the starting point for all of our projects.

Benefits of alignment

Our Four in a box model gave us a method to get everyone on the same page. Alignment across disciplines affords us the ability to continuously deliver quality products to our customers. With a unified understanding of what we need to build, teams could focus on their piece of the story while maintaining awareness of the other teams efforts.

And for our design team, we could spend more time focusing on designing a great user experience rather than worrying about whether we have the right requirements.

The culmination of all these methodologies has improved our process tremendously. Had we not stopped to solve this problem it would have eventually began to creep into our customers experience. As a design team we knew we could not let that happen at all costs.

Evolving our process

As a design team we are constantly reviewing our processes and methods to ensure we are continuously delivering quality designs. We take a step back and iterate our process the same way we develop our designs. We understand our problem is not unique and other teams may be going through similar problems. We’ll be sharing more of how we are improving our process, in the hopes that you find inspiration to improve your own. In our next article we will share how the VMC design team leverages Jira to progress design stories from concept to production.

We’re hiring!

The VMware Design team is looking for talented designers to help us continue transforming enterprise design. Check out our open positions!

--

--

Brian Mireles
VMware Design

Boring designer with a soft spot for enterprise design.