Loading ...
Sorry, an error occurred while loading the content.

Scrum and NonScrum

Expand Messages
  • Ken Schwaber
    Scrum is really simple, barely a process, more a framework. The hard work in using Scrum is fixing the things that it exposes, actually inspecting the things
    Message 1 of 99 , Mar 28, 2006
    • 0 Attachment
      Scrum is really simple, barely a process, more a framework. The hard
      work in using Scrum is fixing the things that it exposes, actually
      inspecting the things that it makes transparent and adapting to
      optimize the results and the organization that produces the results.

      Scrum is not the organization that produces the results, or the
      amalgam of procedures, tools, automation, and standards that are
      implemented as a result of the inspection, as part of the adaptation.
      Scrum is the very simple mechanism that helps an organization be more
      effective in accomplishing its goals.

      I've been following the threads about type N, A, B, C and advanced
      Scrum. Although these may represent the engineering, personnel, and
      product management practices that an organization adopts as a result
      of Scrum's inspect and adapt, they aren't Scrum. I think we are
      mistaking the consequences of Scrum with Scrum itself.

      What may be most destructive about these supposed extensions is that
      they will divert people from the real work of Scrum ... seeing what is
      going on in their organization and going through the change process to
      become effective. And learning how to continually inspect and adapt to
      keep their organization's practices optimal. Instead, people may think
      that all of these things that use the Scrum name are advances in
      Scrum, templates that they can mimic and then, amazingly, they are
      advanced development organizations, also.

      We are running the danger of any small process. People want to make it
      bigger. Well, Scrum isn't bigger. Each organization's total ability to
      build complex products is certainly bigger, and hopefully continually
      evolving, but it isn't Scrum.

      Keep Scrum Simple.
    • mike.dwyer1@comcast.net
      Dave: WOW What a huge difference from your posts a year ago. You really need to tell us more about how you got to the point the customer capacity to absorb
      Message 99 of 99 , Apr 4, 2006
      • 0 Attachment
        WOW  What a huge difference from your posts a year ago.  You really need to tell us more about how you got to the point the customer capacity to absorb DONE was saturated.
        Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life

        The greatest oak was once a little nut who held its ground. ~Author Unknown
        -------------- Original message --------------
        From: David A Barrett <dave.barrett@...>

        > >I think someone else said that Scrum is a path, not a destination. I
        > >agree with that.
        > I agree too. With regards to "cookie-cutter" solutions, I highly doubt
        > that there are going to be any to be found for anyone.
        > Personally, I think that one of the key strengths of Scrum is that it is so
        > simple it is easy to make the adaptations that will make if a good fit for
        > a particular situation. I think that above all we need to hold on to that
        > simplicity, and continue to regard our adaptations as simply that;
        > adaptations and not improvements or evolements.
        > I've noticed that some of the people on the list have concentrated on
        > squeezing every last ounce of productivity out of a development team.
        > They've made adaptations that seek to reduce the downtime between Sprints,
        > and to strip out all extraneous distractions from the developers and to
        > deliver as much new functionality as quickly as possible. I'm sure this
        > makes sense within their situations, and I'm sure it seems natural to them
        > to assume that these same goals would be universal. From there, I have no
        > doubt it becomes easy for them to view their adaptations as the natural
        > "evolution" of Scrum.
        > Personally, I wonder what such a pace does to the developers over the long
        > haul. Where's the line between an exhilarating, rewarding and successful
        > environment and a sweat shop?
        > As a contrast, I noticed that Scrum is really good at choking off
        > development when required. A lot of customers aren't able to cope with a
        > virtual firehose of new functionality aimed a them. Around here, we're at
        > one of those points with one of our projects. We've almost completed an
        > early stage of development, and the customer is going to need some time to
        > experiment with the software, find out what works and what doesn't, plan
        > training for their staff, train their staff, implement the new software and
        > evaluate how it's going to change their world. I should add that this new
        > software represents a potentially enormous change to them, and the way that
        > they do their jobs.
        > In the meantime, they might want a couple of tweaks to what we've done, but
        > they can't tell us what the next step should be. We, the developers, can't
        > tell either and any work that we might do before we find out stands a very
        > good chance of being useless, unwanted or just plain wrong. Scrum handles
        > this. Nothing on the PB for this project bubbles up to a high enough
        > priority to make a Sprint Backlog. While we wait, we point the
        > functionality firehose at another customer.
        > My point on that is that we're all looking for something different.
        > Vanilla, out of the box Scrum provides a good starting place to achieve a
        > large range of different goals. Maybe Scrum needs someone like Ken to
        > remind us when we're getting caught up in our own situations and losing
        > track of larger world of software development.
        > Dave Barrett,
        > Lawyers' Professional Indemnity Company
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...
        > Yahoo! Groups Links
        > <*> To visit your group on the web, go to:
        > http://groups.yahoo.com/group/scrumdevelopment/
        > <*> To unsubscribe from this group, send an email to:
        > scrumdevelopment-unsubscribe@yahoogroups.com
        > <*> Your use of Yahoo! Groups is subject to:
        > http://docs.yahoo.com/info/terms/
      Your message has been successfully submitted and would be delivered to recipients shortly.