This is part of our How We Work series of blog posts. Today, we're talking about how we use agile and lean methodologies to quickly deliver platforms that solve worthwhile problems.
Lean development is all about validating assumptions through experimentation and market data. The goal is to increase efficiency while reducing the amount of waste we create during the process. Lean development was inspired by, and draws directly from, lean manufacturing.
Take Kanban, for instance. Popularized by Toyota, Kanban is a lean manufacturing process that uses visual cards as a signaling system. (In Japanese, the word "kan" means "visual," and "ban" means "card.") The cards trigger an action to supply the process with its needs, either from an external supplier or from a warehouse. Kanban is structured as a "Pull System," where long and short cards move through the process based on downstream demand.
Each queue is optimized to perform its function and the entire workflow is managed tightly by using "Work In Progress" limits, preventing more work from being in process than the system can reasonably deliver. This system has clear and powerful applications far beyond manufacturing, which is why Kanban is now a widely followed Agile software development methodology.
Man Cannot Build on Agile Alone
Agile is great. In fact, it's the best software development methodology around:
- Agile is designed to reduce the risk of large technology builds, and it delivers on that.
- Agile is designed to be more responsive to competitive pressures and customer demands, and it delivers on that.
- Agile is designed to improve product quality by shipping faster, and — spoiler alert — it delivers on that, too.
But Agile is not enough. Sure, it tells you how to build fast, and with less risk. But it doesn't tell you what to build, or why to build it. This is where lean comes in. Lean is all about is figuring the optimum set of features to produce maximum ROI. For us, life or death occurs in the backlog — not the done lane.
"One of the biggest and most common mistakes product teams make is to have far more confidence in their product specifications than they should, and they move forward and think they'll adjust the product — if necessary — once they get beta feedback. But of course beta is far past the time for major changes, and it is little wonder so many initial product releases are so far from the mark."
This activity represents a lightweight framework for helping focus goals and objectives, while providing an easily digestible way to communicate these to investors and team members. It is articulated well in this blog post by Marc Beinoff: How to Create Alignment within Your Company in Order to Succeed. V2MOM is a quick exercise, but we use it to make sure we understand the larger impact or importance of this initiative from the onset.
- Vision: What do you want?
- Values: What's important about it?
- Methods: How do you get it?
- Obstacles: What might stand in the way?
- Measures: How will you know when you have it?
Lean Canvas or Value Proposition Canvas
We work together during several collaborative sessions to identify and document the key components that comprise any successful business. Lean Stack is a strong place to start. Another great framework to use is to start with a deep understanding of your value proposition.
During a lean sprint, our objective is to identify the risky assumptions and systematically validate or invalidate them. To do this efficiently, we formulate a set of hypotheses and test them first through customer interviews, then through a demo or prototype. The demo should represent a few designed selected core screens.
We focus on validating key parts of the Lean Canvas through a customer discovery framework:
- Test the Unique Value Proposition (the customer's pain point)
- Test the offer (the solution — a verbal narrative before a demo)
- Test the business model (validating that a customer would purchase and testing price points)
Demonstrating Problem/Solution fit through customer discovery will result in a tested, credible story.
The Lean Sprint Formula
- Expose problems: In a pre-sprint meeting, the team aligns around a common understanding of the business model constraints.
- Define solutions: Team members generate individual solutions, which are captured on one or more Strategy Proposals.
- Shortlist solutions: The best solutions are selected and shared, ranked, and shortlisted in a sprint planning meeting, officially kicking off the sprint.
- Test solutions: The team diverges again to test the strategies using one or more small, fast, additive experiments.
- Decide on solutions: Decide next actions. Results are analyzed and next actions decided in a sprint review meeting.
There are many Agile methodologies, but Extreme Programming (XP) produces the most customer value with the highest quality output.
XP is a disciplined approach to delivering high-quality software, quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing and planning, and close teamwork. Software is delivered at very frequent intervals — typically every one to three weeks. Ultimately, XP creates flexibility for changing business and product needs. It provides insights into the cost and time to build out features and deploy them.
At Very, this is our project management methodology. It's how we build things, regardless of the language or framework we're using. XP is the way we work.
Do you like to use these same frameworks and methodologies? We'd love to work with you. Tell us about a project you're working on.