Re: Scrum illness, symptoms and possible treatments
- --- In email@example.com, "Clinton Keith" <ckeith@...>
>The question reminds me of a topic that was addressed at the XP Days
> We've been using Scrum for three years now and it seems as if a couple
> of teams are experiencing an increased drag from the lack of novelty or
> more of a robotic adherence to the Scrum practices. The Daily Burndown
> is a good example of a practice that they are following, but not taking
> full advantage of.
Germany conference in November. There was a session entitled "Turning
up the heat without getting burned." It dealt with just this sort of
thing - teams falling into a predictable and boring routine. The agile
mode of work seems to call for a certain level of intensity. When that
fades into monotony, some of the effectiveness of agile teams may be lost.
The presenters of that session would probably suggest looking for ways
to stir things up a bit; ways to "turn up the heat". Maybe introduce
some sort of process roadblock or deliberately dredge up a known (but
suppressed) interpersonal conflict. The point is to "shock" the team
into remembering principles by forcing them to confront some sort of
problem as a team (and not as a bunch of individuals).
Even something as mundane as physically moving the team might break
the logjam. Just sitting in different seats and looking at different
backgrounds might give them a fresh perspective.
It sounds like what you've got here is not a "process" problem that
can be addressed in a "mechanical" way such as doing super-short
iterations or increasing the measurements you make (daily burndowns,
etc.). It sounds more like a "human factors" issue.
>Ideally, only the Product Owner can drop stories (or at least, only
> - Lot's of dropped user stories.
he/she can choose which stories to drop when the team explains that it
can't meet its commitments). What's happening in your case? Why and
how are stories being dropped? Is it connected with another problem
you mention, that extra tasks tend to proliferate while the stories
don't change? Do the teams reflect on this and assess how they might
self-correct? Do the teams have Scrum Masters or process facilitators
under some other name? If not, consider adding this role; if the role
already exists, find out why they are not acting on these problems.
>Why are Product Owners / customers accepting the results, then?
> - "completeness" isn't quite there on stories that are marked as
> complete (bugs, lack of polish)
> - Lots of new tasks added during a sprint (without stories changing)
>Might need to prod team members into talking until they get (back?)
> - Very quiet daily scrums
into the habit.
> The question that I have is, apart fromThe beatings should continue until morale improves. That's basic
> beating the teams during the reviews, are there some exercises and
> coaching practices that can be used to help focus on these issues?
Management Science, after all. ;-)
I sure wish I had time to stay on this forum – lots of good stuff.
I’m curious about the people-factor characteristics… How would you describe their general attitudes, level of enthusiasm and other observations you may have noticed, such as inability to agree - even conflict, or negative hallway conversations? Do they surf or take breaks often or otherwise spend a lot of time socializing outside of work-related issues?
Have the teams ever really come together and developed into interdependent and cohesive teams? Did they ever really buy into Scrum? Have they been working overtime – do you think burnout and/or work-life imbalances? I wonder if there may be external, non-Scrum factors involved (layoffs, sociopolitical/organizational stressors, or consistent discouragements and disappointments.
How do you get along with the teams? Are you overworked, such as also doing the people management side as well as development? Do you lean toward Theory-X and/or Taylorism philosophies of management or do you like to be in control? Do you feel the team needs to be managed or coached into a self-organizing, self-directing team? Do you make task assignments or do they determine assignments? Describe the confidence you have in team members and the team. How well do you think you are leading?
Has the teams’ team formation and leadership ever been developed? Are there any strong personalities on the team? What is the typical load factor? Are there many distractions/fires to put out stealing their time? Are there hero developers on the team? Is there inconsistent (hypocritical) sponsorship or stakeholder support?
Have they openly communicated ideas and concerns often, and then no longer?
What is your role? Are you one of the Scrum masters or are you doing Scrum of Scrums and/or managing the Scrum masters? If the latter, apply the inquiry above to your Scrum masters as well. Also, how do the items mentioned above compare between the problematic teams and the others?
Was there a noticeable turning point, or was it more gradual?
If you are interested in this exchange, feel free to respond to me directly (Mark@...).