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