The Agile Heart of the Unified Process

Using RUP as a Scaling Framework for Scrum

One of the common complaints I hear about the Rational Unified Process is that it is too prescriptive and document focused. An often heard complaint about Scrum is that it does not scale to large projects and you never quite know where you are going until you get there. What if we could leverage the best of both methodologies? What if we could deliver with just enough structure and documentation to scale the project but maintain the collaborative, human centered approach of Scrum?

Agile projects begin to break down at scale. This is due to Agile’s dependence on human interaction to transmit information between team members. Agile practices such as collocation and pair programming place a premium on human interaction and rely less on artifacts and formal handoffs. The problem is that as the team grows, information does not get communicated to everyone. It becomes more and more difficult for everyone to share a common understanding of the system. There are greater separation of concerns as members begin working on different aspects of the solution. Some degree of documentation is necessary to keep everyone on the same page.

The secret to scaling Agile lies in doing just enough up front planning to ensure the teams understand the big picture of the product they are creating and have defined the significant mechanisms of communication between the various subcomponents. The RUP provides an ideal framework for helping a collection of small teams define what needs to be done in support of a large scale Agile development effort.

Inception

The goal of Inception is to minimize business risk. This means that you have to understand the vision for what you are trying to create, have a high level understanding of the requirements, and have defined the characteristics of the systems architecture you intend to build.

Begin Inception with a single Scrum team. The team should at a minimum have a ScrumMaster, a Product Owner, an Analyst, a Quality expert, and an Architect. The product backlog will include the features necessary to create the Vision, Use Case Inventory, and Candidate Architecture. It may be necessary to include features in the Inception backlog that prove key aspects of the business vision.

Inception is the least code focused of all the RUP phases. This is due to the requirement to have an idea of where you are going before you begin the project. Since Inception is the least focused on creating working software, and without working software the team is not mitigating risk, it is in the team’s best interest to make decisions quickly and get on with the business of delivering working software.

Key artifacts you may want to consider include: the vision, use case inventory, candidate architecture, risk list, and a high level project schedule.

Elaboration

The goal of Elaboration is to minimize technical risk. This involves choosing the smallest subset of features that will prove out the significant technical assumptions made during Inception. At the end of Elaboration, the system should be fully functional with the subset of features you have chosen to build. The system should be fully tested and the team should be confident that the architecture is stable.

During Elaboration, you may still have a single Scrum team. It is likely that you will add several more senior level technical folks to help begin building the system. The product backlog includes the features necessary to prove the application architecture and to deliver any non-functional components required to build out the system. It is important that the Elaboration backlog contain features the team will need to collaborate at scale. Source control, build environments, automated testing infrastructure, instant messaging, and collaboration software should not be overlooked when preparing to scale an Agile team.

Key artifacts you may want to consider include: a use case survey, descriptions for architecturally significant flows, an architectural description, the architectural prototype, and the results of executing tests of the architecture.

Construction

The goal of Construction is to mitigate logistical risk. This is where the bulk of the software is created and where the Agile team really begins to scale. The core team that helped build the foundation of the system during Elaboration is broken up to seed the newly created Scrums. Each team is organized around a major component of the architecture or a significant feature set within the overall scope. Each team is a complete cross-functional entity that is responsible for delivering its part of the system. These teams are coordinated by a master team that includes a more senior ScrumMaster, Architect, its own technical staff, and the Technical Leads and/or ScrumMasters from the component teams.

At this stage, the backlog is completely feature driven, progress is extremely measureable, and the teams are focused on delivering the bulk of the business value to the customer. As is true during every phase, the code delivered at the end of each Construction iteration is fully tested and integrated with the rest of the system.

Key artifacts you may want to consider include: use case descriptions, supplementary specifications, designs, code, tests, test results, training materials, and user documentation.

Transition

Transition is focused on mitigating deployment risk. This phase deals with training and hand-off to the customer, final user testing, and resolving any issues that were not caught earlier in the process.

During this phase, the team should be able to scale back down to a single cross-functional team or two. The backlog is related to the remaining documentation, training, and defect resolution features remaining to get the product in the hands of the customers.

Key artifacts you may want to consider include: installers and data conversion plans, customer surveys, and an outstanding defect list.

Conclusion

To scale an agile project, you must have enough of a vision to help the team understand where the project is headed. You must understand enough about the scope and size of the project to help the business understand what they can commit to market. You must have enough of a plan to help the team understand that they are on course or if corrections need to be made. You must have enough of an idea of the solution you are going to build such that teams can work independently from each other and converge on a coherent solution.

The RUP provides a process framework for helping the team understand how and when to scale with Agility. Careful use of the RUP artifacts, UML, Process, and Process Mentors can aid the team in coming to a common understanding of the evolving system. Documentation should always be used to faciliate communication, so used carefully, these tools can become a powerful contributor to overall team success.