There are a number of techniques, primarily from the Agile space, that are great for getting the best work out of yourself, and your team. They keep you focused on real problems (not anticipated or imagined ones) and focus on high levels of communication across the company.
The best way to keep people on target is to provide them feedback as often as possible. The sooner you can provide feedback, the more likely the behavior is to change. I don't wait until Christmas to correct my daughters when I see them drawing on the wall. I stop them immediately and we 'discuss' the reasons they shouldn't write on the walls. Usually this an effective feedback loop.
But we expect developers to write code that no-one looks at for weeks or months, then learn and grow from the "feedback" they get from testing or QA groups. History tells us that's a pretty inefficient way to improve. People don't remember what they were doing a week ago, much less four months. We've got to provide feedback in a more timely manner.
Use continuous integration and automated tests to exercise the code and provide feedback very quickly. If a developer writes code that breaks functionality, they can find the problem while the code is still fresh in their minds. If you cover the code you write with tests, who else on the team can break your code and not get caught? (More on your code in a future post.)
What about peer code reviews? We work differently if we know someone's going to be looking at our work. It's human nature. So let's ensure that one other person will read your code. Ideally someone who can pick on us about the hacked, junky code we write when we've got deadlines. This also lets us explain our code to another person, so that when/if we leave the team, someone else knows what our intention was. This is amazingly useful.
Tight feedback isn't just for developers though. XP advocates talking to the customer every day. Scrum wants the customer helping to evaluate the backlog frequently. And for good reason. We often build what we think the customer wants. But what if we showed the customer our "To Do" list and let them tell us what they wanted? Think of all the features you added to the last release... how many of them are used? Usability studies show that 90% of features are never touched. If you could eliminate 90% of the next release's features, and still have happy customers, what would that do for your development budget?
Why optimize now? With a global economic downturn it's more important than ever to be sure you're the best team around. If you can turn out better, more targeted product faster than anyone else, who keeps their jobs? Hopefully you will.
The truth is most teams are always behind schedule and over budget. Use these tight times as an excuse to try out some optimization techniques. Tighten the feedback loop for the developers and the customers.
We'll be discussing these ideas, and a few more, at a local meeting tomorrow night. NFJS One, my employer, is providing pizza and drinks, and I'll be discussing "Software Team Tuneups: Using Agile to Optimize Your Team. The meeting link is on Meetup.com. Come out and join us at Frankie's Fun Park of Raleigh. We'll be in the conference rooms in the back of the restaurant.
And if you like the Agile ideas, bring your manager along. Let's get them on board too!
See you there.