Some software projects are slow burns, with incremental wins slowly snowballing after months of work. Others are a flurry of activity that ends quickly and sometimes arbitrarily. In both cases, and all the projects in between, software teams are making tradeoffs that hopefully strike the right balance between quality and speed.
Recently, we partnered with one of our clients on a rapid prototyping exercise that went from concept to code available in the app store in just three weeks. This time crunch provides an interesting glimpse into the tradeoffs that teams make, and how they get to the heart of agile development practices with feedback loops that are lightweight and rapid.
In this episode, I spoke with two members of the team to hear their reflections on the project, and what it taught them about shipping quality software products. Mike Danaher is a project director and long-time leader at 8th Light. He joined the company in 2014, and he’s gone from a crafter to a project director with experience leading dozens of projects, legacy and greenfield alike. Hani Kruger recently joined 8th Light as a UX designer. She has a background in research and usability and has worked in startup environments as well as big tech.
Hani discussed her approach to downloading so much new context and information without getting bogged down in the beginning.
We had to understand the vision and the work that had been done up to that point rather quickly since we had about five days… There was a lot to do in that short period of time, but I think it was focusing on when to do each thing and when to get feedback, which was of course early and often. So we didn't have a ton of updates at once to overwhelm the team. We ended that week making sure we had some high-fidelity mockups for all of these feature flows and really making sure it brought the vision to life, but also served as a roadmap for the work that would be moving forward.
Mike talked about how video recordings helped their communication remain approachable.
We did a quick sync in the morning, but they also started recording their work. They would take a screen recording of what they were working on and say, here's what I was able to accomplish in the last four hours. And people could watch it. And they were usually just a minute or two. So it was pretty quick. And it's amazing how a video can convey so much more than what you could type, right? Like if you open Slack to a wall of text, the last thing you want to do is actually read through it all. And so you open it to a video and you watch it and you're like, oh, that's awesome. Like, they did exactly what I thought they were going to do, and oh, they ran into this issue, or they found this bug.
Hani added that asynchronous updates have the benefit of allowing the team to focus on actually doing their work.
But also we had so many check-ins, and I think a big frustration for a designer always is, when do you have the time to work and actually produce versus talking about what you're doing? So I think that was another way in which we had a lot of check-ins through those videos and through simple status updates on Slack to make sure we're getting all of this information that we need, but also still giving us room in the afternoon to actually get the work done that we needed to for the next update in the next morning.
Mike explained the concept of focusing on outcomes over outputs, and how that gives teams more autonomy in their work.
You may have heard the term “outcomes over outputs.” It's been pretty popular the last couple years as folks in the DevOps community talk about it. The idea is, if you focus on the outcome, what you're trying to achieve, and everybody's aligned on that, and you have to give up a little bit of control, you really have to trust the team, but you say, here's what we want to get to and here's why it's important, and here's what it's going to unlock when we do it. And then just say, let them figure it out, right? You don't need to micromanage your team. You don't need to double-check every line of code that gets written. You don't need to dictate how everything should be done. The devs are the experts here, right? They're the experts in the code. Let them be experts at that and get out of their way. As long as you can all agree on the vision, everything else just kind of takes care of itself.
Mike says that shifting our teams to a focus on outcomes might seem challenging, maybe the best way to start is by focusing on the simple things.
We could start to shift our teams towards this mindset of focus on the outcome, focus on what we're trying to achieve, and make it something that can be done in a couple of days. Don't say, okay, six months from now we're going to launch this beta and it's going to have a thousand features, and we have to make it perfect. Let's just focus on one feature that we can do in a couple of days and get feedback on it.
SUBSCRIBE TO COLLABORATIVE CRAFT
You can listen to Collaborative Craft via Apple Podcasts, Google Podcasts, Spotify, or wherever you get your podcasts. Don’t forget to subscribe to receive notifications of the latest episodes. And if you enjoy what you’re hearing, please consider leaving a review in Apple Podcasts. It really helps others find the show.
