Hi All,
Don't you think that Scrum is pretty much the same as RUP, XP and
other iterative software development approaches?
And the only difference among them is the number predefined rules to
follow. For example RUP has the most, Kanban has the least.
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.
So I think the main power is in
ITERATION and its CLEAR GOALS, but everything else depends on what you
prefer.
Andrej
www.agilemindstorm.com
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
Hi All,
Don't you think that Scrum is pretty much the same as RUP, XP and
other iterative software development approaches?
And the only difference among them is the number predefined rules to
follow. For example RUP has the most, Kanban has the least.
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. So I think the main power is in
ITERATION and its CLEAR GOALS, but everything else depends on what you
prefer.
I have seen Scrum implementations with varying degrees of all the
pieces or half or just some of the pieces. Every part of the Scrum
framework is there for a reason. In general, the work suffers if all
of them are not there in practice.
Subtle differences are more important than can be imagined. Try them,
even if you don't think it will matter. Then reject a part if you
have data that shows you should.
Alan
On Sun, Sep 19, 2010 at 2:54 AM, andrej...@gmail.com
<andrej...@gmail.com> wrote:
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.
> 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.
+1, with "many" substituted for "most".
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Talent determines how fast you get good, not how good you get.
-- Richard Gabriel
--