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