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

Re: The Scrum project that failed - blog

Expand Messages
  • Alan Shalloway
    ... projects that ... things went ... Robin: Thanks for the courage it takes to post something like this. We had a somewhat similar experience years ago where
    Message 1 of 36 , May 17, 2008
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "Robin Dymond"
      <robin.dymond@...> wrote:
      >
      > I am interested to know about your experiences with scrum and
      projects that
      > didn't meet expectations. Is anyone else willing to discuss when
      things went
      > wrong?
      >
      > Robin.
      >

      Robin:

      Thanks for the courage it takes to post something like this. We had
      a somewhat similar experience years ago where we had a client with no
      real customer - just a business owner saying to do something. We
      recommended cancellation of the project for months before they
      finally did cancel it. While the project was a failure, it was
      cancelled months before it would have been without having recognized
      no real business need was being met.

      My own experience with projects doing Scrum is that most aren't
      actually doing Scrum. That is, when we come in to help/train teams,
      they say - we've been doing Scrum for X number of months. But when
      we ask what they are actually doing, it wouldn't qualify as Scrum to
      us, anyway.

      I find that the industry is in an interesting quagmire here. Many
      Scrum thought leaders say defining Scrum is a bad thing. They also
      suggest there are few Scrum practices that can be defined because the
      actual practices must be decided on by the team. While the later is
      true, I am not sure the former is. But what is odd, is I find that
      many people who have not had any training or coaching in Scrum feel
      they have little choice but to follow certain dogmatic principles.
      They've picked these up from Scrum books and comments by CSTs in the
      public domain (or so they've told me). Many of these are difficult
      for a team to just say they'll do. For example, a company that has
      been working in fire fighting mode for years will find it very
      difficult to tell management that they are not going to do that any
      more. How do they make a transition to that?

      When many practices are inferred as being necessary but not all of
      them can be followed, I've seen many teams pick and chose those they
      want to follow. This often results in total chaos and them thinking
      they are doing Scrum when they clearly aren't. An understanding of
      why Scrum works and on which practices it is based seems essential
      for such teams.

      These are some of the problems we've seen teams trying to adopt Scrum
      have when we started working with them:

      * Integrating architecture across teams
      * Time and team dependencies
      * Emerging technical designs
      * Off-shore work
      * Handling interruptions
      * Working on multiple projects at a time when management assigns
      projects this way

      We've had reasonable success helping teams with these problems when
      they've used Scrum in conjunction with other disciplines (XP
      Engineering practices, Design Patterns, Lean Software).

      It is important to note that the team can deal with some of these
      issues on their own, but some they can't. One of the essentials of
      adopting Scrum is getting management and teams working together.
      This is often problematic when many people believe a mantra of Scrum
      is "to protect the team from management". While I understand the
      need for having a team be focused, stating it this way frames a "we
      vs them" mentality of dev team and management (the Chicken and Pig
      metaphor also adds to this as I've commented on in the past).
      Better to start treating management as a partner and not as someone
      the team needs to be protected against. Simply telling management to
      behave doesn't do it either. They need something they can align with.

      This post of yours comes at an interesting time for me. I have been
      doing literally team Scrum training every week for the last 3-4
      months. This has given me an opportunity to see the challenges many
      different teams have been facing (gaming, IT, product, defense,
      education, ...). A common one is not having a clear understanding of
      the principles underneath the Scrum practices of:
      * focusing on one product at a time
      * keeping the team focused on business value
      * having a strong business sponsor
      * having the team swarm on stories
      * having a clear definition of what done means to the team
      * the proper unfolding of stories
      amongst others.

      I think it would be interesting to come up with a table that
      described the essential practices of Scrum, the principles behind
      them, how teams might modify them to work for them. In the real
      world, these have to include projects / products involving more than
      one team. Scrum has a team centric focus, but I haven't worked with
      a "team" in years. I think most individual teams who need to do
      Scrum are doing it - it's pretty easy for a team to pick up Scrum.
      But for an organization, it's another matter.

      I'd also be interested in people's thoughts about the ideas I have
      mentioned here. I continue to come to the conclusion that the
      impediments Scrum brings up which Scrum says must be solved cannot be
      solved just within the context of Scrum thinking (I don't believe it
      is sufficient to just say the team figures it out).

      Alan Shalloway
      CEO, Net Objectives
      Achieving Enterprise and Team Agility
    • Mark Levison
      Re reading this thread has made me wonder has anyone considered a repository for documenting failures? Perhaps the scrum alliance pbwiki even if all we did was
      Message 36 of 36 , Jul 5, 2008
      • 0 Attachment
        Re reading this thread has made me wonder has anyone considered a repository
        for documenting failures? Perhaps the scrum alliance pbwiki even if all we
        did was link back to posts like Robin's. Essentially I wanted Robin's
        Journal of Alpine Accidents except online.

        Thoughts?
        Mark

        -----Original Message-----
        From: scrumdevelopment@yahoogroups.com
        [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Robin Dymond
        Sent: May-18-08 1:53 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Re: The Scrum project that failed - blog

        One of my interests is climbing. When I was a member of the Alpine
        Club of Canada there was an annual journal called "The Journal of
        Alpine Accidents." Initially I thought this was odd. Once I started
        reading it the value instantly became clear. Climbing accidents make
        for gripping reading because lives are at stake. The real value is to
        other climbers who can read about what went wrong, what they did to
        correct, and how the events unfolded. This concept is not new, civil
        and mechanical engineering failures are studied, and we are all
        familiar with the painstaking work of the FAA when a plane crash
        happens.

        With billions of dollars on the line every day, and a spectacularly
        high rate of project failure compared to other engineering
        disciplines, shouldn't we be formally logging and analyzing failures?

        Or at least talking about them?

        Robin


        On 5/17/08, Alan Shalloway <alshall@...> wrote:
        > --- In scrumdevelopment@yahoogroups.com, "Robin Dymond"
        > <robin.dymond@...> wrote:
        >>
        >> I am interested to know about your experiences with scrum and
        > projects that
        >> didn't meet expectations. Is anyone else willing to discuss when
        > things went
        >> wrong?
        >>
        >> Robin.
        >>
        >
        > Robin:
        >
        > Thanks for the courage it takes to post something like this. We had
        > a somewhat similar experience years ago where we had a client with no
        > real customer - just a business owner saying to do something. We
        > recommended cancellation of the project for months before they
        > finally did cancel it. While the project was a failure, it was
        > cancelled months before it would have been without having recognized
        > no real business need was being met.
        >
        > My own experience with projects doing Scrum is that most aren't
        > actually doing Scrum. That is, when we come in to help/train teams,
        > they say - we've been doing Scrum for X number of months. But when
        > we ask what they are actually doing, it wouldn't qualify as Scrum to
        > us, anyway.
        >
        > I find that the industry is in an interesting quagmire here. Many
        > Scrum thought leaders say defining Scrum is a bad thing. They also
        > suggest there are few Scrum practices that can be defined because the
        > actual practices must be decided on by the team. While the later is
        > true, I am not sure the former is. But what is odd, is I find that
        > many people who have not had any training or coaching in Scrum feel
        > they have little choice but to follow certain dogmatic principles.
        > They've picked these up from Scrum books and comments by CSTs in the
        > public domain (or so they've told me). Many of these are difficult
        > for a team to just say they'll do. For example, a company that has
        > been working in fire fighting mode for years will find it very
        > difficult to tell management that they are not going to do that any
        > more. How do they make a transition to that?
        >
        > When many practices are inferred as being necessary but not all of
        > them can be followed, I've seen many teams pick and chose those they
        > want to follow. This often results in total chaos and them thinking
        > they are doing Scrum when they clearly aren't. An understanding of
        > why Scrum works and on which practices it is based seems essential
        > for such teams.
        >
        > These are some of the problems we've seen teams trying to adopt Scrum
        > have when we started working with them:
        >
        > * Integrating architecture across teams
        > * Time and team dependencies
        > * Emerging technical designs
        > * Off-shore work
        > * Handling interruptions
        > * Working on multiple projects at a time when management assigns
        > projects this way
        >
        > We've had reasonable success helping teams with these problems when
        > they've used Scrum in conjunction with other disciplines (XP
        > Engineering practices, Design Patterns, Lean Software).
        >
        > It is important to note that the team can deal with some of these
        > issues on their own, but some they can't. One of the essentials of
        > adopting Scrum is getting management and teams working together.
        > This is often problematic when many people believe a mantra of Scrum
        > is "to protect the team from management". While I understand the
        > need for having a team be focused, stating it this way frames a "we
        > vs them" mentality of dev team and management (the Chicken and Pig
        > metaphor also adds to this as I've commented on in the past).
        > Better to start treating management as a partner and not as someone
        > the team needs to be protected against. Simply telling management to
        > behave doesn't do it either. They need something they can align with.
        >
        > This post of yours comes at an interesting time for me. I have been
        > doing literally team Scrum training every week for the last 3-4
        > months. This has given me an opportunity to see the challenges many
        > different teams have been facing (gaming, IT, product, defense,
        > education, ...). A common one is not having a clear understanding of
        > the principles underneath the Scrum practices of:
        > * focusing on one product at a time
        > * keeping the team focused on business value
        > * having a strong business sponsor
        > * having the team swarm on stories
        > * having a clear definition of what done means to the team
        > * the proper unfolding of stories
        > amongst others.
        >
        > I think it would be interesting to come up with a table that
        > described the essential practices of Scrum, the principles behind
        > them, how teams might modify them to work for them. In the real
        > world, these have to include projects / products involving more than
        > one team. Scrum has a team centric focus, but I haven't worked with
        > a "team" in years. I think most individual teams who need to do
        > Scrum are doing it - it's pretty easy for a team to pick up Scrum.
        > But for an organization, it's another matter.
        >
        > I'd also be interested in people's thoughts about the ideas I have
        > mentioned here. I continue to come to the conclusion that the
        > impediments Scrum brings up which Scrum says must be solved cannot be
        > solved just within the context of Scrum thinking (I don't believe it
        > is sufficient to just say the team figures it out).
        >
        > Alan Shalloway
        > CEO, Net Objectives
        > Achieving Enterprise and Team Agility
        >
        >
        >
        >


        --
        Robin Dymond
        VP, Managing Partner
        Innovel, LLC
        www.innovel.net
        cell: (804) 239-4329

        ------------------------------------

        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.