Art of Getting Things Done
Recently, two of my relatives moved to Bangalore for their jobs. Both of them stayed with their relatives until they found a place to stay. The first person, let’s call him Tom, moved to a place along with his family within few days of moving to the city. While the second person, let’s call him Harry, is still looking out for a place even after a month.
Let’s analyse it. Tom made a decision that he needs to find the new place with the least time possible, but also added the below conditions:
- The house has to be close to the office to avoid time spent on travel
- It needs to be just enough for a family to stay
- The rent has to be within a specific range
But more than these, what was more important for Tom is to move to his own house as quickly as possible. Tom knows that taking more time to find a house doesn’t guarantee that the house is perfect.
While Harry didn’t have a clear plan about what he wants. He has put no constraints and never defined the “minimum” criteria on what he needed. It took longer, which was difficult for Harry because he had to travel a long distance to his workplace. But Harry failed in having a plan and a strategy which took longer for getting things done.
We can relate this to Software Delivery very well. Tom believed in the strategy Done is better than perfect and he got things done faster. It is counter-intuitive to see that the teams who add more constraints, especially time constraints around them, get more things done in the least time. They have more clarity on what they want and they apply strategies around the constraints so that they can reach the destination. Like Tom, they also believe nothing is “Set in Stone” and it is more important to get things done.
And this clarity is the first step towards Small Batches. The teams cannot slice things into small without having a great clarity on what they want. Applying time constraint helps the teams to have a rigor on their journey.
I’ve been talking about small batches in the last few posts. In my posts, I also mentioned that I will share my thoughts on how to create small batches. Like I mentioned, there are only yardsticks you can apply such as INVEST in good stories and SMART tasks.
What had worked for us is the applying time boxing instead of estimating. We started asking “what can be done in a few days” than asking how long something will take. Applying the time as a constraint, helped us to think of better ways of delivering software which wouldn’t have happened otherwise.
Joshua Kerievsky has written about how they moved to continuous flow ten years ago. One Day Sprints by John Cutler is another approach you can try in which every day is to Have The Conversation, Do The Thing, Review, Go Home
I’ve come across an exercise, Elephant Carpaccio, to help the team understand about thin slicing. This was invented by Alistair Cockburn, in which teams do planning, developing and deploying in 90–120 minutes.
You can use this facilitation guide by Henrik Kniberg & Alistair Cockburn and try out the same within your team.
But the key to all this is the clear vision and culture of hustle without which the mindset usually will be that things can take longer and it cannot be sliced.
