Sometimes called “time-boxing,” this approach focuses on rapid-fire releases where the amount of functionality in a given release is based on the amount of time, not the other way around. One can think of this as rapid prototyping — it is and it is not.
Rapid prototyping usually means throwing together a mock-up that is used as a model for the real thing. Instead, this is the real thing, it is just successively refined.
Today’
s development technologies make it only incrementally more difficult to create a screen that works than one that does not.
In the early stages one might use a “toy” or personal database while nailing down the actual contents, then later shift to an industrial strength version when the tables settle down. The point is to get users to use it right away. The sooner they use it, the faster will be their feedback. Make sure everyone knows this is a moving target, and do not get painted into any corners until necessary. Stay out of the critical path at first, and let the users report when it is ready for prime time.
Expect changes and problems and plan for them, which means not only releasing early but repeatedly.
MYTH 4: DEVELOPERS DEVELOP AND TESTERS TEST
The mere fact that there is a title or job description of tester does not mean that testing is only done by testers. Quite the contrary: a major component of the test effort occurs in development.
The fact is, only the development organization has the knowledge and information essential for unit, integration, and system testing: testing the individual units, their interaction with each other, and their behavior as a whole. Developers are responsible for creating the software, and they not only should test it — they must.
The assumption that only testers test is especially insidious, because it shifts responsibility for software quality to those least able to affect it. The testers are not there to check up on development; they are there to protect the business. When development operates under the assumption that they have a safety net, the odds are higher that the system will crash.
The real and only reason for having an independent test organization is to represent the users: not to assure that the software does not break, but that it does what the business needs.
Reality: From the End of the Line to the Front
In this new paradigm, testing moves from the last line of defense for development to the front line of defense for the business users. It changes from testing to make sure the software runs to making sure the business does. Developers test software; testers test business processes.
This means the test cases and conditions are derived from the processes that have replaced the requirements. Testers do not verify that the order entry screen pull-down list of items is sorted alphabetically; they try to enter 100 orders in an hour.
Granted, the sorting of the list may dramatically affect productivity if it is not
alphabetized, but the focus is on how well the job gets done, not how well the development was done. The design has no meaning outside of its purpose: to support the process.
In this scenario, testers are not baby programmers hoping to graduate to real development. They are expert users, making sure that the business needs are served. Developers are not creative, temperamental artistes; they are professionals delivering a working product. The purpose of testing is not to break the system, it is to prove it.
MYTH 5: TESTERS DETERMINE QUALITY
Test organizations generally find themselves in an impossible position. They are asked to determine when or whether the software is “ready.” This is impossible because the testers usually cannot control the quality of the software provided by development or the rate at which problems are corrected. They cannot control what end users expect of it or will do with it. To say that the schedule is out of their hands … well, that should go without saying.
The uncomfortable truth is that testers are often approached as impediments to release, as though they somehow stand in the way of getting the software out the door. This is a dangerous idea, because it puts testing in a no-win situation. If they find too many problems, the release to production is delayed; but if they do not find enough, the release fails in production.
Reality: Ask, Do Not Tell
In the millennium, the business decides when the software is ready, based on what the test group discovers. The rolling release strategy provides for a constant flow of functionality, and the test organization’
s role is to constantly measure and report the
level of capability and stability of the software. However, it is the business user’
s
decision when it is acceptable. In other words, the user may elect to accept or waive known problems in order to obtain proven functions. This is a business decision, not a test criteria.
This does not absolve development from creating working product or test from performing a thorough analysis. It does mean that it is not up to them to decide when it is ready. This can work either way; the developers may be satisfied with a design that the users reject, or the users may decide they can live with some bugs that drive the testers up the wall.
The key is to remember that the system belongs to those who use it, not those who create it.
MYTH 6: RELEASES ARE FINAL
The initial release of an application is only the first of many, perhaps over decades.
Mission-critical applications are frequently revised monthly, if not more often, throughout their entire lives. The idea that everything the system will ever do must be in the first release is patently untrue.
This belief drives schedule slip: that one must hold up or delay the system because it does not do one thing or another, or because it has bugs. The truth is that it will never do everything and it will always be imperfect. The real question is whether it can provide value to the business today and, especially, in the future.
Thus, a software release is not an event; it is a process. It is not a wall; it is a step.
Reality: The Rolling Release
The concept of a release as a singular, monolithic and, often, monster event is an anachronism. Software that truly serves the business is flexible and responsive, supporting competitive agility and rapid problem resolution. Releases are like heartbeats: if they are not happening regularly, the system is dying.
Therefore, instead of a one-year development project with a vacuum after that, plan for four quarterly releases followed by monthly ones. During test, make weekly builds available. While this may sound like a pressure cooker, and using traditional methods it would be, it can be properly positioned as a safety valve.
Design defects are more easily corrected the earlier they are identified. Additionally, errors or inconsistencies are less annoying if they will be corrected in weeks instead of months. Emotion over missed re quirements subsides considerably if they will be coming sooner rather than later. Value is perceived faster, and the potential for runaways is all but eliminated.
All of this, of course, drastically changes the nature of testing.
RECOMMENDATIONS
With a development process based on assumptions that are consistently demonstrated to be untrue, it is no wonder one misses schedules and budgets. The answer, of course, is to throw out the existing process and define a new one based on reality.
The accelerating rate of new technology and techniques aimed at improving the development process can address the technical hurdles but not the organizational ones. In order for this rapid-fire, rolling release strategy to work, several things have to happen.
Code Speed
Although it sounds good to say that developers need to slow down and get it right, the fact is they need to speed up and get it perfect.
A case in point is the no longer simple process of creating a build, or executable. The build process involves assembling all of the individual components of an application and compiling them into a single, working whole that can be reproduced and installed as a unit. With the advent of component-based development, this is no mean feat. The build may encompass dozens, if not hundreds, of discrete modules, libraries, and files. As a result, the build can take days … if not weeks, or even months, to get it right.
In the time -box, rolling release world, builds are done no less than weekly. The only way for this to work, and work consistently, is for the code to be under tight management and control and for the build process to be strict and streamlined.
Speed has a way of burning off fat, and sloppy coding practices cannot survive the friction of this new model.
Standard Standards
Many development shops have adopted, documented, and published development standards, only to find them in useless repose, stored in binders, never to be referenced again. Without constant training, consistent code inspections, and other oversight practic es, standards quickly fall by the wayside. To a developer, standards are straightjackets to be worn only unwillingly.