Skip to main content

Agile team behaviours in large organizations, a SM reflection.

Last post 09:27 am May 26, 2014 by John Tyson
1 reply
04:32 am March 30, 2014

Hi all @ scrum.org

I attended PSM training, hold PSM1 and have Six sigma background.
My personal opinion of scrum is its a great framework and is very simple.
Certainly I don't have all the answers but do believe in what i do and trying to keep the
team together,Keep them interested, further their knowledge, coach on BP
always give a reason "why" and explain it and encourage.
When I started out my quest it was because I wanted to know more about scum and also why scrum
fails in organizations and had no real idea, now I can report back on what I learned.
i.e how does it go from scrum a framework to non framework, i.e just a name.

There was one great post on here https://www.scrum.org/Forums/aft/388
This concerned the PO behavior, its a long post but an educational read for some insight.
Behaviors should should make "sticky" status as its common and no frame covers this.


Background:
Recently I was a SM for a team of eight people in an organization.
A Large organization also containing mainly a demographic of 30-55 year old people.
Agile in place now for well over a year and running Sprints over that period.
This evolved from two teams of seven to post reorg one team of eight with one SM and KM.
I had the fortune to be coaching a team pre reorg that really could see why this worked
and was a real pleasure to work with, and one that I consider as a SM as a real success from
no real in depth understanding to "we get it" and what it can do for a team.
post reorg we had a mixed ability with some people really buying into what it is,
Some keen on learning and people just not interested and making it disruptive/problematic.
This is where it went wrong certainly for this team, two people disrupted the progress.


Problems and behaviors:
I had two members that eroded the development and real acceleration of the team.
The other team I was not responsible for before the merge certainly had a different way of
working. This goes back to Agility in name only, not scrum, not agile, not even waterfall,
more non structured and disorganized if i have to put a term on it.
There isn't a framework or method out there to compare with.

This may sound familiar so you can see how many you tick off as danger signs.
Always making issues when a very simple request was asked.
Sprint events always being called another meeting.
Not willing to commit to agreements such as be on time at stand up.
Sometimes not even bothering to attend the stand up.
Cant see any benefit in retrospectives.
No benefit in estimating tasks.
No benefit in updating work.
Meetings too long.(time-frame they agree to).
Meetings too short (time-frame they agreed to).
Too many meetings (all subject to having the option to decline).
Don't see the point in estimating. (didn't do that before you came).
We worked better before (even if you cant prove that to back it up).
We have always done it like that, this will not work.
Not willing to commit to the team as a team to an agreement that's made.
No real input to the team as a whole.
No matter what you do there will always be complaints.

As a SM I did all the right things for the team.
*Explained why we do things
*What those benefits are continually.
*Continually showed those benefits.
*Coached on all aspects of scrum.
*Tried to get them involved.
*Tried to get them to commit as a "team".
*Tried to get them to inspect and adapt as a team.
*Tried to get them to be brave and fearless.


This still wasn't enough for the members that were not buying in.
Generally made the life as a SM really difficult as they possibly could.
The team didn't have the confidence to deal with the situation as its not in their DNA.
Management wouldn't deal with the situation either.
As a SM have no real authority to do anything, "put up or shut up".
Rather than tackle the problem people generally put plasters on things is my point.
Teams, individuals, managers, why you ask? Because its as good a solution as any.
Usually one that pacifies until the next problem.
"Its okay"
"they find change difficult"
"give them more time"
"you have to understand their mindset"
I thought it may have been down to the most basic fundamental question
"Do they understand"
Had that most fundamental question not been asked, had they had any form of training?
The answer is yes and yes and also know of the company they received it from.
As a company its pretty solid without naming them.
We can tick off a basic understanding and I also coached through my time.


Reflections:
After several months of still getting the same responses,complaints and behaviors
With no real help in resolving the situation,It was too much to deal with as SM and
also undertaking full-time development team role.
Members that really wont move on, undermining the framework and generally causing problems
in the team does have an effect on teams,and also taking time from committed team members.
I too decided to follow my own advice and called time on SM Role with that team.
I did apologize to members who feel I may have let them down by stepping down
and they now have to live with the chaos afterwards.
This goes back to people happy to ignore things, say Agile doesn't mean you will do Agile.
A plaster is as good as any framework attitude in some big companies, and that's a real shame
Somewhere from the top that message is diluted and diluted and diluted and we end up with
teams like this who are left to run loose as its the easier option than tackling the problem



I look on that team I coached as a success for a percentage of that team, they understand what
scrum really is all about. They will go on with the following,
The right mindset, the right attitude, a desire for the knowledge and an understanding.
Thats all that really matters.
My point being that over time those few may encourage another few and the cycle continues
with the right mindset and at some point in time that catches up.
When coaching and explaining and showing benefits doesn't work, that's a behavior issue.
If you don't get any help in resolving that and the team wont resolve it.
you also have to consider your sanity as a SM as you cannot do it all, you are important too.
As SM should not have to do it all or be expected to, the team should accept that.
Some organizations are more "say-and don't do" than you think and will run for the plaster first.
Even large organizations, so don't be surprised by this.
Plasters are only good for a short while, the problem does not go away, we just repeat the cycle.



Summing up:
This may sound like a sad tale, indeed it isn't, its something I can share.
I now have a greater learning of problematic teams.
One other aspect is I have also know that "say-and don't do" is a huge problem at all levels.
Just because an organization says it is Agile (not going), doesn't mean to say they are Agile.
So far In my life have seen change fostered all the way in an organization once.
No dilution, and that company still is a success even now 15 years post change.
It produced some great mindsets and teams and that is reproductive and why its successful.
From that I can draw the following conclusions on commitment vs interest.
you will have high success of scrum adoption with full support across the organization.
if you don't get that support will have limited success of scrum adoption.
Limited success is better than no success as it also has its rewards.
The future will take care of the bigger rewards from the limited success of today.
Success is the key word here even if its limited, not failure and you get to keep your sanity as a SM.
:-)

michael


09:27 am May 26, 2014

Management wouldn't deal with the situation either.
As a SM have no real authority to do anything, "put up or shut up".



This is why management needs to understand SCRUM and buy off on it. They recommend that everyone in an organization, even top management, gets some kind of SCRUM training so they know what to expect and will back up the people implementing it.


It was too much to deal with as SM and also undertaking full-time development team role.



So you were both a Scrum Master and a Development Team Member? Technically allowed, but not recommended. I wonder if some of your Development Team Members were jealous of your SM role?

I will also add that this is where the self-organizing concept falls apart. I was on a scrum team where my fellow Dev Team members would not provide me with the details I needed to test their work. Our SM didn't help me either (the scrum team was more of a clique), so I had to go to the VP (next level up) to get cooperation and the VP was mad - at me, because the team was supposed to be self-organizing. Bottom line: If you don't have a mature group of people and management support, the team won't be successful.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.