If I give you my boss's phone number can you call him and share this with him?? ;-)
In Australia, it's a 37.5hr work week.
So when I originally saw 40hrs, I thought you meant for people to work overtime :-).
Chris
I moved to this new team (I can say I was invited :)) where it was a total Chaos, people worked 50+ hrs and that was the first thing I got fixed; when people were little relaxed after the break I started introducing rest of the stuff (things listed above by Roy) and believe me it worked like a charm
I truly believe in Agile/Scrum & have been practicing it for past 4 years & I have proven success in multiple projects
Agile Rocks :)
Thanks
Prasanna
Really interesting, down to earth tips. I try to apply them all, even before read this post, not it's not easy. Way too many people don't follow these simple rules.
37.5 hours work week?!
Chris, are they looking for more developers down there? :)
I think the Demo is also great to create a constraint for the team. Everyone focuses more on the things that need to go into the demo, rather on other development.
Everything you mentioned is perfectly fine and I have experienced it. Using exactly these techniques, we were able to complete our projects On-time & On-budget everytime.
But I would like to mention about Issue Tracking System. I really feel it plays very important role in complete delivery of projects like automated builds & releases, Daily meetings, automated testing, acceptance tests, Customer Demos etc.
By using Issue Tracking System, right from starting, every Team Member can log small small issues whenever it comes into notice during project development stages, these issues can be assigned to right persons and will remain open untill fixed or resolved, this will ensure proper tracking and closure of issues which many times go unnoticed and comes in the form of surprises during final stages of the project.
This will also help the Team Lead to evaluate quality of work done by developers.
Re: code reviews. I've heard about them but i'm not sure how it would be run so as to be useful and not just people staring at a projector. the idea of including the tests to show the interfaces/business logic steps is good.
Don:
We do code reviews like in pairs. We review live code (fresh in the developer's mind). After selecting the code to review, the writer walks through the code verbally, and the pair tries go through a short list of items to see it's ok - find bugs, performance or memory issues, readability, etc. The sessions are not long, and focused. Affectivity of founding bugs is high. I would do more, but at least we have this.
Roy,
Very concise and to the point! But I have yet to see the company where all these principles are sufficient to qualify for a team lead :(
"In Australia, it's a 37.5hr work week."
Since when? I've always worked 40 hrs as standard!
Great set of tips, which I agree with 100%
Nice one Roy.
I want to add:
Develop and establish the coding standards and naming convention. Make sure your team follows.
Nice idea to collect a "best practice" for team leads.
We practice most of the above, not code reviews though. We have two weekly interations where at the end of the iteration the lead engineer will do acceptance on the work completed over the iteration. This may include test/code review, design dicussions etc.