Jeff Patton recently wrote a blog post on 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.

1I would like to explore 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 using 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.

2.1

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 to 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 for 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 the analysis paralysis and creates the pressure to moving ahead even when things are uncertain. We found that people adopt 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, take breaks and most important, suggest that the team own their own 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 is common agile practices, the how and what of agile, the emerging culture and practices depend on 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 to the job they try to get done
  • Expect to see different team behaviours and climates depending on the challenge the team is facing
  • There’s 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 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

 

References

Jeff Patton and Accosiates, Common Agil Practice Isn´t for Startups

mySugr

Seapoint Center, How to Avoid Team Decisions That Plop

The McCarthy Show

Management 3.0, Bring Kudo Cards Back to Your Office!

The IT Risk Manager, Understanding Uncertainty’s impact on Learning