Feedback from Class 3, Week 2 (Value prop on the BMC) was that the teams needed help setting directions and daily to-dos. This is a problem for any company, large or small, and is magnified by the weekly cadence and the sheer level of getting stuff done in the accelerator. I think the Kanban Board, embodying the two schools of Scrum and Agile, is the perfect tool to cut through the clutter and focus a team.
Dillon has been teaching Agile Product Design at CCEW for the past semester and I leaned on his experience to help teach this class. For both of us, our inspiration comes from Joe Justice and the WIKISPEED team. WIKISPEED builds cars that get over 100mpg, all with a distributed team working in a variety of cities and countries around the world, and without any central guidance. As Joe would say, Awesome!
For a complete writeup of how WIKISPEED uses Scrum, Agile and Xtreme Manufacuring to achieve its goals, check out this case study I wrote with Martin Kupp from ESCP Europe and Linus Dahlander of ESMT European School of Management and Technology. Download the WIKISPEED case
Here’s how Dillon and I mapped out what class should focus on:
At the heart of it is the Kanban Board. On the board goes a backlog of user stories, which is in large part the value props and features from the business model canvas. As teams start work on user stories (which get broken into specific, less-than-4-hour tasks), they move the user story into the “in progress column”.
One of the key aspects of using a kanban board is to limit the amount of user stories and tasks that go into the in progress column. I think two or max three is the right number for a two-person team on weekly iterations. Often a team will get new ideas and want to move them into the in progress column immediately! But that isn’t possible – the old tasks/user stories need to get moved into the done column before launching new ones.
In the lean startup model, a user story is often an assumption that needs to be validated, so passing or failing the validation test is what moves the user story into the complete column.
Scrum adds in the concepts of standups and self-governing teams. A standup is a daily short (often ten minute) meeting, where team members update the group on what they accomplished the previous day, what they have on tap for the current day and any roadblocks they’ve encountered to getting their work done. Standups are a great way of removing documentation from the process (although I’m having the startups document their progress and experiments for my benefit, since I’m not a member of the teams).
Self-governing teams means there isn’t a manger handing out tasks. Instead, each team member commits to completing certain tasks during the week. Scrum uses the concepts of sprints to say what work the team needs to commit to at the start of the sprint to be finished by the end of sprint. Sprints of 1-3 weeks are common. At the end of the sprint, two things happen: 1) the work finished is compared to the work committed to and 2) the finished work product is demoed for the customer. I’ve set the sprint time to one week for the purposes of the ten-week accelerator. One-week cadences are great for keeping startup teams making forward progress. Our experiment process also necessarily demos the work product for the customer each week too. The demo’s purpose is to make sure what the team is building is what the customer is expecting.
Agile is based on this manifesto – http://agilemanifesto.org/principles.html. It is very software focused but as Joe discovered, just change out the word software for whatever it is that you’re working on and agile still does great! On top of the proven benefits to workplace productivity, as a personal aside, I find it tremendously interesting how agile appears to dramatically improve team morale and happiness. Taking pride and ownership in one’s work and seeing meaningful change over short time periods is good for the human spirit!
The key work we did in class was creating a kanban board backlog from the business model canvas. I see these two tools as intricately linked in the weekly workflow. The week starts with an update of the business model canvas based on the experiments of the previous week. The bmc is fantastic for cataloging the assumptions that need to be worked through and to check that the business is in line to product income! But the bmc isn’t great at telling a team what to do day-to-day. That’s where the kanban board comes in. As the team creates the tests and experiments it wants to run, those are crafted as user stories (use feature + to solve problem + result) and added to the backlog. The team burns down the backlog during the week running the experiments, and then the cycle starts over the next week.
Here’s Dillon rocking the classroom. Plus fancy motion effects around “velocity”! (PS: We put up our nascent idea to start a language immersion dorm at OU to fill out the kanban board. We’re going for a one week start-to-finish validated project).
- what’s a kanban board look like
- user stories (assumptions, features) – use feature + to solve problem + result
Exercise: Transfer business model canvas to a kanban backlog
- product owner ranking (HW)
- customer reviews – with rankings and points
- Scrum Master (3 biggest impediments)
- Sprint/Product iteration
3. Agile Principles – http://agilemanifesto.org/principles.html