Stop starting. Start finishing.

When we started using the Agile development concepts at Answers.com, we started by putting up a Kanban board.


We then created a post-it note for each active project.


Result? The board was not big enough and the concept of Kanban looked overwhelming. How were we supposed to track this many projects?


That's when we took the drastic step of stopping many of the projects we we re working on. We implemented the "Stop starting; Start finishing" philosophy.


Initially it was counter intuitive: We were trying to get more done by doing less?


Yes. That was the game plan - and it worked!


Instead of thrashing between multiple projects, each team was focused on a single project or milestone. More than that: we stopped using each team to its full capacity!


What? You had people do nothing?


No. Never. Worst case scenario, the spare people would take care of things link technical debt; those little annoying things that really should be done but nobody gets around to them.


Most of the time these spare people were taking care of emergencies and other rush jobs that had to be done immediately, if the company was to survive. They could also step in to replace a team member who is absent, or do pair-programming on difficult issues.


What happened? Since the teams were now focused on a single task, and didn't have to spend time deciding which project was more important, and since they were not distracted by "emergencies", they started delivering in record time.


They were now often able to deliver in 2-week increments, including testing. Previously they were delivering in 2-month increments with many weeks of testing and integration issues before the project could actually be delivered.


So the fewer things that were started, the faster they get finished. Throughout goes up, as well as team morale.


It takes while for management to get used to the idea that a pet project is waiting for a slot. But they eventually understand that once that slot is found, their project will be finished in record timing.


But don't they classify their projects as emergencies? In a future post we'll discuss what are emergencies and what gets to jump the queue.


Lesson learned: Do one thing at a time, and do it well. 


- Danny Schoemann