In http://ryan-white.blogspot.co.za/2015/10/three-rules-for-sustainable-and.html, I wrote about 3 rules, the first being DELIVER. In this post, I'm sharing a bit about actual ways to make this 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.
Some useful tips for delivering
1 What's the actual problem here?
Often, you're told to do X to fix Y problem. Spend a couple of minutes figuring out if Y is really a problem, and if there isn't some better/easier way than X to fix it. I've saved countless hours with this.
2 What can be done RIGHT NOW, and then what is the correct solution?
There's always a problem with time. Figure out the absolute bare minimum that needs to be done RIGHT NOW to solve the problem. Then think about how to solve correctly. You might only have time to figure out the RIGHT NOW solution, but you'll be aware that it's going to need attention later on.
3 Naive estimate first, THEN optimise.
Don't waste mental cycles and time trying to shoe-horn everything into an elegant, efficient model or schedule from the start. Treat each part as if you were doing only that part. As the scope becomes more concrete, you can optimise for re-use, common functionality etc.
4 Figure out what needs to be done first
Sounds obvious, but your predisposition for linear thought is acting against you here. You need to weigh Urgency vs Importance vs Difficulty vs "Force Multiplication" vs "Internal Setup Time". Using these, you'll end up with a sometimes non-obvious order of execution that is better.
5 Sub 4 hour resolution
Aim to have no task estimated at longer than 4 hours to complete. This seems like overkill, but trust me - paying this much attention when estimating means you're much less likely to overlook things. And you end up with a plan that can tell you, within half a day, whether you're ahead or behind schedule.
6 Spike solutions
For things that are unknown, or difficult, use a spike solution. Zoom in on the specific technical problem you're trying to solve, figure out the smallest possible thing you have to do to solve the problem, and solve just that problem. The point is not to solve the larger problem: it's to help you understand unknowns, so you can better plan your way forward.
7 Solve end-to-end, then polish.
An inefficient, badly written complete solution is better than the most elegantly written incomplete solution. Get something working that solves the problem as quickly as possible, then focus on parts that need refactoring or rework. Unless you're building an Air Traffic Control System. Then get it right the first time.
8 Notes, for start-stop work
Do yourself a favour: keep yourself well informed. Never assume you're going to remember everything. Write notes down (either as comments in the code, or separately) as you go.
9 Work in bursts
I typically never work for more than 50 minutes without taking a break. Often, taking a break is just getting a cup of coffee, going to the loo, or reading an article for 10 minutes. Work hard, and reward yourself with little breaks. Most of the time, better approaches or insights happen when I'm NOT at my desk, thrashing out code…
10 Remove distractions
Plan for "available time" and "unavailable time". Disable notifications as much as possible. Check your mail once every hour or two only, and schedule actions from the mails, rather than trying to deal with them on the spot. Work from home. Find an isolated spot at the office somewhere.
11 Multiply force
Have sections of work that others are waiting for you to do, before they can move on? Kill those ASAP. Try never to have people waiting for you.
12 AUTOMATE
macros/scripts/applications/other people - "Anything worth doing twice is worth automating" is maybe taking it a bit far, but repetitive tasks are best done by machine or multiple other people - you're just being a bottleneck otherwise.
13 Glossary
- Spike solution: notes here: http://www.extremeprogramming.org/rules/spike.html
- Urgency: Anything that must be done NOW - that's holding up other people, or preventing people from using your software correctly, or closing a lead/sale is Urgent.
- Important: Anything that will have a big impact on your business/unit/app/site in future. Often expressed as "let's worry about that later" by the suits, until it becomes Urgent.
- Difficult: Anything that you can't get your head around in an hour or so. When you answer a question of whether something can be done, and you initially say "no" - it's likely difficult.
- Force Multiplier: https://en.wikipedia.org/wiki/Force_multiplication explains well, but basically, if you can build a tool, app or process that allows many other people to do work on your behalf, or get it done automatically, that's a force multiplier.
- Internal Setup Time: "Internal setup activities are those that require the process to be at a standstill before you can conduct them safely while external activities can be done while the process is still running." (check out http://setupreductiononline.com/ for the full story). Yes - the roots are in the changeover of press dies, but there are many parallels and lessons to be learned for software engineering. If you can find a way to reduce internal setup time, the process of making something new or fixing/repairing happens much faster.
