Designing Our Design and Development Process
One of the most powerful things about Spotify’s Squad Framework is that each team has the autonomy to decide what development process works best for them. But without a company-wide process defined, teams can go through periods, especially when first starting or when new members have joined, that can feel chaotic and hard to align around how they want to get their work done.
Our team has been going through one of these chaotic seasons and we’ve needed some aligning.
So in an attempt to steady ourselves and come together as a team, we’ve set out to define our process. The goal has been to establish a rough map of how we plan to work, who takes on what responsibilities, better support each other in being able to do our jobs and to create a shared language to help streamline our retro conversations so that we can continue refining our process with every sprint. Here’s how we’ve set out to do it:
1️⃣ Get the team together and get everything out on a whiteboard
We started on the whiteboard and mapped out a combination of what we do today, with what we would like to try to do.
2️⃣ Digitize and get everyone talking
After whiteboarding with the team, we digitized the sticky notes and shared them on Invision’s Freehand. This gave everyone on the team time to digest what we had come up with and share their questions and offer feedback on their terms. Also, the benefit of this is that it gives a voice to the folks who are less comfortable sharing their thoughts and opinions in a group setting.
3️⃣ Discuss as a team, clean up and give it a try
We hosted a follow-up conversation with the entire squad to talk through the feedback left on the digitized version and adjusted the process accordingly.
4️⃣ Make it physical and get people interacting with it
We then printed out the process artifact, hung it up in our Squad’s area and use it as a talking point/make adjustments to it on the fly as needed. We found that having the framework printed out helped identified new issues with the process and language used.
For example, we had named the initial stage of design the“Idea” capturing phase, but one of our developers pointed out that this language is misleading and problematic. As a team, we want everything we build to be solving problems for our customers. We want everything to be rooted in an actual “problem”, not in an “idea”. With the process printed out, we were able to talk about it and update it in real-time. We changed the title of the first phase to “Problems” and had a great discussion about how we want everything we do to be adding value to our customers by solving their problems.
5️⃣ Retro, iterate, and repeat
We now keep an eye on our process throughout the sprint and during every retro, we use it to talk through what is working well, what has not worked well and what we want to try to improve or experiment with.
