In http://ryan-white.blogspot.co.za/2015/10/three-rules-for-sustainable-and.html, I wrote about 3 rules, the third being COMMIT TO NOTHING. In this post, I'm going to talk about how to make this (not) happen ;). Things to think about. Tips and tricks. I could almost write a book about each point here, but I'm not going to put you through that.
1 First: WHY?
Simple. When you commit to nothing, achieving it is easy ;)
Of course, this is a bit tongue in cheek. You're going to have to deliver SOMETHING at some stage, because, well, if you don't, you won't get paid.
"Commit to nothing" really means "Manage expectations VERY carefully".
Of course, this is a bit tongue in cheek. You're going to have to deliver SOMETHING at some stage, because, well, if you don't, you won't get paid.
"Commit to nothing" really means "Manage expectations VERY carefully".
2 Committing to nothing is NOT THE SAME AS SAYING NO
Devs, a lot of times, have a reputation as the ones who can only see problems. The ones who's first response to anything new or exciting is "NO".
In a world where there's a lot of noise generated when things break, but everyone quickly gets used to everything working 100% fine, this is a natural defence mechanism. But it slows down progress.
Rather than "No, because…", you should aim for "Yes, but…".
"YES - we can do this last minute rush project for you, BUT… which items/projects would you like us to delay instead?".
"YES - I think that idea should be possible, BUT… we're going to need to investigate, to figure out timings and impacts".
"YES - we can talk about this scope change, but would you rather have us talking about the new feature, or finishing the stuff we're scheduled to work on now?".
You get the idea: All work is really a matter of logistics. How many hours of development time available, vs how many are needed to get all the things done. Communicating the difference is vital. This is why Rule#2 - TRACK EVERYTHING is so vital: when you have data on how long things take, you're able to negotiate and estimate with confidence.
In a world where there's a lot of noise generated when things break, but everyone quickly gets used to everything working 100% fine, this is a natural defence mechanism. But it slows down progress.
Rather than "No, because…", you should aim for "Yes, but…".
"YES - we can do this last minute rush project for you, BUT… which items/projects would you like us to delay instead?".
"YES - I think that idea should be possible, BUT… we're going to need to investigate, to figure out timings and impacts".
"YES - we can talk about this scope change, but would you rather have us talking about the new feature, or finishing the stuff we're scheduled to work on now?".
You get the idea: All work is really a matter of logistics. How many hours of development time available, vs how many are needed to get all the things done. Communicating the difference is vital. This is why Rule#2 - TRACK EVERYTHING is so vital: when you have data on how long things take, you're able to negotiate and estimate with confidence.
3 Time is your friend
Unless you're in a mission critical "production is down" type of incident, there's no need to make decisions or commitments in real time. No work should be undertaken unless the estimations and planning have been done. This doesn't mean that you should be delaying unnecessarily. You should be working as fast as you can to reduce uncertainty and get a reliable, dependable estimate and impact assessment out. Agile needs less certainty and upfront estimating to get started than Waterfall - so the amount of scoping you do depends on requirements of the methodology.
Say "I'll get back to you", and then do that.
Say "I'll get back to you", and then do that.
4 The people doing the work make the estimates
It doesn't matter if you have consultants telling you how long things SHOULD take. It doesn't matter if you're a team lead, with experience in the tasks, and have an opinion on how long you WOULD take. It doesn't matter if you have the CEO ranting and shouting in front of you telling you how long you MUST take. The only people making that call will be the people actually doing the work. Whether it's by providing the estimate, and sticking to that, or taking whatever time is dictated, and delivering to the time they would have estimated anyway, the team actually doing the work determines the delivery date.
You'll need the entire team to chip in with estimates for their bit. Make CERTAIN the team is in "Estimation Mode" - in a planning session, or similar. When hearing about the concept for the first time, or sitting in a meeting with CLIENT is not the right time. If you're a lone dev, this whole story still applies. You need time away from everyone to think carefully about what needs to be done…
You'll need the entire team to chip in with estimates for their bit. Make CERTAIN the team is in "Estimation Mode" - in a planning session, or similar. When hearing about the concept for the first time, or sitting in a meeting with CLIENT is not the right time. If you're a lone dev, this whole story still applies. You need time away from everyone to think carefully about what needs to be done…
5 Remind everyone that you're committing to nothing. Regularly.
Unless you're constantly reminding people that NOW is not the time in which you're committing, that THIS discussion is only about what MIGHT be possible, but you're not committing to anything, your statements on whether things are possible, or how achievable you THINK things are will be taken as absolute, iron-clad commitment by the CLIENT - who is under intense pressure to get things done.
6 When you DO commit, DELIVER
All of this "I'm committing to nothing now" talk will upset people, and things could get quite heated. You want to make people's problems smaller, not bigger. Introducing "uncertainty" into the situation by repeating the mantra "I commit to nothing" is not going to help calm things down. It is vital that, when you DO commit, you DELIVER. When you first get a request to do something, don't commit to doing it, but do commit to getting back with a first-pass estimate in some near timeframe. Within 24 real-time hours is preferable.
When you send the first pass, make sure to be clear about what you are and aren't committing to yet. Usually, you still need to run some spike solutions and do more research to get to a nice level of certainty. From the first pass, you should be able to give estimates for when you will have the scope planned to a level you're willing to commit to. And so it goes.
When you send the first pass, make sure to be clear about what you are and aren't committing to yet. Usually, you still need to run some spike solutions and do more research to get to a nice level of certainty. From the first pass, you should be able to give estimates for when you will have the scope planned to a level you're willing to commit to. And so it goes.
7 Conclusion
By being careful about the expectations you create, you increase certainty: building a reputation of dependability, one round of work at a time.
8 Glossary:
- CLIENT: the person who will ultimately say the work is done. In the Agile setting, the Product Owner.
