- Simon Waight
I was going to write a big post about this but every time I come to work on it I find I spend more time that I intend to capture what is actually a fairly easy to understand set of principles that I've been lucky enough to pickup during my time working on software delivery teams. So here they are:
Flexibility: a lot of people join teams expecting to play only one role. While specialists can probably expect this to be the case, the rest of us should really be prepared to play whatever role is required depending on circumstances. I've seen a lot of people who have been unprepared to show role flexibility where the result is that some aspect of the project delivery is negatively impacted. Software delivery is not all glamour – there's a lot of grinding leg work needs doing on any project in order for it to succeed.
Commitment: think about how many teams you've been on where you've had people who have contributed but ultimately their contribution is dwarfed by others on the team. What commitment boils down to is doing the things you say you will do by the time you said you will do them (or otherwise early and clearly communicating why they won't be done).
Respect: pretty much all the best working relationships I've had (and continue to have) are based on respect. If you approach all relationships you have with your team mates on this basis you will find that your team is far more successful than it could ever be otherwise. Yes, if you are having challenges with other team mates around "101" concepts it can be a bit hard to proffer respect for them, however you should try your hardest to make it work and to find elements that you can respect.
Communicate: be open and keep everyone across what you're doing. Be pro-active about communicating – don't wait for someone to ask you for information. The one proviso here is that you determine what is appropriate for others to be told. I lean more towards over-communication – people will soon let you know if they don't need to know the level of detail you are giving them.
Reliable: don't be random. Try to keep your behaviour the same as often as you can – people should come to expect you to behave in a certain way in a certain situation. Some of being reliable goes back to commitment: do the things you say you are going to do when you said you will do them. Delivery of any project is challenging enough without having team members going off-piste and doing ad-hoc work that was never on the cards. Ultimately if people don't find you reliable then you will struggle to be trusted and trust is certainly at the core of any great team.
Well I guess I could ramble about this topic ad nauseum and if you're reading this far then I salute you!