Peter Kellogg-Smith, VP of Product, Sharon Tom, Lead Product Manager and Tony Pelosi, Product Management Director, share lessons they have learned at BCG Digital Ventures’ startup foundry. This post originally appeared on LinkedIn.
Agile is polarizing.
Some companies credit Agile for huge advances in software development productivity. Others do everything they can to avoid it. While Agile is not appropriate for every team, Agile is often criticized based on unfair misconceptions.
Given our experience running teams at BCG Digital Ventures, we know Agile can provide value when done right. In this article, we dispel six common Agile misconceptions.
A client once told us that her colleagues believe Agile is an excuse to avoid planning. She said, “If I tell them we want to use Agile, I will get laughed out of the room.”
Funny enough, planning is a critical component of the Agile Scrum framework. Each sprint (i.e., development cycle) involves planning. The planning process lets engineers and product managers get their ducks in a row before the next sprint begins.
In addition, Agile product managers continuously update their roadmap—some even plan more than a year in advance. After explaining this to our client, she felt more comfortable suggesting Agile to her team.
Contrary to this myth, documentation is actually a large part of Agile. To stay coordinated, teams must be able to reference a single source of truth.
Agile does not over-index on monolithic specifications like the Waterfall methodology. Instead, Agile teams focus on a “north star”—documenting the most important use cases and requirements in the form of epics and user stories. These help engineers build and launch compelling features more quickly. This approach fosters strong collaboration across product, engineering and design.
Agile also involves backlog grooming, where engineers and product managers discuss upcoming stories and priorities to ensure a collaborative process. As priorities shift, product managers groom the backlog.
We had a client engineer tell us that Agile documentation is terrible because it doesn’t depict exact requirements. This is an important reminder that Agile isn’t for everyone—some engineering teams want to be told exactly what to build and how to build it. But if your engineers want more freedom to think critically and collaborate with cross-functional teams, Agile may be a great choice for your team.
Two important things to note: First, Agile has zero correlation with good or bad product or code quality. Second, completeness doesn’t equate to robustness.
In Agile, completeness depends on the organization’s goals. Completeness should mirror what you want to learn—it has nothing to do with the volume of documentation. At the same time, Agile ensures quality and completeness by providing a central place to record user stories, acceptance criteria and test cases.
One client was launching a new product and startup and was baffled that we didn’t have thousands of test cases written. She thought the product was lower quality based on this metric alone. She didn’t understand that the lifecycle of the product determines the type of QA needed. While a mature company needs thousands of test cases, this is impractical for a startup.
The misunderstanding of expectations was solved by creating a plan for a phased roll-out, linked with an appropriately increasing product quality and scalability. Completeness should be determined by the organization’s goals.
This isn’t strictly about Agile, but we are going to sneak it in anyway.
After developing IBM’s huge OS/360 operating system in 1975, Fred Brooks wrote The Mythical Man Month. The central theme of the book is that adding manpower to a late software project makes it later. Similarly, in Getting Real by 37 Signals, the authors argue that companies should only hire the very best and stay as lean as possible to minimize communication overhead.
Agile is about collaboration amongst people. More people translates to more overhead and not necessarily greater productivity.
For Agile to be effective, it must extend beyond engineers.
Team members across different functions must constantly validate product-market fit through a series of build, measure and learn loops. However, over the years we’ve encountered many teams that practice what we call “Faux Agile.” This is a variant of Agile where product research and planning are conducted in traditional Waterfall fashion, but development is conducted in a series of sprints—often without testing for product-market fit. Real testing for product-market fit may not even occur until the launch and test phase. The image below illustrates this issue.
At one point in my career, I spent nearly two years planning and building a product in siloed teams. During this time, the team never tested the product with customers and competitors launched new products. By the time we launched, we were already obsolete.
At DV, our cross-functional teams are constantly prototyping and testing—from definition through launch. This ensures that what we bring to market is relevant and solves customer needs.
Agile by itself isn’t enough to build products that people love.
Clients often ask if they should use Agile, Lean or Design Thinking. It’s not about using one over the other, but about combining them for the best outcome:
- Design Thinking uses a human-centered approach to uncover problems and solutions.
- Lean applies a scientific approach to validate product-market fit.
- Agile is all about iterative, rapid development.
When you create a team that is capable of using all three methodologies in tandem, you discover the secret to building innovative and disruptive products. DV used this combined approach to launch the startup AutoGravity, a revolutionary car financing platform. As a two-year-old company, AutoGravity attracted big name lenders, received $1B in fund requests and raised $80M.
The six Agile myths that we have dispelled in this post is just the beginning. Look out for a future post where we’ll identify and dispel several additional common misconceptions of Agile!
Read more from DV’s product team here.