p.s. my question from post is in italic.
> Hi All, Don’t you think that Scrum is pretty much the same as RUP, XP and other iterative software development approaches? XP and scrum are more alike then RUP
Important part of scrum and xp is the self-organizing part. Calling them only “iterative development” might look technically correct, it is wrong.
> I don’t think the Kanban people would agree that Kanban is iterative. But no matter which iterative approach you are planning to use you
> need to adapt it to your organization. In case of Scrum or Kanban each team comes up to its own rules, but in case of RUP you can adjust/change already predefined rules.
which is why they are totally different.
that is how these approaches differ for you. Not for me.
Yes, there is a few similarities, of course but, I would tell you that you have to understand that the Scrum philosophy is much more: Visual Management, Retrospectives and what about all the books writen which advice you on very good practices?
When you say iterative process, you make it look very simple. But tell me, what practices do you do to succeed, and tell me if you can learn more 🙂 (not trying to be aggressive at all !!)
A name and a concept are very abstract, and they do not define details (good practices) Scrum, is about people, experiences, good practices and sharing all that knowledge… The Scrum knowledge tells you much more that RUP, in my opinion. Hope you know what I mean.
Good question , got me thinking this morning.
I do agree that Iterative approach to problem solving is part of Scrum framework and we can draw some parallels between RUP and Scrum in this regard.
I also see as RUP as a very defined process where as Scrum is a framework with lesser defined rules on how to approach the problem and focus is on values and principles. Most of the Scrum rules are backed up by the foundations like focus, empiricism, collaboration , self organization. So I believe the purpose behind Scrum rules are explicit and backed up by foundation and values and not just as best practices that worked in some other context . I have been able to effectively able to use those underlying foundations and values when adapting Scrum to different environment and use it as a general management and problem solving approach in different contexts.
> need to adapt it to your organization. In case of Scrum or Kanban each team comes up to its own rules, but in case of RUP you can adjust/
> change already predefined rules. So I think the main power is in ITERATION and its CLEAR GOALS, but everything else depends on what you prefer.
I totally agree that adapting any process to your organization is key for the success of any way of working. What Scrum provides is a set of rules(simple for some , not so simple for other based on your outlook towards some of the Scrum values and how much you can stand behind them) . For me the beauty of Scrum lies in the autonomy (self organization ) , ownership (commitment) and importance Scrum places on people interaction between people. I have not seen that being explicitly stated by other frameworks, I am hoping that more and more frameworks value people over processes. Explicit reference to transparency and courage in believe is a great way of surfacing impediments and dysfunctions and effectively resolving them. Finally it all depends on the people involved and how much they can internalize the values and foundation to achieve success with Scrum rules.
Great question again.
Kurt: I get the feeling that most people are using it as a mere planning and scheduling tool, rather than a tool to surface problems, and promote organizational change. I suspect a lot of people are just using it embedded in the development departments/phase within a waterfall process rather than as a replacement for waterfall at a higher level. Both of which are hard to argue against if the scrum guide is being used to defend them. I would rather see the scrum guide take a bolder approach, and condemn such a watered down approach to scrum.
Ron: +1, with “many” substituted for “most”.