When I heard about this article last week, I was curious if IBM would try to portray Scrum as an “add-on” to RUP, or if they would introduce Scrum as a standalone process with which RUP disciplines/workflows(whatever they call them now) can be incorporated per the discretion of the team. In other words, is RUP presented as the container and Scrum the contents, or is Scrum presented as the container process with RUP workflows as (potential contents).
Although at the beginning of the article they seem to give self-organization and “Scrum is a management-wrapper” lip service, the author seems to forget all of that by the conclusion which reads:
“In general, RUP satisfies organizational demands by bringing a structured and proven process framework to the table, and Scrum patterns can add additional dynamics to the project.”
I’d argue that Scrum, by virtue of it’s foundational requirement for team self-organization and empirical process, can never be contained or absorbed by another process that dictates defined processes, like engineering practices. Can RUP practices be used with Scrum? Of course! Any team that chooses to do RUP workflows because that’s what works for them, is free to do so under Scrum’s self-organization. In this case, Scrum is the parent-process, not a subordinate process.
But it can’t work the other way around: if we are doing RUP our world of engineering practices are limited to the workflows defined in the RUP. That limit flatly violates core Scrum principles.
Actually, if IBM treats Scrum as a sanctioned add-on to RUP, and Scrum allows teams to pick and choose their own engineering practices, doesn’t RUP then become “anything the team wants to do”. I doubt IBM would want to take it that far.