Computers and Technology

Guest View: Getting to market faster doesn’t mean sacrificing quality


Everyone’s getting squeezed. As customers demand more intelligent, connected products, companies feel intensified heat to deliver quickly or risk disruption.

The pressure created by the convergence of these two forces is often felt most by development teams. Typically, not only are they asked to do more with the same amount of resources, but they’re also told to do it quickly.

Add in the fact that since connected products often require establishing new, collaborative relationships between hardware and software teams — which speak different languages and operate under divergent methods — and this shift in process introduces further strain.

Given these mounting pressures and shrinking release cycles, it’s tempting to opt for speed and test the limits of your organization by barreling through development as fast as possible. The cost of this approach isn’t just the quality of your final product, but of your company’s overall health and morale. What could go wrong?

The good news is, moving fast today doesn’t necessitate lowering your development standards. While there’s no silver bullet that will magically shield you from the pitfalls of tighter development schedules and faster iterations, there are some steps you can take to create a process that will withstand the growing constraints.

Better requirements
Requirements are the backbone of successful products. If these aren’t defined, communicated, documented, and followed properly, you won’t end up with the right product.

Requirements management software can alleviate a lot of struggles, but it won’t take care of the nagging problems consistent with human communication. Specifically, teams need to learn how to strike the balance between just enough and not too many details when relaying requirement information.

Requirements with too little detail leave room for ambiguity, which opens the door to misinterpretation, confusion, and ultimately building the wrong thing. Provide excessive detail and product and engineering teams may feel stifled creatively and unable to innovate.

Instead, requirements should keep teams aligned on “what” is being asked for, as well as “why.” This leaves the engineering experts free to solve “how” to implement. Additionally, creating a glossary of language and common terminology can also help ensure everyone is on the same page.

Aligning teams
It’s traditionally been the case that hardware and software teams work separately. In many cases, companies creating traditional hardware products — whether it’s refrigerators, coffee makers, or watches — might not even have a software team in house, and vice versa.  And even if a business does have both, there’s usually not a ton of collaboration taking place.

Successful connected products demand hardware and software teams work together, and companies need to devise a plan bringing these two expert groups closer together. Any solid plan must include a path toward unification, which includes space for transparency, open communication, and accountability.

You also no longer need to guess about whether or not your plan is working. Monitoring the progression of both teams throughout the development process via analytic insights should tell you in real time. The key is to share your goals with your teams and as a group come up with measures of success. Be mindful of vanity metrics that can easily be manipulated and balance them with countermetrics, which measure events or goals that are directly impacted by the success or failure of your other metrics.

And finally, be sure that you have a balanced scorecard. If you are only measuring how fast your team is working then they will optimize for that and things like quality and accuracy may drop. Collecting qualitative data is an excellent way to counter the quantitative data normally used to report things like velocity and throughput. Polling your teams on happiness or roadmap excitement can often surface issues long before they ever turn into defects in your product.

Take advantage of new technologies
One of the biggest knocks on adopting new technologies is that they will slow your company down. And how are you supposed to manage that while your deadlines are getting tighter? The truth is that while you may experience an initial adjustment period, the long-term benefits will ultimately diminish any temporary delay. Plus, you may not really have a choice.

Development teams can only move so fast when they’re weighed down by emailing revised documents back and forth, waiting on reviews and approvals, and then counting on the one person in the organization who understands how to operate their legacy platform to implement all the changes correctly.

Modern product development platforms can take the burn out of a lot of these processes, making teams more nimble and iterative. When a gap or change emerges during development, stakeholders can be immediately notified of the impact, reducing blind spots that could otherwise spiral into critical defects. Today’s platforms have also been designed to be accessible enough so anyone in the organization can pick them up quickly, demystifying the process and removing the gatekeepers.

As mentioned earlier, some platforms even have the ability to monitor your teams’ performances, providing up-to-the-minute insights so stakeholders can make better informed, strategic decisions.

Don’t delay
Whatever eventual route your organization chooses, procrastinating isn’t an option anymore. Companies that aren’t used to this speed of development will wake up one day and realize everything has changed. Arriving seemingly out of nowhere, their new competitors will move quicker than those that have been in the market for decades.

While it may take some time to scope and adjust to new processes and technologies, the earlier you start, the better. Things aren’t going back to the way they were, and tomorrow’s game-changing products aren’t going to wait around for us to develop them.



Source link

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *