Development Team Leadership : First Steps Part 7

Honesty

Honesty is the best policy…

…unequivocally.  Trying to cover something up simply doesn’t work.  Everyone makes mistakes, even your boss, and if they’re worth working for, they’ll know that.

As the lead you should be the first to admit when you:

• are not going to make a deadline;
• did something silly that broke the build;
• are wrong;
• simply don’t know the answer to a question.

The last one is really important.

Don’t be afraid to say “I don’t know”, just follow it with, “but I can find out” or “let me get back to you”.  False information can be harmful on a number of fronts, materialistically it could cause incorrect decisions to be made on the back of what you’ve said, the repercussions of which would be a loss in confidence in your abilities in the long term.

In being honest and upfront with your colleagues you’ll build trust within your team, giving them confidence that if they make a mistake, firstly your toys won’t come out the pram, and they probably won’t get sacked.  Job security and fear are most likely the main culprits as to why attempts are made to cover up mistakes, negate this by leading by example.

Blame Culture

As above, mistakes happen, and when they do, as a Lead Dev starting a Witch Hunt is about the least helpful thing you can do.

Everyone creates bugs from time to time, it’s a fact, no amount of unit testing, regression testing, automated system testing or code reviews will prevent this.  Working in an Agile environment is also about accepting this and, barring a complete show-stopper, any issues should be dealt with in the context of a Sprint in accordance with a priority assigned by the Product Owner.

When an issue arises, I will generally:

1. Look at the issue;
2. Check the Version Control history and see what was changed and who by;
3. Understand the problem and assign it appropriately.

It’s important to note that the who is not important from a resolution perspective here, it is however important to give advice on avoiding the same issues in future.  Shared Code Ownership is one of the basic premises of the Extreme Programming movement, your team owns the code and resolving issues should not be limited to the developer who introduced it.

As the Dev Lead you will likely be accountable for the code base as a whole and the direction it travels in, shirking this and pointing the finger will earn you no favours from your team and almost certainly won’t get a positive reaction.

Best-laid plans

The best-laid schemes o’ mice an’ men gang aft a-gley.

…or in English…

The best-laid plans of mice and men often go astray.

I read the book Of Mice and Men at school and this quote, from a Robert Burns poem as the title, stuck with me.

Your plans may not always come to fruition and in these times it’s important that you’re prepared for these eventualities.  I try to build a map in my head of my, and the team’s dependencies and try to understand the likelihood of what you are anticipating happening.

It may sound obvious and cliché, but it often helps to plan your Software and Architecture for your requirements going on a tangent in the future.  Being Pragmatic, and picking the right slice through your application will certainly mitigate some of the risk of things going wrong.

Unanticipated things happen, your client gets bought out, key staff members leave, heaven forbid your internet goes down, these scenarios are far from the edge of possibility, it’s at these times your leadership and judgement will be tested.  If you have a Plan B or a practised ability to formulate one, you can minimise your impact and keep yourself and your team productive.