Right on time

Most projects fail because teams run out of time. They run out of time to deliver better code, to deliver tests, to deliver (almost) bug-free software. And the crying starts: it’s because the customer, it’s because the time, it’s because the tools, the hardware, the existing system is a mess… and so forth. Complaining will not fix the situation. You’ve failed. You’d better do a post-mortem analysis and try to learn from your failures to avoid committing them again.

I’ve always said that committing mistakes it’s not bad; committing the same error twice it’s the devil thing. So, try to commit new mistakes every time!

Software development is like a marathon: it’s a long-running race, so it’s better to save strength and energy for the final meters. Most software teams work long hours, getting fed up soon and quitting from the project or, even worse, from the company. That’s not good. Long hours should be considered like a failure of finishing our commitments on time. Long hours should be the exception, not the rule.

I’ve been working on a software factory company on a team developing features every release (every month). Those features involve 3 – 5 people, a month of work and I’ve always been successful. On the other hand, I’ve seen many mistakes many times, so I wanted to share my experience about this, and where I see that others fail where I am successful, IMHO.

Continuing with athletics, take iterative, incremental, feature-development management like a 100-meter race. The key is: don’t never ever relax.

So, software development is like a marathon, feature development is like a 100-meter race. Get it? In other words, software development is like a war, feature development is a battle… whatever, I’m rambling…

Like 100-meter races, feature development management consists of:

  • Start tough
  • Keep it up during the race
  • Don’t relax at the end

Start tough

Most teams fail at the very early stages, due to the “paralysis of the analysis”. Lots of uncertainty is around when gathering requirements and trying to estimate tasks, dividing user stories and so forth.

Don’t estimate too early. Realize that you don’t know almost nothing of the software you have to build and work on that uncertainty. Don’t estimate till you have taken a look into the code you’ll have to deal with.

Use prototypes, mock ups, UML diagrams… whatever you find useful to make the problem understandable. Share your drafts with your analysts  or customers to reduce uncertainty. Try to explain what you have to do to your analyst, to check that you’ve got it. Involve the customer. Stress this till you get their attention. Try to make him aware of the importance of being involved, specially in the early phases of development.

Don’t get stucked. While you wait for some answers, try to formulate more questions, work on other requirements, diagrams, see the code you’ll have to work with.

Don’t be fooled by a far deadline. Define objectives for everyday, so you can measure progress from the very beginning.

Try to assign work to developers as soon as possible, and involve them in the early stages of development, so that they are not mere “programmers” but they think about what they are doing and think whether some solution makes or doesn’t makes sense: adds value to the customer or does not.

Keep it up in the middle

As soon as you get “velocity” and things start going well, you’ll have the sensation that you can relax a little bit, because “you are doing well”. Don’t. Things always get complicated at the end: requirement changes, bugs, forgotten requirements, non-functional requirements not fit (performance!)…

Keep the pace. The earlier you finish your iterations, the better. You’ll get more time for the Unforeseen at latter stages.

Don’t relax at the end


The final stages are vital, and lots of things (specially stupid things) can happen:

  • Someone forgot to commit that bugfix
  • Someone forgot to push that bugfix
  • Someone fogot to merge that bugfix
  • Someone forgot to version that file
  • Someone forgot to include that configuration change in the deployment instructions
  • Someone understood incorrectly some requirement change.
  • Someone assumed that someone else would be responsible for THAT small tweak in the code.
  • The list grows.

It’s too bad to trash your hard work at this stage just for those naive mistakes…

So, when you’re about to deliver, sleep well, eat well and get some coffee. Make sure you are pretty awake and check every single thing. Control it. Double check. Ask. Twice, if necessary. Don’t leave anything loose, keep everything fastened.

Some more pieces of advice

Measure the progress all the time.

Involve the customers, analysts, testers and developers. All of you are on the same boat, all of you have the same aim, so all of you must point on the same direction.


Try to define objectives every day and check if you achieved them at the end of the day or why you didn’t achieve them. If you didn’t, you have a risk. Make a plan to handle it. This strategy will help you to detect risks very soon, before they are out of control. Be disciplined and stay alert.

Share the status with your team, so they get involved and aware of the situation. Make them feel part of the management, of the goal.

Don’t force you developers to work long hours. Enforce that they do their own commitments. You won’t get disappointed. Developers LOVE achievable challenges, specially when they feel that they have signed to them. Make them sign their own commitments and remember them that those are their commitments. It’s their word. Their honor. If eventually they don’t comply their commitments, handle that as a risk: review your plan and your estimations, but don’t get angry with your team; be patient.

You are a facilitator. A guardian. Don’t let your team be interrupted externally. You are the focal point of your team. You are the bodyguard, the shepherd dog. You control the communication channels: the executives channel, the customers channel, the Q&A team channel, the analysts channel. There’s nothing more annoying for developers that get distracted from something else than… development. Don’t get me wrong: developers don’t work isolated; they constantly talk to each other but… they talk about development, nothing else. Talk to them to be sure that they don’t get stucked. Fix their problems, find solutions, do whatever is needed to make them work easily. Provide good chairs, big tables, hardware… whatever your team need. Don’t wait till they ask you. Take a look at them and figure out what they could need.


I’ve tried to keep in mind these topics when leading developments and the number of long hours have always been minimal, the team members were highly-motivated and they felt part of the big issue, providing ideas, designs and detecting problems in the solutions upfront. Team members had time to sleep, go on with their personal lives, eat well and have fun. That’s what marathon runners do. Saving energy for the future.