Being a Lean Startup Machine mentor was definitely a very rich experience for me.
Last year I wrote a blog on how to evolve the Agile Development process applying the Lean Startup and Customer Development principles to it. I called this new model User Driven Development (see UserDrivenDev.com, or please come to see it at the Agile2012 Conference in August).
Now, at Lean Startup Machine San Diego, becomes clear to me how powerful the process can be if we do the opposite path, that means, apply the Agile methodology on top of the existing Customer Development process.
These are some common issues that I could observe on a Customer Development team (actually, common issues for any team formation):
– Team misalignment: People are talking and doing different things inside the same team.
This quickly causes individual unmotivation, because of the lost of the team synergy.
– Lack of progress visualization: The team is doing a lot of progress but for some reason it is not clearly exposed and tracked. This brings a lot of frustration to the team because they can’t proof their own progress and they can’t compare themselves with other teams.
– The Board as a brainstorm tool: The team adds all the thoughts that are being produced straight to the board (a.k.a. canvas). This can be verified when the team has a lot of lost sticky notes all over the board. This quickly causes lost of track because the board becomes too complex to handle.
– Hierarchy inside the development team: Some people concentrate the decision power and act as a boss/manager/owner inside the development team. This drastically decreases the learning experience for the whole team.
The good news is that all the problems above are already being addressed by the Agile Development methodology and can be solved with the Agile practices.
– The team misalignment can be solved with frequent Demos.
When the team has to present their work on a regular basis and not only at the end of a release, it forces the team to focus on few activities at a time and forces the individual to find out what exactly these team activities are, instead of move ahead by their own.
– Lack of progress visualization can be solved by time boxing the process in small sprints.
Cutting the development process in small chunks of time forces the team to make frequent stops and revise their own progress before keep going to the next development period.
– Brainstorm on the board can be solved with a task backlog and a planning meeting.
On a planning meeting the team selects the few amount of tasks to be prioritized on the next sprint and adds to the task board only these few prioritized ones. All the other tasks specified can be stored on a backlog spot out of the task board.
– Hierarchical teams can be solved spreading the self-managed or the independent team culture.
No significant task can be accomplished without the help and cooperation of any of the members;
Members typically specialize in different tasks within the team, and
The success of every individual is inextricably bound to the success of the whole team.
The compressed Agile Methodology
Organizing Agile Hackathons in South California brought me enough experience to understand how to compress the Agile Development process to a weekend as a learning purpose. Which can be a very good match for the Startup Weekend, the Lean Startup Machine or many other Hackathon formats.
(I’d like to quote here that compressing a process from their ideal model, it does loose a lot of the potential and the characteristics of it. That is why I think it should be done only for learning and gaming purposes.)
This is how the agile process can be applied for a Hackathon event:
– Sprints time boxed in a period between 4 to 6 hours, giving to a weekend the opportunity to iterate over 2 sprints on a Saturday plus 1 sprint on a Sunday with the final release demo at the end.
– Each sprint on a Saturday should be composed of:
Sprint Planning and prioritization – 15 minutes
A “stand-up meeting” composed of 5 minutes brainstorming about the steps to be accomplished by the team at the current sprint, 5 minutes to prioritize a few tasks, 5 minutes to distribute the tasks between the team.
Build – 3 hours
Sprint Demo (with Usability Test) – 20 minutes
The teams pair in two and demo their progress to each other in 10 minutes each. For each sprint, each team chose a different team to pair with. It is good to share experiences inter teams.
If the sprint already produced something that can be tested, so instead of a presentation demo, the team should do straight an usability test with the other team actually experiencing the artifacts produced during the sprint.
Team Retrospective – 15 minutes
Each person at the team talk about the top problem/impediment he or she had during the sprint around the process or the tasks they are performing, and say what he or she can do to solve it or to at least minimize the problem.
– Between sprints, other activities (like presentations, body stretching sessions, games ,…) can be applied to encourage participants slow down and stop working between sprints (see eXtreme Programming sustainable pace).
– The Sunday sprint should be composed of:
Sprint Planning and prioritization – 15 minutes
Build – 3 to 4 hours
Release Demo preparation – 1 to 2 hours
Final Event Demo for the whole event
Final Event Retrospective for the whole event
– Each team with a visible board (or customized canvas) that can show status and progress of the team activities.
(I suggest a big other board for the event itself showing overall progress and status for the event as a whole)
– A coach should be assigned full time at the event to help participants specifically with the process.
– An event retrospective meeting with all participants Saturday after the second sprint could be applied to collect feedback for the event itself.