Marketplace entrepreneurs often become fixated on technology and features, instead of what is arguably the most important ingredient for marketplace success: having the right process, methodology or approach in place. The right approach will ensure that resources are applied productively and increase the opportunities for success.
We’ve previously written about the importance of distinguishing between the initial once-off cost of building marketplace infrastructure and the rolling budget required to reach product-market fit. This time we focus on which project management approach is best suited to transform your marketplace development roadmap into successful outcomes AND stay within budget.
Kanban and Scrum are two popular project management approaches that are often bandied about in software development circles. In this post we will demystify them and explain how they can both play an important role in minimising risks, boost productivity, and realise goals.
The road to successful marketplace project outcomes is invariably a rocky one that often requires painful first-hand experience to illuminate the best way forward. Traditional project management approaches have been woefully inadequate in dealing with this baked-in uncertainty and risk. A rigid production-line approach simply can’t accommodate the vastly differing variables, such as user flows and go-to-market strategies, of individual marketplace projects.
An apt analogy would be the upstream struggle of salmon past countless obstacles – from gushing rapids and waterfalls to a plethora of predators, including grizzlies, orcas and eagles. If it wasn’t for salmon’s uncanny ability to navigate (by using the earth’s magnetic field like a compass) and agile swimming abilities (they swim at speeds of up to 30 km/hour and can make vertical jumps of almost four metres!), we wouldn’t be enjoying any lovely smoked salmon, gravlax, or sushi.
Flexibility vs Agility
Just like salmon migration, successful marketplace development requires efficient AND effective execution. Or put another way, reaching desired outcomes with the lowest amount of risk.
The ugly truth is that 65% of projects started worldwide fail. The solution according to project management guru, Professor Te Wu,
“To achieve greater success, projects need to be managed and executed in such a way that reflects the complexity of their environments. Projects should be executed with speed and agility, making them adaptable [flexible] in the face of risk. ”
If flexibility is the ability to react to change, then agility is the speed at which we react to changes. Both are products of specific thought processes.
Psychologist, economist and Nobel prize-winner, Daniel Kahneman, in his seminal book Thinking, Fast and Slow contrasted two modes of thought: System 1, which entails faster, instinctive thinking vs System 2, which represents a slower, more methodical and investigative thought process.
Neither is ‘bad’ or ‘good’, but from a project management perspective you need to know when to use which one. System 2 thinking is ideal for the interrogation and design phases of a project, when you need a deep understanding of the risks and challenges. It sets up your project for agile execution.
System 1 thinking is better suited to executing plans at pace and reacting to emergencies or standalone events. It allows your team to respond to changes in a flexible manner.
As online marketplace developers we need a project management framework that supports both agility and flexibility. Fortunately, there is a proven project management approach that allows us to do exactly that.
There is near universal agreement that Agile project management methodologies like Kanban and Scrum, combined with Lean principles, have contributed to superior outcomes for many software development projects. Successful marketplaces like Amazon, Airbnb, FanPass and MobyPark have followed this approach to ignite strong growth trajectories, while making optimal use of resources like time and money. Their secret? Knowing when to apply Kanban or Scrum to their development road map.
Before we delve into the different use cases for Kanban and Scrum, let’s first make sure we are all on the same page with regards to Agile and Lean. We’ll kick off with a look at Agile.
What is Agile?
It’s incredible to think that the Agile Manifesto is 21 one years old this year. The brainchild of seventeen software engineers, it consists of four values and twelve principles that encourage better software development. Its main purpose was to be a framework that puts people (instead of convoluted processes, excessive documentation and overplanning) at the centre of the development process.
This core philosophy of Agile is expressed in its four key values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These values find their practical expression in the 12 principles of Agile:
Agile’s approach to project management emphasises flexibility, collaboration, and continuous improvement. On a practical level, it involves breaking a project down into smaller, more manageable pieces called sprints, typically lasting 1 – 4 weeks. At the start of each sprint, the team sets specific goals and identifies the tasks needed to achieve those goals. The team then works on these tasks, regularly checking in with each other and stakeholders to ensure that the project is on track.
Continuous improvement is encouraged through regular retrospectives, where the team reflects on what worked well during the sprint and what could be improved. Based on this feedback, the team can adjust their approach and make changes to the project as needed.
How does Scrum fit into Agile methodology?
Where Agile is a broader approach to project management that emphasises certain principles and values, like flexibility, collaboration, and continuous improvement, Scrum is a specific framework within the Agile methodology that provides a set of guidelines for managing complex projects.
Key differences between Agile and Scrum:
- Roles: Agile does not prescribe specific roles for team members, but Scrum defines specific roles, including the Product Owner, Scrum Master, and Development Team.
- Process: Agile is focused on delivering working software or products in an iterative and incremental way, while Scrum is a specific process framework that defines the events, artefacts, and rules that teams should follow.
- Time-boxed iterations: Scrum operates on the basis of time-boxed iterations called sprints, typically lasting 1 – 4 weeks. Agile projects can also be structured around sprints, but this is not a requirement.
- Prioritisation: In Scrum, the Product Owner is responsible for prioritising the backlog of work items, while in Agile, priorities are typically established collaboratively by the team.
- Meetings: Scrum has a set of prescribed meetings, including the Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Agile projects can have these same meetings, but they are not required.
What is Lean in software development?
Lean in software development is an agile framework of principles and practices that emphasises creating value for the customer by maximising efficiency and minimising waste. It is based on the principles of the lean manufacturing philosophy developed by Toyota in the 1950s and 1960s.
Key principles of lean software development:
- Delivering value to the customer: The primary focus of the development process should be on delivering value to the customer.
- Continuous improvement: The process should be continuously improved over time to eliminate waste and improve efficiency.
- Pull system: Work should be pulled through the development process based on customer demand, rather than being pushed through based on an arbitrary schedule.
- Empowered teams: Teams should be empowered to make decisions and take ownership of the development process.
- Visual management: The development process should be made visible through visual management tools, such as Kanban boards, to enable teams to identify bottlenecks and improve efficiency.
- Lean culture: A lean culture should be developed within the organisation, with a focus on continuous improvement, customer satisfaction, and waste elimination.
What is Kanban?
Kanban is a visual project management system that emphasises a lean workflow and just-in-time delivery. It is commonly used in manufacturing and software development to help teams visualise their work, identify bottlenecks, and improve the efficiency of their processes.
It utilises a visual interface (Kanban board) to organise and manage unexpected or urgent standalone issues, typically divided into columns representing different stages of the work process. Each task or work item is represented by a card, which is moved across the board as it progresses through each stage of the process. This allows the team to see at a glance which tasks are in progress, which are waiting for input, and which are complete.
Kanban is based on the principles of pull production (part of the Lean framework), which means that work is only started when there is capacity to complete it. This helps to avoid overburdening team members and ensures that work is delivered just-in-time, when it is needed.
Kanban also emphasises continuous improvement, with a focus on identifying bottlenecks in the process and finding ways to eliminate them. By visualising the flow of work and tracking cycle times, the team can identify areas where work is getting stuck and take steps to improve the process.
Pros of Kanban
- Speed: Kanban tickets travel a shorter path to get released (no grooming, deployment, etc.)
- Adaptability: Kanban tickets are usually not dependent on each other. So it’s fairly easy to remove or swap tickets from Kanban sprints.
- Healthy backlog: It’s much easier to build a balanced backlog of work, because tickets cover all aspects of the platform.
- Good at visualising tasks
Cons of Kanban
- Dependencies: Dependencies between tickets can be overlooked. This can cause blockers and bottlenecks among developers.
- Lack of timing: Independent (standalone) tickets make it difficult to build a sequence of work within one Kanban sprint.
- Non-optimal solutions: The best solutions often require thorough investigation of where it fits in the value chain and how its relationship with other elements improves the user experience. Kanban’s focus on quick execution is not ideal for this.
- Risk of tech debt: Rushed tickets may result in the need to re-address the issue in the future, creating tech debt.
What are Scrum Epics?
Epics are collections of inter-related user stories that comprise a feature or a main component of a large feature. Each story in an epic should contribute to the user journey and make sense from the user’s perspective.
Typically an epic runs over 20 man-days on average, at the end of which a demo is given to the client before the feature or feature component is tested in a UAT environment.
The size and frequency of epics are influenced by how soon the client wants to release a feature or version. Sometimes it makes sense to split a large epic into several smaller epics to ship more often or to address urgent issues.
Epics form part of the Scrum project management methodology which provides a structured framework for product development. In line with Scrum principles, epics and their constituent user stories are executed within well-planned sprints.
Pros of Scrum Epics
- Optimum solution: Epics are ideally suited to building cohesive user journeys.
- Goal centric: The grooming stage helps to align tickets and sprints with the client’s business goals.
- Budget control: Epics are estimated at 2 or 3 stages using different techniques. Epics are also tracked daily and reported to clients weekly for more granular control.
Cons of Scrum Epics
- Slower: Epics are released less often than Kanban tickets. This can be a challenge if a part of an Epic is very urgent.
- Scope changes: Changes in the scope of an Epic can have a major impact on resources, timelines and budgets due to dependencies.
- Healthy backlog: It’s harder to build a healthy backlog for all developers because an Epic is less diverse than Kanban sprints. This can result in some Epics requiring lots of backend work, but with little for frontend developers to do.
How we utilise both Kanban and Scrum Epics at CobbleWeb
At CobbleWeb, we use either Kanban or Scrum, depending on which one is best suited to the issue. Both Kanban and Epic tickets (issues) are grouped into sprints.
We use Kanban for tickets that involve:
- Bugs that are independent (standalone) issues as a result of previously released epics
- Urgent bugs that have an impact on the operability and business viability of the platform
- Upgrades or new features that require a small effort (less than 2 days). This minimises the risk of tech debt or implementing a non-optimal solution.
- Analysis that supports a potential epic. It could for example be an investigation of the feasibility of a new payment provider that will be discussed with the client during the discovery phase. Otherwise, analytical tickets usually form part of a signed-off epic.
We use Epics (Scrum) when:
- Extensive effort and resources are required. Epics offer better control over the client’s budget.
- Tickets impact the same user journey. For example, when an update is required for product-related elements (e.g. filters, keyword search and indexing).
- The value of the ticket is not clear. How will it help the client achieve their goals?
A conclusion as crystal clear as a salmon run in an Alaskan river
Marketplace projects contain many moving parts that can easily thrash out of control like wild salmon, leaving your incipient marketplace dry-heaving on the beach of failure. Knowing when to use which project management tool, whether it’s Kanban or Scrum, can keep your shoal swimming fast and as one into the spawning grounds of opportunity.
