Exploratory Development

Is Scrum better than RUP?

Yes.

No.

That’s an incorrect question. We can’t say that Scrum is better than RUP because we can’t compare them reliably. In fact a process is a multidimensional essence. As you know from math we can’t compare two vectors – only their norm. And norm can vary depending on the space. The same is true for processes – to compare them we need single value to work with and context.

Success rate? It depends heavily on project size, executive involvement, whether requirements are stable or not, etc.

Any process has some ideal context in which it is the most useful. We can’t say that one process fails more often – this process may have been applied in a wrong environment. For instance, if one is going to apply pure Scrum in development of new Boeing – he’d better think again. And if one is going to use full-blown process in accordance to government military agencies’ norms for developing small web-site s/he will have tough time trying to get profit.

It makes sense to bear in mind while choosing, designing or adjusting a process:

• Project’s context
• Industry experience
• Needed level of flexibility and reliability

Context is important

Project’s context contains specific problems which have to be addressed and conditions under which it should be developed (e.g. staff, corporate culture, regulatory norms, contractual agreements, etc). However there is no clear line between problems and conditions – it is possible to consider almost any problem as a condition and vice versa. A process is aimed at resolving specific problems and operating in specific environment. So, we can’t say that Scrum is better than RUP (or whatever), but we can say that Scrum is better suited for this particular project. That’s why I believe that PM BOK is not enough for a good project manager (apart from the case when all potential projects of the manager fit PM BOK perfectly, but that’s almost impossible). S/he should know several methodologies and approaches to be able to choose the right one.

Someone may suggest that people should use principles here (e.g. Agile manifesto) instead of sticking to a specific methodology. Although Agile manifesto principles fit much more projects than specific methodology does it doesn’t fit all projects. If cost of a change is very high or that’s impossible to break development into parts then iteration may be a bad choice.

Don’t ignore experience of others

There is lots of experience behind the vast majority of commonly used processes.

Sometimes process owners ignore this experience - a project has custom process that process owner (project manager, program manager, division manager or SQA manager) believes is the best and the most appropriate one for this project. The process owner claims that the process fits exactly project’s needs and s/he doesn’t need any of widely used processes. After some analysis it turns out that this process is used because process owner doesn’t know other processes or practices, sticks to this process since it worked well for some projects in the past, doesn’t analyze relevance and suitability of this process for a specific project due to inertia or doesn’t pay attention to it at all.

Design a process if needed

But what to do if no process fits specific project exactly? Consider context-driven approach. Actually, that’s designing a process on the fly. Project manager (or program manager) should have deep knowledge of different processes and rich experience in order to construct a process that ideally (or near) fits specific project. That’s the next level – design of a process.

Surely it doesn’t make sense to start every time from scratch – it’s better to use existing processes as the base. Again it requires that PM knows wide range of approaches. At the level of design one works with practices, techniques, tools and context; process is a result. Having proper understanding of what problems specific practice resolves and what environment it requires helps to choose appropriate set of practices.

It sounds quite easy but in practice it is not. To design a good process one should have really deep understanding and knowledge. And that’s not a single action – actually, designing is a continuous process itself. PM should analyze current state and adjust process to changes.

Balance flexibility and reliability

Designing a process takes time. It may lead to additional risks if PM has not worked with such process before (or s/he has insufficient knowledge and skills). And it has some negative sequences for an organization – if there are a lot of different processes then it’s hard to manage projects because every project can have its own stages or flow. People on new project should spend time learning new process. It increases overhead expenses.

Existing processes cover wide variety of projects, so it’s a smart move to select ready process and then adapt it if needed. It helps to avoid time loss and reduces risks.

If company’s projects are quite similar it makes sense to choose some core process with minimum set of practices which is mandatory to follow. And then project can add new practices if it is appropriate. Having knowledge base with set of useful practices helps to share experience within entire organization.

There is a choice

To summarize, there are several options:

• Use the same process for all projects
• Choose from some predefined set of standard processes
• Use the same minimal core process and extend it for specific project
• Choose from some predefined set of standard processes and extend/modify it
• Construct specific process for each case

Decision which approach to choose should involve context as well – acceptable level or risks, regulatory norms, diversity of projects, qualification of project managers, corporate culture, team, etc. But that’s very important to remember that there is a choice and not just one-size-fits-all solution.

And don’t forget about people - right people is one of the most critical success factors. Or even the most critical one.