Guaranteed Results!

I flashback to Ron Popeil TV commercials and SNL take-offs as I sit here writing this entry. But I will tell you I am guaranteeing results. If you implement the two techniques with your team that I suggest in this blog I guarantee that the average amount of time it takes your team to fix bugs will decrease by at least 30% within 12 months.

But wait there's more: I also guarantee that your total over bugs found after release will decrease by at least 20% for the same period...

But wait there's more: I also guarantee that these techniques are so incremental that you will not notice them affecting your schedules directly.

Here are the two techniques:

• Assertions
• Root Cause analysis

Now I know you are about to say that these are not new. I agree they are not but most teams do not employ these easy techniques.

Assertions are an easy way for your code to find it's own problems before your customer find them symptomatically. I would much rather have a message be emitted during testing or deployment that detects an issue than having data corrupted or having a blue screen event.

You can do this incrementally by saying that no bug fix or new feature can be checked in without all changed methods containing assertions. Assertions should test three things: input, output and state. Never assume anything is correct. Input and output assertions are pretty obvious but there are some places in the code where the program is in a unique position to verify the consistency of internal state. All three will not only help insure quality but also give you a leg up when you change your program's assumptions.

Each team must decide what mechanism to use for assertions. The assertions should be light weight and provide enough data when they are triggered so that developers can easily debug the problem. Most assertions can be active all of the time and should be. There are times in critical sections of code where assertion can greatly impact performance. In these cases, you may have to employ other techniques like turning on assertions during testing only and checking result around the performance-sensitive section at a place where the assertions will have less impact.

Because this only affects modified or new code, the incremental cost should not be great. Often assertions can be inserted in minutes per method.

The second technique is really a change to process around bug fixes. If you don't measure and analyze your bugs it is hard to avoid them in the future.

Root cause is easy to do. Don't allow anyone to close a bug without inserting a root cause. Have a fixed number of choice for why the failure occurred (e.g. requirements, design, coding, testing, deployment, other).

Once a month conduct a mortality conference where you review a rollup of causes and go through a representative sample of the bugs. This requires that someone do some statistical analysis to prepare for the meeting to identify frequent causes and commonalities for those bugs.

The next step is to establish changes that will stop those problems from occurring again. This may result in new processes or work.

The act of doing the root cause work has little overhead. As I carefully said above, this will not directly impact your schedules in a direct way. Clearly you may identify process changes or projects to address the root causes and take enough effort that might impact resources.

If you take the statistics, do the work and don't see the impact I guaranteed above, I will provide a free day of consulting to work with you to figure out how to achieve those results.

More later ...

Effective execution

Here is an interesting checklist that can help you determine how effectively and how efficiently your organization is executing. The answer can obviously scale by size the size of your organization. This list is not in any order and is by no means complete but it is a good start for any sized organization.

Are test developers separate from test executers?

Do code developers develop automated unit tests?

Is functional test greater than 70% complete against absolute best?

Is integration test greater than 70% complete against absolute best?

Are there clear owners for each release/project?

Do you have proposal phase?

Do you do a proposal phase actual signoff?

Do you have a definition phase?

Do you do a definition phase actual signoff?

Are there preliminary product requirements in the proposal phase?

Are there rough engineering estimates in the proposal phase?

Is there a target release date in the proposal phase?

Are there complete product requirements in the definition phase?

Is there preliminary engineering (functional/design) specifications in the definition phase?

Is a criteria document (beyond no critical bugs) defined in the definition phase?

Are there committed detailed schedules in definition phase?

Is the more than 90% of testing automated?

Can you do a full test cycle in less than 7 days (except duration)?

Can and do code developers run an automated test suite before checkin?

Is there a 12 hour representative test (full function, representative integration)?

Do you require full functional/design specifications before checkin?

Do you require full unit test pass before code complete?

Do you have predictable releases?

Do you require code reviews before checkin?

Do you do nightly builds and pass your 12 hour test?

Do you allow adequate time in integration achieve 90% of the criteria document before release?

Do changes in the release plan require signoff and revised schedules?

Do you have at least 75% confidence in all of your schedules?

The more of these questions you can answer "yes" to, the more effective your team will be.

More later ...

How can you create trust between engineering and management?

The software development industry is very much like a dysfunctional family. Executives don't trust that engineering will deliver what they say they will deliver and they don't trust it will be on time. Engineers think that executives set unreasonable goals and don't provide them with the resources to succeed. What can you do to engender trust as a manager?

Here are some basics:

• Be feature agnostic
• Be completely open about schedules
• Give executives some choices
• Provide information early about risks and their mitigation
• Provide non-confrontational opportunities for executives to interact with engineering
• Be responsible

Many engineering managers get very passionate about what should be in the product. Passion is good but you must set a boundary for yourself. It is product management's job to take input from the field, engineering, and competition and set priorities. If you appear in the slightest to be sandbagging or subverting in order to push your own agenda, you will lose trust. If you are objective, it is easier to gain trust.

Give all of your information to anyone who wants to see it including schedules and designs. Hiding information reduces trust. If someone does not like the plans your team has developed, have an open discussion. Get down into details. Remove the mystery. It will be painful at first, but people will gain trust over time. If someone wants to argue about the length of time for a particular item, stand your ground. They hired you for your expertise and if they cannot allow you to do your job, your company will have big issues and trust may not be possible.

Make sure you provide alternatives. Consider the following alternatives:

• Existing resources, normal work schedules
• Existing resources with extra effort
• Extra resources
• Phasing features
• Modified release dates

The point is to not come into your boss and say "This is the only thing we can do". Everyone knows there are always choices. If management knows you have looked at the possibilities, It will build trust and confidence in you and your team.

Make sure you are the one informing your management when there are risks. Do not go in and expose a risk without some plan to mitigate that risk. When your boss hears things about your group from others before they hear it from you, it reduces their trust in you and your team.

If the only time your team interacts with management, is when something is going wrong, then it will be hard for you to trust each other. Find informational, social, research and other reasons to meet and build a relationship between you, your team and the executives.

Finally, try to make sure your team meets it commitments. If they can't, take responsibility and make sure that you and your team are working as hard as possible to make it up.

There is a lot more to this, but the above items are a good start.

More later ...

Work Harder, Work Smarter, Skip Steps ...

Everywhere I have worked people ask me to have my teams work harder or work smarter. What does this mean and how can you do it?

Unfortunately, we as engineers sometimes translate the orders to work harder or smarter into skipping steps. I have been guilty of it myself. You find a piece of a project that needs to be re-architected in the middle or the end of development and you can face it or pray for a miracle. We have all been there.

However, each time we ignore the correct steps, we pay for it in the end. Either we don't make the dates, burn people out and lose them or incomplete or buggy products to the field.

You should employ smart people and you should employ smart processes. Take the time to do requirements documents, specifications and code reviews. Take the time to get sign-off from all of the stakeholders. Take the time to do it again if things change.

Don't get me wrong, you should challenge your teams to get it right the first and you should challenge them to meet their commitments. You should challenge everyone to act as a team and pitch in when things go wrong. Just don't throw out the baby with the bath water. The fun part of software is coding something and seeing it work. The rest of the stuff I mentioned above is like brushing your teeth or paying taxes. Only your leadership will insure the hard parts get done.

The smartest way to work is to take the time to do good engineering. The effort you and your team will need to employ will differ from project to project and company to company. Take the time to figure out what you need and then help your teams accomplish their tasks and hold them accountable.

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 ...

Does your team have a sense of urgency?

Does your staff drive action items or do they let them happen? Do you have to check on action items you have assigned or does your staff update you on a regular basis? Do projects slip because your staff waited to follow up on action items?

I get astounded all the time by people who do not follow up on critical action items in a timely fashion. Some people do not have a sense of priority. Some people do not have a sense of how much time they will lose if they just let events play out. Some people just to not have the drive to follow through quickly.

You and your teams can easily slip products days or weeks or months without a sense of urgency.

Recently I was involved in a project that was coming to the end of an integration cycle. I was getting status on a Friday morning. I was told that one bug may have an unbounded solution. The manager went on to say that he thought he would get people together that afternoon to discuss it. I said no that we would meet in 10 minutes. If we had not met, then we would have lost at least one half week. By meeting immediately, developers had time to research solutions before the weekend and begin the work. These kind of issues occur everyday.

Here are things I know to do to help this issue:

• Hire people with a sense of urgency
• Set expectations about action items
• Spend time communicating to your group about urgency
• Hold people accountable for being late
• Developing a team with a sense of urgency will, many times, make the difference between success and failure.

More later ...

Is your team working hard enough?

Do you dictate fixed working hours? How do you compare work ethics? What can you do if you are behind?

Every company I have ever been in has worried that the development teams were not working hard enough.

The first thing you must do is decide what kind of work ethic you want in your team or company. Do not think this will happen by magic. Actually sit down and discuss it. Write it down.

Next you need to communicate it to your team. If you have a team in place, expect some fallout. Face it honestly "I know up until now we have had a different set of rules, but now we need to set down some new rules. I understand if this is not what you signed up for and we will help you transition if it is not right for you ..." Having disgruntled employees is worse than replacing some. Obviously job markets, critical company timing and other factor must be taken into account.

You need to be clear to anyone you interview about what the team's rules are.

I have known some companies to dictate 12 hour days, 6-7 day working weeks or fixed hours. There are lots of great examples of successful companies that have aggressive rules and demands. I am not saying one is right or wrong. The important thing is that you make it clear what you want from your employees.

Personally, I like to build teams for the long run. I want to set goals that are aggressive but accomplishable. I want my teams to only work the 60+ hour weeks 2-4 times a year for periods of no longer than a month at a time.

I find that the average age in the industry is a little higher than when I started out and I find that more people have families. I want employees to have balance. I want them fresh the next time I need them for a crisis. I want them to have enough outside interests so that if the company is having issues, the company is not the only thing of importance in their worlds.

When I run an organization, it is schedule driven. For me, the important thing is that we accomplish our tasks in an aggressive and predictable fashion. I care more about function than form. I expect employees to develop their own schedules. From there it is a means test. If a developer is running behind I expect them to work harder. During integration times I expect them to work harder. It is good for employees to know when they can go home at the end of the week. See My blog entries on schedules and what "Done" means.

My final words here are about accountability. Make sure your employees understand how they will be held accountable. Make sure consequences are in fact applied.

By being clear you can get the team you want.

More later ...