Introduction to Agile and Lean Practices for Data-Driven Product Development
This article is part of “Intro to Data-Driven Product Management,” a series of posts from the crew at Notion to help new (and experienced) Product Managers use data to create better products.
If you work in product development, you’ve probably encountered the idea of “Agile” as a methodology to make development faster and more iterative.
“True Agile” is a concept that causes debate, but the reality is that Agile has had a tremendous impact on the way software teams make products. In the old days, “making something” or building your product wouldn’t occur until a linear research and planning process was complete, otherwise known as a “waterfall” process. Most software teams now use a more iterative approach, though there are vast variations on the way teams schedule releases, manage their roadmap and track their progress.
At Notion, we try to practice “a-flavor-of agile” principles, and we help other teams using these strategies to keep track of their progress and communicate about their metrics over time, which can help teams become more iterative (a common goal of Agile and Lean practice).
Agile is based on the idea that teams need to function in unpredictability with incremental, iterative work cadences, known as sprints. Sprint length varies from team to team, but for software development, 2 weeks is a common iteration.
Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about seven people each. It provides a structure of roles, meetings, rules, and artifacts. Teams create and adapt their processes within this framework. Scrum has only three roles: Product Owner, Team, and Scrum Master.
In agile, a team builds software at the same time that they’re gathering requirements. This helps them avoid the traps of overanalysis that can prevent a team from making progress. Using sprints that are shorter, discrete periods of work makes it easier to make quick changes and to calibrate the entire release.
Agile has created a number of concepts that software teams often use to streamline their development process.
- User stories articulate work to be done from the perspective of the user, which helps the relative value of the work to be more clear.
- Estimation lets developers inform the process by working through how much work a story will take to complete, rather than having a top-down approach to deadlines and milestones.
- Burndown charts give teams insight into the work they’ve accomplished in a sprint and how much more they need to accomplish.
Though Agile has its share of adherents, it faces criticism as a product development process for being too rigid and focusing too much on the process of building without real understanding of the value of what’s created.
The Lean philosophy, most famously laid out in Eric Reis’s seminal “Lean Startup” moves towards a more data-driven product development process. The “Build.Measure.Learn.” cycle reflects the goal of informing agile-style product development with better information based on testing and learning.
Data plays an important role in Lean, especially in some key areas, which we’ll cover fully in future articles:
- Continuous improvement
- Validated learning
- Innovation Accounting
In their book Lean Analytics, authors Ben Yoskovitz and Alistair Kroll suggest that the “Measure” step is when things start to fall apart. Often companies either lack the data to make decisions or they lack focus by tracking too much data.
Without prioritized, actionable metrics, teams can’t ever get to the “Learn” phase of Lean, and end up getting stuck on their own ideas and hypotheses informing the “Build” phase (no doubt buoyed by their own egos).
Yoskovitz and Kroll propose that Lean Metrics be understandable, comparative, behaviour-changing, and be a ratio or rate. Track metrics over time to give them context and try using a ratio or rate to offer better insight into your team’s health. Make sure what you’re measuring is instantly understandable to your team and stakeholders.
For the authors, the most important element is “behaviour-changing,” meaning that by tracking this number, you know what actions you will take based on how this metric trends. This can help you avoid “vanity metrics” such as “Likes” or “Site Visits” that are ultimately beyond your control (though you might specifically track “site visits sourced from an advertising campaign,” which you could potentially change by improving or expanding the campaign itself).
One last suggestion from Lean Analytics is to focus on one metric at a time. You should choose this metric based on what lifecycle stage your company is at and what type of business model you have. Here’s a handy chart to get started; check out the book to get more insight.
Notion is a tool to help team leaders collaborate and communicate around their metrics. We’ll be diving more deeply into some Lean Metrics in future lessons, so stay tuned!