Keyboard Aliens

I’m not quite sure who reads this blog but I can guess the rough mixture of job roles would be project managers, coaches, business analysts, managers of various flavours, developers and lastly anyone who happens to follow me on Twitter. My experiences lately have allowed me to learn a lot around how teams interact with each other in various stages of a project.

Projects are evil; generally.

For the most part in a project the idea seemed like a good one but similar to painting a room (for me anyway), halfway through you want to pack it all in and pay someone external to finish it off for you. The end of a project also brings out the best and the worst in a team. It’s human nature for pressure to effect people differently and it takes someone with a very cool head to be able to steer a ship that everyone wants to jump from.

You need to work, day to day, with the assumption that everyone is trying their very best. If you can’t get your head around that, you probably won’t be able to get around anything else I’m about to note down.

I’ve either worked as, or alongside developers for about 10 years. I reckon I know a thing or two about how they work because in most cases; I work the same way. It’s also not hard to go to Google and find out about how to deal with software engineers/developers.

My recent experiences have allowed me to see how various colleagues within business’ and teams discuss developers or talk to them directly; like they are aliens with a keyboard and headphones.

Developers Run the Zoo

Developers in your company are in control of the software. That is easily the most important sentence of this entire post.

No matter what position you hold within a company, whether it be a Senior Manager, PM, BA, Head of Development or any sort of professional with direct reports in an organisation; you are not in any way shape or form in control of the software your company produces. The only people who can own and totally control the product are the people who day in day out spend countless hours and keystrokes building the product itself.

Now that you have digested that little gem, how can you help these colleagues deliver the best software possible?

Learn how to write user stories

Requirements do not need to be indepth or a dummies guide to the feature you would like built. Firstly you are wasting your own time by producing reams and reams of screenshots, notes, table structures and validations. A 5 minute discussion around a story could save weeks of pain down the road;

A user story is not a specification, but an communication and collaboration tool. Stories should never be handed off to the development team. They should rather be part of a conversation: The product owner and the team should discuss the stories, or even better, write them together. This leverages the creativity and the knowledge of the team and usually results in better user stories.

Read more http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/ Suddenly your workload becomes less because you get input from the people writing the feature around what the feature does? As we know Shared Documents are not Shared Understanding.

Estimates

Remember the “everyone is trying their best” motto yes? If an estimate is wrong; don’t give a developer a hard time over it. What use is complaining something is three hours late? There always seems to be a tendency to overreact when estimates are compiled and a big magic number is presented.

Of course if you ask for 30 features on a complex AngularJS application it might so happen that it comes to 30-40 days. There is actually something you can do about that you know? (Further down)

ESTIMATE: an approximate calculation or judgement of the value, number, quantity, or extent of something. Just remember the last time you were “late” with the delivery of a task and ask yourself why it happened… funnily enough developers get interrupted too.

Be A Good Product Owner

I honestly don’t need to say anything other than watch this… and then watch it again.

Headphones are a Sign

Speak to your team and get them to agree to the following;

I shall only wear headphones when I do not want to be disturbed I shall not however, wear them all day, as that’s called being ignorant I shall not tap on the shoulder/ stand at the desk of / or harass anyone in my team who is wearing headphones unless the building is on fire or they are casually browsing Twitter when I walk by Simple. Slack/HipChat go a long way to help this too.

Make Feedback Loops as Short as Possible

If you have the ability to do this or you are the one giving feedback; this will help your project more than a lot of other project management methods will. Spotting a misguided developer early is just as good as not putting them on the path at all. Quick and regular feedback sessions or demoes mean these kind of problems can be nipped in the bud.

Let Them Work From Home

Ever worked from home and marvelled at the amount of crap you have done? Funnily enough this works for developers too. That goes for flexible working hours too; development isn’t something that generally switches off in the brain as soon as it turns five o’clock. Do everything you can to allow your developers to work from anywhere at any time and you will see a spike in quality and productivity.

Blame

It’s a natural instinct. Pressure is on and something has gone wrong or a milestone is late. Time to throw someone under the bus? Yuuup. It’s ugly, lazy, obvious and very easy to spot when someone is deflecting blame onto someone else. Ask yourself why are they late? Are they being blocked? Have I asked if I can help with something?

Or maybe you are speaking to them when their headphones are on…

Shortcuts

Strong developers will not do this first of all, but nobody in a position of power should force a short cut be made when they don’t understand the technical debt which it leaves behind. If your team is genuinely wary of doing something; listen to them. It’s better to be late a day with a release than release something which brings the business to its knees along with its reputation.

At the end of the day, would you commission a team of engineers to build you a house and then do everything in your power to make them generally dislike you or think you are incompetent at your job? Of course you wouldn’t, that would be an enormous waste and a huge risk to any project.

So if you wouldn’t do it to someone with a yellow hard hat… why do it to someone with Bose headphones on?