Tips for a successful team lead
| | A few days ago I gave a talk in front of a crowd at Intel Israel. It was actually three talks, and the first was about project management and Team System. I specifically took that talk into a bit of a different direction, and besides showing off VSTS, I also gave some tips for being a successful team and project lead. Here’s a partial list of those tips. Some of them can be seen in various “Agile” methodologies, but taken as simply tips, they can improve the quality of your project-life without needing to work with any specific methodology. Heck, just call it “Osherothology” It may sound crazy, but making sure that your team does not overwork itself is one of the simplest things you can do. As a rule people should not have to work over 8-9 hours per day, even if they want to. There are peaks where I find that people do allow themselves to do this, but you have to make sure it’s not the rule, but the exception. Otherwise you’ll find people starting to “burn” themselves, coming to work late, less productive, and taking long vacations. Eventually, you’ll lose them. One of the keys to a successful project which can keep up with changing realities is the ability to automate almost everything. Have an automated build cycle at least once a day, if not several times per day. Automate deployment to test and staging machines. Automate testing using unit tests and other types of tests, automate code generation for part of the project that could use it. Automation saves you precious time, while making sure you don’t miss any tedious steps in the process. That way you can try out things, see what happens, and revert back if you find a problem. |
Get info from your team on what’s going on right now. A daily meeting of 5-10 minutes where you ask three questions: “What did you do yesterday, what will you do today, and what problems do you have?” each person on your team answers these.
Weekly meetings are less helpful because as a team lead you might miss out on a problem you could have solved 4 days ago.
Daily meetings also free the team from unneeded meetings about status.
Try to have some kind of demo to your client or client representative (could be the product manager). As simple as a command line or a UI that shows features you managed to finish by now. Get feedback about the direction you’re heading in. You’ll find that you made a mistake, but instead of waiting 6 months to find out about it, you only lost a month.
If you can manage getting the customer to run acceptance tests on your product, you’re in luck. When they all pass, it means you’re done!
Without some form of automated testing, you can’t check if you broke an existing feature in your work on other features(called a ‘regression’). Have as much as you can of these and run them during your automated build.
- Don’t compromise on the best tools
The difference between a team working with the right tools to do their work and one that doesn’t even know that the “right” tools exist can be as big as the difference between using Notepad to program instead of Visual Studio. Huge.
It can be as simple as buying bigger screens for your team to work in (I once worked at a place that to this day still has some 15” monitors for developers)
As a lead, it’s your job to stay ahead of the game and find out about new tools and addons that can help make your team more productive. Checkout SharpToolbox for a list of tools in many categories.
I can’t stress enough the importance of this. Have at least a weekly code review with each person in your team (or have other people in your team do it). The quality of the code can go miles up , and you can find hidden bugs and non-standard usage of libraries in your code. Most importantly, you’re letting your developers know that you care about what they write, and you’re passionate about teaching them how to do it better.
- Test Reviews are even better than code reviews
If your developers are writing unit tests, do a “test review” on a weekly or even a daily basis. The thing about reading people’s tests is that it takes considerably less time to go over it and understand it (about 10th of the time it takes to review the actual method being tested). Reviewing people’s tests lets you:
- understand what feature they were trying to write
- make sure the tests are high quality and readable
- allow you to find logical errors in the method under tests due to the declarative nature of unit tests (A test that makes sure a method throws an exception given some value may tell you that the developer did not understand that you meant that method never to throw an exception)
And I don’t mean a cork board (they have a nasty habit of being filled up with pictures and non related papers that never get thrown away for years). A whiteboard is a way to have a visual conversation in an ad-hoc manner. To do quick design sessions, or even to have your daily meeting in front of, checking boxes and showing overall progress on this week’s or iteration’s tasks. It’s an “information Radiator”, that radiates information to whoever’s in the room.
Got any tips of your own? I’d love to hear them!