Handover like a pro

 

Recently I started to read a book, the one that Christian was praising so many times. I’m just through the first few chapters but already one of the sentences sounds in my head all the time. John Seddon, in “Freedom from Command and Control” writes how there was an improvement made to a process in one of the call centres. He said that “all the information was filed in the form so it was never coming back from the downstream person with the request for missing information”. This one off step was making improvement as it was never coming back.

John explained that it was possible to realise the impact once someone took a step back a took a look at the system and the flow through it as a whole.

 

This made me think about something that my other colleague, Pat did at work. When he was rolling off the project, he WIKIed all the information about it and left the Spike (proof of concept) code in the repository. He also made some comments in a code, whenever it was not entirely clear of its intention. It was one of the best handovers with no direct contact I was ever involved in.

I realised that the handovers should be looked at from a different perspective.

Typical approach is to … drop whatever at someone and let him finish the work. Whenever more information is necessary, it could be chased.

Instead, I should prepare handover in a way that would make it possible for a person who will pick up the work after, to have a brief look (at the code in my case), realise where the info is (wiki, tests, some comments) and move on with the flow.

Funny enough it encourages some good coding and work practices, like:

• simplicity
• clean and understandable code
• less time context switching and interruptions (own and others)
• tests that ensures functionality and quality
• lack of outdated and non-maintainable documents

Handovers are a problem and should be avoided when possible. When programming is involved, Pairing reduces the danger of the need for them. If not, all the members should concentrate on the most important thing, make sure the work keeps flowing through the system and what could I do to make it happen.

Cheers, Greg