bj

39 BACKGROUND SSA is a 21-person unit specifically established to develop a proprietary software management tool for a 700-person software company, also known as the SBA. In particular, the SSA unit is in charge of internal software development tools used in testing microprocessors manufactured by the business units of this multi- billion-dollar company. HISTORIC PROBLEM In the past, SSA would usually spend up to six months collecting requirements from SBA, sometimes accepting requirements midway through the project, and trying to make everyone happy. In doing so, SSA would normally end up with a project that had a long list of features to accomplish. As a result, many projects took a very long time to finish. In many cases, promised features were dropped, but still usually with a huge scope creep. There were so many complaints of SSA's handling of its projects' scope and timeline, literally from all sections of SBA, leaving SBA no option but to act. To help lessen the negative consequence, SBA put together a team made up of per- sonnel from its major departments to analyze the situation. After a long study, the team proposed that SSA change its business model into a "quick release" model. CASE STUDIES The quick release model was intended to be used as a way to improve quality in new product development for several years, but was just recently employed for the first time ever. WHAT IS QUICK RELEASE FUNCTIONING? Mandy Bock, manager of the SSA group, explains his team's approach: "Contrary to our existing model, the quick release approach favors frequent, smaller projects, each one implementing a small number of features only. We call these small projects quick releases. In particular, scope of each quick release is frozen at the beginning of the development phase of the program life cycle (PLC). This happens after the discovery phase, which is the first phase of the PLC. Each quick release scope typically has only two or three features, and must be approved by a program manager. Let's say we have a big program called program X. Instead of running it the way we did, we break it down into smaller projects (X;), each with a few features. We begin to work on project X (programming part); we plan its execution in detail, then transfer programming to the Russian part of the team. We then begin to collect requirements for project X2. So, all of us from SSA here in Hillsboro, and all the other guys in Russia work on only small but frequent projects. Each quick release usually takes around three months, and is officially part of the program upgrade. In other words, any change aside from those related to the specified two or three features is difficult. And those two or three features are usually clearly defined because we don't have to focus on too many things at the same time. So without major changes we usually cruise through the program, almost never seeing scope creep or change in scope. Less is more!" Discussion items 1. Generally, what do you think about the quick release approach vis--vis the conventional approach? Put together the list of strengths and weaknesses for both. 2. Is the quick release more suitable for large or small software development organizations? Justify your choice. 3. Explain how the quick release approach prevents large delays typical of mega-projects