Agile is Not Enough – Learn About the Modern Approach to Product Development

Fierce competition, dynamically changing expectations and the emergence of disruptive technologies (especially AI-driven) have made it more challenging to create successful products, especially for the B2C market. The good news is that there are proven practices, techniques and tools that ensure higher chances of success. Read on to get tips on how to build a credible framework for modern software development.

Developing successful software products is not easy

McKinsey shows that over 50% of product launches don’t meet business targets. On a smaller scale, most features, once released, do not meet business expectations, either. For organizations struggling to increase return on investment (ROI), this means months of planning, designing and hard development work go to waste. Usually, this failure is not due to poor technical quality – rather, something has been introduced to users which they don’t want to use (and pay for). This could be a result of the business team not doing proper research, the feature becoming obsolete or a changing situation on the market.

But the main reason for not meeting business expectations is that companies weren’t lucky enough. Sadly, luck is a big factor in product success and failure. But if you’ve ever gambled, you know there are ways of improving your luck. In software development, it’s by being prepared to fail. As Harvard Business School Professor Clayton Christensen famously claimed, 95% of new products fail. So, instead of betting on one opportunity, assume that eight out of ten times you will fail and try a dozen different things, within the same budget and time, instead of focusing on only one feature. Dealing with failed investments means being ready to quickly cut your losses and move forward. And this is the root of modern product development.

What development teams get wrong

Research indicates that across organizations, 11.4% of all resources are wasted due to inferior project management processes. To address this problem, more and more teams have adopted Agile methodologies – and the results are striking. In KMPG’s 2022 Project Management Survey, 71% of participants believed that adopting Agile methodologies improved their overall project delivery. It’s worth nothing that a 2022 survey showed that 87% of Agile practitioners implemented the Scrum framework. When using Scrum, development teams should keep the following tips in mind.

Roadmaps often cripple the Agile approach

Comprehensive and rigid long-term roadmaps cripple any attempts for a process to be truly agile. It’s like saying to a software team: do it anyway you want, but this set of features needs to be ready by this date. What’s agile about that? It also conflicts with the “don’t assume, learn as you go” principle. From the beginning, you’ve already decided what features you want to develop.

SCRUM is focused on steady increments, but not on speed of delivery

Nowadays SCRUM and SCRUM-based frameworks are the most popular software development frameworks. Usually, they are not bad for product development as they are simple, flexible, well-known and focused on business goals. But they are also centered around consistent development (time and quality) and creating (not delivering) new features. But what is needed, besides high quality, is speed.

Of course, SCRUM-based frameworks are flexible, and you can add some elements that emphasize speed and delivery more, but there are better alternatives. One thing to avoid at all costs is a heavyweight framework like the Scaled Agile Framework (SAFe), which can add a lot of additional overheads, slow down progress and limit flexibility that you will need. If you have a big development team that doesn’t stay within SCRUM boundaries, explore more lightweight frameworks like Large-Scale Scrum (LeSS). The problem of changes interfering with one another should be resolved by implementing a proper component versioning strategy and combining loosely coupled architecture with test automation and a deployment strategy.

Development processes don’t tackle the technical aspects of software development

In most engineering teams, disturbing patterns can be observed. Usually managers (like delivery managers, Scrum Masters) are responsible for the process, and engineers (architects, technical leads) are responsible for technical aspects of the project. There is a clear separation of responsibilities, and everyone focuses solely on their role.

The problem is that often technical aspects can help or hinder the development process. You’ll only get the full picture when you combine processes with technical aspects. For example, the way you deploy your product often impacts the way you conduct your QA activities. Moreover, the way you’ve organized your team impacts the overall system architecture. Yes, after 60 years Conway’s law is alive and well.

Consistent quality level hinders an experimentation approach

Almost all QA teams and test engineers strive to reach the highest possible level of system quality, usually measured by the number of bugs. Software engineers also fight for code quality, which translates to the easiness of understanding the code, making changes in it and the likelihood of introducing a new bug while making changes.

There’s nothing wrong with keeping high quality, right? Well, there is – it takes time and money. And in an experiment-based approach, it’s all about time and money. This doesn’t mean that you shouldn’t worry about quality. Too many bugs lead to unsatisfied customers and lost revenue, while poor code quality across an entire system negatively impacts the development time of new features. You need to keep this fine balance or often deliver things of “barely sufficient quality”. On the other hand, features that bring money to the table need to be kept in good quality.

Quality often omits important aspects of your product

Software system quality is often measured by the number and severity of bugs and code quality. But can you really call a feature that is bug-free and written according to every known good engineering practice, but fails to attract customers, a success? Should this only be a worry for the business team? What will happen to an engineering team if their product fails to meet business goals?

OKRs

Objectives and key results (OKRs) are a useful tool for measuring goals, if used correctly. What are the most common mistakes companies make when introducing OKRs:

• Objectives are vague and not related to a company’s strategy. “By the end of year, increase revenue by X%” is the most common one. While it describes the desire, it doesn’t indicate how to achieve it.
• Too many objectives and key results. As a rule of thumb, on each level, you need to have up to three objectives and each objective needs to have no more than four key results.
• Cascading instead of aligning. Objectives on lower levels need to help achieve higher-level objectives, but they shouldn’t be cascaded. The most common bad example: “One of the sales team’s key results is to acquire 30 new customers, so let’s create a key result for each sales team to acquire 10 new customers.”
• Inability to track progress. Often, teams create key results that later can’t be measured because the team lacks the necessary data to do so.
• No frequent reviews. OKRs need to be frequently reviewed and if needed, the method to achieve them should be modified.

Remember, OKRs were designed to help companies focus on what’s important, not to create irrelevant KPIs.

Data trap

Lastly, don’t fall into a data trap. While it’s important to keep track of and measure your data, it’s easy to forget that it doesn’t tell the whole story. Be constantly in contact with your customers and remember there is a real human being behind the data. You need to enhance the picture drawn by data with customer feedback.

Cooperation between the technical and business teams is key

The most advanced software system is useless without a good business model and even the most brilliant business model will crumble if your product is of low technical quality. It should be clear that communication between the engineering and business sides of a company is crucial for the success of your product. Sadly, that’s usually not the case.

Product managers, engineers and other specializations from the technical and business sides need to be united by the same goals. That, along with mutual understanding and trust, should be the glue to combine people from different backgrounds into one team.

An effective product manager participates in a team’s daily standups and is available whenever the team needs support (within reason, of course). The same goes for engineers. When a product manager wants to talk with them, they should be available, especially during the discovery phase when engineers work on a feature and the product manager should be on the hotline.

Two high-level goals are the same for all product teams:

1. The commercial success of the product.
2. Maintaining capabilities to adjust the product to current needs.

While the first one is obvious, the lack of the second one is the bane of many good products. Products that started strong soon went into oblivion because they failed to keep up with quickly growing competition – Blockbuster Video, Kodak, Palm Pilot, Blackberry and Yahoo Search are just a few examples.

Get product development best practices

Companies should explore proven strategies and frameworks that help reduce time to market, build a high-performing engineering team and create customer-centric products. Nowadays, maximizing software development processes means deploying AI tools, integrating meaningful KPIs and following a holistic approach to engineering that improves product quality and performance.

Looking to enhance your software development? Download The Modern Approach to Product Development, a comprehensive, yet concrete, guide filled with experience-backed best practices and practical examples of effective software delivery.