{"id":3346,"date":"2013-04-22T12:03:55","date_gmt":"2013-04-22T20:03:55","guid":{"rendered":"http:\/\/blog.mozilla.org\/webdev\/?p=3346"},"modified":"2013-04-22T12:06:05","modified_gmt":"2013-04-22T20:06:05","slug":"kanban-for-mdn-development","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/webdev\/2013\/04\/22\/kanban-for-mdn-development\/","title":{"rendered":"Kanban for MDN development"},"content":{"rendered":"

\"MDN<\/a><\/p>\n

MDN workflow was a formless void<\/h2>\n

When I first joined Mozilla there was no workflow for MDN; in fact, there were no full-time developers for MDN! To push my first bug fix<\/a> to the site, I had to negotiate a mess of mdn bugs, wiki pages, and IT bugs, strung together with email<\/strong>. It took a couple weeks to get a simple fix into production, and worst of all – I had to interrupt at least 3 other peoples’ regular workflows.<\/p>\n

Let there be Scrum<\/h2>\n

\"MDN<\/a><\/p>\n

I had done Scrum for a few years at SourceForge so I naturally started to work in some “scrummy” things for MDN<\/strong> – first I added some agile\/scrum features to the Bugzilla JS addon<\/a>. Then we got another couple of developers on the team and we used more agile practices in our MDN workflow<\/a>. So we did user stories, standups<\/a>, retrospectives,\u00a0planning poker<\/a>, and sprints on top of Bugzilla<\/a> with Paul McLanahan’s fantastic ScrumBugs<\/a> tool. We used it to run our sprints for over a year; to migrate MDN from MindTouch to Django<\/strong>. Sprints helped<\/strong> us prioritize, plan, and commit to release batches of bug-fixes, enhancements, and features at regular intervals.<\/strong><\/p>\n

Continuous Deployment<\/h2>\n

\"MDN<\/a><\/p>\n

On our new Django platform, James<\/a> and Jake<\/a> hooked chief<\/a> up to give us continuous deployment to MDN; our “regular intervals” went from weeks to hours. Our flexibility and adaptability with continuous deployment is awesome. Pushing frequently caused a series of effects on our workflow, though:<\/p>\n

    \n
  1. We naturally prioritized things by hours or days<\/strong>. So, during our sprints, we would<\/li>\n
  2. remove and add items between planning meetings<\/strong>. This had knock-on effects like<\/li>\n
  3. making it hard to see what we’re actually working on<\/strong> between meetings, and<\/li>\n
  4. making our sprint-based estimates totally inaccurate<\/strong>.<\/li>\n<\/ol>\n

    A ban came, it’s name was Kan<\/h2>\n

    Around this time, I read Kanban<\/a>, by David Anderson and some of Kanban and Scrum<\/a>. A couple things stood out to me:<\/p>\n