I recently left a company and had some time to reflect. I was a Development Team Lead, and though the job definitely has its perks I found that the role wasn't the best for me. That said, people said I was a good team lead, so at the request of my replacement I decided to draft a list of some day to day activities I performed. These are just suggestions, but I think they’re all excellent practices that all teams should try to adopt or have alternatives for. They're mostly centered around practices found in the Agile manifesto. There are many other Agile practices I could have adopted, but unfortunately I didn't receive the kind of buy-in necessary to achieve them. This post documents what practices I've actually employed while on the job.
This is your typical daily scrum. Scrums are part of most modern software development methodologies. It gives everyone on the team the opportunity to hear about what each is other is working on. It fosters collaboration & debate among the group.
I’ve scheduled scrums for 9:45 AM each morning because that works best with everyone’s schedule. Scrums should happen whether I’m around or not (pick an alternate “scrum master”). They should be time-boxed to 15 minutes and it’s important to keep people from delving into too much technical detail. The format of the scrum I use is the following.
- What did you do yesterday?
- What will you be doing today?
- Discuss any roadblocks or ask the group any generic questions about the work.
Case Pick up User
Another aspect of Agile development methodologies I’ve tried to adopt is a general case bucket that anyone on the team can poll and pick up a new case to work on. This gives the dev more freedom to pick what they may not have normally been assigned. It allows devs to pick up new skills and spread knowledge across the group.
I assign all types of tickets to this bucket, but it’s important to make certain everyone know the proper priority of cases to withdraw from it. Client support cases should be the highest priority. This is followed by current release milestones and then triage cases. I generally assign about 50-75% of all cases assigned to me by product management to this user. There are exceptions where I’ll assign a case directly to a developer (i.e., they had worked on the case previously or have a particular skill set required for the case). I will always review the case before assigning it to the pick up user. In some cases I’ll call a dev over for their opinion.
Mandatory Code Reviews
I try to get everyone on the team to perform code reviews before every commit. Sometimes it's hard to get devs to buy into it, but I think it's worth it. A colleague recommended that a good alternative to mandatory code reviews is peer programming, but I don't think it's realistic to assume every dev will be attached at the hip with someone for all their tasks. Code reviews don't have to take too much time.
It's worth mentioning that a couple of recent events have rekindled my passion for the code review.
- A post by MarkCC titled Things Everyone Should Do: Code Review
- The hiring process at Empathica (my new employer) in which the 2nd interview is essentially an on-the-job code review!
Here are some rough notes I compiled for my team as Here are some notes on my justification for code reviews for every commit.
I do code reviews for three reasons
- It will force the implementer to account for a chosen design
- It will allow for more than 1 member of the team to be aware of changes going into the project
- Drive remediation work and make the implementation or fix that much better (two brains are better than one)
How & what to review
- This should not be seen as a time to critique team members, but an opportunity to learn from one another, collaborate better as a team, and produce higher quality results
- If there's a disagreement on an implementation then include the rest of the team for discussion
- Reviewer should challenge what use cases have been tested
- Depending on the feature you may review with a different member of the team
- If you don't know who to review with then review with myself
Don't review with the same person every time, spread them out. This will maximize the dispersion of knowledge among the team.
Team case tracking
One of the most important functions of a responsible Team Lead is to know the progress of everyone's activities on the team. In an Agile shop, this is easy for everyone to see via the project planning board. In my last position we didn't employ these boards, but instead used case tracking software FogBugz (FB). FogBugz is the best case management software I've ever used. This should be no surprise as the Fog Creek Software CEO is none other than Joel Spolsky of the popular Joel on Software blog. I'll put a shameless plug below to entice you to learn more.
"FogBugz is the world's easiest bug tracking system, built for teams who are serious about shipping great software.
- cooperate with teammates
- meet deadlines
- maintain control of your projects
- integrate with source control
FogBugz incorporates the lessons Joel Spolsky and the team at Fog Creek have learned over a decade of learning how to write software better."
I track cases in my team through a few different filters, but in order to see what everyone on my team is actively working on in one list, this is a screen cap of the generic filter I use in FB
You can apply this filter to any of the predefined FB filters available. It's a simple convention. Just add the following to the "containing" section of your existing filter. Notice that I also include a virtual user that I use as a bucket to put cases anyone on the team can pick up and work on.
assignedto:"Team Pick Up User" or assignedto:"Team Member 1" or assignedto:"Team Member 2" ... or assignedto:"Team Member n"
When I get dumped with a lot of cases and need to provide estimates (i.e. for a new milestone). I book a room with the whole team and go through them one at a time. I’ll take notes in a spreadsheet about each case. I’ll apply notes to actual cases after I’ve had some time to digest what was said.
The team can assign the majority of cases estimates, but sometimes it’s not possible until further investigation is performed. I use my best judgement on how long it will take to complete these cases based on our current calculated throughput of cases per day per developer. Historically, on my team this has worked out to about 1.25 cases/day per developer.