In march 2012 seven it-agile people (including me) formed the StartupMarch team. We decided to build a product to make online discussions more effective. In the end we had built http://www.discuss2decide.com and http://www.discumeter.com.
This blog post is about the “process” we used. We just started to build the product – without any discussion of the process to use – Scrum, Kanban, XP? We just didn’t talk about it. This is what emerged:
- Before the start of the StartupMach we only had decided on the problem to solve (online discussions) and the technology we would use (Rails). So we invested the first day for some conceptual work.
- At the second day we started the development of the first ideas. We had the first product (Duscuss2Decide) live at day 3 and the second (Discumeter) at day 5. After that we had more than 15 releases per day. The rule was simply: whatever you commit into the master (aka Trunk/Head) will go live immediately.
- Typically we started the day with an informal wrap up of the product usage (a kind of review if you want). Then we discussed what to do during the day (kind of planning). And then we did it. For both “meetings” together we invested 30 to 90 minutes.
- During the day we had 2 to 4 sync meetings to check where were and how to proceed (kind of Daily Scrum).
- We did no Task Breakdown but Story Splitting on a very tiny level. We worked with MMFs (Minimal Marketable Features) that we broke down into User Stories. Most stories were done in less than 2 hours.
- We managed work in progress by gut feeling. Normally we all would work on the stories of one MMF (single piece flow). That way a MMF normally needed one day to complete.
- We did Pair Programming in most cases and often switched pairs at the sync meetings.
- We had two retrospectives. One in the middle of march, one at the end of march.
- There were no roles. No Product Owner, no ScrumMaster, no Testers etc. Just team members. During our second retrospective we had a discussion about the roles. The conclusion was that we sometimes would have profited from a ScrumMaster for facilitating discussions and forcing us to face uncomfortable facts. And we thought that the absence of a Product Owner person was helpful. The team was not only empowered to decide on how to do the work but also on what to work on.
It was a great time. We had a lot of fun, we learned a lot and it felt very productive. Although we didn’t acquire millions of venture capital for our products, Discuss2Decide seems to have value for users. There are some regular users of the tool and most online discussions at it-agile are done with the tool today.
Will it travel?
Will the “process” travel to other contexts? I don’t know. I think there were two special ingredients that are uncommon and may have been crucial:
- With the seven team members we had roughly 45 years of experience with Agile of different flavors in the room: Scrum, XP, Kanban, FDD.
- All team members shared a common cultural background (it-agile) that showed up as an extreme openness for other’s ideas, perspectives and needs.