Scrum and RUP

by Gary K. Evans

The Waterfall development process is still the most prevalent software development process in our industry. Two leading alternatives to Waterfall are the IBM/Rational Unified Process (RUP), and Scrum. RUP is a large-scale, iterative process that can be tailored to be either very heavyweight or agile. Scrum is an inherently agile process that embodies the ideal that "less is more". Either can be a fruitful choice over the command and control rigidity of the Waterfall process.

RUP is both a process framework, and a software product. The product is sold by IBM and is bundled into their Rational Method Composer product. RUP comes pre-configured in two versions: one for large projects, and one for small projects. The current RUP version 7 is not trim: it consists of at least 7,500 files in 278 folders. Using RUP is an exercise in navigating almost one thousand HTML files. The Rational Method Composer is the tool for creating your own configurations of the RUP framework.

Starting in version 7 IBM has unified the underlying concepts of RUP with IBM's own product architectures, known as the Unified Method Architecture (UMA). UMA defines both Method Content and Processes, which can be tailored independently through the Rational Method Composer.

When taken as a development process straight out-of-box, RUP can be appreciated as a half-way house between Waterfall and Scrum. Like Waterfall, RUP delineates in significant detail the deliverables a projects should produce, the many roles that produce those deliverables, and the 9 disciplines, or activities, that are performed within each of RUP's four phases of a project. Like Scrum it is iterative, risk-focused, modifiable and tailorable to a specific culture and project. Because RUP prescribes so much of the what, how, who and when, RUP is a very tactical process. For companies moving from Waterfall, RUP's tactical exposition offers what I call a "ledge" -- something familiar to stand on as projects migrate to RUP's iterative, and possibly agile, capabilities.

Scrum, in contrast, is a thoroughly strategic process definition. Scrum does not enumerate numerous project roles nor dozens of artifacts that should be produced. Rather, Scrum is affirmatively minimalistic: it defines 3 project roles, 3 work products, and 4 meetings within the project. The entire outline of a Scrum project can literally be defined in 2 pages of text. The roles that Scrum does define are the Product Owner, the Team and the Scrum Master. The Product Owner represents the interests of all stakeholders of the project, and creates the project’s vision and overall requirements (in collaboration with the stakeholders, of course). The Team are everyone responsible for developing and delivering the project functionality. Scrum empowers the Team members with collective responsibility for the success of each iteration and the project as a whole -- no finger pointing. The Scrum Master serves as the project management role. But the Scrum Master is only a facilitator, not a commander. The Scrum Master's two responsibilities are a) to remove any and all impediments on the project, and b) to assure compliance to the spirit of the Scrum process.

Scrum does not provide any guidance on how the Team will organize themselves or solve the problems that come their way. It merely says the Team have to find their own way using the skills and creativity within the Team, and any other resources they can enlist. Scrum does not allow the Product Owner to set estimates or assign tasks. It clearly delineates that the Team are responsible for making all estimates and signing-up for work. After all, are they not the best to estimate how long a task will take to complete? And do they not then have a clear ethical responsibility to meet their estimates?

How does an organization moving from Waterfall choose between these alternatives, or others? The answer depends more on the company's culture and willingness to accept change, and the kind of change it will accommodate, than on the merits of either RUP or Scrum. Organizations that want to hold onto some form of command and control can adopt and adapt specific portions of RUP to their development projects. I have worked with companies in various industries to do just that. Some augmented RUP's phases by adding an Initiation phase prior to RUP's Inception phase. Some adopted just the Business Modeling, and Requirements, disciplines to incorporate use cases into their requirements definition and to get better buy-in on these requirements activities. Others maintained their nominal Waterfall process, but gave the development team license to adopt RUP's iterative execution model so software can be delivered often and validated much sooner. Even in the largess of RUP there is room to be selective.

Scrum requires a willingness to jump into process change with real commitment. Because the structure of Scrum is so different from the structure of Waterfall, I have never seen any organization successfully move into Scrum incrementally. For companies who see the value of Scrum, but are hesitant to jump in completely, I have found a simple win-win: jump in completely but only on an isolated, non-critical project. Some call this a "pilot", or "trailblazer" project. I call this a "limited, local victory". And when a small but meaningful project succeeds, it becomes the foundation for a broader implementation of Scrum in the organization.

Both RUP and Scrum can yield significant benefits to the adopting organization. Both require changing how we think about how software can, and should, be developed. Evanetics is experienced at moving a Waterfall organization toward either, and sensitive to the culture and organizational constraints that must be given careful consideration. Waterfall will always be an option, but is that where you want to stay?

    Gary K. Evans, Certified Scrum Master