It's Embarrassing!!!!

We can do better!

Last august Toyota announces a major Prius software bug and recall
Last November Microsoft announce major changes in management and delays in Vista
This March the FBI announces more delay in their $500 million upgrade
This April Microsoft announces more delays in Vista
...

Every company has them. Delays due to engineering schedule slips are common place. Significant Quality issues due to inadequate testing or integration.

I want to acknowledge we are all working on our own stuff. At first glance maybe you should not care if Microsoft has another delay. We are used to it. They are not us. They might even be the enemy and you may take joy from their misplanning. I am here to ask you to reconsider.

Whether you like it or not we are part of an industry. From the Linux developers to Windows developers, from embedded to supercomputer, from Assembly language to business logic we are failing. No one can depend on us. Not our customers. Not our sales people. Not ourselves.

One might say the problems stem from the youth of our industry or the rapidness of change. You might want to blame hungry investors and executives who have become accustomed to setting impossibles goals assuming that no matter what date is set won't be made. Still other might indict the workforce for not being able to plan or not working hard enough.

I will suggest we are all to blame. We can do better. Dogma and standards will not win the day here but results will. I believe there are two things that can make the greatest difference between predictability and the status quo:

• Leadership
• Education

Without leadership from investors, executives and managers nothing will ever change. You have to vote for predictability to make change. You have to know it will take time to achieve. You have to know it will require tough decisions like making priorities.

Without education we will never be better. We have to start training technologist to be leaders in school. We cannot expect them to magically develop those skills in the work force. We have to train engineers before we ask them to be managers.

Dr. Dobbs has just published an article I wrote on some of the things it takes to be a good manager in their June issue. Check it out. It is a good way to start the dialog. Feel free to contact me on how we can start to change the industry (mark@heavenstoneinc.com).

More Later ...

How do you address unproductive employees?

I just read an article by Scott Reeves at Forbes on this subject. He made a lot of salient points and the article is worth reading (click here to see article) but he missed a basic point: how do you make employees accountable?

Many employees confuse accountability with micromanagement. As Scott says in his article, micromanagement will never succeed. Employees resent micromanagement. Your team needs to understand that it is you job to produce predictable results. Your team needs to understand it is your job to get measurable status on a regular basis for all employees. Sounds like micromanagement right? Well the difference between accountability and micromanagement is in the process of getting the information and what you do with it.

Here are the signs of a micromanager:

• Ignoring pre-agreed to reporting points and asking status more frequently
• Getting mad at people for missing status
• Constantly changing working assignment
• Dictating implementation instead of requirements

You have to give people a chance to do their job in a positive environment. You need to look at problems as just things to be solved. You need to engender trust so you can get the truth when you ask for status.

Without an environment where there is accountability and trust, you will never help employees improve and you will never manage problem employees out of your organization. Every employee should know what tasks they should be doing. Every employee should know if they can go home at the end of the day or if they need to work harder. Every employee should have a schedule.

Employees should be involved in making their own schedules. Managers need to work with them where appropriate. Some employees are not experienced enough to develop schedules on their own but they should be involved in the process. Dictated dates are artificial and you will not get buy-in. You need employee buy-in to have reasonable accountability.

Once everyone has a schedule, you need to track it. At the beginning of a schedule, weekly meetings can suffice. At the end of a schedule during integration periods, daily meetings are often required. Do not expect everyone to be making their schedules on time.

From here the process of objectively identifying unproductive employees is easy. They are the ones who chronically miss their schedules.

Your number one goal should be to make them productive. Managing employees out and finding new ones to replace them is costly and it is worth some effort to try and turn them around. This requires a positive attitude on both the employee's and manager's part. If this fails, then the accountability based on real schedules will be an important piece of documentation in taking further or final steps. If it reaches this point, you need to follow your company?s policies carefully.

More later ...

How do you develop predictable schedules?

Let's go back to basics. I believe predictability is the main reason to have schedules in the first place (see my earlier post on schedules). The only way to get predictable schedules is to pick good tasks. So how do you pick good tasks?

Here are the basics on how to do it:

• Pick tasks of reasonable size (10 days maximum)
• Make sure the result is measurable
• Legitimize design time, test development time, integration time, etc.

If the duration for your tasks are too long, then you will not know your task is running late until it is too late. Slips in long tasks cause slips in releases. The only way to mitigate this risk is creating smaller tasks. This may require more scaffolding to test intermediate results. It may require longer schedules. If your goal is predictability, you need to tell your team that predictability is a priority for you and it is ok to identify shorter tasks, even if it results in a longer schedule. Longer schedules alone will not provide predictability. You need smaller deliverables.

Each task should have a measurable deliverable. Without a measurable deliverable, the schedule and the task are meaningless with respect to predictability. It is easy to create a task whose description is "Coded new APIs" but at the end what do you have? All you have is that code. Does it tell you that you are finished? Does it tell you it works? What if someone finishes the coding but it takes twice as long to get working? Identifying a separate integration phase does not help either because you cannot tell how far along you are. Instead I suggest a task description like "coded, developed tests, code reviewed and checked in 5 APIs". If the original goal had 15 APIs, then I would create three of these tasks (or whatever fits in 10 days). This sends a clear message that the task isn't done until it includes all of its pieces and is measured.

Finally, make sure that tasks include explicit time for design, code review, etc. It is easy to either slip because of these items or worse skip them. They are not the most fun tasks for engineers, so make them count. Without these items, it is easy to slip a schedule late in the game because of a lapse in up-front hygiene.

This is hard and your teams will need both practice and help to succeed, but it will payoff in success and rewards.

More later ...

Schedules, Schedules, Schedules

Why create schedules? How do you make schedules? How do you get your team buy-in to schedules?

Schedules are about predictability. This may be obvious to you but get lost on the way to the troops. It is always important to talk about rationale. You need to be able to predict product availability so your sales team can sell and your executive team can predict revenues for budgeting and investor purposes. You need to be able to predict integrations points between constituents on your team like QA or docs and development. Your developers need to predict when they need to work harder or longer and when they are done and can go home for the weekend.

Schedules are not rocket science but they do require effort. First you need agreement on what you are building and therefore you need both requirements documents and preliminary engineering specifications and you need them to be consistent. Next you to do project decomposition and there are a lot of books on this subject (just google software project decomposition). Next you must define integration points. Some hints:

• Only schedule 4 days a week
• Update the schedule weekly and do not let slips go unattended
• Don't let people go home if they do not finish their tasks
• Make people sequentialize their tasks even if it takes longer. Mounds of partially completed tasks will result in slips
• Allocate enough time for docs, qa, integration and field test feedback

Many engineers will tell you that software is not schedulable. They are wrong but it something that can only be believed when experienced. Get some people who have done it before as part of your team. Make your first release smaller and eminently accomplishable to help get your team experience. Goals have to be top down but schedules have to be bottoms up --- do not dictate dates.

Persevere.

More later ...