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

Re: The Scrum project that failed - blog

Expand Messages
  • Robin Dymond
    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.
    Message 1 of 36 , May 18 10:53 AM
    • 0 Attachment
      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
    • 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.