Five Common Agile Practices that Work with Startups

Blog

1 Jun

Jeff Patton recently wrote a blog post on the limitations of common agile practices within startups. I like Jeff’s bottom line “to keep the spirit of agile but discounting the dogma” but have made experiences with agile practices that generally seem to work for a startup.

I would like to question what is common in agile practices which in fact depends on what are the common jobs people need to get done when moving from finding a vision, planning the work and getting the work done that makes them use agile practices.

Recently I’ve been coaching two teams at mySugr, a startup in Vienna that aims at making diabetes suck less. One team was working on the LOGBOOK, the diabetes tracking mobile app, that helps people suffering from diabetes to keep track of their medical data in a fun and gamified way and which is the main product of the company.

The team working on the LOGBOOK is working on incrementally innovating within an established product ecosystem. Their product has found a solution market fit and the main challenge is to deepen the value proposition and customer creation. For this team a Scrum model with weekly sprints, weekly user testing and a Product Owner who helps to prioritize a backlog works pretty well and creates stability and high velocity in the team - that’s what Jeff calls common agile practices.

The other team was working on a new service offering called ACADEMY, which provides education and training. This team just had a first MVP ready and now testing and improving with real user behavior, thus was iterating thru a customer discovery and validation cycle. Both teams were started in parallel and in a retrospective we’ve found that the team’s climate, behaviour and how they were doing things was different to the team busy with LOGBOOK. The team came to the shared assumption that the other team was performing better with higher velocity and more clarity in roles and process. What helped them was stepping back and understanding that their task of product discovery just required a different mode of working since the uncertainty of the why and what was much higher for the ACADEMY.

Here’s what I have observed within this team and what we have learned that seemed to work consistently in the context of startups, product discovery dojos and small teams, e.g. in an early phase of developing a game or even on a tight ½ day design challenge at the #PoDojo:

1. Lightweight Facilitation

If someone in a team, even if it’s just 3 people, takes the facilitation role and takes care of time boxing, helps with tools, team space set-up, meetings, decision making and reflection on how things are going then teams learn faster, are more relaxed and become more creative.

2. Timeboxing

Timeboxing helps teams to avoid analysis paralysis and creates the pressure to move ahead even when things are uncertain. We found that people adapt to time boxes and perception of what can be done in 5 minutes changes over time. But be careful with this, there should be plenty of slack time too, breaks and most important: make the team own the time boxes. Here’s a clip showing how timeboxing used as a constraint generates different outcomes.

3. Visual Management

There’s an agile principle that says the best way to convey information is face to face communication and we’d like to add: supported by visual tools. As Alex Osterwalder says ‘the wall is the new desk’ use canvases, kanban and sprint boards to create a space that supports the team in thinking and decision making. When you decide to split up into problem and solution team a shared wall space and visual facilitation is essential to keep the shared vision intact.

4. Decision Making

Teams can get stuck if they miss a protocol for decision making. The worst that can happen is if teams develop a culture of ‘Plop’: someone makes a proposal, no one listens and everyone moves ahead as if nothing happened. We’ve used a simplified version of decider protocol that helped a lot to help a team decide fast. Other tools we like to use are dotmocracy, value/planning poker and the rapid versions of those that use affinity grouping.

5. Retrospectives

Last but not least are retrospectives that help teams reflect on how they work. We’ve observed teams getting value out of a 3 minute standup briefly checking what to keep, what to stop (important!), ideas for doing better and kudos for people who did a great job (even more important!).From my point of view, what are common agile practices, the how and what of agile, the emerging culture and practices depend on the task and context of the people who are working together. Finding the vision or discovering the product is becoming more and more common, not only in startups. I believe that the tools have to follow the problem not the other way round. The main point of agile - as I see it - is to help groups create value and continuously become better in doing so, and this doing may look very different in different contexts.

Lessons learned

Start with a minimal toolbox, e.g. just the 5 practices or even less like No 1, 2 and 5 in our list could do
Don’t judge teams from outside using a preconception how things should work, the behaviors you observe may be just a good fit for the job they try to get done
Expect to see different team behaviours and climates depending on the challenge the team is facing
There are no common agile practices but common jobs that teams need to get done, e.g. product discovery or incremental innovation
Product discovery requires different agile practices than an incremental change of an existing product
Make use of models, e.g. stages in customer development that help the team and stakeholders make sense of the situation
For product discovery use tools (e.g. Value Proposition Design, Lean Startup and Design Thinking) to create a feedback loop even when things are very blurry