Determining ship readiness

Shipping is a feature! How do we set the acceptance criteria to determine when a release is ready to be implemented? First you need to agree with the customer as to the requirements and feature sets to be implemented. You then need to develop the application and test to those requirements. Sometimes a particular date in the future is critical to the business and needs to be taken into consideration.

Requirements

We won ‚ t bore you with all the nit and grit details of what follows an initial customer meeting, but it boils down to two different scenarios in our experience. The first is what we call the ‚“Documented Approach; ‚½ the other is the ‚“Pressure Cooker Approach. ‚½ We are sure there are others you have experienced , but when boiled down, they can fit one of these classifications or a mix of the two. The ‚“Documented Approach ‚½ is where you write some sort of functional specification (also known as a requirement document), and/or include a prototype as the requirements are collected. The developer(s) get a pretty good idea of the scope of the project or projects. Estimates are created based on the requirements (usually overly optimistic) and a ballpark cost (hourly or fixed price) is completed.

The second approach is the ‚“Pressure Cooker Approach. ‚½ This approach is also known as ‚“Requirements-to-Shipping Approach. ‚½ This is where the customer needs to have something yesterday , or more likely a month ago. There are many causes of this scenario. The customer might have some brand new competitive pressure. They may see a brand new opportunity with a legitimate small window of opportunity. Their previous developer might have moved to another continent for a change of scenery or a new career. In our experience it is none of the above, but more likely some pointy-hair boss who delayed the project because he has budget concerns that reflect on his quarterly bonus, and then tells the software folks it is time to get cranking at the last minute. Whatever the reason, you are on the hot seat to get something in production. It is time to change into the superhero outfit of your choice and deliver the software in world record time. This scenario is played over and over and over in software shops around the world. There are never any estimates more than a month, because this is when the application is due. Typically you get the first version of the app running, moved to production, and then are allowed to step back and take the ‚“Documented Approach ‚½ for the rest of the system. At least we would like to believe we have a chance at the ‚“Documented Approach ‚½ for the second phase. Sometimes the projects are in the ‚“Pressure Cooker ‚½ for all phases.

We cannot stress enough the importance of written specifications for a project ‚ s success. Contrary to popular belief, specifications on the back of a napkin are not reliably transferred into software. Please use the napkin notes jotted down at lunch or dinner when you write the real specifications. The specifications have to be written down in some form and the form needs to be consistent across all the company ‚ s projects. This allows developers to transfer from one project to another and eases new developers into the company as the company grows. Without some specification there is no way to prove the final product does what it was set out to do. It also helps developers taking over an existing project to know how the product is designed to work. We find very few customers actually read the functional specifications word for word, but it gives us a place to refer them as they are testing the application so they have our perspective of their business.

You as a developer are responsible for ascertaining the real requirements and the nice-tohaves. One observation we made is as time moves forward, more and more projects are subject to the ‚“Pressure Cooker Approach. ‚½ It may have to do with the fact we live on Internet time. It may be people have poor planning capabilities. It may be you develop better each time and the customers have higher expectations for your services. Whatever the reason, our experience proves time and time again that the ‚“Pressure Cooker Approach ‚½ fails more than it succeeds. One fact of life is designing applications consumes time, but it is time well spent. Many customers don ‚ t want to make this investment, a mistake we don ‚ t want to them to make.

A wise developer somewhere once said, ‚“I can walk on water and deliver applications on time that meet all the requirements in the specification, as long as they are both frozen. ‚½

Feature sets

Once the requirements are collected they must be reviewed and organized into feature sets. This is a group of requirements that need to be implemented together. The feature set is usually the most critical path issue involved with shipping a product. The customer needs to clearly state what is needed in this version of the application. These functions are usually business driven. They usually revolve around some pain the users are feeling. This pain usually leads to statements like, ‚“I need to track these thing-a-ma-gigs and get a grip on costs and I have to have this implemented by the end of the month, ‚½ so make sure they understand that delivery dates are in reality a feature.

This is where the negotiation starts between the developer(s) and the customer. Which functions can be delivered by what dates? Must all the requirements be delivered at the same time? Can certain features be delivered first? Can others wait until version 1.1, 1.2, 2.0, 7.0? (Always skip versions so you can send the rookie developers looking for them later.) Each feature set included in the version that ships next should be determined as early in the development cycle as possible. There will always be scope creep in development so leave room to negotiate extensions to time frames later if needed. We found success in these situations when we have the customer decide what to take out of the release to make room in the project schedule for the new hot features they want. If the customer has to have it all (and when is this not the case?), the ship date has to slip to a date in the future. If the date cannot slip, then hopefully you have a bonus provision pre-negotiated to cover the extra time you (and possibly your team) are going to be putting in after normal business hours.

Prototypes

Developing a prototype of the application during development allows the customer to see features they desire translated into a working application. At the same time we have written developer tools that reverse-engineer the prototype to develop the functional specification. These tools scan the forms, reports , menus , class definitions, and quickly format information dumped into a word processor. This text is later formatted by macros to make the information readable for the customers and the development team. Add in a business rule here and there and presto, writing a functional specification is not as painful as it was in the past. This also saves your team time and allows you to concentrate on the ‚“fun ‚½ part of development.

Preparing customers for testing

We discuss the various types of testing in other chapters in this book. Planning for testing is another whole facet that needs to be discussed. We often find customers who are new to custom applications never consider the time and effort necessary for them to test the application.

To show how customers like to test we think a short story will demonstrate the extreme lack of interest users have for testing our applications. Late in 2002 and early in 2003 Geeks and Gurus was hired by a developer to convert a suite of vertical market applications from a VFP database and tables to SQL Server database. The original application was well designed from the beginning to move to a SQL Server backend, but numerous changes were still required and the suite of applications was feature rich. There was no test plan for the original application and the single requirement for the conversion was to port the application with no additional functionality. The conversion was several months in the making and took the staff of the developer ‚ s company more than a month of testing to make sure we got it right. We demonstrated the product and the end users were ready to deploy it to production. We noted it needed a complete system test in the production environment in beta mode before being fully deployed for production use. We estimated the testing could easily take more than a month, but knew user pressures could compact it to two weeks.

The end users were floored by our estimates. Three days into the beta test they announced they were ready for the implementation. The error logs delivered in this short time noted several minor problems and a couple significant problems as expected, and was by no means ready for production. We managed to control their enthusiasm during the beta by noting several bug fixes to major features the customer did not report. The error log showed several problems we considered showstoppers, but they intended to live with in production. The one bug that brought them back to reality was an OLE error during a Word Automation program. Word choked on NULL values and stopped some letters from printing. Fortunately, we deployed the application in production two weeks later and have only needed to fix a few minor bugs since the deployment.

Setting user expectations in advance can reduce the ‚“push for production, ‚½ or at least establish some expectations that the completion of the development phase does not mean the application is ready to be used. Depending on the size of the feature set expected to deploy, your experience will hopefully help determine how much testing is required before the application can be installed into production.

Delivery dates

Most software development projects are driven by delivery dates. How many serious Y2K projects had delivery requirements of December 31, 2002? There are real business rules that drive delivery dates. We have never had a customer say, ‚“I have no date I need it by so there is no problem getting this system done five years from now. ‚½ Usually it is something like ‚“I need this as soon as possible (ASAP), ‚½ or ‚“I needed this last week. ‚½ We always remind the customers that the only acceptable dates are ones in the future and ones that validate in their applications. For instance, ‚“ASAP ‚½ cannot be entered into a date field. We also note that initial dates are target dates and never chiseled in marble. Target dates are a way to focus the development team to complete a project. Target dates are also used to manage the scope of a product delivery.

Often the customers want to dictate all the factors used to determine when a release can be made. One approach uses three factors ( Figure 11 ): features, time (also translated to money), and delivery dates. Software developers can let the customer select and determine two of the factors first, and then calculate or determine the third factor. For instance, if the customer determines they need fifty features delivered in the next two weeks, the developer has the right to charge a lot of money because they will have to pay a number of developers to work overtime on the project. If the customer has a restricted budget and needs it in the next month, the developer can restrict the number of features that will deploy.

Figure 11. The development tradeoff triangle