--- 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