Re: Scrum is bad for employees (apparently)
- --- In firstname.lastname@example.org, "David H." <dmalloc@...> wrote:
>The SMs attended the certification class, but as many of you have
> On 01/08/06, woynam <woyna@...> wrote:
> > Unfortunately, my experience has shown that as Scrum get adopted, 20%
> > of Scrum practices will be ignored by the professionals, and 40% of
> > the practices will be ignored by management, with little turnover.
> Where is the coach or Scrum Master then?
> This is one of the things I will not have nor did I ever allow them.
> Of course, as an external coach, it is easier for you to break with
> paradimes, but still. You need to put your foot down. Some rules are
> not broken, period.
experienced, some of them simply didn't "get it", i.e. the agile
principles. At other times, the SMs felt powerless, since they don't
actually wield any power. If the team chose not to self organize, or
ignore agile practices, there wasn't much the SM could do, especially
if the managers weren't themselves 100% committed. Often the managers
would pull team members temporarily off the team to work on other
problems, violating the principles of agile.
The sad reality, as many of us have experienced, is that it's easier
to adopt the agile label, and use a few practices, e.g. daily meeting,
than learn what it really means to be agile.
> > Sigh.
> > They'll call it 'Scrum', but they won't really embrace the principles.
> > Too many organizations find it easier to bend the process to fit their
> > existing culture, than fundamentally change the staff, or replace
> Yepp, but as I said above, if you do not allow yourself to be bent,
> then you can make a difference. Sometimes being laid off because you
> believed in something is not such a bad thing. I know that it scored
> me a job once.
(responding to Paul)
Do you censure or reward performance for the team as a whole,
or for individuals? Scrum is good at exposing problems. We get
to choose how to address them. You might find Alistair Cockburn's
writings on "Personal Safety" (e.g. in Crystal Clear) worth reading.
I reward both individuals and teams. I’ve always made it clear that the team succeeds together or fails together and that I don’t care if a poor team member causes a sprint to fail because it’s “all for one and one for all”. On the flip side I am also very much aware of the performance of individuals as I want to make sure that good people don’t feel badly done by because they struggle with poorly performing team members.
Thanks for the tip on the book. I’ll head off to the shops at lunch and have a look.
- I have also encountered some turnover with teams adopting agile. I'd have to venture out and say that something must be working if a couple of people cannot stand what it exposes. It's my opinion that these are the same people who were probably hiding behind bureacracy all along.I've experienced the Cowboy Coder, the Houdini, the Bad ScrumMaster, and the Sneaky Product Owner - and some companies allow this bad behavior in the name of self-managed teams. I have also seen the Turbulent Tester and this person remains with the team because he has proven to be the (loud) voice of quality and reason on the team. Sometimes not all 'bad' traits are bad; giving people a chance is certainly worth what comes out of their own self-discoveries. And, also, not all can make it through the change.Not everyone will agree with a new methodology all of the time. That goes for waterfall or agile. And this thread is also correct in stating that many teams/programs/companies adopt the agile designer label, but alas, there's nobody filling out the pants. Seeing lots of this lately. It takes a willing leader (at the director or C level) to stick her neck out and believe in the principles - not just sign the checkbook.
- We've had some turnover at my company after adopting scrum. We've been through two developers and a QA tester. It is hard for some people to get out of old habits. For the developers the idea of having to write code that works (unit tested, and checked into the build) and always being able to have a near shippable product is a big change. They're used to letting guts hang out and not have to worry about the mess until the mad rush towards the end, and let QA find all the issues and report them back to be fixed!Our QA manager was never able to relax and allow for acceptance testing early in the iteration. They insisted on testing everything at the end when the code was completely "frozen."On Jul 31, 2006, at 5:45 PM, Richard Banks wrote:
- Stacia wrote:
> I've experienced the Cowboy Coder, the Houdini, the Bad ScrumMaster, and the Sneaky Product Owner - and some companies allow this bad behavior in the name of self-managed teams. I have also seen the Turbulent Tester and this person remains with the team because he has proven to be the (loud) voice of quality and reason on the team. Sometimes not all 'bad' traits are bad; giving people a chance is certainly worth what comes out of their own self-discoveries. And, also, not all can make it through the change.Agree on Stacia's statements. When these become visible issues, it is important to get these issues addressed using open, honest, respectful methods. "Fearless Change" describes the late adopter and the laggard. Bringing along a late adopter has been very beneficial in my experience as well as providing the Skeptic role that helps us be thorough.
- Richard Banks writes:
> Employee B (who just happened to be mentored by Employee A)That's one possible translation. I hope you allowed for other
> left because "scrum is too restrictive". "What do you mean?"
> asked innocently. "Well", came the reply, "when I have to do
> a job I really like to investigate it, to understand what's
> going on deep in the code, to really get a feel for the inner
> workings of the problem and the intricacies involved. Having
> to deliver every 2 weeks means that I don't really have time
> to do a lot of investigation. There are a lot of things I do
> at home that could really improve the product and I don't
> get to try them here because we keep having to do things from
> the backlog".
> Translation: I can't muck around and play as much as I used
> to. Why don't I get to decide on my own how the product works.
> Scrum means I'm accountable for my time and I don't like that.
possibilities. "I like to ... understand what's going on deep
in the code" might mean "I don't understand what's going on
deep in _this_ code." That could say something about employee
B, or it may say something about the state of the code base.
Sometimes it's the newer employees (I'm assuming B was a
newer, based on his being mentored) who are the first to
notice a design or refactoring deficit that the old-timers
have grown numb to.
"There are things that could improve our code base that I
don't get a chance to try" can also mean "This code base is
stale and we're not letting in new ideas". If you're one of
the old hands who had the original ideas, this can be hard
to hear and easy to dismiss. But it is worth checking out,
since a stale, debt-ridden code base can be a barrier to
lots of things, including bringing new people in to the
team. This might be a good agenda item for your team's next
- dwsmtnview wrote:
> Richard Banks writes:Hi Dave,
> > Translation: I can't muck around and play as much as I used
> > to. Why don't I get to decide on my own how the product works.
> > Scrum means I'm accountable for my time and I don't like that.
> That's one possible translation. I hope you allowed for other
> possibilities. "I like to ... understand what's going on deep
> in the code" might mean "I don't understand what's going on
> deep in _this_ code." That could say something about employee
> B, or it may say something about the state of the code base.
> Sometimes it's the newer employees (I'm assuming B was a
> newer, based on his being mentored) who are the first to
> notice a design or refactoring deficit that the old-timers
> have grown numb to.
Not wanting to speak for Richard, but yes those are indeed alternative
translations and possibilities worth exploring in some instances. In my
experience a disruptive team member can unbalance the team and cause
considerable pain for everyone. Usually it doesn't take much people
management skills to determine whether an individual is genuinely trying
to make a postive contribution and needs help or whether they are hell
bent on being disruptive.
When it is the latter IMO as a leader you must act, and act quickly. A
good analogy IMO is sport. A good coach doesn't hesitate in getting rid
of a player who is disrupting the team. If you do not act, you
jeopardise your credability and trust with the other team members and in
so doing reduce your effectiveness as a leader. After all who wants to
follow someone unable to make decisions?
BTW. Acting may mean exploring the problem as a team, and deciding that
as a team we will help and address the concerns of employee B, but if
after a while the team concensus is still that employee B is a pain,
then that person should go.