Best practices for shipping software on time

Imagine you don't have the problem of feature creep, you have a motivated and stable team, clear defined problems to solve, AND you know the domain/language/tools related to your project.

How do you stick to a schedule and accomplish that 1.0 milestone?
What is your approach to an iterative shipping?

I'd like recommendations specially for a small team, where there are few or almost none communication problems.

From stackoverflow Camilo Díaz

• 1. Focus on features not implementation tasks.
  2. Work in iterations (like weekly or biweekly).
  3. Release working features to your staging environment in order of priority.
  4. Unit test your code as you go, so you're not slowed down by a buglist that increases geometrically as you approach the release date.
  5. Be prepared to cut scope from the less important features. Stuff always takes longer than you think it will.
  6. Make sure you sketch out the UI in advance (if there is a UI), and show it to potential users.
  7. Test, test, and test some more. This seems counter-intuitive, but it saves more time than takes.
  From Sam McAfee

• That's probably an Utopian scenario ;-). But anyways, if there is no feature creep, very good team and clearly defined requirements with absolutely no communication problems then probably the best way to deliver the product on time would be

  1. Weekly meeting with team to assess the current status (PM with Team, if there is a PM)
  2. The team lead can have a small daily meeting with the team members to assess their status on the issues/requirements delegated to them. If there are issues then he/she should take necessary steps to resolve the issue.
  3. Project Plan Tracking and Work Delegation (Team Lead would need to know the individual strengths of each team member to delegate work appropriately).
  4. Testing can be automated to the extent the technology allows.
  5. Ownership of work by each team member.

  End of the day, it boils down to how passionate a person is towards their work.

  Just my 2 paise's ;-)

  From vikramjb

• Question: How does a large software project get to be one year late? Answer: One day at a time!

  That doesn't provide an answer to your question, but I think it does point to the need to stick to your schedule -- if you even get one day behind, you need to catch it up somehow. (Unfortunately, the rest of The Mythical Man Month is all about how in most projects there is no "somehow"...)

  Also, have a look at the Evidence Based Scheduling in products such as FogBugz. This will give you an up-to-date estimate of when the product is likely to ship -- in fact, it gives a range of dates, with probabilities for each date. If you see your likely release date slipping past the deadline, this will let you know that you need to do something about it -- and hopefully with enough time to have an effect.

  From TimB

• There is one small point missed by previous posters. To meet the deadline first of all realistic schedule should defined. The project should be split down to small task it's depend on the project size, but in my world with projects taking about 3-4 months, we trying to split them into maximum 2-3 days task. This way the time estimation are mostly realistic and risks are calculated in advance and added to the proposed schedule.

  From Ilya

• There's a lot of good advice in this thread. The only thing that I have to add is to adopt a regular timetable for releases. My company switched to this a few years back and it was painful at first, but it does have a lot of benefits, the biggest of which is to allow people to easily defer features.

  It becomes okay to defer features because you know that your feature can make it into the next release and you know when that release will be. This means that rather than rushing to get your half-baked feature in at the last minute, you can spend a little longer and have it in at the beginning of the next release.

  From Dave Tarkowski

• Barring unreasonable timelines from sales/marketing/management, you've pretty much ruled out all the reasons that a projects don't ship on time. The history of software development methodologies is a collection of methods to work around, reduce the impact of and/or avoid:

  • poorly defined scope
  • feature creep
  • lack of domain knowledge
  • large teams with communication problems
  • unmotivated/incompetent developers
  From Sean McSomething

• Stage periodic (monthly? weekly?) product walkthroughs using the current accepted build, for the benefit of the Product Team. Begin these as early as possible. Demo every feature, regardless of their current usability; don't skip over the ones which are lagging behind.

  The point is to give the stakeholders a clear idea of the current state of the product over the course of the project. This way decisionmakers are more likely to tackle schedule risks promptly, rather than jeopardize the ship date.

  From mseery

• Know what the mission-critical features are for the client. Protect the progress on them. It is often very true that 80% of the success comes from 20% of the work.

  From J.T. Hurley