The back story. How did we get here?

I’ll be blunt.

We had a pretty big design process failure at the start of the COVID-19 pandemic and the work-from-home “new normal”. A new feature that should have taken less than a month to design dragged on for close to 3 months…with the end design pretty close to first design. The inefficiency still would have happened if we were all in the office but being remote compounded the issues, of which there were a few:

  1. No clear requirements at the start of the project
  2. Not having the key players in the initial meetings
  3. Bringing on new people throughout the process
  4. Long periods between meetings

Now, let’s dive into each issue in more detail.

  1. When we started there was no clear idea of what “success” meant. And worse, everyone had a different idea of what “success” meant. So, as designers, we were shooting arrows in the dark at a bullseye that kept moving. We spent hours defining, and redefining, what certain terms actually meant.
  2. We started the process with a few key stakeholders from “higher up” in the business. We thought by having their thoughts and buy-in, we could then pull in the developers to implement the solutions that the designers put together. The problem was the developers had their own thoughts, and more importantly, disparate nsights into how the product should work including insights from previously designed products.
  3. We found that as we pulled in the developers, additional questions and points were brought up, which then had to be taken back to the key stakeholders. We compounded this problem by continuing to bring in additional developers at every stage, who would then have additional comments/thoughts that had to be taken into account. This ended up creating a series of circular discussions that continued to compound the timeline.
  4. And finally, we just took too much time between meetings/design reviews. A design update would be done in a day and we would wait a week to review it with the team. I believe this is where working remote hurt us the most. In the office, I would tap people on the shoulder to get impromptu feedback. Working remotely forced us to schedule meetings and work around pretty busy schedules.

So, the solution? Let’s do the complete opposite and get the next design feature done in a week. What could go wrong?

Design Sprints. The Process.

Since we were working remotely, we had to modify the Design Sprint methodology a bit to accommodate our work from home policy including:

  1. All meetings would be conducted via GoToMeeting instead of in person in a conference room.
  2. Figure out the key players we need to get in a room to quickly figure out this design. We landed on a mix of designers, dev leads, and developers. We also decided to have a few follow up meetings with “higher ups” to give a review of the days progress.
  3. By picking team members, we also made it clear that those folks would be speaking on behalf of the rest of the team. It would be impossible to pull together the entire company and get 100% agreement. At some point the team leads would have to delegate control to others.
  4. Following the “official” design sprint methodology the team should devote 40 hours to this process. Given current in progress work and the fact that this was a “beta” initiative, we landed on 90 minutes a day to get this feature done.
  5. The design team put together an outline that covered what we wanted to accomplish each day (** Add a footnote, or screenshot of the schedule)
  6. While we did review the official methodology we took quite a few liberties with the process to make it work for us.

How did it go?

Without beating around the bush…really, really well.

  1. The developers have expressed a wish to be more involved in the design process. Design sprints allowed for them to express their thoughts from day one. The process also allowed them the opportunity to sketch out and design what they thought the solution should be…whether that was pen and paper or a simple PowerPoint. design sprint
  2. We decided to utilize the Mural software as our virtual white board. This ended up being a great decision allowing for everyone to type their own thoughts during brainstorming or “starring” items they wanted to see developed further. Throughout the week, the group would continue to reference notes and sketches from the first day. design sprint
  3. We did get behind schedule on day 1. The 90 minutes a day was my biggest fear starting this process. I know how quickly meetings can go off on tangents, causing you to easily lose a ½ hour. We made it a point to try and parking lot those discussions as quickly as possible, but they did happen.

What we will do next time.

While the Design Sprint was a success, there are a few things that we could change to improve the process.

  1. Devote more time daily. Ninety minutes a day just wasn’t enough time to get everyone’s thoughts fully fleshed out.
  2. Ideally this would be done in person, with white boards, post-its and eye-to-eye contact. We did the best we could over the phone, but realize in-person feedback is ideal.
  3. Have a concrete group of customers who are willing to devote the time to give us feedback on the prototype.

Wrap up.

Will this work for your team? I think so.

At HCL Software DevOps, we have a very opinionated team that wants their voice heard. This process allowed for that to happen. When everyone is excited about what they are working on and feel like they had a hand in the end-to-end process, the product can only benefit. To make it work, you will have to devote the time and give your team the necessary resources to not feel overwhelmed by day-to-day work. But the end result is a concrete deliverable prototype that can be tested….not bad for a week’s work.

HCL Accelerate can help you get to sprint success, whether your teams are distributed across the globe or still working together in the office. With features like swim lanes to organize work by team member, and the ability to integrate with the tools you’re already using, HCL Accelerate makes measuring, tracking, and optimizing your DevOps pipeline easier than ever. Download it for free here.

 

 

Comment wrap
Further Reading
article-img
Secure DevOps | June 9, 2022
Introducing HCL Accelerate v3.1
HCL Accelerate is continuing to see significant Value Stream Management adoption! With the release of HCL Accelerate 3.1, we brought significant features and performance improvements for our largest customers. If you are not far in your VSM journey, see below for some new onboarding features and guidance.
article-img
Secure DevOps | May 19, 2022
Accelerate on Kubernetes: Or, How I Learned to Stop Worrying and Love Automated Container Orchestration
Containerization is everywhere these days, and technologists are scrambling to adopt it in their organizations. But what exactly is it? Is it actually beneficial, or just a fad? What's the best way to leverage it? And most importantly, how does it relate to HCL Accelerate?
article-img
Secure DevOps | April 25, 2022
OpenShift Installation Updates
Starting from HCL Accelerate version 3.1.0, OpenShift Template installation will be removed. If you are an OpenShift user, do not worry, we will continue supporting OpenShift platforms through Helm charts.
Close
Filters result by
Sort:
|