Agile not just about Methodology but also about team behaviour

[srini E]

Hi,
I believe that, Agile is also about team behavior (change to be agile) as much as it is a methodology.
How do we infuse Agile behavior into the team who have been doing non-Agile methodology for ages and make them appreciate the good things about Agile. For a good number of team size, going Agile would it be good? are there any exercises to appreciate Agile methodology.?

Regards,
Srini

[Clyde Smith]

I also believe that Agile requires a shift in team beliefs, values and behavior.

I am in a situation with a government agency; they have used Scrum successfully for another large effort and are now attempting to start up a new large effort.

We have many challenges; the top 2, imho, are:

1. The product owner is absolutely unwilling to commit. The "assigned" scrum master (assigned, but not really a pig; more of a chicken) enables this by allowing the product owner to put user stories like "As a product owner, I need to have the best web site for my users." into our sprint backlog. This scrum master is a CSM; and the product owner has been to training. I am not sure how to try to help him get beyond this behavior - and really not sure he's amenable to it! Any suggestions?

2. The team members are, obviously, frustrated by this - it leaves them feeling like they are just taking blind stabs at trying to meet sprint objectives. The mantra is turning into: "I don't have any development tasks to work on". As the unofficial scrum master (not recognized, but doing that role), how do I get the team members to go beyond the roles that they feel they were hired for and work as scrum team members? How do I help them see that we all have to work on every/ any task on the backlog - whether it involves writing code or not? (maybe I just answered that question on my own... )

Any specific thoughts/ advice on working in a scrum-like setting for a government agency? Sometimes it seems like we're trying to scrum - but certainly not in an agile way!

Thanks!

Clyde

[Amr Elssamadisy]

Hi Clyde,

Both of your questions are great, I'll address them in different posts. The first on:

1. The product owner is absolutely unwilling to commit. The "assigned" scrum master (assigned, but not really a pig; more of a chicken) enables this by allowing the product owner to put user stories like "As a product owner, I need to have the best web site for my users." into our sprint backlog. This scrum master is a CSM; and the product owner has been to training. I am not sure how to try to help him get beyond this behavior - and really not sure he's amenable to it! Any suggestions?

As you're painfully seeing, training doesn't mean change of behavior or actual understanding and adoption of new beliefs and values.

To start off with, you have a very difficult problem and there are no guarenteed solutions. But here are some issues:

1) You cannot change anyone's behavior, so don't even try. You can only change your own.
2) What you can do is step back to business values and process smells that your agency has. Why did you start doing Scrum? Was there a reason other than 'it is the latest and greatest?' There probably was. So, you may be able to have a conversation around 'is Scrum as we are practicing it meeting our goals?' That is the starting point. If the people you want to affect can see the problem themselves, then you have a chance of change.

Some good resources are:

Manns and Rising's: Fearless change
Avery's: Teamwork is an individual skill
and a new guy - Amr what's-his-name's: Agile Adoption patterns

[Amr Elssamadisy]

The team members are, obviously, frustrated by this - it leaves them feeling like they are just taking blind stabs at trying to meet sprint objectives. The mantra is turning into: "I don't have any development tasks to work on". As the unofficial scrum master (not recognized, but doing that role), how do I get the team members to go beyond the roles that they feel they were hired for and work as scrum team members? How do I help them see that we all have to work on every/ any task on the backlog - whether it involves writing code or not? (maybe I just answered that question on my own... )

This one is simple but not easy. You can't change other's behaviors (sorry, don't we all wish we could?) But the very best reference I have for this is Avery's "Teamwork is an Individual Skill".

A good idea would be to run a reading circle around the book, or better yet, bring Avery in to teach Knowledge Team Leadership. Human dynamics are the basis for any high performance team.

Good luck Amr

[Amr Elssamadisy]

I believe that, Agile is also about team behavior (change to be agile) as much as it is a methodology.

Agreed 100%.

How do we infuse Agile behavior into the team who have been doing non-Agile methodology for ages and make them appreciate the good things about Agile.

Umm... that fills a book. I think there is one by a guy named Amr Elssamadisy - Agile Adoption Patterns Also Christopher Avery's book - Teamwork is an individual skill - is a good foundation and so is Mann's and Rising's Fearless Change. (So it fills 3 books).

For a good number of team size, going Agile would it be good? are there any exercises to appreciate Agile methodology.?

Yes, Agile has been used successfully from teams of 1 to I believe 800.

[Ilja Preuss]

Originally posted by srini E:
are there any exercises to appreciate Agile methodology.?

There are a number of games (you might want to call them simulations instead) that can give big insights with a relatively low investement. See http://www.xp.be/xpgame.html for example.

[Katrina Owen]

Ilja, that is a fantastic link/resource!

I just love this bit:

To give the game a more "real world" sense, the game master may decide at the end of an iteration that "the specifications have changed". All stories written on cards of a certain color have no business value at all. This change retroactively applies to stories that have been implemented!

Katrina