Your Cyclical SDLC is a Downward Spiral

At some point in my life, software stopped being an app on a CD-ROM that you bought in a cereal-sized box, and started being a web-based thing pulled up in an internet browser. At subsequent points in my life, I worked on software products – from conception to delivery – with a trusty old Software Development/Delivery Lifecycle (SDLC) methodology to guide the way.

Your SDLC Is Missing R&D

In a traditional SDLC, each software team has a method – defined or not – of planning, designing, building, testing, delivering and maintaining their app (although anyone using buggy sites can argue that testing is far too often left out). The steps repeat in a way that feeds the loop.

Once the delivery step is reached, it’s time for a new cycle to begin and internal resources begin firing up their planning skills. If your salespeople have done their job and/or your product is going to stay current and relevant, your next iteration absolutely must be updated with some shiny new features.

Cycle Creep

You’ve certainly heard that agile is all the rage in delivering products faster by chunking big projects into smaller pieces which get through design, build, test and deliver steps faster. Agile also touts the ability to handle change better since making a change to a small chunk is easier than delivering a huge project and then finding out there needs to be a change.

So here we are in a world where getting through the SDLC faster is considered better. There is a lost respect for the art of each step, and a glorified blur of fast spirals where steps run together.

What Feeds The Cycle?

Hold up! Back to the planning and requirements phase. Off the Kanban shelf comes a dusty backlog item or feature request which is put into scope then moved into the design and implementation phases.

How did a request get into the backlog or prioritized? While we’d like to think it is backed by well-founded research and reasoning, that is too often the exception. Maybe you can recognize some of these sources of feature requests:

• Salespeople based on what they want to sell or what will close a certain deal in the pipeline
• CEOs and executives based on what they want to say their company does or to gain a great position on the PR scene
• Internal QA teams based on what helps them get through test scripts faster for testing the platform or what annoys them as they bang through workflows on auto-pilot
• Internal Devs, Product Designers and even interns based on what they want

So the SDLC is rolling downhill driven by everyone inside of the company, and with absolutely no external input on what the market wants, no idea what would best meet the users' needs, or (worst of all) no clue how users are currently struggling with the product.

Imagine your product is a donut… You’ve mastered the basic glazed donut (MVP) and decide to advance on to some of those fancy tricked out carbs you’ve been dreaming of for years. So you make a new donut based on what the front counter salesmen want to sell, what you want to tell everyone about to astound them with your clever ideas, and what the baker thinks will be the easiest way to get the job done. Ta da! Triple peanut chocolate sprinkle curler is done! What happens if your customers are all allergic to peanuts? Or if the combination of ingredients is a bad idea? Will you know, or are you too focused on which sprinkles go on top?

The Value of VOC + R&D

It has been said that 1 hour of research can save 10 hours of development time. If you are focusing on SDLC improvements to make things efficient, you might need to re-adjust that focus to the user.

Simple user interviews, persona development and observation studies can help direct the course of your product road map. Maybe the salesperson is really onto something with their feature and the users love it, or maybe it degrades their experience and they become frustrated. You won't know unless you understand the Voice of the Customer (VOC) and flex the Research muscle missing from your Research & Development plans. Let your users be the tie-breaker when it comes to deciding what features are useful.

Do the research and VOC work upfront and the entire SDLC cycle will be working towards a better, more usable product for your customers. If you wait until after the SDLC reaches a maintenance phase post-deployment, your users are given a donut they may or may not want to bite into (and pay for).

Ready to rethink your development processes? Have a look at our range of Consumer Insights services.