The Passionate Consultant: Supporting a Team that Misses Deadlines
by QLer Marc Garreau
Disclaimer: The title is absolutely a nod to The Passionate Programmer, by Chad Fowler. Read it.
Missing deadlines is but a symptom of one or more problems. Any number of issues can contribute to lower than expected velocity: changes to the team, introducing unfamiliar technologies, changing API contracts, and on and on. Let’s chat about some ways you can be effective after you’ve identified a contributor to missed deadlines.
New members are added to the team
Any software management 101 course surely includes the lesson from The Mythical Man Month: throwing more developers at a project eventually has negative returns. In this example however, let’s assume a new team member is backfilling a position. Or maybe the new developer is you, the consultant coming on board. At any rate, team velocity tends to slow when a new developer joins the team and gets up to speed.
What you can do:
As a consultant, you regularly play the role of new developer on the block, so it’s in your best interest to consider how you can jump into new projects more quickly. Understanding the context that project decisions were made within is crucial to getting out of the gate fast. Prior to the engagement, communicate with your colleagues in sales, account management, or development who have contributed to the account. Try to understand what pain points are being experienced, what constraints the project may be under, and who has decision-making authority. Ideally, this information transfer should take place in a formalized handoff process.
Armed with some business context, it’s time to learn the code context. There’s a lot you can look at to gather this knowledge: the README, the file structure, the number of contributors, the amount or type of discussion in pull requests, git history, comments left in code, or the lack of any of these things. My colleague Laura gave a great related conference talk about the Archaeology of Programming.
Once you join the new team, take as many notes as you can about who does what on the team, what processes exist (think: pull requests, elevating blockers, etc.), and what the current priorities are. With this level of understanding, you can help reduce the time it takes to ramp up new hires on the project. Bolstering the project README, updating stale on-boarding documents, and passing tribal knowledge by pair programming or less formal interaction are all great ways to improve on-boarding for future developers. My colleague Ben has more ideas on how to ramp up developers quickly.
The team is working with unfamiliar technology
Technology decisions are informed by healthy motivations (e.g. “It’s the right tool for the job”) and unhealthy motivations (e.g. “It’s bright and shiny”), but which category a particular technology falls into is entirely context-dependent.
What you can do:
If a technology decision has not yet been made, help the stakeholders understand all of the factors they should consider before making the decision. These might include current team expertise, supply of the skill in the market, maintainability of the code going forward, productivity gains or losses associated with adoption, stability and support of the technology. Make the effort to divorce yourself from your personal preference and honestly evaluate what will continue to be the best decision for this client even after you’ve moved on to the next one. When a decision is made by the group, buy in. It won’t do you any good to lament what could’ve or should’ve been.
If the team is using an unfamiliar technology, then help to keep the momentum moving in the right direction. If you’re familiar enough, volunteer to lead a Lunch and Learn session, where you give an introduction and demo some features. Another exercise is to swarm on a task as a team until you get far enough along where people feel comfortable picking up their own stories. This works best in groups of fewer than ten, so that you can still have a dialogue and not a lecture. A team lead or whoever is most comfortable with the technology should drive the development and lead the conversation, vocalizing the pieces of the puzzle they do and don’t understand. Setting up a new project’s tooling as a swarm, for example, can be a good way to build a solid foundation that the team can continue to build on.
The work is changing
Chasing a moving target is the most reliable way to have a frustrating development experience. Sometimes the reason for work changing out from under you is out of your control, such as changes to external API that you rely on. Often though, you can prevent wasted effort.
What you can do:
Some development shops will “agile” themselves right into counter-productivity. There’s a lot of good that can come out of iterating quickly, but incorporating your designer’s last minute tweaks on work in progress can also really eat up the clock. If your team does not have a well-defined process in place, this is a big red flag and it’s time to establish one.
If you have the ability, organize a meeting with the relevant stakeholders for the purpose of agreeing on some working practices. If that’s out of the scope of your role, have one-off conversations with the individuals that most often affect your workflow. A couple agreements that might help your cause are:
- A unit of work (story, ticket, etc.) must have detailed acceptance criteria before it is considered “ready for development”
- Once a story is in progress by a developer, its acceptance criteria cannot be altered. A new unit of work must be added to the backlog for any tweaks that have been thought of along the way.
It can be difficult for some members of your team to understand why moving some header text five pixels to the left deserves its own ticket. In fairness, it might be a change that only takes 30 seconds and hardly interrupts your flow. But it’s a slippery slope. As a developer, you really feel that pain if those small changes require another pull request, interaction with QA, or sign off process with another stakeholder.
Closing thoughts
In practice, you can stick some of these ideas squarely in the “easier said than done” category. The difficulty of putting them into practice comes with the territory, though. Part of what separates a great consultant from a code jockey is the ability to have challenging conversations with all kinds of stakeholders.
In the case of a team missing deadlines, cracking the whip louder might get a quick win or two, but a lasting solution requires addressing the root of the issue. Sometimes that’s just a temporary blip in velocity, resulting from a new member being added to the team. Other times, there’s a systemic problem to confront. In either case, take the realities of your situation into account when bringing solutions to the table. Plan A is not going to work for Company B, just because it worked for Company C.
Finally, teams that miss deadlines can usually use a morale boost. A little enthusiasm on your part can be infectious to the team and aid you in any of the initiatives described above. So, smile!
Originally published at Quick Left.
