Four R’s of Software Process Improvement: Requirements, Reviews, Retrospectives, and Results

© 2000 Johanna Rothman. Abstract Process improvement projects can be difficult to start, keep on track, and assess results. We can use the same requirements gathering and specification techniques that we use on product-projects on our process improvement projects. This paper discusses how to define requirements for process improvement projects and how to use reviews and retrospectives to assess the results of process improvement efforts. Introduction Software projects are hard to do correctly; therefore many of us have started process improvement projects to make our projects work better. Process improvement projects aren’t particularly easy either. I recently saw this ad on the web: There’s a bright future ahead on the right road to process improvement. We know the right road and all the steps in it to achieve process improvement success. Our experts will guide you, making sure every step is aligned with your company’s goals and everyone in the organization is headed in the same direction. If only it were so simple. We could call in the experts, hand off our process improvement projects, and live happily ever after. Unfortunately, every process improvement project is different, because each organization has its own context and problems. I like to apply standard project questions to discover the motivation behind my process improvement project: What outcomes do you expect? What are the desired process improvement results? What do you need to do to know about those results? What are the process improvement requirements? How will you know you have achieved those results? What techniques will you use to review, test, and measure your process improvement project? Use Results to Generate Requirements...

A Problem-Based Approach to Software Process Improvement: A Case Study

© 1999 Johanna Rothman. This article was originally published in Crosstalk, October 1999. Organizations struggle [1] with their process improvement efforts for a variety of reasons. Perhaps the most common struggle pattern is to take a long time developing a general understanding of their processes and then trying to define all possible alternatives in the product development process. This pattern leads to large, unmanageable, unreadable, and incomplete [2] process documentation. This paper is a case study of one organization that minimized the struggle by taking a different approach to the development of their product development process. Introduction The organization described in this paper was a 12-year-old company, formed out of two startups. It created and sold graphics products. We will call this organization “ExtendIt.” ExtendIt employed about 150 people worldwide. The product development staff was split into two locations: about 50 people in the Boston area office, and about 20 people in a European office. ExtendIt was in a typical chaotic state — most of senior management did not understand the software product development process. Engineering management did not know where or how to begin, project management and product management were nonexistent, and engineering processes were completely inadequate for product development and testing. Projects were planned for four to eight months, but typically took 13-18 months. Even at the end of the extended development time, ship decisions were generally based on emotional reasons to ship, not objective reasons. For example, management made the decision to ship a major release because the developers were too tired to continue the 80-hour weeks, not because the project met the ship criteria. In...

Achieving a Repeatable Process

by Johanna Rothman. This article was originally published in Software Development Magazine, June 1998. Large, permanent engineering cultural change–or process improvement–generally takes a long time to implement. However, key repeatable processes can free up time in an organization and let people spend more time on the creative work of software development. I recently worked with a software development organization that had trouble meeting any of their promised product ship dates– all releases were late. In addition to being late, the releases were often missing key pieces of functionality and had significant bugs. The group I worked with on this project consisted of six developers, three testers, a part-time writer, a project manager, and a product manager. Overall, morale was low. Current management focused on sales, and was not good at, or especially interested in, managing product development. With the original founder gone and no software engineering process, the engineering team was in turmoil and the project was in a state of disarray. The responsible vice president realized that he needed to take different action to finish the project. He called me in as a project and program manager. His directive to me was “Get the project to beta ASAP and ship the final version by July 1.” He didn’t care about process improvement or the culture, he just wanted the project done. I first assessed where the staff was spending their time, to understand who did what. I discovered several problems at that point: no project manager or schedule; time-consuming customer calls; no public configuration management or automated public bug-tracking system; no formal review process; no unit tests; inadequate system...

A Problem-Based Approach to Software Process Improvement: A Case Study

© 1998 Johanna Rothman. Abstract Organizations struggle [1] with their process improvement efforts for a variety of reasons. Perhaps the most common struggle pattern is to take a long time developing a general understanding of their processes and then trying to define all possible alternatives in the product development process. This pattern leads to large, unmanageable, unreadable, and incomplete [3] process documentation. The long process development duration tends to make the technical staff suspicious of the process itself. Add the unreadable process development documentation and the result is that the staff is generally reluctant to accept the end result. This paper is a case study of one organization that minimized the struggle by taking a different approach to the development of their product development process. Management believed that the key to product development success was to plan for success, while understanding the current problems. They were convinced that product development quality and timeliness comes about when the process is clear, easy to understand, and leads to the desired end result. Planning for failure was not to be part of the process definition and improvement effort–each project needs to plan for its own risks. But management wanted to make it clear that reasonable people, following a reasonable process, could produce products successfully. The process group took an approach that incorporated: solving their specific problems, frequent testing, and rapid, evolutionary delivery of results. This paper describes the efforts of that steering committee to define a reasonable, but not comprehensive, product development process. Introduction The organization described in this paper was a twelve-year-old company, formed out of two startups. It created and...

Case Study: From “Chaos” to “Repeatable” in Four Months

© 1997 Johanna Rothman. Abstract Recent writing in the software process improvement literature [1,2] discuss those organizations who start off at an ad hoc level (CMM level 1) and proceed to a repeatable level (CMM level 2) and higher. However, there are many organizations who cannot make progress towards level 2 until they have a firm grasp on level 1 – the knowledge that they perform processes as part of the their daily work. This is a case study of lessons learned from an organization’s journey from level “0”, a total lack of knowledge of process, through ad hoc, heroic processes, to a repeatable process. Keywords: software process improvement, software engineering, software product development, program management, project management, concurrent development and testing. Introduction to Case Study The work described here was preceded by a short informal assessment of the project. Given the results of the short assessment, we chose not to conduct a formal assessment. We surmised that any assessment results would be rejected by the development staff, which would lead to a less effective working relationship. Since the purpose of this work was to develop and ship a product, not specifically to improve processes, it was critical to build a positive working relationship with the staff. This paper is a case study of a small product development group working as an individual division within a large software company. The software process improvement approach here used the CMM as a reference, but not as a roadmap. This case study shows that it is possible to get good results by doing some simple things. The product is a middleware communications...