Team Productivity
A lovely thing about Christmas is that it's compulsory, like a thunderstorm, and we all go through it together. Garrison Keillor
The human brain is an amazing pattern recognition engine. Yep that's right kids, at our core we're all just a REALLY complicated regular expression. Today we're going to share some tips and observations we've noticed on developer team productivity.
We're going to share how Santa and the Elves make all those wonderful toys, year after year, like clockwork.
Tip 1 - It's Not Clockwork
This one is usually the hardest for companies to swallow, so let's just get it out of the way first. Programming like most knowledge or creative work doesn't fit neatly into a 9-5 schedule. For Santa's sake, most people even schedule deployments outside of normal working hours to reduce the impact of mistakes. You can't have it both ways, so quit trying to force it.
Tip 2 - Tools
Which tools you use in and around your development team matter. Bad tools, those which are difficult, cumbersome or just plain annoying to use, get in the way of getting real work done.
You'll likely never get everyone to agree on every tool, but you should strive for concensus and whenever possible allow teams to choose their own tools. Santa gets sad every time your new development team is forced to use the same tools as another team, just because you've already purchased them, because IT said so, or some grand notion of inter-department cohension.
Be willing to try out new tools, but fire them quickly. One thing I always try to be aware of when leading or managing a team is complaints around tooling. Does it seem that your team grumbles mostly about one or two particular tools? Then get rid of them or replace them with something else. The switching cost may seem high in the short term, but the staying cost is often much higher.
Keep in mind that it is less about simple metrics like it takes 12 clicks to do something routine and more about how the team feels about using the tool. If they don't find it useful, they won't be happy about being forced to use it it and that decreases overall productivity.
Honestly, most of the time the team slowly drifts away from a mandated tool with or without permission anyway so just give them the permission.
Tip 3 - The Holy Grail of Code Flow
One easy way to head toward better productivity is by optimizing just a couple of things. While it's not always possible, you should strive toward:
- One command to install/launch/rebuild a local development environment
- One command to setup and run tests
- One command to deploy code
And in the darkness bind them... er wait no we're talking about Christmas not Hobbits.
Nearly everyone does the second one on their own without fuss. Some companies make #3 overly complicated. And almost no one optimizes #1.
Sadly optimizing the first and the last bits are arguably the most important overall.
Automating Development Environments
Making it stupid easy to fire up a new development environment does a few things for you:
- Helps in onboarding new hires to the team, sub-contractors, or consultants you may end up hiring.
- Ops and environment changes to non-development environments are easily distributed to all of the team as they happen. So everyone can use the same versions, of the same stuff, at the same time.
- Not needing to reference 3 out of date wiki pages full of instructions is just plain faster. If the process is documented in the code that automates it, you have a single always accurate source of truth.
- Different branches or lines of development can have independant needs more easily.
- Removes any excuses for shared development environments that bottleneck developer progress.
The last one is the most important. Every time we work with a team that has some system or process in place to put something onto the shared dev or staging server the bottlenecks are palpable. When Sally can't show Steve that bug fix, because John is currently showing off a demo to The Big Customer you've got problems.
If you're having trouble justifying the time to automate this or the infrastructure costs frame your argument around the fact you currently have multiple $50-100k+/year resources waiting on a single $100-500/month resource.
Automating Deployments
"Sorry, only Bob and Timmy are allowed to deploy." If you find yourself saying that, you need to re-evaluate your processes.
What exactly is special about Bob and Timmy? They're likely checking several things to ensure a smooth deployment or the steps are complicated and in an effort to minimize mistakes the task is centralized around them.
Mistakes are going to happen, but re-read that last paragraph. Checking things and complicated steps that need to be done perfectly. Sounds like a job for... software!
As mistakes happen adjust the deployment code to catch or handle them and get back to your real work.
Tip 4 - Communication
Obviously you have to be able to communicate with other members of the team, but finding the right balance of communication interruptions and focus time is hard.
Everyone talks about minimizing meetings or grouping them onto certain days. These are great tactics. But be careful to not ignore or gloss over sacrosanct meetings like stand ups. If you're the team lead and you find that not much is really getting accomplished in that daily, weekly, or monthly whatever kill it and move it to some async communication like email.
Favor async over synchronous communication always.
Tip 5 - Optimize for Miscommunication
This is the most important bit that religions er I mean
workflows like Agile and Kanban accomplish.
Groups of people are terrible at planning things. We're bad at communicating the initial plan and we're even worse at disementating changes to the plan.
Optimizing for miscommunication means you need to be doing things like code review, which ensures what the developer wrote is clear to the other developers. And it also means getting the change in front of the people who wanted it as quickly and early as possible to sort out the inevitable miscommunication that happened.
Tip 6 - Legacy Processes
As projects grow, they naturally develop a bit of cruft. So you need a plan for dealing with that. Small agile-ish changes work better than skunk works rewrites with most teams. It's like cooking, if you clean up as you go you don't end up with a huge mess at the end.
Sadly the real world gets in our way here. While not always plesant, it's often the perfectly correct answer for a business to rush a feature or fix out the door with duct tape and chicken wire.
Product, Sales, Marketing, Customers or Whoever is Your Boss are going to do this to you. More than once. So have a plan for dealing with it.
One technique we've seen be effective is to "pay it forward". If you work in some sort of sprint structure with points, just explain that it costs 3 points to do it correctly right now or 2 points to half ass it this sprint and 2 points to clean it up in the NEXT sprint.
The requesting party can make an informed decision if the extra work is justifiable. And your team gets to clean up as they go. The next sprint part is important there. Don't let them allow you to clean it up at some arbitrary point in the future, because we all know it won't happen.
Another technique that improves your code, processes, and overall morale could be called Geeks Gone Wild. Friday afternoons are low productivity days, partly from the long week of work and partly from the anticipation of the weekend. Remember your team is made up of humans, not robots that eat requirements and shit code.
Since Friday afternoons are low productivity anyway, make them a free for all for your team. Give them the ability to add that utility they've been trying to find time for. To clean up that one nasty section of code that has been bugging them. To finally have time to give that new tech or tool a spin.
I'm not talking about heading to the bar right after lunch. It needs to be work related and drives something useful forward. You just don't get to pick what that is. Honestly your team probably knows better than you do anyway.
If it's bugging them, consider it a bug.