3 Ways to Minimize Cycle Time in Software Development
Minimizing cycle time in software development would seem to be an obvious strategy for getting new products (or features) out the door and into the hands of users. How teams make that happen, however, isn’t so obvious. For the past few years that I’ve been in-house at SaaS companies, my teams and I have struggled to find the perfect formula for getting it right. Of all the ways my teams and I have experimented with process, three things stand out as accelerating design → development cycles:
By creating shared understanding among the team from the start, you get everyone on the same page, greatly reducing potential rework. To help get that clarity, you can write user scenarios (which help the team understand the “why” behind a set of features) and collectively groom user stories. I’m a huge fan of having the whole team groom user stories (which should be done ahead of when the development actually begins for those stories) because it gives the new feature a chance to “marinate” with the team. Sometimes it helps designers to sit on an idea and then come back to it another day. Developers and product managers are no different in that respect. Giving the team time to process the story can lead to some really great questions and ideas that come later, which can often lead to improving the original intended experience.
It’s not rocket science. Release early and often. Working in smaller batches allows you to push to production more quickly...getting the new feature into users' hands more quickly...leading to getting user feedback sooner...allowing you to iterate the feature more quickly. (Yes, this might seem challenging if you have long release cycles because of some technology reason or organizational red tape. If that’s your case, then it’s up to you and your allies to effect that change. However, if you don’t fall into that boat, then why not give it a try?)
There are so many ways to do this, and all yield great results!
- The obvious match here is UX/product management. These two likely have the greatest overlap in responsibilities, mindsets, or focus. (We’ll save that for another blog post.)
- A less likely pairing is UX/QA. In a lot of companies, QA is the last stop on the train. Some good things can come out of getting UX and QA together early, though. Pair them up in the beginning as designs are gelling to give QA greater awareness of intended interactions. (QA will usually have some great “gotchas” that the UXer can address before the design goes to code.) Pair them up during testing so that QA better understands which styling inconsistencies are acceptable and gets a sense of how to prioritize UX bugs.
- Last but not least (and my personal fave), @@UX/Dev pairing is a super way to shorten the feedback loop when it comes to design@@. It makes zero sense to revise...and revise...and revise nitpicky details of a design artifact (e.g., a wireframe or mockup) and throw it over the wall if you can just pair up with the developer who’s working on it and change it right on the spot. @@ Communication should trump pretty deliverables every time.@@
A clear benefit of reducing your cycle time is that you can deliver value more quickly to customers. An added benefit (that I’ve seen firsthand) is that it can increase your team’s morale! It feels good when you make progress and aren’t stalling over creating perfection. It feels even better when you start getting that user feedback rolling in, knowing that the team’s equipped to quickly address issues.
So, while I don’t have “the” answer to how to reduce cycle time in software development, I can say that the three things above have helped in the past. What are some things your teams have experimented with to get things out the door more quickly?