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