A significant task during the mobilisation phase of a programme involves the mobilising of a team - which is not nearly as fun as it sounds. Often, within larger organisations, many of the names destined for a programme will already be in the frame, maybe those who worked on a bid/assessment phase of the programme, or resources from other parts of the business. (This may be a blessing or a curse - depending on who those names are). However, if you are charged with mobilising the team from scratch then you need to start considering this real quick. It won't matter how good your pivot tables are for your end-of-month progress report, if you haven't got any people then there ain't gonna be no progress to report. (Yes, yes, double negatives, I know). So, even metrics spreadsheets must take a back seat if you haven't got a team.
Building the right team takes time. If you are planning to grow, say, a twenty-strong development team then you'll need to start thinking about this a good three months before full-tilt development is due to begin. If it’s due to being tomorrow, then your first job is to announce to senior management a three month slip. Good luck with that.
But remember, in your hast a very very important lesson: it is better to get the right person, four weeks hence, than the wrong one tomorrow, even on a programme of only fifty-two weeks. Hell, even on a programme of only twelve weeks! I would comfortably state that productivity variance between a good and a bad engineer can be, say fourfold - easily. And this might be the case in an average organisation. But, in fact, the extremes are so much worse they can't even be expressed as a ratio. I can quote multiple cases of engineers who exhibited negative productivity. That is, they absorbed more time in management and/or undoing their work, than they actually produced. So, do not take recruitment lightly, and do not fall into the trap of some senior management in counting one body as one body. Not all bodies are equal - as well we know from reading Cosmo.
I will not talk about recruitment or interview techniques - that is a black art all of its own. And I certainly won't pass comment on what makes a good software engineer. I know what's good for me! But I will single-out one class of engineer for special mention, because, well, they are special, and so often are overlooked as such. Test engineers. When it comes to building a solid well-rounded team, the lesson here is obvious (yet seemingly easy to ignore): Test engineers must be test engineers.
Possibly one of the closest things to an accepted axiom in the software world is that testing is essential. Moreover I would say that the considered implementation of robust testing principles is fundamental to the success of a programme (and so will be discussed later). As such, the testing function is just as important as the development function - if not moreso. But, here's the rub, very few engineers actually like (or want) to do it. For this reason, often weaker or junior engineers get put in testing roles. This is a mistake. Testing is a specialism. So, particularly for your test team lead, you need someone who understands testing, who 'gets' it, and - vitally - who likes doing it. This is the only way you will get value out of your test function. Passionate testers are a rare find. If your firm doesn't have anyone that fits this bill, recruit - hire an expensive contractor if you have to. It will pay. I promise.
Which brings me to my next topic. To contract ... or not to contract? That is the old chestnut of a debate I shall re-ignite shortly. Just as soon as I've dug my bunker...
But remember, in your hast a very very important lesson: it is better to get the right person, four weeks hence, than the wrong one tomorrow, even on a programme of only fifty-two weeks. Hell, even on a programme of only twelve weeks! I would comfortably state that productivity variance between a good and a bad engineer can be, say fourfold - easily. And this might be the case in an average organisation. But, in fact, the extremes are so much worse they can't even be expressed as a ratio. I can quote multiple cases of engineers who exhibited negative productivity. That is, they absorbed more time in management and/or undoing their work, than they actually produced. So, do not take recruitment lightly, and do not fall into the trap of some senior management in counting one body as one body. Not all bodies are equal - as well we know from reading Cosmo.
I will not talk about recruitment or interview techniques - that is a black art all of its own. And I certainly won't pass comment on what makes a good software engineer. I know what's good for me! But I will single-out one class of engineer for special mention, because, well, they are special, and so often are overlooked as such. Test engineers. When it comes to building a solid well-rounded team, the lesson here is obvious (yet seemingly easy to ignore): Test engineers must be test engineers.
Possibly one of the closest things to an accepted axiom in the software world is that testing is essential. Moreover I would say that the considered implementation of robust testing principles is fundamental to the success of a programme (and so will be discussed later). As such, the testing function is just as important as the development function - if not moreso. But, here's the rub, very few engineers actually like (or want) to do it. For this reason, often weaker or junior engineers get put in testing roles. This is a mistake. Testing is a specialism. So, particularly for your test team lead, you need someone who understands testing, who 'gets' it, and - vitally - who likes doing it. This is the only way you will get value out of your test function. Passionate testers are a rare find. If your firm doesn't have anyone that fits this bill, recruit - hire an expensive contractor if you have to. It will pay. I promise.
Which brings me to my next topic. To contract ... or not to contract? That is the old chestnut of a debate I shall re-ignite shortly. Just as soon as I've dug my bunker...
No comments:
Post a Comment