Archive

Archive for June, 2011

How to create an accurate software delivery schedule: not as difficult as it may appear

How many of of you have been in this situation?

The schedule of a major software development project has to be updated.   The team cannot meet original milestones and the project is delayed.

Ignoring the reality for a second, what if we had the luxury of going back in time and doing some things differently in order to create an accurate schedule the first time?   Is it even possible?   The answer is yes.

Before sharing my perspective on the problem of inaccurate software development schedules, it’s important to identify factors that cannot be controlled (not an exhaustive list):

– Highly competitive (do or die) market expectations and very aggressive delivery schedules;   this however does not mean taking significant shortcuts in functional depth or product quality.   The risk of delivering an underwhelming software product to a market closely watched by industry observers and analysts cannot even be measured.   My guidance:   simply don’t deliver an underwhelming software product or release.

– Deep and unknown technical debt can surprise even the most capable software engineering teams.    Large scale refactoring efforts carry a lot of risk despite best efforts to manage these risks and schedules.    Technical debt gets even worse when it has been inherited.   Someone else wrote 1M lines of code and your team has to first understand what it does.

What factors influence the accuracy of software development schedules?   Is there a single factor which helps ensure accurate schedules more than any other factor?

People.

Because if the right people properly assess the problem, the result will be a better estimate.  There is no substitute for the right people who can understand the problem (at the right level of detail with all the right inputs and considerations) and determine options to solve it.

Only then the right process applies.    Many software engineering projects fail because a manager tries to apply a perfect process to a team that has difficulties solving the problem in the first place.   To illustrate:  it’s equivalent to asking an excellent driver to fly an Airbus A-320.   The driver will fail because he / she does not know how to fly this aircraft although the _process_  of driving a vehicle and flying an airplane is very similar.   The real problem is however not the driver who is being asked to be a pilot.   It’s the manager who creates this problem in the first place by asking someone who cannot be successful to step into the position of guaranteed failure.

Software engineering projects that suffer many delays show the same symptoms:

– Managers who exhibit “every leaking faucet is a plumbing problem” approach.   Different problems require a combination of techniques to assess and address in a sustainable manner.

– Software engineers who never refactored code and cannot apply a classic “cover and modify” technique.   Yet there are software engineering managers who will continue to ask their employees to do what they have never been exposed to.

– Quality assurance engineers who do not understand the full extent of automated software testing and tools (not every tool can be used for every automation challenge)

– Lack of continuous internal retrospection:   what do last 20 regression problems really mean?   Why did the team generate these regression problems?   What can we do better?   How frequently should these lessons learned exercises be conducted?   Once at the end of the release is not a good approach.

Simple steps towards an accurate software development schedule:

– If you are a manager, be very honest with yourself first.   Have you done this before?   If not – be the first to ask for help.   Assess your team.   Given the complexity ahead, do you have the right team?  If not – make changes.

– If you are an engineer, be very honest with yourself.   Am I up to the challenge?   Can I “fly this plane”?  Do I have the tools and experience?   If not – ask for help or be ready to ask for help.  Set your own measures of success.    For example, what if you were asked to help bring Apollo 13 back to Earth?  What would you do?   How could you contribute and help?

– Assess the problem correctly.   Let’s assume an engineer will work on 2 projects:   write a payroll program and write a virtual memory management component for a new operating system.   Which project will have more error management code?   Shouldn’t error management code and the effort to implement it be in the schedule?

Accurate software development schedules begin with people:  people who manage well and people who design and engineer the answer to the problem.    Both have to be first successful in one critical element:   assess the problem correctly.

Don’t forget to attract, retain, and reward great people in your software engineering organization.