Re: [scrumdevelopment] Tackling Agile lean change in a large org
- AgreedAll numbers are 1/4 the number 3/4 using your brain to interpret the numbers.
On Jan 30, 2010, at 6:17 AM, Alexander Kriegisch <Kriegisch@...> wrote:
Thomasjeffreyanders ontwin@Gmail. com, 29.01.2010 04:59:
>> Whatever you do, be aware that in the beginning you get quite a lot
>> of freedom to advocate and implement change. While you do this and
>> create transparency, resistance will grow in certain parts of the
>> company, because transparency can be unpleasant. This will slow you
>> down. A few months later, somebody might kill the whole agile
>> approach if there are no tangible benefits. So you better think
>> about how to measure progress. That the teams might like working
>> with lean/agile, will not be enough.
> Yes agreed, we are big on getting measurments in place, thinking of
> a bunch of metrics, some examples...
> Work to build over work to fix per feature
> Trouble tickets at help desk per release
> Cycle per t- shirt sized feature
> Defects over time
> Cycle time
> Of course these are all IT metrics we need to tie in business
> metrics as well, but sometimes the usual suspects can be hard to get
> at (roi, roe, etc)
> If you have any ideas on metrics I'm all ears...
I am not suggesting any specific metrics, but trying to point out a
bootstrapping problem: Even though you might introduce simple metrics
such as velocity in an environment where there did not exist any useful
metrics before Scrum introduction, you might have a hard time proving
that anything has improved because you have no pre-Scrum metrics which
you can compare the new and hopefully improved situation with. You might
be able to compare stuff one release cycle from now, but I am not sure
if you get enough time from your management. They are usually impatient,
unwise though that may be. So try to record the status quo *before* you
start 'scrumming' and be able to use it as a benchmark.
As for defect rates, be careful: A new feature such as automated crash
reporting or a bug report wizard in your software might trigger a flood
of new trouble tickets which will help you improve the product but make
'bug rates' skyrocket if you merely compare the numbers.
>> Record the status quo and concentrae on making improvements,
>> however small they might be. Document them and be able to report
>> them whenever asked. Try not to focus on eliminating problems,
>> because everyone will think you are a smart-a**. Try a
>> solution-focused approach and try to motivate people not just to
>> make fewer mistakes and produce fewer waste, but tell them: "There
>> is a considerable amount of good stuff here. How can we make more
>> of it?"
>> I told you this because I was a smart-ass too often, just because
>> I wanted to help people and solve problems. It turned out they did
>> not want me to solve problems, even though they said so. What they
>> really wanted was to improve their situation.
> Interesting but I think I would need a more concrete example,
> anything to keep me from falling in the same trap :)
Let me tell you a little story about a Scrum coach who started his
carreer as a software developer because he *loves* to solve problems,
sometimes just for the sake of it. So whenever he saw a problem, he felt
tempted to point it out to others and offer his help and good advice
about how to solve it. He was very constructive, not just mentioning
problems but also possible solutions. Anyway, while he thought that he
was a particularly nice guy because he tried to help others, they
thought he was rude because he kept laying his finger into their wounds,
showing them what was wrong - or worse, what they were doing wrong.
Sometimes they did not even agree with him that a problem existed at
all, because it had always been like that. In the same instant the Scrum
coach was seen as a smart-ass, especially because he was rather blunt
than diplomatic in nature because he thought (and actually still does)
that the truth is always the best thing to say. Unfortunately, not
everybody thinks like he does...
So, if you are anything like this guy, try to resist the urge to talk
about problems all the time. Talk about how to improve the current
situation. Focus on solutions  rather than problems, and try to find
out how to make people want those improvements. If they don't, even the
best improvement idea will be useless.
 Solution focus: http://www.sfwork. com/jsp/index. jsp?mnk=c10
Bottom line: An impediment list is an important and helpful tool, but
try not to rub impediments into people's faces all the time.
Probably I am disappointing you once again, giving general rather than
concrete advice, but I think it would be charlatanry to offer concrete
advice about something I do not know much about: your concrete situation
and the people involved. I try not to do 'remote diagnosis' like that.