This Agile Hammer Doesn't Work For New Product Development

You've heard the old saying:

"If you only have a hammer, every problem starts to look like a nail."

As an engineering leader, you may be expected to help your company bring new technology products to market. What product development approach you use for that effort will have an effect on the ultimate outcome. It can make the difference between market success and failure. And probably your job.

It is important as tech leaders to know, for example, of the relative strengths and weaknesses of two popular Agile frameworks, Scrum and Kanban. Each is good for some projects, not so great for others.

[Assuming you're building digital products, you should also employ the technical practices from eXtreme Programming, such as test-driven development and continuous integration. But since they work fine with either Kanban or Scrum, we won’t talk much about that here.]

Over the last 22 years, I have personally coached, mentored, or advised about 150 startups at last count. And I’ve worked with about 100 large organizations and hundreds of software development teams, some of which were developing new products and services within an enterprise context. I've seen every imaginable Agile configuration, from strictly "by-the-book" approaches, to hybrid approaches, to "totally-making-it-up-as-we-go" approaches.

From that perspective, I am going to try to save you and your team some time (and probably a lot of useless argument) by giving you a simple heuristic for how to choose which Agile approach to take depending on your situation.

Technical Risk

If you’re managing a large system that is part of an already established business, Scrum will work quite well for this. If you're responsible for developing a new system to replace an existing one, particularly if your stakeholders are internal to the organization, Scrum will also work fine.

Scrum was developed for big IT projects, like system migrations or the replacement of large complicated components, or even building new systems to automate processes that were previously done by humans. When you have a project with multiple stakeholders and a high degree of internal business and technical risk, Scrum is an ideal approach.

Scrum's structure, its very clearly defined roles and rituals, makes it ideal for reducing, or at least capturing and encapsulating, the vast technical complexity of these big IT projects. You don't have to know every detail about what you are building in order to get started. But you do need to have a pretty good idea of where you're going, and what the success criteria will be.

It has a great facility for breaking down complexity to make it more manageable for engineers. Breaking a big scope into smaller manageable user stories, and working on those stories in time-boxed sprints, helps to provide focus and clarity to the engineers. Encouraging the team to assign a goal for each sprint brings even further clarity and focus.

Over time, as the team settles into a rhythm, the use of story point estimates (coupled with explicit feedback loops to make them gradually more accurate) can surface a stable velocity metric that can allow the team to predict the completion dates for parts of the system with increasing accuracy.

Scheduling a regular cadence to review progress with stakeholders, collect feedback, and then adjust the backlog accordingly, allows the organization to make more rational decisions about how to efficiently deploy financial resources to IT projects, whether that means staying the course on your project, making some modifications to the plan, or changing directions entirely.

Scrum is a million times more effective than its predecessor IT project management approaches for large scale IT projects. If that's your situation, Scrum is your best friend. Learn the basics first, and practice them closely. Then, once you've mastered them, you can add your own modifications as needed.

But it is nowhere near fast or flexible enough for new product development.

Market Risk

When you are responsible for bringing a completely new product to market, Kanban (coupled with rigorous Lean Product Management) will be much more effective as a development approach.

Your team is in startup mode. It doesn’t matter if you are working inside a large company or not. If you're bringing a new product to market, the laws of startups still apply.

Startups are temporary organizations, operating under extreme uncertainty, attempting to find a scalable and repeatable business model before running out of money — Steve Blank and later, Eric Ries (more or less).

The uncertainty for startups is discovering what customers want, not how to build it. In the dot-com boom of the late 1990s and early 2000s, the main uncertainty appeared to be how to build technology, or technical risk. E-commerce was relatively new, not everyone had a website, and there was a lot that we take for granted now (cloud, mobile, social) that was still being figured out.

Today, we can build almost anything customers want. The technical risk is vastly lower than what it was years ago. What’s most uncertain now is what exactly customers want and will they actually pay for it, or market risk.

As your team is forming and deciding what process to use, you’ll probably consider something like Scrum. Scrum is more well-known than other Agile methods, by a wide margin, so it's natural that someone on your team has tried it before and will suggest it. That would be the wrong move.

Scrum was not developed in, for, or by startups. While it is indeed very flexible for the above enterprise IT purposes, it is not flexible in the right ways to make it compatible with the extreme ambiguity and speed of new product development.

The challenge with startups is that you need to be able to iterate very, very quickly. How quickly? That depends on how badly you want to stay in business. For any new product to be successful, it needs to solve a painful problem for customers in a sizable, reachable market. And every idea you are working on, I promise you, is already being pursued aggressively by other teams at other companies. Time is critical.

You are facing a range of risks and uncertainties that need to be systematically addressed as quickly as possible. The customer segment is uncertain. Their most painful problem is uncertain. Whether your solution idea is any good for solving that problem is uncertain. Whether your idea can scale is uncertain. And on and on.

Consider that in a typical tech startup these days, and you either are one or your competition is, it is possible to have an idea, sketch it out, code it, and deploy it directly to customers literally the same day, sometimes within hours, and measure their behavior to see if your hypothesis was correct. (This is as true for B2B products as it is for consumer ventures. You just have to be clever about how you do it.)

When you're working at this speed, waiting for feedback from the last two-week sprint simply won't do. The rate of learning (of reducing uncertainty about market risk) is correlated with the number of times you can iterate and get feedback directly from customers, not from the Product Owner, not from the Sales team, and not the CEO. If you can only learn from actual market feedback after each sprint, your competitors are learning tens of times faster than you are.

The roles of Scrum don't really fit into a startup environment either. A good startup team is cross-functional (Product, Engineering, UX), self-organizing, and technically quite mature. There is nothing for a Scrum Master to do. If your team needs a Scrum Master to help coach them on Agile practices, they should not be in a new product development environment in the first place.

Likewise, the role of the Product Owner doesn't really fit. There is no backlog of clearly defined user stories in the way that most Scrum teams expect. There is a list of hypotheses that need to be tested using experiments. Those experiments might require coding, research, interviews, prototyping, integrating third party tools, or any number of activities. You can't estimate them in the same way that you would with a stack of user stories. And you can't prioritize them the same way either.

Effective startup teams instead share the responsibility for managing the backlog of hypotheses to be tested. Product, Engineering, and UX collaborate to identify market risks, test new ideas, iterate, improve, and adapt. Oh, it's Agile alright, but it's definitely not Scrum.

In an environment where the work is highly heterogenous in nature (sketches, landing pages, customer interviews, coding, infrastructure, analytics, etc.) and arrives in the input queue at a pretty much random rate (usually generated by the internal work done by the team themselves), a method like Kanban works much better.

There are a million good articles on Kanban (I wrote one years ago, and Nave has many good ones here), so I won't go into the details. But here are the key points for you to consider for new product teams. Kanban...

• Emphasizes rapid, continuous delivery and feedback loops based on the smooth flow of work, and de-emphasizes specific rituals and roles.
• Encourages tight cross-functional collaboration through constraining work in process. Focus is on the flow of work, not the worker.
• Allows you to start with what you are doing now, and systematically evolve from there.

In most startups, the workflow already looks a lot like Kanban without the team having formally adapted it. They naturally optimize for fast, continuous flow and feedback loops. They know that the most important thing in this first phase between having an idea and hitting product-market fit is validating that customers will actually pay for the solution, thus reducing market risk. They don't get hung up on formal roles or ceremonies. They work collaboratively and cross-functionally by default.

In large IT organizations, it's generally the opposite. The culture is quite structured and risk averse, and for good reason. There are large and complicated systems for which the teams are responsible to keep running. The optimization here is to verify through detailed specification and discussion the myriad requests that are coming in from the business. Changes need to be carefully managed. In such an environment, it's not all about speed. Stability and predictability are more highly prized. The main features of Scrum beautifully address these challenges.

Culture Clash

In most established technology organizations, Agile is already present in some form. According to the recent 15th State of Agile report by Digital.ai, Agile development is now the mainstream approach to software development. 81% of the organizations surveyed in the report are using Scrum, or some variation of it (Scrumban or a hybrid).

I would guess that nearly 100% of those organizations are trying in some way to develop new products or services. If Scrum is your go to tool for software development in your existing products and services, it is very easy to assume that, of course, it should work for new product development initiatives too.

Most large organizations simply assume that all software development should follow the same process and simply assign new product development responsibilities either to existing Scrum teams or form new ones just for that purpose. The results are nearly always disappointing.

Here's more or less how that goes. The board of directors has set very high growth targets for the next year or so, and puts pressure on the CEO every board meeting to come up with some new sources of revenue, or else. The CEO turns to rest of the C-suite and says, "Hey, team! We've got to come up with some new products right away. Get on it!"

Feeling the pressure from both the board and the CEO, the C-suite leaps into action, brainstorming a bunch of ideas that they think are just great, many of which they've had in their minds for some time. One or more of these projects are identified as "critical new initiatives" and assigned to a Product organization to go "implement."

The Product organization weighs the importance of this new initiative against all of the other projects that have already been approved and paid for at the annual budget meeting, and assigns one of the Product Owners to take it and run with it.

The poor PO must now find a team, and negotiations begin with Engineering leadership to find "resources" to work on this project. The names of developers are moved around in a spreadsheet, until, at last, some semblance of a team is identified. The team members in question, happily working on an existing system for months, suddenly receive orders to report to this new team for duty. There is a kick-off meeting, where the PO explains to the team whatever they can grasp about the goals of this new initiative from their harried meeting with the CTO earlier that week.

From the back of the room, the most senior engineer raises a hand, and asks, "where is the backlog of user stories that we can start working on?" Good question! Where indeed will those stories come from? In all likelihood, they will be dictated by the most senior stakeholder who put the pet project on the table in the first place.

What I've described so far happens outside/before the decision point (usually) of picking an Agile framework, unless the organization is so committed to Scrum that it's a foregone conclusion you'll be using it. This is a dysfunctional organizational pattern, to be sure. But it happens like this in most companies today, so I am trying to keep the story realistic.

You may not be in a position to change how these new product initiatives were selected, handed down, and funded from where you stand in the organization (we can help you with that at Startup Patterns, so if you're interested in that aspect, drop me a note). But you can maximize the success of the initiative from here on by making the right choice of Agile approach.

If your team finds themselves in the position of developing a new product or service, leveraging the techniques actually used by startups is going to be your best bet, and that amounts to a Lean/Kanban approach. If you want steady, predictable, but not quite as fast, learning in an environment of high technical risk and numerous stakeholders, but with clearly defined outcomes, Scrum is your best bet.

Finally, I know that some of my colleagues in the Agile coaching business will zealously object to my advice here and claim that yes, of course you can use Scrum for new product development, too. Sam is not being fair. Sam didn't read the Scrum guide properly (I've been keeping an updated copy on my bookshelf since 2008). Sam is mischaracterizing the roles of Scrum Master and Product Owner.

So, let me just address their concern with this call to action. Don't take my word for it. Try the different methods yourself. Focus on outcomes over any particular methodology or process. Measure your success with real product metrics, and benchmark your cycle time and throughput so that you can work to improve it. Use your brain, your intuition and your senses, to experiment with different ways of working, and never be afraid to sacrifice any sacred cows that stand in the way of your success.

Good luck! And please reach out if you need help.

--

Ready to improve technology leadership in your organization? Try our free diagnostic tool.