How to make good teams great, part two
This is the second part of How to make good teams great. First part is over there.
Feed your brain
In a rapidly changing environment - as the IT world is - you want to stay on top of things and you can’t only rely on techniques, languages, frameworks & technologies you played around with at school or in your current projects.
You must feed your brain with new ideas, new cool stuff (even old cool stuff by the way) and there are various places you can get brain food: conferences (if you or your company can afford it), bar camps & user groups (often free), brown bag sessions over lunch at the office, …
Say “well done”
Give your co-workers credit for a well done job. It does not necessarily need to be for big accomplishments only and you should also communicate on smaller achievements. Kudos can be given via an email sent to the Kudos mailing list or can take the form of a small present you know will be appreciated (a chocolate bar for instance).
Keep in mind that not everyone likes to be a star (even for a minute) and it is important that one gets kudos only if she/he wants.
In my team we use one of those EASY buttons (that says “that was easy” when you press it) to tell the floor someone has achieved something (small or big). It is not exactly the same as saying “well done” but still is a nice way of showing some pride.
Eat your own dog food
As a developer you should already be familiar with the quick feedback that a suite of unit tests provides but that is still pretty “low level”. Feedback is important but quick feedback is even more important since it helps you catch bugs early and fix them early (at a lower cost).
So what about testing the software as a whole? What about using it yourself? Eating your own dog food is all about using the software you develop instead of simply developing, shipping the product to the testers and waiting for feedback. By doing so you also see your software with your end users’ eyes (may it be a tester - internal - or a customer - external) and have a better understanding of their needs.
Experimentation time - motivation through innovation
By giving the developers the opportunity - read time - to explore and implement new ideas a company is making an investment that may or may not pay back. But a lot of products were born during experimentation time (FedEx days at Atlassian, Google Fridays, …) and if a company can afford to set a couple of hours aside for their employees to think out of the box it should go for it.
Do what you want time
The do what you want time differs from experimentation time in the sense that it is more about assigning some time (like 20%) for the developers to improve or implement a feature not yet in the backlog in an existing project.
You can find the slides from Sven’s presentation at Jfokus here.