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.