As I’ve mentioned, lean startup is hard. So is agile. So is user centered design.
When we try and adopt a new paradigm it’s hard to differentiate tactics like “use a business model canvas instead of a 60 page business plan” and the principle of “planning based on unknowns is wasteful, so plan to learn.”
If we don’t recognize the difference, we might create a Business Model Canvas and then leave it on the wall…
A static business model canvas is as useless as a static 60 page business plan.
What’s the one exception? Retrospective.
If there is one tactic that you should implement to get the fundamentals of lean startup (or agile for that matter), it’s retrospectives.Doing regular retrospectives is a requirement for learning. There are no exceptions.
“But change is so hard!”
Whether you’re a small startup or a big enterprise, changing your habits can be very challenging. At a smaller scale, with just two team members, you’re going to get lazy and just assume that you’re both in agreement and you’ve got your lessons learned.
In an enterprise struggling to adopt lean startup principles, there may be outright resistance and hostility to yet another management driven process change designed to generate more paperwork for people just struggling to do their jobs and get home on time.
There’s an awful lot written about creating good habits that you should check out, but to save you some time, start by making it as easy as possible to implement a retro. Don’t try to read the entire Agile Retrospective book and conduct a fishbone follow by the five Whys. Do a one minute retro.
The One Minute Retro
Have each person grab a stack of yellow sticky notes and a sharpie pen (or just a piece of paper and a pen if that’s all you’ve got.)
- Set a timer for one minute.
- Ask the group, “What’s the one thing in the last sprint/meeting/day/fortnight that you would like to change or improve about the way we do business/our meeting format/our coding practice/the way we order lunch?”
- Start the timer.
- Write something down on your sticky note.
- When the timer goes off, collect all the feedback.
It’s the person running the retro’s job to take the feedback and choose one and only one thing to improve for the next time period.
Why a timer? Setting a timer lets everyone know that it will only take a minute and won’t be another one hour meeting where nothing gets decided and there are no action items.
Why not talk? Writing things down instead of brainstorming out loud prevents group think and also makes the retro mercifully short.
Why not have everyone sort the feedback? Having the organizer deal with the feedback, again, cuts the retro short enough that no one can complain about wasting time.
Selecting one and only one thing to focus on:
- limits scope creep (which exists in process improvements as well as technical specifications);
- gives the team small wins to help show positive progress;
- is just about all you can manage in a short sprint anyway.
Isn’t that just a crappy retro?
Yes. This is not a great way to analyze what went wrong in a six month project.
The point here is to establish the habit of a retro rather than have a perfect retro. You’ll find that most of the nuances you’d get out of a deep dive retro are probably being blocked by more obvious things that are quickly pointed out in a one minute retro:
- People not showing up on time to daily standup;
- Couldn’t make a decision because not all decision makers present;
- (and my favorite) No action items coming out of retrospectives.
Until you cover the basics, getting into the details is irrelevant. Go for the quick wins.
When someone brings up “No action items coming out of retrospectives” it’s a good sign that you should ramp up to a five minute retrospective.
So…what should I post next? Tweet to tell me what to write:Show me how to test product market fit!
orHow can I do lean startup in my friggin' huge company?