faster time-to-market with less silo thinking

Tear down the silos for faster time-to-market

One of the challenges that all software development groups face is the trade-off between time-to-market and adding new features.  Software is so malleable that it is tempting to make changes right up until the day of release; when we think of one more feature that’s too cool to ignore.  The problem with last-minute changes is that you almost always get unintended side effects. And so we’ve all learned over the years that last minute changes are not a good idea.  This results in longer release cycles of once or twice a year, so that we can do full QA on each feature.  The result of of this approach is you end up with backlog of cool new stuff your developers have built but that you cannot release to customers. 

How can we improve our time-to-market and not sacrifice software quality?  There are two keys to achieve faster release cycles with better quality:

  • Ensure that you have tests to formalize existing behavior
  • Expose these test to everyone on the team for editing and execution

Most development groups fall short on both points. Existing tests are not complete; and they are kept in silos that are maintained by different teams.  The developers, integrators, and QA engineers all have separate sets of tests, and these tests are rarely shared between the groups.  We could argue forever about what complete testing means, where test efforts should be focused, and what sort of testing provides the best ROI.  But there really is no valid reason to not share tests. 

When tests are kept in silos, it leads to an adversarial relationship between team members.  New features are marked “done”  by the developers only to get “stuck” in QA for weeks.  Why are they stuck?  Is the QA team evil?  Are they sabotaging the developers?  Of course not, they get stuck because the developers are delivering changes that have not been tested adequately.  Why are the changes under-tested? Are the developers lazy, or uninterested in quality?  Neither, the changes are being judged by a “hidden” set of criteria – the QA tests that the developers cannot access – so, it’s not surprising that new features break these tests. 

Make this the year that you blow up those test silos and start sharing tests. And ignore the excuses you hear from the naysayers: “We don’t have enough hardware”. “Only Tom knows how to run those tests”. “Only Sally knows how to interpret the test results”. “Some of those tests always fail, but they’re not real bugs” … 

One of the best things that you can do to improve the quality and time-to-market of your software :
Ensure that everyone on your team is a tester!


Share on linkedin
Share on twitter
Share on whatsapp

1 thought on “Tear down the silos for faster time-to-market”

  1. An impressive share! I’ve just forwarded this onto a colleague who has
    been doing a little homework on this. And he in fact
    bought me lunch because I found it for him…
    lol. So let me reword this…. Thanks for the
    meal!! But yeah, thanks for spending some time to talk about this subject here
    on your web page.


Leave a Comment

Related Posts

A single source of truth - source code

A single source of truth

Software projects produce lots of artifacts over time, obviously the source code, but also requirement and design docs, test cases, bug reports, CI scripts, installation

The safe & secure software factory

The Safe & Secure Software Factory (SSSF) merges the principles of DevOps, Safety Criticality, Cyber Security and Industrial Manufacturing. SSSF enables you to create a

Software quality a winning team

Software quality: Winning as a team

We have exposed a nice framework in previous posts: raw data produce metrics and indicators, and a rating model evaluates quality for each project component.

Hey there!

Subscribe and get an email every time we’ve got a new quality piece on here.