Four things that helped our team to stop missing deadlines
I got promoted to team lead pretty early in my software development career.
I was good at coding. Not great.
But I was great at one thing: solving problems for other devs.
You know how devs like to write code but not read code? I actually like to read code.
After getting promoted, I realized quickly that it wasn’t good enough to just solve problems for my team. I had to anticipate the problem.
When we find problems early, the cost to fix it is exponentially lower. Shift left.
Ugh, reading?? I know, right? If you’re the kind of person that would rather watch the movie than read the book, register for my videocast on March 11. I’ll have a lot more to say.
When you find problems late in the iteration, the cost to fix it is magnified. People get tense, extra hours have to be put in and there is a cascading wave of negativity that affects lots of people across your organization.
I came to believe that not only is this one of the keys to shipping on time (which my boss cared about) but it is one of the most important factors to software developers having a high quality of life (which everyone should care about).
Hitting your commitment and stopping bad things from happening is all about finding risk early in your iteration.
I believe identifying risk early in your sprint is a skill team leads (and any developer) can hone and improve over time. And like most skills, it’s an art and a science.
Unfortunately, there is no training course for this skill. So here’s four things that worked for me over the years that you can try.
1. Focus on leverage points
I believe everyone on the team is equally important. But in any given iteration there are normally a small number of devs working on items that have a disproportionately high effect on the success of the overall sprint completion. Those are your leverage points.
On day one of the sprint, figure out which devs are working on the most important work. Often times it is the work that other devs are most dependent on. Other times it is a dev working on a technical cornerstone that everything relies on.
Give them a little more attention. Ask tough questions to make sure they’ve considered all of the angles – technical design, scalability, testing, rollout. If you help make them successful, it’s likely that your overall iteration will go smoothly.
2. Use your stand-up
There’s a lot of reasons devs don’t talk about their blockers during the stand-up. Sometimes they are afraid to slow the meeting down. Sometimes they believe they can fix their own problem. Sometimes they don’t even know they have a problem to begin with.
I like to ask pointed questions. You should not drill in with everyone but you can pick a few people (leverage points). I find the following questions tell me a lot about where a dev is with their work:
Has (fill in the dev or team who is dependent on this work) reviewed this?
Tell me about your feature roll-out plan?
What are you thinking for scalability testing?
The dev team @ LinearB’s daily standup
If you get a succinct answer with dates like “I’ve reviewed the plan with the PM and XYZ team and we’re starting the roll out on Tuesday. I can send you the doc if you want” you’re probably good.
If you get “the look” or they start listing things they need to do before they can get a plan together or have a conversation with the PM, you might want to dig deeper.
*Pro tip 1) Make sure everyone knows where you are in the iteration. It’s easy to lose track of this when your heads down writing code.
Pro tip 2) No matter what you hear in response to your pointed question, don’t respond during the meeting. You have to keep things moving. If you hear that something might be off, make a mental note and take it offline.*
3. Show up prepared for the stand-up (or 1:1 meeting)
When I first got promoted to team lead I thought of the stand-up the same way I did when I was an individual contributor. One of the best pieces of advice I ever got from my VP was to take 30 minutes before the stand-up every day to prep.
Over time I found there were certain data points I could look at that were accurate indicators of potential issues.
WIP to days-left ratio. Let’s say you have 5 days to go in your iteration and most of the team has 1-2 WIP open. If one of your devs has 6, that could be an indication they aren’t going to finish. It’s useful to look at the average WIP to days-left ratio from iteration to iteration for the entire team and individual devs. If your WIP to days-left ratio is higher than normal, this can tell you your dev has a workload problem even if they don’t know it yet.
High-interaction PRs. If your team’s average PR has 5 comments and you see one with 30, it could mean your developer is struggling to deliver what is expected or there is an internal debate that needs resolution.
Lightning PRs. This is what I call branches that are merged with no review. Some teams are OK with this. We avoid it because it is a good predictor of quality issues. It is better to invest in review time upfront than rework time later.
Complex branches. I consider branches that have a high number of code changes combined with a high percentage of refactor or rework to be complex branches. These branches have a high amount of risk so you can make sure they have 100% test coverage and even assign early review cycles (before the PR is issued) if necessary.
If you have this information going into the stand-up (or an individual 1:1), it helps you focus your time on the areas where you personally can have the biggest positive impact on your team.
Pro tip 3) Block your stand-up prep time on your calendar to make sure you don’t get distracted.
4. Know your cycle time
Cycle time is the average amount of time it takes to get a piece of work coded, reviewed and released to internal or external customers. I believe it should be the primary metric dev leaders use to measure the efficiency of their team. It helps to also look at key phases of cycle time:
Coding time. The amount of time you are writing code until you first issue a PR. We also call this fun time 😊
Pick up time. The amount of time it takes for your PR to get picked up for review.
Review time. The amount of time it takes to merge the PR after review starts.
Release time. The amount of time it takes to release functionality to customers after you merge.
If you are using continuous deployment then your merge time is effectively your cycle time.
Cycle time is a great sanity check for what you’re hearing from your team during the iteration because it shows you how long it usually takes you to deliver. If you measure your cycle time across each iteration and keep track of your team’s average, it’s easy to see if your current iteration is out of line.
Pro tip 4) If you’re looking for ways to accelerate delivery overall, look at the individual phases of your cycle time. It’s an easy way to detect team bottlenecks.
*Help your team, help the business, help yourself *
As I got better at diagnosing issues early and helping to solve them, I started to notice that people treated me differently.
My team respected me more. They knew I was there to help them, not judge them. They opened up to me more. We all grew closer.
My boss noticed we hit our deadlines more often. He started to trust me a lot more. He gave me more input into strategic decisions.
The CEO knew my name 🙂 And he started scheduling skip-level 1:1s with me. And he actually listened to what I said. Later on, when my boss moved on, he supported my promotion to VP.
Take responsibility for your team going home every night
I read a lot about how flawed culture or inaccurate planning is to blame for the burnout that can sometimes happen within software development teams. But not as many people talk about the things dev teams can do differently inside of the sprint to stop burnout from happening.
Make sure your devs go home and get time with their families, friends, online gaming guilds, or what matters most for them.
All devs should go home on time every night and spend time with their families and watch football and play Zelda Breath of the Wild.
I think team leaders should take personal responsibility for this. Our people are in our care.
I have a lot more to say on this topic and I’m doing a live videocast on March 11. Click here to watch it live or get the recording.
Top comments (0)