I'm Working, So I Must Be Being Effective - How You Can Adversely Affect The Team's Velocity

Did you ever get lost in a task? Spend an afternoon doing something you could've done in an hour if you had approached the problem differently? Finish a task only to realise you'd solved the wrong problem? Spend an hour banging your head against the desk, only for the person sitting next to you to get it resolved in 30 seconds flat? If only I'd known that... If only you'd asked, you mean...

If you're a developer, you've done all of these and more. And on more than one occasion.

So why did you bang your head against the desk for an hour, rather than ask for help? I think it's because you are perceiving yourself as a lone developer rather than as a cog in a machine that exists solely to get stuff done. Thinking like a lone developer leads to thoughts like:

• I should be able to work this out
• I am going to look stupid if I can't
• I am going to look like the biz when I get this task finished 
• This task is kicking my ass and there is NO WAY I am backing down

All this adds up to a very strong impulse to prevaricate, obfuscate, to refuse to ask for help... An impulse which is strongest when the going gets tough, which is precisely when you need to be asking for help. And the consequence of that impulse is that part of the team is suddenly not getting tasks done, and the rest of the team is often unaware that tasks are not getting done.

It's a difficult habit to break... But being aware of the some key indicators can help you to cut the prevarication out of your coding life.

Step 1 - Recognise When Your Productivity Is Dipping
Most people can do this already. Observe your own behaviour. You may have different patterns, so learn to recognise your signs, but some common ones are:

• You had the flow. You lost the flow.
• Getting hot and bothered
• Staring out of the window
• Sighing
• Hitting the Twitter
• Hoping that nobody asks you how you are getting on
• Trying lots of stuff in rapid succession, none of which works
• Being so scared of making a mistake that you won't commit to a solution
• Having a P, a 4 and a 5 floating around in your mind

Step 2 -  Accept That You Need Help
This is the tricky bit. I have spent days doing all of the above, because the alternative is to ask for help - I can't even type it. I don't know why it is so hard, but it is. But if you stop thinking "I should...", "I will..." and ask yourself the question "How is what I am currently doing helping the team to get tasks done?", you will invariably come up with the answer "It's not." And that will be enough to get you to ask for help.

And if you train yourself to recognise the signs above you will be able to trigger a cry for help more quickly. Which will impact immediately on the team's velocity.

That said, your ultimate aim is to become a fully self-sufficient, kick-ass coding legend who never has to ask for help 'cause those 1's and 0's dance as they trip out of your consciousness... So you probably don't want to get into the habit of crying for help the second your brain starts to grind a little - it's generally profitable to spend a bit of time thinking about a problem before asking your neighbour...

These techniques may help while you wait to ascend...

Step 3 - Techniques That Can Help

• Time Box Your Efforts
• Use GIVEN... WHEN... THEN... To Define Problems And To Break Them Down
• Compile A Document As You Are Developing
• Be Aware Of The Importance Of Feedback Loops And Keep Them Tight
• Now You Are Asking For Help, Do It Well
• Be Open About Your Strengths And Weaknesses

Step 4 - Have A Backup
There will be times when you have tried everything you can think of to move a task forward and you are still getting nowhere and the people you need to talk to are not going to be available for some time. The best thing you can do at this point is go and do something else useful instead. Rather than waste a chunk of this unexpected free time trying to work out what to do, have one or more projects on the back burner that you can get straight onto. If you adopted technique #Compile A Document As You Are Developing, you'll have an entry point that will get you back up and running with this project quickly.

Compile A Document As You Are Developing

Doing your Business Analysis? Make your notes in this document. It doesn't have to be pretty, treat it as a jotter.

Got your 'To Do' list sorted? Jot it down here until you have compiled your skeleton unit tests.

Something pops into your mind about a scenario you should consider? Jot it down quickly and stick with the flow of what you are doing.You can think about this new scenario later.

You've just discovered something that will be useful for the testers? Jot it down... You can transpose it to the Work Item later.

This document can give out a lot of things, all of which impact directly or indirectly on the team's velocity:

• It means you know where you are with a WI. If you have to break off and do something else for a few days, jot down an entry point that will help you quickly get back your brain back into the right space...
• It can help you maintain your flow even when your brain is throwing stuff at you that is not to do with the flow you are working on
• It can help you give more accurate estimates of how much is left to do on a WI
• It can improve the quality of the documentation you leave behind you, making subsequent stages flow more quickly. You will find stuff out about the domain as you write your code. You will consider different approaches and come down in favour of one - the one that ends up in your code. You will identify scenarios that are so unlikely to happen in the real world business flow that it is not worth the effort to add in code to cover those scenarios. You will find ways of setting up data that make it easier to test your new functionality.
  
  If you document all of this stuff concisely before you pass your Work Item on for peer-review, you will save the reviewer a lot of time. If they are a good reviewer, they will think about other possible ways of tackling the problem you have solved. If they can see that you have already considered those options, and the reasons you discounted them, it will save time.

Use GIVEN... WHEN... THEN... To Define Problems And To Break Them Down

The tightness of the structure will force you to think early on about the true nature of the problem and you will be surprised what you find out in advance of starting to code.

When You Ask For Help, Ask Well

Collate the relevant information before you ask for help. Whoever you ask will have questions. If you can anticipate what they will ask, and have the information ready, you will save time, and have an immediate impact on the team's velocity.

Be Aware Of The Importance Of Feedback Loops And Keep Them Tight

Test Driven Design is a great way of integrating feedback loops into your code. But what about in other areas of the process? Are you getting the same feedback?

For example, given that Business Analysis is an easy step in the process in which to get lost, get some feedback at the end of that process. Then if you have got anything wrong, it is likely to get picked up before you start coding. Sorting it out now will be a lot quicker than sorting it out once you've chipped out a load of code.

Be Open About Your Strengths And Weaknesses

You probably don't want people to know what you are not so hot at, but let's be honest, you've worked with the people in your team for long enough that they know your CSS is flakey... And do you know what? It's not even on their list of priorities, 'cause they are more worried about the fact that their JavaScript could be better...

But if everybody's strengths and weaknesses are an open thing in the team, it means the team can organise itself to play to its strengths - "Here's a WI that has a lot of CSS, it might be a good one for you to work on alongside X and you can learn some stuff..."

A well judged "How are you doing?" from a colleague has saved me a lot of time in the past. If people know you are working outside your comfort zone, they are much more likely to check in on you from time to time... And suddenly you are no longer working on your own, you are working as a team.

Time Box Your Efforts

You learn from struggling with a problem, but you only learn so much before you just become ineffective. So when you notice you are starting to struggle, set a timer going, give yourself half an hour, an hour, whatever, to get to grips with the problem and at the end of that time assess honestly how much closer you are to the end of the task...

If the answer is not much closer, you need to ask for some help.

If the answer is that you have come up with an angle, you probably still need to run it by someone because you already identified that you are out of your comfort zone - you wouldn't have started your timer otherwise. Getting confirmation that you are indeed on the right track now can save the team a lot of time in the long run... You may have come up with a complicated solution that somebody with more experience will want to streamline... Better that they do it now rather than in two days once you've implemented it.

Business Analysis is a good phase in the process to time box as it is easy to:

• Get lost in existing code
• Come to incorrect conclusions because of a lack of contextual / background knowledge