2

I am really eager to hear different perspectives on team complacency about their Agile adoption. Is it the ScrumMaster's problem? The team's issue? The manager's fault? I can see so many complex webs here. I'd love to know what you think.

  • Could you please elaborate "team complacency" term, it's a big vague especially for non-English speakers – yegor256 May 12 '11 at 2:45
  • Complacency looks like this: a team no longer looks to improve. A team has no more enthusiasm about their work. A team resists change. If this occurs, I think a team is frankly no longer Agile. I also think the team will ultimately give up Agile. What are your expereinces? – Jean Tabaka May 22 '11 at 22:52
3

Literally, it's the team's problem and the ScrumMaster's issue.

The complacency is the effect, not the cause, therefore no particular person owns the effect, but, for sure, there is an owner for each of the causes. Focus on finding the causes and the owners should become clearly visible.

Scrum Master is the owner of each impediment and he owns the part about solving the issue. On the other hand, SM is not directly capable of solving every issue. Some may be solved by the team itself, some by the management and some by someone out of the loop, so big part of such issue is not owned by SM. Her job is to make others solve such impediments.

Regarding the complex connections, it is difficult to judge without making guessed assumptions, so I will only serve some questions:

  • Is the complacency the impediment? Why do you consider it so? Are there any drawbacks already?
  • Is the team overconfident? Have you talked about it freely? Have you described them your point of view on Agile adoption? Why did they ignore it?
  • What is more exaggerated? Is it your concern or their complacency?
  • Have you tried making the workshops about it? Did you run some team games to simulate and reveal the problems?
3

Answer D. None of the above! W. Edwards Deming, management theorist and systems thinker, said that 95% of performance issues are attributable to the “system” (work design, structure, management, processes, technology, etc.) and that only 5% are attributable to individuals. When teams get complacent it's usually due to "friction" they encounter within the system. You likely need someone who can understand the system and can affect change in that system. In my experience, people who are working "in the business" are too close to the situation and can't affect that kind of change. You may need someone in a separate role who can work "on the business", like an Agile Coach. Coaches can bring experience, specialized skills and a fresh perspective to teams whose practices have become stale. For example, someone in a coaching role can open teams up to new patterns or ways of doing things. They can work across teams to resolve inter-team problems. They can reinforce principles and values underlying the practices so that people keep fresh in their practices. They can lead a community of practice or help individual teams raise the bar on practices where the teams have self-identified opportunities for increased performance. Obviously, this works only when everyone (managers, ScrumMaster and the team) has an appreciation for the coach's input and it will in the end, require everyone who is working within the system to participate in the revitalization.

  • +1 for offering the systems-based perspective. Welcome to the site! – Mark Phillips May 16 '11 at 12:56
  • +1 ANnnnnnd, who is that person in "a separate role" who can elevate the complacency issue as one of the system? I fear a "complacent team" will receive blame for their behavior. Perhaps that is why complacent in the first place: lack of trust and resultant artificial harmony. – Jean Tabaka May 22 '11 at 22:59
1

You can't solve it by designing the right system. It is about people, more often then not. Each case has to be approached and understood individually so you can work with the people involved.

Adoption of a new process, and particularly adoption within an existing process structure, is highly individualized by each organization.

As you indicated in your question - there are many complex webs here.

Spend time learning and understanding the dynamics at work in each individual case. This is not so much a "systems" issue as a rich and complex "human nature" question.

If there are techniques you can use to encourage your desired behaviors, use them. But it is rarely the case that one size fits all. (You have to get to know the people and place.)

  • 1
    Hmmm. I DO think it is a "system" problem, no offense to you. What if the problem is that the organization never backed the team? What if the team was forced into "doing Agile" because some V.P. heard that it would make the team deliver faster? Perhaps it is the ScrumMaster's job to expose this. If so, what does one do? – Jean Tabaka May 22 '11 at 22:55
  • 1
    I also think that it's a "system" problem. Never blame people, blame yourself as a project manager. – yegor256 May 23 '11 at 1:01
1

Are you a team member or external to the team?

If you're in the team, as J.B. says above, ownership is not the issue. If you know there is a problem, regardless of your role you should raise it with the rest of the team. It sounds like a great topic of conversation for a retrospective. 5 whys or similar technique to get to the causes of the perceived complacency and take some team actions to resolve those seen as the biggest issue.

If you're external to the team, I'd definitely have a chat with the Scrum Master about it and get their views. Your perception as an outsider might be very different to how the team feel or, equally, your external view of the team could provide insight into a problem the team hadn't yet noticed.

  • Being prepared to raise the issue in the team is important. Being prepared to have someone outside the team prepare to support and challenge the team through 5 whys is also valuable. I agree it is a topic of retrospection potentially. Here is the dilemma I see: a complacent team won't speak up in a retrospective. Or, they won't have a retrospective at all. – Jean Tabaka May 22 '11 at 23:01
0

When someone asks this question, rather than "what should we do about it?" or "what potential causes should I consider?" it makes me nervous. I don't mean this in some idle collectivist fantasy sense, but what does it matter who "owns" the problem? and what do you mean by "own" here?

If a team shows signs of complacency, then surely that complacency will affect its performance, and surely that will show up in a value stream map or during a retrospective or in the occurrence of some unfortunate incident. If the team sees a symptom in any of those forms, then who owns the problem?

Now I could interpret your question as "Who should focus on detecting complacency on a team with a Scrum-my structure"? Well, "becoming complacent" seems like a risk to me: who has special responsibility for identifying and watching out for risk realisation indicators on a Scrum-my team? Scrum Master seems logical; manager seems logical; any senior team member seems logical. I would think that we'd want some redundancy built into the system so that at least 3 people are watching out for this kind of thing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.