Scrup

Process, process... the holy grail of software development. I would like to share here another experience we made at Sofshore: adopt the best of two worlds, IBM's Unified Process (RUP) and Scrum. Pretty contradictory at first sight - i even read somewhere that the RUP violates various agile principles.

Scrum

I am personally an agile enthusiast (even if the definition of "being agile" does not have a common acception). Scrum is great because it brings in itself all the agile principles (of course), and because of its focus on productivity and project management. On the other hand, Scrum falls short on many aspects, requirements management for example.

RUP

On its turn, RUP has three interesting characteristics.

First, it is a framework more than a process: it is highly customizable, picking only what is needed. At this respect RUP is far from being a "bureaucratic heavywheight" process.

Second, a focus on preliminary and progressive architecture definition (the elaboration phase). This is interesting because software engineering is research process: it makes sens to work first on the most critical technical issues.

Third, a structure that is iterative in the small but sequencial in the large (the phases). This is important because most projects follow a life cycle that is sequencial, from the expression of a need until the deployment. In this, RUP fits well the workflow used at the business side.

Scrup

So, our processes integration has the following noticeable characteristics:

Phases
- We use the RUP phases, in which we integrate one or more Scrum's sprints (sprints are used as RUP iterations).
- For most of the development, we function the scrum way, using sprint planning, daily scrum meeting and retrospective.

- We use the RUP artifacts for requirements and project managements: Use Cases and Supplementary Specifications, Software Architecture Document, Project Plan, etc. Always taking care not to fall in heavy bureaucracy (having a plan does not mean it should be 200 pages long).
- We also use the Scrum artifacts: the Product Backlog (composed by a prioritized list of use cases), which is actually the most important part of the project plan; the iteration backlog and of course the burndown chart;
- We use Use case instead of User Stories

- About velocity: we use it, its value is of course roughly known during the elaboration but its value should be reasonably known by the end of this phase. At least enough to have a reliable project plan for the construction phase.
- Using a project plan does not mean that this project plan is immutable - this would effectively violate the agile basis. The project plan is adapted when necessary - as the product owner makes decision during the project.
- We also used short iterations (2 weeks), but this is not very important here - we might have used longer ones.

Scranything

As mentionad above, the RUP sequential structure fits well the IT administrative process. Wanting it or not, companies need realistic plans on the mid-term in order to allocate resources and follow results.

Actually, many similar sequential corporate processes exist, always following the steps of demand, acceptation, construction and delivery. Hence, Scrum can be integrated with almost any other linear administrative and validation process. We already did this twice.