Change Your Team's Oil

Every 5,000 miles or so I take my car in to the shop for an oil change. It's part of the routine, preventative maintenance I do to keep my car running in tip top shape. Routine maintenance gives me the peace of mind that my car won't leave me stranded somewhere, extends the life of my car so I'll get the most out of it, and makes sure my car is always functioning effectively which is extremely important with gas as expensive as it is. Routine maintenance just makes sense – cars are expensive and mine plays an important role in my day-to-day life. So it is only logical that I would want to take good care of my car.




Routine maintenance is good for other things too. I go to the dentist twice a year for a routine cleaning and inspection to make sure my chompers are in good form. I remove the cruft from the gutters on my house once a year so they don't clog and cause bigger problems. I take my dog to the vet for blood work and a general checkup every year for her birthday to make sure she stays happy and healthy. I don't want to lose my teeth. I don't want the gutters falling off my house. I don't want my dog getting worms or licking my face with bad breath. Regular checkups and maintenance help me avoid these things.

Routine maintenance is important for software teams too. Part of the total cost of ownership for any software development team is the cost of the routine maintenance that keeps that team healthy, happy, and working at peak efficiency. The last thing I want is for my team to break down in the middle of an iteration. Even a team failing to live up to their full potential is something that can be avoided with simple routine maintenance. Burnouts, flare-ups, missed commitments, firefighting – these are all signs of wear and tear that must be repaired to bring a team back to center. Wouldn't it be easier just to avoid all that though? Preventative team maintenance is the single most cost effective way for ensuring teams have a full and happy life, operate effectively, and won't break down at critical times such as in the middle of a project.

Teams don't have oil to change every 5,000 miles, but there are still activities that should be a part of every team's regular routine maintenance plan. Here are some of the things I've found useful on my teams.



Retrospectives and reflection – This is the oil change, the physical, the teeth cleaning of the software development world. Every member of the team gathers to think about and discuss how their practices are actually working for the team and project.

What do I do? At its most basic, a retrospective is a ritualistic, round table discussion where everyone on the team has a chance to share their thoughts and feelings on how the team is doing. Agile Retrospectives" by Esther Darby and Dianna Larson is a great reference for getting started with team retrospectives.

How often? Retrospectives should be done once every iteration, generally at the end. If iterations are long it might be worth considering doing them more often. If using a continuous release schedule, pick a date every 2 weeks to 3 months to reflect as a team even if you use continuous improvement practices.

Exploration – Always doing the same thing day in and day out creates ruts in our minds and spirits. Most people who are great at developing software will get bored if left to do the same things for too long.

What do I do? Toss things up by letting folks try new things. This might include running an experiment with a new technology or methodology, learning or taking full responsibility for a new-to-you team role, or taking on non-development tasks like writing documentation or coaching. Carefully consider risks when exploring and mitigate appropriately to ensure you still satisfy your threshold of success.

How often? This depends on the team. One tool I've found useful for understanding how prone to exploration teammates might be is the VIEW Problem Solving Style assessment. Retrospectives coupled with solid software risk management will also help determine the right amount of exploration.

Upgrade tools – Sticking with old and busted when there's a new hotness available not only makes us feel unprofessional but can also hurt us.

What do I do? Buy the best you can within the technical constraints of your project.

How often? Upgrading doesn't have to happen with every new release. There is a diminishing return by upgrading too often. Major upgrades that only happen every few years for tools that are your team's lifeline (like, say, Visual Studio) are a great candidate for upgrades. For less critical applications like Office you might skip releases. And if the team says a tool is critical then don't give them a hard time – figure out how to meet their needs!

Quality downtime – Vacation and holidays, time away from computers, projects, and even each other helps keep the team fresh and ready for work.

What do I do? Encourage folks to leave the office every once in a while. Part of this is culture – make it OK to go on vacation and *Gasp* not check your email! The big trick is that this needs to be quality time off, not just time away from the office.

How often? At least 4 weeks a year, more is better. That's enough for the standard American bank holidays plus another 10 days. Time off should be taken in good size blocks, spread out throughout the year (keep in mind that American holidays are sparse throughout the spring/summer), and preferably not interfere with day-to-day team operations. With enough forward notice, anyone should be able to take a vacation whenever they want.

Status meetings (with visible progress) – Check the pulse and blood pressure of the team.

What do I do? Get together to review progress, risks, tasks, sanity, problems, and make sure there are no big surprises. The key here is to get a real sense of the important things the team wants or needs to track. Big visual charts are great for this – use data when possible to show real status. A round table will catch the outliers that can be challenging to measure.

How often? Generally a one hour weekly status meeting is enough, even if you're already doing daily stand-ups.

Parties, downtime together – Take time to celebrate your successes! A team that parties together is a team that builds great software together. Do things with your teammates other than writing software.

What do I do? The sky's the limit – happy hours, LAN parties, hikes, concerts, dinners, lunch. You don't have to have the whole team for every event, but folks should feel comfortable hanging out together. Designate a social committee to come up with fun things to do or make it a team role that moves around.

How often? At least once every iteration or once a month. Just go have fun and you'll be OK.

What else?

Look, you're going to pay to keep teams working one way or another. Either you're team will break down and you can pay to rebuild it (which may not always be possible) or you can set aside the time and resources to do the routine maintenance. You don't always get to choose when a catastrophic breakdown will happen, but you do have the choice of when to schedule your next oil change. Retrospectives are a no brainer – just do it.

Comments

Popular posts from this blog

Dealing with Constraints in Software Architecture Design

Managing Multiple Ruby Versions with uru on Windows

Agile Software Architecture (with George Fairbanks)