Tag Archives: Digital Engineering

Managing the Software Chaos: Achieving Quality Product Development Outcomes

Have you heard this before? The product development started great and we made our first milestone. BUT, ever since then things have gone off the rails.

Or how about this one? Our technical debt is unsurmountable, our only option is to depreciate. We are seeing horrible retention rates. How did things go so wrong?

Customer experience (CX) is about delight. Making the consumer of the application happy to use it and be in awe of its value to them. Novelty will only get you so far. Reality will hit your user community. Bugs will disappoint. Depreciation of keys features will enrage them. Upgrade paths that are no different then rip & replace will lose you customers. CX is about delivery of quality software. The better the software, the better the experience.

We all know what great software is. We all understanding the benchmarks. The problem is achieving those benchmarks. How do you avoid the primrose path of product development? By understanding, embracing, and enforcing sound engineering best practices.

What is Your Dream?

Let’s start at the beginning: ideation. This is where you define your vision. Who is the consumer? What is their journey? What is the market: from a price, value, and definitive profit opportunity. We live in reality, what are your acceptable trade-offs? How are you going to sell this product? What are the marketing materials required? What is the go-to-market strategy like market segment and demographics? What timelines do we have?

This will allow software creation within the constraints of the business. This means budgets, roles, responsibilities, and investment requirements. Hopefully you have heard “no bucks, no Buck Rodgers” — its as apt now as 50 years ago. This vision will allow your team to make good decisions. The vision is what creates and enables business alignment. When aligned, we can begin creating value.

Realization is Better than Building

Developing a software product is sometimes called sprinting. I see it an appropriate term. To generate business value, you will want to set a short-term goal, work on it, and measure if you made that goal. What is the release strategy? What timelines do you have, that defines the goal setting. Remember the marathon is the release. Segmented sprinting will get you there with the least amount of technical debt possible.

What is technical debt? Product Manager’s boogeyman. That is wasted productivity. When you ask to build something that provides no business value, it is a waste. If you have to re-write something in the future, it’s waste. Eliminating or minimizing technical debt is a key feature of quality software development. That is why agile development principles exists. It aligns development to the business regularly minimizing waste.

As part of agile you have planning sessions to talk about your goals and set them up. You have retrospectives to learn, grow, and adapt to challenges. You have tools that track tasks, resources, and hours. These are vital best practices that make quality software. But even bad software team have defined processes and great tools. The real difference is in the culture or in the people. Using the process to grow talent. Being accountable so you make goals. This is only possible with sound leadership and quality resources. Doing the work is about harness a team’s excellence. Maintaining that begins with quality assurance.

Software is a Business, Run it Like One

Great software is not defined by delight. Great software is a measured outcome like any other business unit should be; with SLAs and KPIs. Your vision should include your tolerances. Enterprise-grade, Commerical-grade, and Carrier-grade: there are many standards out there. What is your standard? What contract do you have with your consumer (written or otherwise)? Once you have your standards, we need to understand the different layers of missing them. What is a P1 vs P2? These thresholds will set the bar of quality of your software. They will allow you to compare individual output to team outcomes. Understanding your standards and your consumer base will enable you to create a test strategy. This is your bar. This how to define quality software.

Many organizations get held up on test automation. Automation is about helping resource management and being more efficient. This is an excellent goal for mature development. But if you first cannot test manually, then you are not ready for automation. Automation distracts many organizations from the purpose of testing – reporting. You need to know if you are making your standards so you can release. That is the most important party. Releasing software is the goal. Businesses expect releases. Testing reports, will tell the team they are ready to release. But they also provide more value. Testing results will also let you if you are resourcing correctly or “achieving velocity”. Do you have enough developers? Do your developers need more training? Who are your leaders? Do you need automation? Great software is made in the QA phase. Applying standards and data, allows software to be released on time, under budget, and with minimal defects.

Best Practices are About Managing People

Excellence in development all about applying best practices. Starting in product visioning. Applying agile development processes. Releasing with quality assurance. The trick to managing the software chaos is following best practices. This is not about the latest development tool. This is not the latest development language. This is not the latest process framework.

Software development best practices are about the people. Its about leadership having the proper data to make good decisions. Engineers focusing on excellence in delivery. You get this working, then ideas become experiences. And experiences change the world. Reach out to me if you ever need to change world, I have a team ready to help.