yes that is what I was saying.
Last year I blogged about it. you can read it here.
Post by s***@tieto.comHI,
Do you mean to say that you gather for retro and actually touch the code
for one hour and improve it?
Can you elaborate more on this?
*Sent:* Wednesday, November 20, 2013 10:29 PM
*Subject:* Re: RES: [scrumdevelopment] Retros repeating action items
something else I do, is when energy is low for retrospectives, is hold *work
retrospectives:*
that is: during the timebox of the retrospective, ask people to pair up
and thing about something they want to improve in teh code that they never
have time for. and ask them to do it.
one constraint: at the end of the retro they have to check their code in.
(or they should check in multiple times in between)
so whatever they do, it should be small.
What I saw the first time I did this;
- one pair that had totally not finished (aka not able to do work in one
very limited timebox)
- a few pairs had checked in some small improvement
- one other pair had done an improvement where everyone was complaining
for months they should do it, and nobody ever took the time. to their own
(and everyone else surprise) they had finished 18 of the 23 independant
tasks. And the quality had improved a lot. (one of the two developers,
finished the last 5 task the next morning)
I have redone this idea already multiple times at multiple clients ever
since, and always with similar great results.
you can compare it to Fed-ex days, or hackatons, yet now only 1 hour (for
1 week iterations)
yves
What works for me doesn't necessarily work for you. What works for you
doesn't necessarily work for me.
We each have our own inherent set of limitations. Some we can overcome if
we strive to understand and train them. For example, if I am not strong
enough to do something I can train to become stronger. However, if I am not
tall enough to do something I may have to find another way.
Because we are all individuals there is no best practice. At the same time
we are often more similar than we are different. So, most of what works for
you probably works for me. Just not ALL of it. To become better I must
1. What works for me and why, so that I can make it better
2. What doesn't work for me and why, so that I can mitigate or overcome limitations
3. What works for you and how I can incorporate it. If it works better it
may even supplant something I currently do
This was the philosophy that Bruce Lee used in his approach to the martial
arts, but it works pretty well for software and other things.
Of course a Best Practice exist. There is a best practice for breaking
an egg if one is a short order cook. It is very different than my (not
best) practice. But all really good short order cooks appear to use the
similar best practice - so it must exist.
Perhaps the problem is that you are all mixing up the domain within which
you are seeking answers and practices. Do you think that breaking eggs is
the same domain type as building software? I do not. One domain type is
very simple. One domain is very complex. Perhaps that is the distention
between when we should look for *A* best practice and when we should avoid
the concept that there is a best practice.
See: Cynefin Framework by David Snowden
We keep repeating the same action items every retro
SM: Why?
Because we are not making necessary changes to our process
SM: Why?
Because we don't believe the process works
SM: Why?
Because no one follows the process
SM: Why?
Because everyone is getting tired of the process
SM: Why?
Because whenever something goes wrong, people keep asking why
On Wed, Nov 13, 2013 at 1:39 PM, Charles Bradley - Professional Scrum
Yup. Good one!
-- Sent from iPhone
------------------------------
*Subject: *RES: [scrumdevelopment] Retros repeating action items
*Sent: *Wed, Nov 13, 2013 3:30:00 PM
Hi Charles,
This is a question I always wanted to make: "May I say that 'Avoid Best
Practice!' is one of your recommended best practices?".
Marcio
Professional Scrum Trainer and Coach
*Enviada em:* quarta-feira, 13 de novembro de 2013 13:22
*Assunto:* Re: [scrumdevelopment] Retros repeating action items
http://www.scrumcrazy.com/Best+Practice+-+Make+Retro+Action+Items+Highly+Visible
http://www.scrumcrazy.com/Best+Practice+-+Review+the+Action+Items+from+the+Previous+Retro+in+the+Current+Retro
Please forgive the usage of the term "Best Practice" (on my backlog to fix
that). It should say "Popular" or "Proven Practice" or something like that
instead. I have come to learn that "Best Practices" are a unicorn. (They
don't really exist)
-------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
ScrumCrazy.com <http://www.scrumcrazy.com/>
------------------------------
*Sent:* Wednesday, November 13, 2013 5:48 AM
*Subject:* Re: [scrumdevelopment] Retros repeating action items
Sharmilla,
The pattern I have noticed consistently when coaching teams is that this
problem is usually the result of treating symptoms rather than the root
cause.
When we pick fruit from a tree, more fruit grows back in another spot to
replace what was removed. Keeping the tree clean of fruit becomes daunting
and the team lets up so the fruit begins to grow back. Sometimes this re
growth makes the team believe the problems are impossible to solve so they
settle and become willing to work around them.
If I identify this as the case, I generally work with the team to help
them look beyond the painful symptoms and find the true root cause of
problems.
Circle of questions
5 why analysis
Asking powerful questions.
Cherie Silas
Sent from my iPhone
Hi,
I have been facing this problem that in retros the improvement gets
discussed but after a while when the focus is lost, it comes back in retro
that we need to improve this.
Which means that improvements are not becoming business-as-usual.
How do we make sure that the retrospections take teams to the next level
and not come back to same areas in a rhythmic way.
Any thoughts on this
Regds,
Sharmila