Development Team Leadership : First Steps Part 10

Don’t take requirements on Face Value

Often your requirements can overstep outlining the business need and into murky waters of business users defining technical solutions; which are rarely the way we would choose to do it, or in some cases even technically feasible.

“Has the world gone mad; or is it me?” – Ben Howard

As professionals it’s our obligation to probe these requirements until we’re left with something that makes sense that all parties are happy with.  It’s always worth asking why, sometimes a requirement can disappear altogether as a result.

This isn’t doing yourself out of work, it’s enabling you to do the “right” work, this is mutually beneficial; we’re paid not only to write software but to provide a service, probing will prove your understanding of the business and ultimately build trust.

Bigger Picture

Make sure you understand how the component you are writing fits in with the architecture as a whole.  As the Development Lead you’ll be expected to be capable of participating in conversation with all areas of your team and all levels of the business, from those with a vested interest in a particular piece of functionality, all the way up to those who aren’t interested in the minutiae, just the fact that the system works.

If you don’t understand how your software fits in with the wider Organisation you won’t be able to fulfil this.  Again, if you can prove your understanding you’ll gain trust, but it’ll also enable you to more conclusively understand requirements if you understand for example what impact your validation (or lack of!) may have on downstream systems.

Are we there yet?

You’ll inevitably be asked (“probably” by Project Managers, and “probably” numerous times) whether you’ve finished a Task, it’s nice to have an answer to hand about not only your own work, but that of the team.  Having a visible board to track progress on is really part of the Agile process, having one of these can ease the pressure, (but that doesn’t mean you won’t be asked!).

Not only is it good to have an answer to questions, but if you have an idea of whether your team is likely to finish all of the tasks on your current sprint then it will allow you to raise the alarm early, or re-prioritise workload within the team.

 

Development Team Leadership : First Steps Part 9

Identify Bottlenecks

It’s important to be able to take a top down view of your team and it’s bottlenecks, internal and external.

bottleneck.jpg
Bottle Neck

External

For example, the inputs to your sprints “should” be nailed down when planning, you might need:

  • a data model definition;
  • web service schema;
  • validation use cases;

…the list goes on.

If they consistently aren’t appearing on time, this is a bottleneck hampering your productivity.  It’s important to raise the alarm. Continue reading “Development Team Leadership : First Steps Part 9”

Development Team Leadership : First Steps Part 8

Constructive Criticism

Something I’ve seen many people struggle with is the ability to take constructive criticism, and inversely offer it.

Giving Constructive Criticism

I’ve previously recommended being free with advice.  An extension to this, and a vital leadership skill is the ability to critique a colleague’s work without causing offence.  Obviously being rude about someone’s work will alienate them and earn you no favours, but it’s often the case that a colleague won’t quite have understood the direction in which you wanted them to head with a certain task.  There’s a couple of things personally you can take from this : Continue reading “Development Team Leadership : First Steps Part 8”

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.

Continue reading “Development Team Leadership : First Steps Part 7”

Development Team Leadership : First Steps Part 6

Pragmatism – Take your time

I’m sure you’ll have heard the saying :

Rome wasn’t built in a day…

…and it’s fair to say that 99% of the time, neither will your app be.  Be realistic regarding what you can achieve and by when.  Everything about the Agile methodology points to being able to work sustainably, and getting better at doing so along the way.  There’s many articles about picking a vertical stripe or horizontal stripes through your architecture and delivering a concise set of functionality.  My advice would be, don’t let your chosen stripe get too fat.  If you can’t hit an imposed deadline, be honest and say ‘no’.

Continue reading “Development Team Leadership : First Steps Part 6”

Development Team Leadership : First Steps Part 5

Saying No

One of the most important skills in leadership, is knowing how and when to say ‘no’.  It might sound trivial but it’s really far from it.  There’s an excellent chapter in The Clean Coder by Uncle Bob Martin.  I was fortunate enough to read this prior to having been put in a situation where I needed to say no and I found it  invaluable in hindsight, would highly recommend.

As a fresh Lead you will no doubt have a number of challenges in managing client expectations, and at points they will inevitably ask too much of both you and your team.  It’s times like these when you will gain the respect of the client for your honesty and integrity and the gratitude of your team for not putting them in awkward situations.

It’s easy to say yes, don’t fall into that trap, but just remember there’s a right way to do it. Continue reading “Development Team Leadership : First Steps Part 5”

Development Team Leadership : First Steps Part 4

Push Yourself

Don’t be afraid to tackle situations that will push you out of your comfort zone, you’ll always be better for it.  If you’re :

  • nervous about a presentation, do it;
  • putting off an awkward conversation, have it;
  • unfamiliar with a technology, learn it.

…you get the picture.

There are of course limits, be sensible.  Start small, Rome wasn’t built in a day and so on, but each time you tackle something new your horizon has expanded slightly, you’ll be unstoppable.  Have confidence.

Continue reading “Development Team Leadership : First Steps Part 4”