The definition of higher productivity is doing less work to get the same result. A task that you skip is a 100% productivity gain. This list contains unnecessary activities, and you can feel good when you stop doing them.
This list was originally called "Stick your con call up your estimate! 6 things you can skip to save time in a software project."
Travel takes a lot of time. You might think it speeds up projects by bringing your team together. However, if you know how to manage a distributed team it's actually a lot faster to sit down wherever you are and just do the work.
I like to have one big team meeting per year. This builds relationships between team members and gives us a chance to promote new ideas. You can have small meetings between the right people. I like to give team members a budget to travel and meet in small groups when they need or want a meeting to work on a specific question. They take advantage of this to go to nice places, and they get a lot of work done.
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, programmers are not responsible for this problem. Teams get slower when you add project managers. This is one reason that open source teams can scale up to do large projects. They are usually very flat with up to 20 contributors sending code to one maintainer, and everyone works on code. With good contributors and tech leads, you can do something similar.
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 sink. 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's nice to do a big kickoff call to make sure everyone on the team has heard your plan. After that, when you do group calls, include only the right people. Choose carefully. Your listeners will appreciate the call if it is actually relevant for them.
It takes a long time set up job interviews, and more 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 how a good job candidate should look. 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. Often 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 situations where time estimates are useless:
Task scheduling is an even bigger waste of time than estimating. You can learn to estimate correctly, but you never do tasks in the order of the original schedule. Then you end up spending more time adjusting 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. You can do them in any order, and you don't have to spend time fixing the schedule.
It always takes longer to do work with a fixed scope or fixed specification. You have to gather requirements, make the specification, do some difficult estimating, and agree on the business deal, BEFORE YOU CAN START. In the same amount of time a team that had simply started and worked incrementally might have finished something better than your original spec.
You may feel like a winner when you purchase services using a fixed specification, but if gathering information and creating the spec take longer than performing the services, you come out behind. You can get good results from an Agile team by starting quickly and setting a fixed price for a fixed time.
It might seem like 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?
Post-it notes have a glamorous role in the world of Agile Scrum and Kanban teams. They represent the power and intimacy of small team. Using Post-it notes, you throw out ideas with a satisfying squelch. You rearrange and reorganize your task board on a whim.
But Post-it notes also cause problems. They are bad for distributed team members, or even for someone who happens to be home with a sick child. If someone is not in the room, handling the paper, they aren't included at all. There is only one version of posted truth, and alternative organizations are not considered. Worst of all, at the end of an iteration you throw away all the information on the notes.
Post-it notes are an instrument of oppression and control. You use them to control access to the task board. You use them to oppress anyone who is not in the room with you. You use them to erase institutional memory and rewrite the past. You can chew them up and eat the evidence.
In a world with lots of good online ticketing and issue management systems, there's no excuse for the tyranny of Post-it notes. You should put your notes and task boards online where everyone can comment, and you don't lose the information.