The definition of higher productivity is doing less work to get the same result. Maybe that's why most of the feedback on my recent podcast was about the list of "don'ts" - things that you can cut out of a software project to save time. Or maybe people just found some of this advice surprising. Let's count down the greatest hits.
Traveling takes a lot of time. You might think that it's going to speed up your project by bringing different parts of your team together. However, if you know how to manage a distributed team, it's actually a lot faster just to sit down wherever you are and get the work done.
5) Architect in advance
Agile gurus recommend that you design "as late as possible" - ALAP - meaning that you wait until you need to implement something before you add it to your architecture. But, most engineers find it unsettling to start a big project without an architecture to match. Even the people who say they like ALAP often don't really practice it (sort of like pair programming). But, the reasoning behind the ALAP idea is very sound. If you wait to do something, you might never have to do it. The project might go in a different direction, or be canceled, or be great in a simpler form, or you might figure out a better way to do it. The work you didn't do is 100% time savings.
4) Add project managers
We all know that bigger teams are slower. According to the statistics in the big fat book "Software Assessments and Best Practices" from Capers Jones, my favorite bedtime reading, programmers are not responsible for this problem. Actually, teams get slower when you add project managers.
3) Conference call
I have noticed something when we go to "rescue" a project. If the team spends a lot of time on conference calls, the project is probably delayed. Maybe the delay causes the phone time. All I know is that conference call time is closely correlated with project failure. It's best to avoid conference calls. You should write down your tasks in tickets, hold a quick stand-up meeting, and maybe keep a chat thread running. If you start setting up conference calls, your people will be bored, and you might get sucked into a time warp. In the two years since I started making this claim, I have never heard someone say "I worked on this project with a lot of conference calls, and it went great!" This never happens. Prove me wrong, I dare you.
It takes a long time set up job interviews, and some time to do them. If you go straight from a resume to a paid trial task, you get to the work more quickly. You might also get better results. Job interviews are deceptive. You might think you are hiring someone because they proved they can do a good job, but statistically, about half of the time, they are just good at interviews, or they matched some preconceived notion that you had about what a good person would look like. That's why orchestras often hold auditions behind a screen. Try trials.
A lot of technology, skill, and time goes into estimating how long things will take. In many cases, this expenditure of time and treasure is useless. Maybe you can skip the estimates, and get your real work done faster, or take the time that you save and do something equally useless on Facebook or Twitter. Let's look at the cases where the time estimate is useless:
- You already know what order you are going to do things in, and no estimate is going to change that. This is the big escape route. If you can get things into priority order, with a good roadmap, you will not need to estimate.
- You already know how much time and money you are willing to spend on the project. This is the typical reality. It doesn't matter what your estimate comes to. The project is worth a certain amount of time and money. As an entrepreneur, I totally sympathize with this time-boxing money-boxing approach, and I recommend it. Given a new product idea, I am perfectly happy to say that it should take X weeks to build and not more. A bigger organization might pretend that they care about how long you think it SHOULD take, but most of the time, they are lying to make you feel better, or self delusional. You can deal with this by using the agile method of prioritizing, and always having something that you can ship, however incomplete.
- The estimate is going to be wrong anyway. There are ways to improve estimates (reduction to detail, self-estimates, historical velocity, etc.) However, some projects have a lot of dependencies and undertainty, and over a certain size of project, the estimates are almost always wrong. You can use the tactic of tracking your estimates and comparing them to actual velocity. If the estimates get better with this technique, then keep doing it. If they keep going off track, then maybe it's best to give up, and just prioritize better.
Task scheduling is a worse time waster than estimating. You can learn to estimate correctly, but you always do things in a different order than the schedule. Then, you have to spend time fixing the schedule to match reality. That is why we schedule by stacking a bunch of tasks (not ordered or scheduled) to be done before a milestone date. That way, you can do them in any order, and you don't have to spend time fixing the schedule.
Now that I am at it, there's more. These aren't tasks to skip, but rather, situations to avoid altogether.
Do anything with a fixed specification
You may feel like a winner when you purchase services using a fixed specification, but if getting to a spec takes longer than doing the services, you lose.
Divide work geographically
It might seem like clever management, a nice simplification of roles, to send your requirements to Chicago, your coding to Bangalore, and your testing to Lima. I think this wastes talent and makes your life harder. Why not hire people in all of your locations that can handle the complete process?
Use synchronous collaboration (phone, video, screen sharing) to manage fast-moving situations
It's the job of a good manager to avoid fire drills, emergencies, and any type of fast-moving situation. People should have enough time to do good work.