Achieving alignment is a challenge when you are working in collaborative software development environments. Teams frequently consist of Product Managers, Solution Architects, Tech Leads, Project Stakeholders, Developers, Site Reliability Engineers and often many more. Getting everyone on the same page and agreeing on when and what to build is difficult. Each member of the team brings their perspective, experience, and agenda to the table, and negotiating becomes challenging.

Teams often try to reduce their differences by agreeing to an “MVP” product. I’ve found that the technique of building an MVP to get something out the door doesn’t always work. MVPs don’t always account for things like resiliency or compliance requirements — items your SREs or Stakeholders find essential. The other challenge is that the traditional vertical slice of a DB, a web server, and a UI no longer works. I’ve learned the hard way that this model isn’t enough to deliver something meaningful; your Stakeholders or Project Sponsor may find it problematic that you spent six months building an MVP that will ‘tip over’ the first day it is in Production. So how do you solve the two challenges of alignment and MVPs?

Over the past few years, I have refined and developed a technique that has proven to achieve alignment not just within a Development team but also your project sponsor and stakeholders in the organization. We combine brainstorming techniques to create not only multiple versions of your MVP, but also understand what your product will look like as it matures across multiple dimensions.

Image credit: Diane Loviglio, Mozilla UX (https://blog.mozilla.org/ux/2012/06/whats-the-difference-between-ui-and-ux/)

First, before discussing the alignment activities, let’s do some metaphorical level setting about Cupcakes, Cakes, and Wedding Cakes.

A cupcake and a wedding cake have similar features but are on a different scale. A wedding cake is more substantial, takes more time to bake, frost, and is likely more elaborate and if you do not get it right, you have wasted a lot of time and materials. You would not want to bake a wedding cake for the first time and use all your flour, sugar, eggs, frosting to only find out that the cake doesn’t taste right or the icing doesn’t work.

If you were to bake a cupcake that has all the same features of a wedding cake but at a smaller scale, you can iterate through multiple versions of the wedding cake without using all your resources while baking something similar. You will learn the right proportions of ingredients, the pros, and cons of the different combinations of frosting and flavors and what works and doesn’t work; allowing you to iterate until you get something that is of value and is applied to the next version of the cupcake you bake.

The cake is in between the two and serves to help you think and imagine what your larger cupcake would look like as you get closer towards knowing what you’ll want to make for the wedding cake. Remember it is not just a smaller version but a version that represents the characteristics of what you want to build.

When I first learned about this technique, it struck a chord with me. Almost everyone has had a cupcake, cake, and wedding cakes. All three are variations of the same thing, but at a different scale. When I related this to various teams I had worked with, something clicked. Given the time and financial constraints teams are under, I could see how we could build different versions of cupcakes without spending our finite resources (time, money) on creating a wedding cake that we have never baked before.

This exercise encouraged us as a team to think differently, but there was no clear way to take the idea and put it into practice.  Over time I was able to transform the idea into something actionable. The below process is the result of that work that you should be able to use to help your teams with similar challenges.

How do I build a Cupcake, Cake, Wedding Cake…?

I like to start with a brainstorming session (you’ll find it is similar to a mind-map but in an excel format) that identifies all of the features, characteristics, and adjectives for your product, and list them out.

This is the template I recommend using to begin with:

Start with a “What” column in a spreadsheet and start listing out characteristics of a noun,adjective or verb that relates to your project: think personas, use cases, types of validations, etc. Below, I’ll walk you through how this would look for a Cloud Native Application, running in a container(s) on Kubernetes. Though that may seem complex on first inspection, in my experience these are things you have to start thinking about, as opposed to traditional 3-tier architectures.

First Slice (with Gavin Mead)

As this starts to take shape, you can add requirements from your stakeholders and compliance teams such as security, performance, and uptime requirements (this will be covered in a follow-up blog post).

You’ll find that your team will start to negotiate as this takes place, and most importantly, you will begin to see and gain alignment on what you are building and when you’ll be able to work on it.

Wrap-Up

This technique has helped me and the teams I’ve worked with get two key things: alignment on what we are going to build, and a roadmap and maturity model of what we’ll drive towards. Your team will be happy as their voices were included in the agreement stating how to build the product, and your stakeholders will be happy that you now have tangible milestones for product outcomes. You now have something that is detailed enough to start building your Agile backlog which can often be the toughest barrier to getting started! Hopefully you find this technique as valuable when working with your teams as I did.