Earlier this year someone used a lovely phrase in conversation which was new to me, even though I should have known it, and even though I am a long-time advocate of the concept: stop starting and start finishing. I don’t know where the phrase originated, but it’s well-known enough to live as the title of a book.
We were talking about helping software teams focus on getting stuff done. It’s all too common for a team to have lots of things on the go at any one time: work in progress, things in the test phase, code needing review, features needing sign-off. Whenever a piece of work moves to someone else, it’s easy just to pick up whatever is waiting to be started next. There’s just so much to do.
The problem with this is that nothing generates value until it’s out the door and being used. “Stop starting and start finishing” tells us to put our effort into getting things finished and in use, and hold back on starting new things. This is difficult, as it’s likely to push people outside their comfort zone. It’s often much easier to start something fresh than it is to pick up something with which we have to take time to familiarise ourselves, and which carries recent baggage. As it means less work in progress it can feel like we’re less active, and will also mean more collaboration—ten pieces of work in progress with five people allows a lot more individual working than three pieces in progress with the same team.
But the benefits are significant: primarily, of course, things get done sooner, which means we start earning the benefit sooner. But there is also better knowledge sharing from that increased collaboration, less pressure on individuals who no longer are only ones who can solve certain problems, and there are all the benefits that come from greater focus—better plans, less miscommunication, less time lost to context switching, higher quality outputs, and greater motivation.
What’s also valuable about the concept of “stop starting and start finishing” is that it doesn’t apply just to single work items within a project. It also applies to our projects within our overall roadmap. I’ve been in too many organisations where there is a logjam of projects, the teams are struggling to keep up, and the senior managers don’t understand why everything takes so long.
So, a useful concept at different levels… and a very pithy phrase.
niksilver.com 