In http://ryan-white.blogspot.co.za/2015/10/three-rules-for-sustainable-and.html, I wrote about 3 rules, the second being TRACK EVERYTHING. 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.
1 time, Time, TIME
I can't say enough about time tracking. It's vital for your ability to deliver consistently to be good at estimating, so when you're asked to DELIVER, you can :)
OUTLINE & ESTIMATE: Break down the project into finer and finer pieces, until you have items with a MAX of 4 hours estimated effort. It's always about time. I know, I know, Story Points are about complexity. But, inevitably, you end up talking about Velocity - which is really about points per Sprint, which is a time-box. Your estimates are best "Naive". How long it'd take you to do this bit of work, if you were working on just this task, and weren't experiencing interruptions. Time to execute, not actual time for this to be done. So it excludes time spent waiting for other people to check/code reviews/budget approvals or whatever. If you KNOW you're going to need a code review, that's a separate task, with its own estimate.
TRACK ACTUAL: The point? - you're trying to see how accurate you are when estimating. Track your actual time taken, and at the end of the week/sprint/project/whatever, have a look at your estimated vs actual times. Learn from this, see if you can figure out ways to bring the two figures closer together. It also doesn't hurt to be able to say (and back it up with figures) that you track every minute of your day.
OUTLINE & ESTIMATE: Break down the project into finer and finer pieces, until you have items with a MAX of 4 hours estimated effort. It's always about time. I know, I know, Story Points are about complexity. But, inevitably, you end up talking about Velocity - which is really about points per Sprint, which is a time-box. Your estimates are best "Naive". How long it'd take you to do this bit of work, if you were working on just this task, and weren't experiencing interruptions. Time to execute, not actual time for this to be done. So it excludes time spent waiting for other people to check/code reviews/budget approvals or whatever. If you KNOW you're going to need a code review, that's a separate task, with its own estimate.
TRACK ACTUAL: The point? - you're trying to see how accurate you are when estimating. Track your actual time taken, and at the end of the week/sprint/project/whatever, have a look at your estimated vs actual times. Learn from this, see if you can figure out ways to bring the two figures closer together. It also doesn't hurt to be able to say (and back it up with figures) that you track every minute of your day.
2 Master the tracking systems you're given
Most companies have some sort of timesheet system they subject the workforce to. Understand that this isn't going away. It is to your ADVANTAGE to become a pro at it. I use Emacs org-mode, and then funnel data from THAT into whatever system HR is running. The reason? usually, the HR system can't help with planning or estimating. With org-mode, I can outline, estimate, track and report, all from one system, at a much richer level than any other system I've encountered. And I'm in full control of the original data, so it won't get lost or mangled. And I'm able to process and query it for interesting insights.
3 Track conversations with writing
After any meeting, deskside chat or watercooler session in which a decision or agreement is made, back it up with a mail. Or other written medium - as long as you can go back to it later. You can check on it and remind yourself what to do (so not wasting anyone's time) - and in the event of disagreements/arguments, you'll have something to refer to. It sounds stupid, assuming everything could turn into a persecution session, but remember: TECHNICALLY CORRECT IS THE BEST CORRECT.
Make default choices/assumptions. And share the choices in writing. This helps move things forward faster, and you're minimising the risk of people having nasty surprises by letting them know beforehand what you'll be doing. Of course, only do this when you have run out of other options, such as reading the briefs, chatting/mailing/texting whomever you need advice from etc.
Need an answer, decision or output from someone? Feel free to do so in person, over the phone, or in the hallway. But make sure you back this up with a mail or other long-term written record.
Make default choices/assumptions. And share the choices in writing. This helps move things forward faster, and you're minimising the risk of people having nasty surprises by letting them know beforehand what you'll be doing. Of course, only do this when you have run out of other options, such as reading the briefs, chatting/mailing/texting whomever you need advice from etc.
Need an answer, decision or output from someone? Feel free to do so in person, over the phone, or in the hallway. But make sure you back this up with a mail or other long-term written record.
4 Use Analytics
TRACK EVERYTHING applies to your apps/websites too. It's vital for you to know and understand what's going on inside them. Whether you use New Relic or Google Analytics, make sure you're able to see what's happening in your app/site. Mostly, you're instrumenting for the reasons you CAN'T think of. A bug will emerge, and you'll want historical data. Your site will get hit with a ton of traffic, and you'll want to see if there were patterns to people's behaviour. That sort of thing. Often, analysis is done, and people say "wouldn't it be nice if we had xxx data or yyy detail?". Do your level best to make it so this is never said of the work you do.
5 Track your progress with notes/documentation
Coding is difficult enough. Remembering state for the myriad projects you're on is crazy. Do yourself a favour, make notes, and have a 5 minute break. It doesn't matter whether you make the notes in the source code, some text buffer or post-its - the important thing is to do it.
6 Rather over communicate than under
Keeping CLIENT calm whilst you're solving their problems is half the battle. Remember: they aren't telepathically plumbed in to what you're seeing, and the progress you're making. So it's vital that you give regular updates. How regular depends on the client and what you've agreed upon as well as how urgent the job/task is. Even if you have nothing to say, other than "I'm still investigating" - let people know you're working on their stuff. Don't lie. If you're only going to get to their stuff later, that's OK, just let them know.
7 Bonus: WHY to track all the things
Simple, really. When you've made an audit trail of what you're doing, you don't have to remember trivial details, like when you started and stopped a task, and what you were doing last Tuesday. If you're a contractor, you're already focused on this, either because you're billing by the hour, or have committed to a fixed-cost project, which is based on estimated hours… If you're permanent, remember: you've signed an agreement for x many of your hours per day. It is optimal to work that number of hours per day. Any more, and you're being exploited. Any less, and you're stealing ;)
No comments:
Post a Comment