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

Hire Interns Today!

Do you have reduced budgets? Are you getting pressure to offshore work? Are you restricted from hiring full-time employees? Consider hiring interns.

In tough financial times, it can be very hard for new college graduates to find employment. I have been very successful at both helping new college graduates get training and get a foot in the door as well as helping companies get more affordable help and have a chance to qualify future employees.

Here are some tips in using interns:

• Look at graduates from non-name schools with degrees in the areas you need
• Find people with good attitudes and good communication skills
• Don't do long interview cycles
• Find a contract house that will manage their employment
• Free up more senior full-time staff from doing ineffective tasks
• Expect to spend some time training
• Hire a group at one time

In tough times, employers hiring full-time employees often pick employees with the best pedigrees. There are a lot of great candidates with great skills that went to lesser known schools. I often find candidates through referrals from someone who knows a graduate working at a local gym or restaurant. The candidate much rather be working in a job that will provide them with experience pertinent to their long-term goals.

I typically will interview candidates for at most 30 minutes on the telephone before making them an offer. You cannot expect them to have great expertise in your product. The idea is that you will train them. I most screen for basic knowledge (tell me about a college project) and I screen for attitude and communication skills. You should know fairly quickly if they will be effective and you will not risk much if you learn there is not a match after a month.

I tend to find these interns through referrals but have them managed through a contract house because they are not full-time and they have already graduated from school (so it is not a co-op). Reputable contract houses can provide low end management including paying employer contributions and workman's comp for about 25% overhead. Many also will provide the employee with the ability to purchase their own healthcare.

You should be able to have the interns target work that frees up senior full-time employees to work on projects that require their experience and skill. While you will have to train the interns, a little investment will go a long way. Try to hire them in groups so you can train many at one time thereby lowering the overhead. In the end I have hired many of the interns for full-time employment at the end of 6-12 months.

This will be a win-win for the intern and for your company.

More later ...

How should you measure engineering?

One of the common questions I get asked is how should you measure engineering. It is a loaded question. Usually there are personal biases and long painful experience that color the question. However, the sentiment of the question is correct. If we do not measure ourselves we cannot get better.

The common industry term for these measure are Key Performance Indicators (KPIs). As a general guideline, I like these to be simple and easy to measure.

The following three questions are important to the business, can give you an idea about how we are doing and have answers that are reasonably easy to measure:

• How productive is engineering?
• How good is the quality?
• How quickly can we respond to customer problems?

The first two are solely engineering measures and the third is a joint measure with support.

You can easily measure engineering productivity by measuring the number of features that engineering releases to customers per quarter. In order to create this measure, you need to have a common denomination or coin of the realm to normalize the size of projects. You can classify your projects into small, medium, large and extra large where you can size those project sizes and provide some basic equivalences. For example:

• Small - less than 1 development week effort == 1/3 medium project
• Medium - less than 1 month of development effort
• Large - less than 3 months of development effort == 3 medium projects
• Extra Large - greater than 3 months of development == 9 medium projects

You could clearly make the measurements exact but this method also provides a normalization that both reflects the impact of larger projects by virtue of rounding up and removes anomalies by capping the translation. This measure will have a direct effect on the company's ability to compete and to manage costs.

You can measure quality by how many bugs need to be fixed in patches per quarter and in the next release per quarter. The idea here is that it does not matter what the company marks as the priority or severity of a bug. Instead if the company requires the bug get fixed in a patch or release, then for whatever reason engineering had to expend resources to fix the bug. Quality then becomes about addressing issues earlier and removing the need for the company to spend resources after software has been released. This measure will have a direct impact on customer satisfaction and engineering productivity.

Finally, we all know that there will be critical problems that we cannot foresee that the company must address. It is important that the company reduce the time for customer relief for critical bugs and measure it at least quarterly. The fix could be a work around developed solely by customer support or a complex engineering based fix and therefore this is a joint measure. Efforts like customer training, robust error-logging, and code assertions can help reduce time-to-relief. This measure will have a direct impact on customer satisfaction.

If you don't measure you cannot get better.

More later ...

What is the role of a manager?

Opinions vary on a manager's role from writing code to ordering dinner. I tend to like my managers to be technically trained and competent individuals who have learned they can be more effective helping many people succeed. I have talked about what makes a good manager in other posts but what should they actually do in the organization? Here are the basics:

• Planning
• Hiring
• Employee development
• Execution

Managers help their bosses and their employees plan. This includes budgets, resource capacity planning for projects, schedules, etc. Expect that this is an ongoing task and will take a good percentage of time. In a fast-paced industry things change quickly from customer requirements to found opportunities. Managers must learn to hone their accuracy and deliver estimates quickly.

Once a budget is set, the most important thing a manager can do is hire. Without people they cannot accomplish the tasks at hand. This must be a concerted effort that managers spend time each day doing. From screening candidates to shepherding the process to setting expectations of interviewers and approvers. This can be daunting but is a cornerstone to any company's success.

People development is often overlooked. We cannot expect that all people who come to work for us were born with all the skills and knowledge they need. Nor can we assume they acquired the skills or knowledge in school or previous employment. Employees need both technical and soft skills. There may be times when you can find a class for an employee to take to build skills but managers should be capable and interested in direct mentoring both technical and soft skills.

Finally we get to execution. Execution will dictate company success. All of the other items discussed above are necessary but not sufficient to execute well. In addition, managers must monitor schedules, manage dependencies and troubleshoot issues. This is the day to day management of a team developing a project. You must not lose sight of this activity while doing planning for the next big thing. Managers should represent and be held accountable for his or her team's deliverables. Deliver with quality. Deliver ontime.

With enough managers capable of the above the tasks, your company can achieve its goals and success!

More later ...

What is the role of an architect in software development?

Everyone has to do architecture work to develop and maintain good software products. How do architects fit into the process? What should their responsibilities be for architecting features or products? How much responsibility do they have around product direction? What impact should they have with regards to development processes?

As with many roles, you are best served by defining clear boundaries around what architects should do. It is easy to imagine turf wars between architects and a number of other constituencies including developers, managers and product managers.

Here are the three basic areas that architects should own:

• Architectural roadmaps
• Architectural specifications
• Developer processes and best practices

The architectural roadmap is the first place architects feed into the process. These roadmaps should feed into product management just like other requirements including those from customers, sales, standards, competition, etc. The format can easily follow similar strategic documents I have proposed in the past:

• Taxonomy - what is important in a particular areas
• Report Card - how the product does in that area
• Today picture - a visual representation of what the area looks like today
• Tomorrow picture - a visual representation of what the area could look like
• Projects/Tasks - a list of what must be done to actualize the tomorrow picture

The areas might include discreet technologies like storage or networking or they may reflect attributes like quality, usability or performance. The architects should develop roadmaps for each area that constitutes a value proposition for the customer.

The second place architectural oversight is necessary is around specifications. This process should occur after requirements are available from product management but before engineers develop design specifications and schedules. The architects should have unique insight into the overall product and develop these specifications as a leg-up for engineering.

Architectural specifications should include the following:

• Refined requirements - embellishing product management requirements based on the architects broader and more detailed view of the technology and product.
• Investigation items - these should be resolved before a specification or schedule are approved
• Architectural requirements - these must be addressed in any design or development
• Excluded items - these should not be included in the project

This makes the architects the bridge between product management and engineering and provides direction and guidance instead of a blank sheet of paper for engineering. The result should be more consistent products that meet broader goals including interface integrity, performance, quality, etc.

Finally the last place the architects should play a role is in the specification and oversight of development processes. This includes:

• Developing a design/functional specification template and process
• Developing the guidelines and process for code reviews
• Specifying coding conventions and tool selection

The processes should have oversight from the architects. For example, they should get to approve who the reviewers should be for code reviews. Do not mistake this item with saying that the architects must do all the specifications or reviews. They should delegate but retain oversight and they should be accountable. If architects end up doing all of the detailed pieces, developers will resent them and you will not make efficient use of both the architect's and developer's skills.

All of the above items could be distributed throughout an organization but they are usually assigned to senior members of the team and often designated as architects. The important thing is that these tasks must get done and you should make it clear who is responsible for getting them done.

Make your architects more successful and your team will be more successful.

More later ...

Planning

People ask me about Agile and other project planning methods in high tech today. What I tell them is that all tools can be used well or poorly. It takes leadership, forethought, common sense and perseverance to plan and follow through on a project.

Many managers do incomplete jobs at planning, or they do not manage the plan once it is developed, or they do not handle change appropriately. Each of these mistakes will affect predictability. I have seen some organizations that embrace some of these techniques as a facade for "it will get done when it gets done". The problem is that your CFO, VP of Sales and customers cannot plan appropriately in that kind of environment. Your company needs predictability in order to succeed.

I am a lot less interested in the form you use to plan than the functionality. All of these techniques can be applied using almost any method. Here are some basics:

• Do not commit to a date until you have preliminary specifications and detailed schedules
• Make sure every stakeholder physically signs off at each phase
• Adopt a train model
• Don't make top-down dates
• Complex projects require very detailed planning that will change
• Manage each slip with urgency and importance
• Deal with major changes as if you were starting anew

I have talked many times about the proposal and definition phases of a project. You cannot have predictability without specifications. Those specifications must be good enough to ensure you hare heading in the correct architectural and product direction. They must also be good enough to create schedules. The schedules must prove that you can make the target date. You must work with the information you have at the time and understand that it will change. The schedules should be manageable (< 2 week tasks, measurable deliverables, etc.).

Don't assume that verbal or incidental communication is enough to get buy-in from your company. Get a signoff sheet for each phase in writing. Make sure development, QA, docs, architects, sales(customers), support, and the CEO are all in the loop. It is awful to find out after you have spent money on developing something that you have done the wrong thing.

Feature driven releases often slip. If a major feature slips and the release slips, then there is pressure to add more features since it will be a while until the next release. Adding late features can cause more integration work and potentially more slip or worse yet cause quality problems. Separate features out from releases. Make releases time based with a shorter cycle (3 months). With a time based release, the features that are ready can go out. Big features can be developed independently. You can respond to customer needs more quickly. The train model requires adequate automated testing to be successful in order to reduce the overhead of more frequent releases.

Top down dates don't work. Schedules must be bottoms up. Managers must help there teams make aggressive but accomplishable schedules. Managers must help make trade-offs around function, quality and resources and have substantive business discussion to achieve the right balance. Don't commit until everyone on your team can look you in the eye and commit. This is a pay-me-now or pay-me-later issue. It is more than a burn-out issue. It is again about predictability.

Complex projects need detailed schedules. Even if they go out two years. Schedule re-scheduling events for long projects. If you use Agile, you can translate detailed schedules into sprints but you still need the homework upfront. You need the exercises to get predictability. The schedule is really a step-by-step design. It makes your developers think. It allows your team to identify many dependencies and resource issues upfront. It will change -- get over it. There is no free lunch. You cannot have predictability with coarse grain tasks. You cannot have predictability without having your best guess at the details upfront.

You need to manage the plan. Most slips start from day one of the schedule. Require your team to have at most two tasks open per person at one time as they accumulate risk (this may require scaffolding). Require that each slip have a mitigation plan on a weekly basis. Do not shove all delays into a bucket to be dealt with later. Your team needs to adjust quickly to issues.

Finally, if you have major changes including features additions or architectural surprises, you need to go back into a planning phase. Never assume you can just add it on. Do the resource planning, specifications and schedules. Do new signoffs. Anything less will affect predictability and cause slips.

We all face these issues. True leadership in planning is the foundation for success for your team.

More later ...

What are good goals for testing?

Sadly, software testing has not become a prestigious endeavor in our industry. In ASIC design, for example, the test verification folks often are paid the most and lead the teams. In software, test development and test execution are often looked at as stepping stones to product development. As a result, test development has developed a stigma and is often done as an afterthought and often not pursued by the best engineers.

Without reasonable tests and test infrastructure, your company will spend a lot of time and effort doing manual testing at each patch or release. You may not be able to respond to customer requirements in a competitive fashion. The worst result may be inflicting poor software on your customers and having them find your bugs while you lose your reputation.

So how can you set good goals and get better results in your testing effort? Here are the basics:

• Make sure everyone feels responsible for quality
• Define detailed acceptance criteria that drives what you test
• Invest in infrastructure for testing
• Drive toward specific goals around automation and responsiveness

I have talked about many of these issues both in the book and in other blogs but I will summarize them here as a reminder.

Everyone needs to feel responsible for quality. From the developer who should produce automated exhaustive functional unit tests to the project or release owner who should drive quality across many functional areas, everyone should feel responsible. Break down the organizational walls. Treat quality like performance or reliability and bring to bear the resources you need to make it happen. Don't differentiate between a development specification and a test specification -- make them one document. Send a message that there is only one thing and that is a quality product for your customers. Send a message that there is only one team and everyone must work together to achieve quality.

Don't let acceptance of a project or product only be that it contains no critical bugs. That measure is a second order measure. Define the parametrics for the product around performance, durability, interoperability, compatibility, usability, etc.. Decide on those things together with all of your developers and product management. Use those criteria along with exhaustive functional unit tests to drive the test portion of your specifications. Make sure you identify real customer scenarios as a basis for the tests. Finally, measure, measure, measure the results in both your schedule as the tests are completed and in your integration as more of the tests are deployed. Do not hide these details behind test points. Expose them in highly visible presentations. Make sure everyone can see what is important to the team with respect to determining progress and whether the project or product is done.

I hate the word framework. It is used to denote a lot of things and does not communicate what work is actually being done. Testing frameworks fall into this grouping for me. So what infrastructure needs to be in place for people to actually develop automated tests? Here is a list of the basics:

• Tools to setup and knockdown a test. These may include tools that can reboot or reinitialize test platforms and/or test drivers automatically. They may include setting up a configuration or data set. Clearly how fast they work is a factor.
• A programmatic interface to the test platform. This may be through a CLI, scripting language or API. It must work remotely. It must control as much of the product as possible in order to test as much as possible. Avoid doing this through the GUI as test vehicles that go through the GUI are often hard to maintain.
• A standard output format. Define what you need for summary and detailed information. If every test produces different output formats or worse undecipherable output formats, you will spend an enormous effort in trying to figure out what is working and what is not.

Obviously there are always more items that you may need for a particular product or environment but your list should always include the items listed above.

The last thing you should do is set goals around automation and responsiveness. How much effort should it take to test a patch or a release? How much elapsed time should it take to test a patch or a release? By its nature, the last question will affect the answer to the first question (i.e. with a limited amounted of time you will need to automate more and it will reduce the effort). So here are my rules of thumb for elapsed time:

• For a patch you need to be able to broadly but not deeply test your whole product within 12 hours.
• For a release you need to be able to test your whole product broadly and deeply within 7 days (excluding duration tests for obvious reasons).

The patch level test is often also used on nightly builds during a development cycle.

Obviously your goals should be to reduce the effort for both kinds of test cycles as low as possible. However, there will always be a manual component to verify that GUIs look right.

If you follow the guidelines above you can set better goals around testing and achieve better results for your team and your company.

More later ...

Compartmentalization

You and your team must do the best job they can. You cannot do everyone else's job. If everyone did a good job at their own tasks, the company would succeed. So what do you if someone or some team in the company is not doing what needs to be done?

Obviously you must try and determine how big an issue it is for the company. If the company will absolutely fail then speak up loudly. Otherwise it enters an interesting realm. Do you let mistakes happen? Do you try to do everything? How do you provide input? How far do you go?

I will admit that I have parted ways with companies over this very issue. I have a strong belief in doing my job well and have my team do its job well. I believe I can provide input to other teams but they have to make their own way. I do not believe I or my team could or should try to do other team's jobs. Sometimes this will result in failures (again temper this by the scope of the item) and it is ok. Sometimes failures result in fixing problems at a more fundamental level.

One metaphor is baseball. If some player is doing a poor job, another player cannot do their job because that will cause failure in their position. While some player's jobs overlap, it would be hard and confusing and ultimately cause failure. The manager must replace or train poor players to be effective and successful. Companies are the same way. Each team must do their job. A manager must train or replace unsuccessful people and teams. Do not expect another team to drive or cover for a poor performing team and not impact the original team's responsibilities.

This comes down to clear responsibilities and accountability. Make it clear who owns what tasks. Hold them accountable. Do not reward others for overrunning a team that is not successful without direction to do so. But make sure there are opportunities for anyone to bring issues to light on anything and create mechanisms to follow up on issues.

Make sure there is a single owner for cross-group projects. Hold them accountable.

If everyone is successful on their projects, your company will be successful.

More later ...

How late should you allow changes in a release?

This entry is about the very end of a release. I have talked about the whole end-game in a previous posting but this period warrants more discussion. There are always more bugs to fix. Sometimes this pressure comes from engineering trying to perfect a release and sometimes from product management trying to help out one more customers or avoid a service call. Either way I suggest you avoid a lot of changes down the end of a release.

There should always be a quiet period before a release where only bugs that would stop shipment and cause an immediate patch of a production release should get fixed. Clearly the length of this period will vary with the size of release or the maturity of a company. But the period should not be less time than a full run of testing (which should be set to take 7 or less days).

In this period, any bugfix is as likely to cause more problems as fix problems. People like to minimize the impact of changes in this period but my experience does not support that position. I have seen slips due to innocuous changes.

If you have not met your bug goals or you have not completed testing do not enter this period because you will need to fix bugs that are not appropriate for this period. Do not assume you can fix a lot of bugs and keep the release stable.

So what can you do to manage this period:

• Show leadership
• Plan a patch release shortly after your release as a vehicle to handle critical non-showstopper bugs.
• Get involved in the bug reviews yourself
• Do not start new testing that has not been performed before in the cycle

Managing this period well will improve your company's and group's predictability which will in turn enhance your chances for success.

More later ...

How can you train managers on an ongoing basis?

You may ask your staff to accomplish a task like schedules, replan, review, or budgets and it does not get done. They make a commitment for a new date and it comes and goes without success. What should you do? Do you admonish them? Do you fire them? Do you train them? This entry concerns the last question.

Clearly it is unacceptable for your employees to miss delivery dates. Make sure they know they are accountable have to inform you early about potential misses. But you need to look at the root cause. Some employees may not have competence and you should manage them appropriately but others just have not been trained.

We know that most managers in engineering have not had management training. Part of your job as a manager is to train them. Take the time and have patience. Do not be surprised if employees with big titles are missing some key skills. Train them and they will not only be more productive but they will learn how to train their own staffs.

Here are the basics for a missed task:

• Set a new deadline for a task.
• Notify your employee that if they miss the new date, then you will work on it together.
• If they miss the task, call a meeting and allocate enough time to complete the task together.

I often use the term "lock the doors until it is done". Then you have to complete the task together. Like any other learning situation you have to be careful to not do the work yourself but you need to be in the room and guide the task until completion.

Once employees learn about this method, you can tell them they can ask for this help before they miss a deadline. Be open and generous in the process. If they feel like they are being punished, you may not get what you want out of the process.

You certainly should explore training classes for employees as a proactive tactic to minimize some of the need for this technique but you should still expect to do this kind of training.

Create a learning atmosphere and your team will learn how to succeed.

More later ...

Follow up!

This is common sense to some and not to others. In any interaction you have with your team, peers, boss and customers, you must follow up. This is one of the great differentiators between junior and senior managers and between those you can depend on for results and those you cannot.

Many times people avoid following up because they have incomplete results. Get comfortable with intermediate status. Inform people often. If you get asked about an action, then you should probably have considered providing status or information without having had to be asked.

Other times people avoid following up because of conflict avoidance. Maybe you didn't meet expectations or you do not see a way to close an action item or you think the item is not worth working on. I suggest you address it before it becomes an issue. Reset expectations, ask for help, or discuss the usefulness but don't let it go unaddressed.

Teach your employees about what you expect. Keep an action item list from your meetings with meaningful deliverables and due dates. Tell your folks how frequently you expect status on items. Follow through with them. Mentor them. Hold them accountable.

Similarly, be proactive with your own list of items you must follow up on. Actually keep a list and manage it. In larger organizations, use a program manager to help manage it. Strive to never have anyone have to ask you where things are at on an item.

Note that you may have to learn how to interact with various people. Even though others may not be explicit about how frequently they want status, you need to adapt. There are lots of ways to communicate including email, websites, phone calls, and dropping by in person. Find out what works best and is appropriate for colleagues versus bosses, etc.

If you follow up you will become more valuable to your company and reduce stress in your job. If you can help your team to learn how to follow up you will surely make them and your company more successful.

More later ...

Code reviews

In this new millennium there are certain activities that are just good hygiene. Code reviews are one of those activities. In addition it is the quintessential poster child for how managers should make changes to development processes. I will tackle both in the following paragraphs.

As I have said in numerous writings, managers must drive change with requirements and not dictate implementation details. Managers must find a way to empower and drive engineers to accomplish all of the tasks they need to do and not just the ones they consider to be fun. Many engineers consider any process to painful and bureaucratic. The best way I have discovered to overcome these issues is to delegate the definition and monitoring of development processes to engineers. Avoid having managers dictate and drive development processes.

My favorite way to delegate processes that affect all of engineering is to establish an engineering leadership team (ELT) to represent engineering. You must populate this team with people who are not process zealots. The members must be representative and respected. Make it clear they they will not do all the code reviews. Instead they will define the process and monitor it. Make sure you allocate real time for people to spend on this. Hold them accountable. Make sure they do not take forever to do it.

Once you have the ELT in place, it is your job to give them requirements and guidance. Often I will hand the team examples of what I have seen done elsewhere as a starting point. Then my management team will give them requirements. Here are some of the requirements I might set for code reviews:

• One process across engineering including QA
• Actions must be tracked
• Code reviews and addressing the resulting critical actions must occur before other internal and external people get exposed to the code
• Code reviews must be done in a timely manner
• A checklist with a minimum amount of what needs review must be developed to engender consistency and help junior member participate
• Code review results must be documented
• Need to have a fast track process for small things

Stay away from things that are not requirements. For example, I will not say what items must be checked or what timely means. That is for the ELT to decide.

I would give the team a week or two at maximum to define the process and roll it out. I would set goals with my management team about compliance and any transition needed. I would communicate how important this is to the whole team and ask them to be proud and not defensive.

Also be careful about tools. Many engineers would rather spend their time implementing a tool to facilitate a process like code reviews before your team decides what they want. Decide first and then if appropriate find or develop a tool to help.

Measure the results like how many features and/or bugs got code reviewed relative to the total, how many critical bugs were found, and how many total bugs were found.

Make this a priority and you and your team will reap benefits.

More later ..

Thank someone each day

Recognition for what we do each day comes rarely. Many of us were brought up in homes that neither gave recognition nor modeled receiving recognition well. Recognition improves job satisfaction, encourages open communication, and reinforces good behavior.

I remember hearing a wonderful story on NPR a number of years ago about an author who had suffered from mental illness and was institutionalized in her youth. Now, many years later, she recalled an anecdote that epitomizes this topic. She had been in a communal area and heard one of the doctors calling on the phone to the maintenance department and asking "Who cleaned my office today?" She had assumed she was about to hear this doctor chide someone for inferior work. Instead, when the doctor had gotten his answer, he went on to say "Well he cleaned my office better than it has ever been cleaned, please thank him for me." The author was blown away.

You too can blow away an employee by taking the time to recognize them. It does not have to be a big public thing.

Here are some basics:

• Learn the facts (correctly pronounced named, the details of what they did)
• Go to them and do not make them come to you to thank them
• Do not mix the message with something they need to improve on (you can send that message another time)
• Find someone to thank each day
• Be sincere

Often, without recognition, employees will not feel valued or just equate good work with compensation. Neither of these outcomes are desirable. Create a culture of gratitude and it will be easier for your employees to go the extra mile for you and your company.

In this spirit, I would like to thank a number of people who have helped over time with this blog:

• LeeAundra Temescue who created my website and the accompanying look and feel for the blog (http://www.thecontrarypublicspeaker.com/).
• Bill Grosso (http://www.wgrosso.com/), Joe Strazzere (http://www.sqablogs.com/jstrazzere/), and Paul Brown (http://mult.ifario.us/) for their kind words about the blog and the book.
• My mom, Sandra Himelstein, who periodically gets on here and attempts to correct my spelling and grammar.

Be thankful and lead a better life and a better company.

More later ...

How should you manage bugs?

Managing bugs is difficult. Often bugs become a battleground within a company. Questions like which bugs to fix when or what amount of bugs is ok to ship a release with becomes unclear and divisive. It take a little process and a lot of leadership to address bug management.

Here are the basics:

• Improve quality so you do not have as many bugs
• Provide clear direction on what bugs to fix
• Track and forecast the trend and effort to meet your goals

We know that we are not perfect developers but there are some good hygiene things that all companies should adopt in order to improve quality:

• Do feature/design specifications and reviews
• Do code reviews
• Require automated passing exhaustive feature unit tests before code complete
• Determine and review root cause for bugs

It will always be better to catch bugs early or better yet never create them. You should pay attention to why bugs occur and help your organization address those reasons. One of the big issues in many companies is how to prioritize bugs. The first problem stems from ambiguous categories like priority described with P1, P2, P3, ... and the plethora of other categories like severity, customer priority, etc. While your company many need to gather the emotion and need of your customer regarding a bug, the only thing your engineers should care about is when to fix a bug. Here are my suggested categories:

• Now (either for a patch or release build)
• Must fix for a particular release
• Should fix for a particular release Future

Don't confuse your engineers with overloaded codes. Make sure that bug backlogs that "must be fixed" for a released are legitimately scheduled and are not expected to be addressed in someone's overhead or free time. Make sure product management prioritizes the bugs in the must-fix categories appropriately and that you have resources allocated to fix them.

Finally, as I said in a previous blog, you need to track the trend of bugs. If your incoming rate does not go down, it does not matter how many bugs you have fixed, you will not have a stable release. Set an outstanding bug goal for your release acceptance criteria. Forecast when you get down to the bug goal for the release and manage to the forecast. Remember that there is always a tail and if you do not defer some bugs for the next release at the end of the cycle, you may never close on the current release. Bugs are tough. Pay attention and make your products quality products.

More later ...

Process is not a substitute for leadership

When an organization is facing challenges around meeting their commitments, hiring goals, retention goals, and quality goals it is often suggested that teams improve their processes. While I have seldom seen teams succeed without processes, I have seen numerous teams fail with them. In my mind they are required but they are not sufficient. In the end, competent and courageous leadership will win the day.

I think the reason why many organizations try to use process to dig their way out of problems is because they are black and white tangible items. They might include well defined and documented phase sign-off, detailed schedules and real acceptance criteria. However, if these processes do not have useful content or the leaders do not make timely decisions or allow constant change, then it is easy for the processes to become lip service.

So what makes a good leader? Here are some basics:

• Communication
• Sense of urgency
• Empowerment

See my recent article in Dr. Dobbs about what makes a good manager at http://www.ddj.com/dept/architect/187203587 for more details.

Here are some basics that you might employ to resolve the leadership gaps in your organization:

• Make decisions in a timely fashion
• Assign meeting action items with delivery dates
• Communicate where your team is headed and why on a regular basis
• Measure your progress and make changes where necessary
• Empower your employees (make it clear what they get to do and let them do it)
• Respond to your employees (respond to emails, questions, etc)
• Treat your employees with respect

Don't get me wrong processes are wonderful things but they are tools. Take the time and interest in leading your team and your processes can be an great ally.

More later ...

Ink has power!

Do you ever have people second guess why you defined the content of a release even though they were in approval chain through email? Do you ever have people complain about the quality of a release when they forced you to send it out early after you told them there were issues? Do people forget about the effect of last-minute features they ask you to implement? You may want to consider old-fashioned ink-signature sign-off sheets for the phases of your product lifecycle.

People often forget casual conversations in person or through email but they do not often forget when they are asked to sign a document. The act of signing has power. In a world where misstatements and fraud are more closely scrutinized than ever before with the Sarbanes-Oxley Act, more executives pay attention to what they sign. Even without this government oversight, many people take the time to examine a document which will contain their signature. The same is true with sign-off sheets. Here are the basics:

• Identify the stakeholders (the higher up the better)
• Provide an executive summary with the salient information
• Provide object information
• Hold up progress until you get a signature

One key to the success of a signature process is to identify the people who are the largest stakeholders. In most companies this includes engineering, product management, sales and support. Try to keep the number of people to sign at a minimum but do not scrimp either. Pick executives with the big picture and big responsibilities -- first line managers or even directors are probably not the right level. Figure out some way (faxes work fine) to have the signature process not bog down due to peoples travel or meeting schedules. Provide a meeting time in case the stakeholders want more information about what they are signing.

You must distill the information into easy to understand pieces and consequence. For example "Waived 50% of bugs that are required to be fixed by criteria and this may result in customer failures and reputation issues." Even better if you can color code critical issues with a red background. Provide layers of information attached to the sign-off sheet so that stakeholders can drill down if they wish.

Many times executives ask how people "feel" about a phase or release. I feel this is inappropriate because it is subjective, inaccurate and often causes significant disagreements between groups. Take a look at the criteria section in my book 100 Questions to Ask your Software Organization for more information on how to objectively qualify releases.

Finally stick to your guns. Often the real discussions do not occur until you require real signatures. If you forgo the process, you will be forgoing the real discussions. A great example of this is that sales teams often complain about what goes in or is left out of a release even after product management has collected their input and closed the loop with them. I have had success in getting to the real discussion because the sales vice president will not sign off.

Ink has power and will help your company make better informed decisions.

More later ...

How can you reduce iterations in your integration cycle?

Do you have volatile integration cycles where many of the builds are not even testable? As a result are you wasting QA effort? Do you end up extending your integration cycle or worse yet release product that has not met your quality goals?

This problem is very common. It does not matter what you call the cycle (Alpha, pre-alpha, Beta, etc.), the impact of entering this period with broken software is profound. You may say that is exactly what this period is for and I will respond that I suggest there is a better way.

Today many organizations complete development and handoff their code to QA for test development and testing. QA must test three things: new feature tests, regression tests and system end-to-end tests. New feature tests will test features that are new to this release, regression tests should test the existing functionality and previous bug fixes, and system end-to-end tests include interoperability, configuration, stress and performance testing.

In my experience, most problems arise from new features. This makes sense because this is where the changes are made. It gets worse if a new feature changes underlying infrastructure or affects a broad cross-section of the product. Often teams endure build after build during an integration cycle to overcome the effects of new features and get to the point where they can find out about regression and system end-to-end tests.

So what can you do? The answer is a very simple concept but will take leadership courage to change. The answer is to move new feature testing and bugfixing before the QA handoff. The answer is to actually use your integration period for integration and not unit correctness.

The new feature's tests should be automated and integrated into the regression test suite before QA handoff. In addition any bugs that you fix to release the new feature to customers should be fixed before QA handoff.

The result will be a more effective integration cycle. The result will be a longer development cycle. This may appear as just a longer overall cycle for a release but in my experience it reduces the overall time for a release and insures better quality. It will also reduce frustration of your team in having to integrate a set of partially working new features.

This dovetails nicely into a train release model as well. No new feature can get onto a train unless it has complete automated tests and bugs fixed.

Philosophically this goes back to the definition of done I spoke of in a previous blog (http://heavenstone.typepad.com/heavenstone_inc/2005/10/index.html). It gets the whole team thinking about moving quality earlier into the development cycle. Because it makes completeness more self-contained within a project, this method can help managers work with employees on areas like ownership and accountability.

Try this and watch your teams be more successful.

More later ...

How do you do capacity planning?

The biggest issue that most development organizations face is deciding what projects to do and what projects not to do. A large part of this process is doing resource capacity planning. It is relatively straightforward and easy to do but is often overlooked.

So here are the basics:

• Determine the projects you want to consider
• Roughly size the effort per first line group per month
• Treat bugs and other overhead issues as projects
• Make priority decisions

The majority of the list of projects comes from product management. They collect requirements from multiple sources including standards, customers, sales, etc. Make sure these stay at the functional level. The projects should be complete solutions you deliver to customers or internal infrastructure projects. Stay away from listing components of a solution as projects otherwise you stand to not invest in all of the pieces that are required to deliver real functionality to customers.

You need to make rough estimates for the identified projects by group by month. This will let you know (or get close to knowing) whether you have the right skillsets to accomplish the projects. Check out the blog entries on schedules to see how to come up with numbers. Limit the time people spend on the rough sizing (do not go and create full schedules). You will build this skill iteratively. Set your sites on being aggressive but accomplishable.

Teams get in trouble by not legitimizing the time they spend on items like bug fixing, estimating, standards committees, vacation, etc. You should make the bigger efforts like bugfixing actual projects. You can create a miscellaneous or overhead bucket for smaller items. Allocate real time for these projects.

Once you have the data, you have to make some decisions. Do not allocate much more that 100% of your capacity (and less if possible) because you will run into unknowns and you need some flexibility. You can run people harder for short amounts of time but it is ineffective to do so for long periods of time. You must learn how to say no to some projects. Pick fewer items and spend more on them and finish them as opposed to work on lots of things at the same time -- context switches are expensive and you should attempt to not have people work on many projects simultaneously. Have a strict ordering for projects and releases so your team knows how to make tradeoffs.

Without planning your team will get frustrated and your customers will lose confidence. So plan and gain confidence of your team and customers!

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 employers and employees determine if a job is right for a person?

We seem to be heading into an upswing in hiring again. Recruiters fees are going up and it is becoming an employee's market. If an employer is going to pay more money for an employee, it is a great time to figure out if they are the right employee. It is also a wonderful time for employees to figure out what makes them happy in a job. Getting down to motivations help both sides do a better job.

I have had a number of jobs in my career and I know what the basics are that make me happy. When I was developing my list in early job seeking adventures, I had a long time friend and mentor, Larry Weber, tell me to make a spreadsheet where the rows were the items I thought were important and the columns were job opportunities. I graded on a scale of 1 to 10 where ten was the best. After I had completed that task, he asked me to weight the rows by grading how important each row was on a scale of 1 to 10. I then used this weight as a multiplication factor for the cells in a row. The total was my overall number.

What happened for me was that I discarded obvious mismatches and was usually left with a couple of choice that were close. The important part of the exercise is to think about your job in an analytical way and to determine some amount eHarmony-esque compatibility.

The items that always end up on the top of my list are:

• Is the job interesting?
• Do I like the person I will be working for?
• Do I feel that both me and the company have a reasonable chance for success?
• Do I feel I will be fairly compensated?
• Is it a short commute?

I clearly have a longer list of less important items and some of the above items are multi-faceted (e.g. interesting equates to technical, management and business challenges). My list clearly includes some objective and subjective items. It has helped me in my decision process.

So what does all this mean for the employer? When hiring it is common to mistakenly hire the wrong person. Often interviews do not reveal enough issues or they do highlight how a known issue with a candidate might play out in your environment. I plan on a 5% failure rate on ongoing hiring and a higher number when doing a large expansion.

Along with technical, leadership and interpersonal skills, it is important to examine candidate motivations. See how what you are offering lines up with what your candidate is looking for. If your candidate has not thought about what they are looking for, then ask them to do so. This will help you make sure you have a match and hopefully a long-term productive employee.

Hire well.

More later ...