5 Practices for Product Development Beyond Scrum

Judging from the number of likes on this Tweet that starts with “Scrum is a cancer”, there is clearly some growing dissatisfaction and a feeling that Scrum has just become a buzzword. It's undeniable that most companies have misguided expectations from simply applying Scrum. They often expect results by adopting conventional rituals even though they barely consider the core Agile principles behind them. This can lead to teams squandering their time and energy on unnecessary busywork, hindering progress rather than fostering it.

?? Consider The Pareto Principle ??

I’ve found that the Pareto Principle, often known as the 80/20 rule, applies to many product management topics. It reminds us that we can invest our limited time and resources in the activities that have the most impact rather than trying to do everything. Especially a high-growth environment, Product Managers shouldn't tie themselves to Scrum conventions. It's become far to easy to go down the Agile/Scrum rabbit hole while losing sight of what really matters. Here are 5 key practices to consider focusing on instead:

1. Invest in Continuous Market and Customer Research ??While it's helpful to have a profound understanding of your target market and customers, waiting for extensive research to provide answers can slow you down. Instead, employ a timeboxed version of the scientific method: First scan the industry, market and customers. Then, start with a hypothesis based on the best available information and prioritize incremental contact with the market to reconcile theory with reality. Learn, adjust, repeat.
2. Constantly Monitor Team and Organizational Structures ??I’ve always found that spending time optimizing team processes had a tiny impact when compared to the result we realized from having the right people with the right skills and attitude on a team. This goes back to the principle of "People over process" in Agile manifesto terms. Another common mistake you see is when a team is created by merely filling in positions by specialization. People don't always work well together for various reasons. Instead, we should focus on hand-crafting a strong team nucleus of individuals who complement each other exceptionally well. If this nucleus performs effectively, then consider scaling with additional staff. If not, make adjustments to the nucleus before expanding the team. Teams that are scaled this way are more likely to remain effective.Still, maintaining high-functioning teams requires vigilance. The demands may change and individual’s needs grow and change as well so you have to constantly assess team effectiveness and make adjustments along the way.
3. Make Pragmatic Technical Decisions ???Technical decisions are critical, especially in entirely new technology domains. You’ll incur major product risks if those decisions are being made in a vacuum. Having pragmatic and deeply experienced technical leadership can make a world of difference here. Ensure that your technical leaders are aligning architecture decisions with your mission, product principles, business goals, and overall priorities. It’s a good sign if the constraints and architectural alternatives were written down and the final decision was documented.
4. Avoid the Build Trap ???Ensure that your product design is well ahead of active development. Falling into what Melissa Perri refers to as "The Build Trap" results in hasty development without proper design that can lead to costly rework, delays, or throw-away efforts. Most of what engineers work on should have been rigorously thought out and validated in some way with its intended customer. Typically, the best way to think through a product is to start designing it while also decomposing it into effective product development milestones.
5. Have Defensible Roadmaps ???Developing a defensible roadmap is essential because it ensures that efforts are in sync with strategic objectives, optimizes resource allocation, and minimizes risks. By prioritizing customer needs, improving communication, and remaining adaptable in a competitive market, a well-structured roadmap instills stakeholder confidence, maintains a long-term vision, and enforces accountability. The critiques, questions, and decisions that are made will ultimately help your team avoid pitfalls. Start with “Big Rocks” such as essential company imperatives or non-negotiables when filling in your roadmap. These should require as little overhead as possible, as some initiatives do not benefit from extensive market validation or elaborate business cases. Swift action is often more important. The rest of the “Little Rocks” can be filled in with any capacity you think you have left. Scrum tends to paper over the idea of dependencies. Recognize and manage dependencies, represent them on your roadmap, if necessary.

In a high-growth environment, the key is to spend your time wisely. While traditional Scrum tactics may have their merits in some environments, Product Managers may find these practices to be more impactful. So if you’re feeling overwhelmed or lost in the weeds, remember the Pareto Principle. Regardless of the process and rituals your engineering team prefers, focusing on these practices can generate 80% of the impact you're looking for ??.

What practices have had the most impact for you? Please share in the comments.