Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

scrumdevelopment · Scrum Users

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 7476
  • Category: Development
  • Founded: Feb 1, 2000
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Real people. Real stories. See how Yahoo! Groups impacts members worldwide.

Messages

Advanced
Messages Help
Messages 29000 - 29029 of 56953   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#29000 From: Ilja Preuss <it@...>
Date: Thu May 1, 2008 7:34 am
Subject: Re: Re: Scrum / Agile Guidelines and Checklist
ipreussde
Send Email Send Email
 
MacKilby wrote:

> That being said, I have no problem if this document is a charter for
> an individual team.  Some teams I've found do need this codification
> at the start, but it ends up becoming a disposable document as trust
> builds on the team (and I'm thinking PO, SM, and developers when I say
> team).

I agree, when the document states what the team members expect from each
other, and when all the team members agree that it is the right thing to
do, and agree on the content of the document. That is, when the document
is the *result* of a conversation between all the affected people.

That's not what I understood Michael's situation to be. It sounded to me
as if the document codified what the team expected from "outside"
members, and as if those possibly even hadn't been asked whether they
wanted such a documented, and as if the document came *before* the
conversation with all those affected. To the amount that this impression
is correct, it would trouble me.

Cheers, Ilja

#29001 From: Simon Kirk <scrum@...>
Date: Thu May 1, 2008 7:30 am
Subject: Re: Re: Specific Change Capacity (was: Scrum Master 360 degree feedback)
sikirkgb
Send Email Send Email
 
Hi Eb. I take your points, just a quick couple of thoughts:

1. By rail-roading their retrospective I meant that I didn't want to
drive the retrospective solely towards what I thought they needed to
improve. If the team identifies something as an issues, it's probably
best to aim to resolve that in some manner, even if I include a bit of
a nod in the direction that I think they should improve. If I do
decide to drive them towards something else I'd better have a good
reason, and make the decision collaboratively with the team.

2. A wider retrospective is something I would look for, too: I think
there you're referring to the team providing me with change items, in
much the same manner as Tobias suggested.

3. My concern for the team is often not engineering related, despite
my wont :)

4. As for having the PO in retrospectives - well that's another thread
that I'm about to start ;)

Cheers for the answer.

S

On 27 Apr 2008, at 17:19, Eb wrote:

> Simon,
>
> Thought I'd jump in here and offer a thought. I'll lead with the
> general Lean / Systems
> thinking viewpoint that you should avoid locale specific
> adjustment / improvement efforts
> and focus on tuning the whole beast.
>
> When you say that you don't want to railroad 'their' retrospective
> (by adding more wider
> change?), I think you should look to a wider retrospective format
> that includes you and
> maybe the wider business 'value' produced by your efforts.
>
> Its great that the team are keen to improve specific engineering
> practices, I know from
> experience how nice it is to focus your efforts on 'engineering
> stuff' - but don't let them
> become blind to the larger mission of delivering value to your
> customer and business.
>
> The finest piece of code will not deliver value if, for whatever
> reason it is functionally (biz
> value) redundant. I think that's where you and the PO (and the rest
> of your company) fit in
> and why you need to bring that into the retrospective process.
>
> I don't think you need to add to the overall volume / amount of
> change the team is
> exposed to, but you could look at wider, smaller, incremental
> change.  I think an
> organisation can evolve but you need 'everything' to change, a
> little, all at once: rise,
> repeat.
>
> Cheers,
> Eben
>
>
> --- In scrumdevelopment@yahoogroups.com, Simon Kirk <scrum@...> wrote:
>>
>> Hi Tobias.
>>
>> I thought I'd start a new thread on this riff since it's slightly
>> departing from my original subject.
>>
>> Using the Scrum process as you admonish is exactly what I'd like to
>> do. However, even when we're doing two-week sprints (thus getting a
>> significant amount of retrospective chances), the amount of change we
>> can come up with AND effectively act on is pretty limited. A team's
>> "Specific Change Capacity" (to crib a physics term) is really a
>> fairly
>> small amount (I have seen it written in this list before by Esther
>> Derby iirc that the same is true for organisations, that being they
>> can only absorb so much change at a time, making Agile adoptions a
>> drawn-out process).
>>
>> Assuming that to be true and bearing it in mind: My team is very much
>> focussed on improvements on their Agile technical practices (pair
>> programming, test coverage, continuos integration, etc etc). I am not
>> about to rail road their retrospectives towards what I think they
>> should prioritise (particularly as I recognise the very pressing need
>> for improvements in all the areas they identify anyway), so where
>> does
>> the time come for the kind of individual growth via retrospectives
>> we're talking about here when my team is so busy changing everything
>> else?
>>
>> S
>>
>> On 27 Apr 2008, at 01:25, Tobias Mayer wrote:
>>
>>> Hi Simon.
>>>
>>> Whatever it is you are looking for... affirmation, criticism,
>>> guidance... I think you are looking in the wrong place.
>>>
>>> Firstly most performance reviews, even the 360 one you are using are
>>> linked directly to salary adjustments.  This is inherently flawed as
>>> Mary Poppendieck points out (as quoted
>
here:http://runningagile.com/2008/01/22/review-process-for-agile-team-members/)
>>> .
>>>
>>> Secondly, even if the performance review is decoupled from the
>>> salary issues I still think it is a flawed and outmoded idea.  Such
>>> a review process sets up a fake environment, far removed from our
>>> everyday work context.  As a result people behave differently and
>>> the feedback offered generally bears little relation to true
>>> feelings and interactions.
>>>
>>> Chad Eaves stated: In order for feedback to be of value, people need
>>> to feel safe in giving it.  This is undeniably true.  Setting up a
>>> special feedback environment (the review process) is not going to
>>> create that safety.  On the other hand, a familiar and routine forum
>>> perhaps will, so use your retrospectives to find what you are
>>> looking for.  Perhaps it is time to take the retrospective to
>>> another level -- a more personal one that is born of camaraderie and
>>> trust -- and yes, courage.
>>>
>>> Thirdly, I am passionately opposed to any form of anonymous
>>> feedback.  I believe it is absolutely without value.  Performance
>>> Reviews promote the idea of hiding information (i.e. hiding the
>>> identity of the reviewer).  This is destructive and causes all kinds
>>> of unresolved, and unresolvable, bad feelings to be surfaced and to
>>> linger.  In a retrospective setting we are accountable for the words
>>> we speak.  Accountability is an essential feature of a healthy Agile
>>> environment, and one we should always be promoting. It is, after
>>> all, an element of transparency.
>>>
>>> So I want to suggest that anyone on this list struggling with how to
>>> run performance reviews, simply throw the whole concept into the
>>> trash (it usually represents massive waste) and use the Scrum
>>> process to continuously provide the kind of honest and truthful
>>> feedback we all need as workers, as humans.
>>>
>>> Tobias
>>> http://agilethinking.net
>>>
>>>
>>>
>>> --- In scrumdevelopment@yahoogroups.com, Simon Kirk <scrum@> wrote:
>>>>
>>>> Hi Chad.
>>>>
>>>> Nice points!
>>>>
>>>> I find it interesting that a significant percentage of the talks I
>>>> attended at last year's Scrum Gathering in London (Roman Pilcher's
>>>> Product Owner talk sprints to mind as an example) had a sheet
>>>> asking
>>>> for explicit and immediate feedback on his course, while the
>>> gathering
>>>> as a whole had a wall for providing feedback on the gathering
>>> itself.
>>>> I'm sure that Chicago's one did, too.
>>>>
>>>> So maybe giving such feedback is seen as safer, in an agile
>>> environment?
>>>>
>>>> I hope I've grown enough feeling of safety in the team by now, but
>>>> it's well worth keeping in mind. Thanks.
>>>>
>>>> S
>>>>
>>>> On 26 Apr 2008, at 15:59, Chad Eaves wrote:
>>>>
>>>>> A big obstacle in feedback is human nature and cultural, I
>>> believe.
>>>>> Far too often, people are not accustomed to being asked for their
>>>>> feedback, especially if it is directed towards a boss/employer-
>>> type
>>>>> person. I teach a Junior Achievement class once a week and asked
>>>>> senior students for feedback on my presentation and they looked
>>>>> stunned. Getting them to offer feedback is one of my goals in my
>>>>> course. I'll let everyone know how that is at course end.
>>>>>
>>>>> In order for feedback to be of value, people need to feel safe in
>>>>> giving it. Unfortunately, companies have undermined this value.
>>>>> How often has an "anonymous" survey tool turned out not to be so?
>>>>>
>>>>> Unfortunately, fostering this safe feeling takes time. And as we
>>>>> all know, that is something we usually do not have an excess of on
>>>>> projects.
>>>>>
>>>>> Without surmounting the personal security issue, great questions
>>> may
>>>>> yield little value.
>>>>>
>>>>> Chad Eaves
>>>
>>> ---------------------
>>>>>>> Original Post...
>>> On Thu, Apr 24, 2008 at 6:08 PM, Simon Kirk scrum@
>>> wrote:
>>>
>>> Hi all.
>>>
>>> We're going through performance reviews at the moment and I've been
>>> trying really hard to move away from the traditional small-company
>>> quick chat, pat on the back and on-you-go for another year "review"
>>> process that has been my experience for the companies I've worked at
>>> before.
>>>
>>> On the other hand I abhorred the thought of going down an ultra-
>>> bureaucratic HR-style route such as I imagine happens in big
>>> companies. Instead some Googling turned up this, which so far
>>> seems to
>>> be going well:
>>> http://runningagile.com/2008/01/22/review-process-for-agile-team-members/
>>> (really it's Jeff Sutherland's original posting on an Agile Team
>>> review process, but with some additional quotes at the start and a
>>> bit
>>> of tidying).
>>>
>>> Now, I was thinking about how I as the Scrum Master could get
>>> reviewed
>>> by my team - if 360 degree feedback is good for them, surely it's
>>> good
>>> for me? One of my team also asked for an opportunity to "review the
>>> reviewer", but nowhere can I find good examples of how a Scrum
>>> Master
>>> can be evaluated, let alone by his or her team.
>>>
>>> For instance, taking the above URL as context, I'm not sure what the
>>> right questions are the team should be asked about me.
>>>
>>> Has anybody got any pointers, I'd really appreciate the help?
>>>
>>> Thanks,
>>> Simon
>>>
>>> ps. No more yearly reviews, either: I've taken this opportunity to
>>> move to two monthly, despite the additional overhead. If anybody has
>>> any comments on that I'd be happy to hear them, too.
>>>
>>> pps. Yes, we do Sprint retrospectives: they're brilliant, but
>>> sometimes they lack the one-on-one that people need occasionally,
>>> ime.
>>> Again, any comments feel free.
>>>
>>>
>>
>
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...
> ! Groups Links
>
>
>

#29002 From: Simon Kirk <scrum@...>
Date: Thu May 1, 2008 7:31 am
Subject: Re: Re: Specific Change Capacity
sikirkgb
Send Email Send Email
 
We get to think like fighter pilots? How cool is that!? :)

Very interesting thoughts thanks Mark - definitely some tools to take
and run with.

Cheers,
Simon

On 27 Apr 2008, at 21:11, Mark Jean wrote:

> Steal a technique from equally busy people - fighter pilots. The
> below is what some squadrons use for their weekly training. It's
> simple & works. (It nudges people in the right direction - and
> builds teamwork.)
>
> Create "SME" (subject matter expert) & weekly "Developer
> Training" programs.
>
> 1. Ask your team to email you the "subject matters" they feel are
> important enough to need an "expert" assigned.
>
> 2. Organize & prioritize the subject areas (the ones most important
> to your work). Note any areas that will require time for someone to
> get up to speed on - you'll schedule those further in the future.
>
> 3. Create a 12 month schedule for weekly lunch-time " Developer
> Training." Friday's at lunchtime (believe it or not) works best. The
> plan should take into consideration upcoming requirements. Plan 2-3
> for each month. For the weeks you'll do training, schedule 1-2
> classes - each lasting a *maximum* of 20-30 minutes (45 min total).
> Hold everyone to this limit. Don't schedule classes on weeks where
> major milestones or reveiws will occur. (Update this 12 month
> schedule each month)
>
> 4. Assign each person 1-3 subject areas. Make one of the topics
> their strong suit - and another an area they've indicated to you
> they'd like to learn. Talk to each person - to get their o.k. Make
> sure you know how much time they need to get ready to present - and
> which they'd like to present first.
>
> 5. Look around your local area for other resources (SMEs) for
> pertinent training. Try to get outside trainers at least once every
> month or two.
>
> 6. Schedule the presenters into the 12 month schedule & let everyone
> know. Post/email the 12 month schedule. (Update this monthly)
>
> 7. Prior to Friday, *always* conduct a review of each presentation.
> Always. Do it at lunch the Wednesday prior.  It forces the presenter
> to complete their training presentation on-time (Wed). Also, it
> gives them an opportunity to practice. You will uncover room for
> improvement. It also reduces the presentation time. (Will take less
> of your team's time on Friday - and be more effective.)
>
> 8. For Friday, arrange to get everyone's order for lunch. Make sure
> lunch arrives on time. Keep the atmosphere professional, respectful
> & fun. Quizzes are o.k. - as long as there's no retribution for
> mistakes. Stupid questions are o.k. The focus is on learning from
> each other, and enjoying each other's company.
>
> Notes:
> The best teams do this - but it takes a little effort & discipline.
> However, it's cheap. It only takes a couple of hours per week.
>
> Alternatively, Thursdays work too - but do the reviews on Tuesdays.
> Lunches seem to always work best.
>
> If there's a negative person, counsel them separately & ask them to
> cheer up.  If someone in the group thinks team training is a joke,
> their value to the group probably should be reviewed.
>
> As the leader, use the intro time to also refocus on goals, boost
> morale, and sincerely praise members of your team. Rotate the praise
> around.
>
>
> ------------------------------------
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...
> ! Groups Links
>
>
>

#29003 From: Simon Kirk <scrum@...>
Date: Thu May 1, 2008 7:50 am
Subject: Off-site POs and their (in)attendance record
sikirkgb
Send Email Send Email
 
Hi all.

Following the recent thread about retrospectives, Eben mentioned about
PO presence in them. This reminded me about a long-standing worry I've
had (probably the same for most other bespoke software houses like
us): that the PO is not on-site and is far enough away that they
cannot be on-site more than once a week at best.

For starters a note of what I hope is wisdom (if anybody disagrees,
please let me know because I'd love to know your reasons):

I believe that the ideal circumstance is that the PO would be
regularly co-located with the team (iirc somebody wrote that it's best
if they're not right there in the team space, but literally just off
to the side, so they can get involved, but are not buried under the
team's feet).

Sadly as said, not the case for us.

One of the biggest resulting problems is lack of communication: POs
miss out on the chance for the osmotic communication process in the
team room: they can't overhear things of importance. Therefore I've
suggested to the team to try thinking as if the PO IS in the room at
all times: In other words they could potentially overhear all those
little problems that happen during the day, technical or otherwise.

This means that if we have a problem of some sort where normally the
team would be tempted to just try and fix it, without reporting it to
the PO, to remember that normally the PO would have overheard the
problem and known about it anyway, so rather than just fix it, report
it to them too (via email, phone, whatever).

Yes as SM I could do this for them, but that adds further overhead of
me letting the team members involved that I'm going to be telling the
PO, etc etc. I prefer the team and PO communicate openly rather than
relying on me as a conduit.

What do people think of this?


Finally, my retrospective worry: Since my POs can only do one day a
week, they can therefore only be with us long enough for a backlog
grooming meeting mid-sprint (working fine) and one day for planning.
As such the planning day is spent doing the sprint review first (of
course without stake holders present, another worrying factor for me -
I have to rely on the PO spreading the knowledge of completed work
throughout their organisations) then four hours worth of planning (we
do two-week sprints).

This means the PO is not able to attend the retrospective: We do that
before the planning day. So, how bad do people think this is? I think
there's a lot of things that would benefit the PO by being at the
retrospective, so should I and how might I go some way to making up
that benefit to them despite their inability to attend?

Cheers,
Simon

#29004 From: Simon Kirk <scrum@...>
Date: Thu May 1, 2008 9:02 am
Subject: Re: Re: Specific Change Capacity (was: Scrum Master 360 degree feedback)
sikirkgb
Send Email Send Email
 
Hi Eb. I take your points, just a quick couple of thoughts:

1. By rail-roading their retrospective I meant that I didn't want to
drive the retrospective solely towards what I thought they needed to
improve. If the team identifies something as an issues, it's probably
best to aim to resolve that in some manner, even if I include a bit of
a nod in the direction that I think they should improve. If I do
decide to drive them towards something else I'd better have a good
reason, and make the decision collaboratively with the team.

2. A wider retrospective is something I would look for, too: I think
there you're referring to the team providing me with change items, in
much the same manner as Tobias suggested.

3. My concern for the team is often not engineering related, despite
my wont :)

4. As for having the PO in retrospectives - well that's another thread
that I'm about to start ;)

Cheers for the answer.

S

On 27 Apr 2008, at 17:19, Eb wrote:

> Simon,
>
> Thought I'd jump in here and offer a thought. I'll lead with the
> general Lean / Systems
> thinking viewpoint that you should avoid locale specific
> adjustment / improvement efforts
> and focus on tuning the whole beast.
>
> When you say that you don't want to railroad 'their' retrospective
> (by adding more wider
> change?), I think you should look to a wider retrospective format
> that includes you and
> maybe the wider business 'value' produced by your efforts.
>
> Its great that the team are keen to improve specific engineering
> practices, I know from
> experience how nice it is to focus your efforts on 'engineering
> stuff' - but don't let them
> become blind to the larger mission of delivering value to your
> customer and business.
>
> The finest piece of code will not deliver value if, for whatever
> reason it is functionally (biz
> value) redundant. I think that's where you and the PO (and the rest
> of your company) fit in
> and why you need to bring that into the retrospective process.
>
> I don't think you need to add to the overall volume / amount of
> change the team is
> exposed to, but you could look at wider, smaller, incremental
> change.  I think an
> organisation can evolve but you need 'everything' to change, a
> little, all at once: rise,
> repeat.
>
> Cheers,
> Eben
>
>
> --- In scrumdevelopment@yahoogroups.com, Simon Kirk <scrum@...> wrote:
>>
>> Hi Tobias.
>>
>> I thought I'd start a new thread on this riff since it's slightly
>> departing from my original subject.
>>
>> Using the Scrum process as you admonish is exactly what I'd like to
>> do. However, even when we're doing two-week sprints (thus getting a
>> significant amount of retrospective chances), the amount of change we
>> can come up with AND effectively act on is pretty limited. A team's
>> "Specific Change Capacity" (to crib a physics term) is really a
>> fairly
>> small amount (I have seen it written in this list before by Esther
>> Derby iirc that the same is true for organisations, that being they
>> can only absorb so much change at a time, making Agile adoptions a
>> drawn-out process).
>>
>> Assuming that to be true and bearing it in mind: My team is very much
>> focussed on improvements on their Agile technical practices (pair
>> programming, test coverage, continuos integration, etc etc). I am not
>> about to rail road their retrospectives towards what I think they
>> should prioritise (particularly as I recognise the very pressing need
>> for improvements in all the areas they identify anyway), so where
>> does
>> the time come for the kind of individual growth via retrospectives
>> we're talking about here when my team is so busy changing everything
>> else?
>>
>> S
>>
>> On 27 Apr 2008, at 01:25, Tobias Mayer wrote:
>>
>>> Hi Simon.
>>>
>>> Whatever it is you are looking for... affirmation, criticism,
>>> guidance... I think you are looking in the wrong place.
>>>
>>> Firstly most performance reviews, even the 360 one you are using are
>>> linked directly to salary adjustments.  This is inherently flawed as
>>> Mary Poppendieck points out (as quoted
>
here:http://runningagile.com/2008/01/22/review-process-for-agile-team-members/)
>>> .
>>>
>>> Secondly, even if the performance review is decoupled from the
>>> salary issues I still think it is a flawed and outmoded idea.  Such
>>> a review process sets up a fake environment, far removed from our
>>> everyday work context.  As a result people behave differently and
>>> the feedback offered generally bears little relation to true
>>> feelings and interactions.
>>>
>>> Chad Eaves stated: In order for feedback to be of value, people need
>>> to feel safe in giving it.  This is undeniably true.  Setting up a
>>> special feedback environment (the review process) is not going to
>>> create that safety.  On the other hand, a familiar and routine forum
>>> perhaps will, so use your retrospectives to find what you are
>>> looking for.  Perhaps it is time to take the retrospective to
>>> another level -- a more personal one that is born of camaraderie and
>>> trust -- and yes, courage.
>>>
>>> Thirdly, I am passionately opposed to any form of anonymous
>>> feedback.  I believe it is absolutely without value.  Performance
>>> Reviews promote the idea of hiding information (i.e. hiding the
>>> identity of the reviewer).  This is destructive and causes all kinds
>>> of unresolved, and unresolvable, bad feelings to be surfaced and to
>>> linger.  In a retrospective setting we are accountable for the words
>>> we speak.  Accountability is an essential feature of a healthy Agile
>>> environment, and one we should always be promoting. It is, after
>>> all, an element of transparency.
>>>
>>> So I want to suggest that anyone on this list struggling with how to
>>> run performance reviews, simply throw the whole concept into the
>>> trash (it usually represents massive waste) and use the Scrum
>>> process to continuously provide the kind of honest and truthful
>>> feedback we all need as workers, as humans.
>>>
>>> Tobias
>>> http://agilethinking.net
>>>
>>>
>>>
>>> --- In scrumdevelopment@yahoogroups.com, Simon Kirk <scrum@> wrote:
>>>>
>>>> Hi Chad.
>>>>
>>>> Nice points!
>>>>
>>>> I find it interesting that a significant percentage of the talks I
>>>> attended at last year's Scrum Gathering in London (Roman Pilcher's
>>>> Product Owner talk sprints to mind as an example) had a sheet
>>>> asking
>>>> for explicit and immediate feedback on his course, while the
>>> gathering
>>>> as a whole had a wall for providing feedback on the gathering
>>> itself.
>>>> I'm sure that Chicago's one did, too.
>>>>
>>>> So maybe giving such feedback is seen as safer, in an agile
>>> environment?
>>>>
>>>> I hope I've grown enough feeling of safety in the team by now, but
>>>> it's well worth keeping in mind. Thanks.
>>>>
>>>> S
>>>>
>>>> On 26 Apr 2008, at 15:59, Chad Eaves wrote:
>>>>
>>>>> A big obstacle in feedback is human nature and cultural, I
>>> believe.
>>>>> Far too often, people are not accustomed to being asked for their
>>>>> feedback, especially if it is directed towards a boss/employer-
>>> type
>>>>> person. I teach a Junior Achievement class once a week and asked
>>>>> senior students for feedback on my presentation and they looked
>>>>> stunned. Getting them to offer feedback is one of my goals in my
>>>>> course. I'll let everyone know how that is at course end.
>>>>>
>>>>> In order for feedback to be of value, people need to feel safe in
>>>>> giving it. Unfortunately, companies have undermined this value.
>>>>> How often has an "anonymous" survey tool turned out not to be so?
>>>>>
>>>>> Unfortunately, fostering this safe feeling takes time. And as we
>>>>> all know, that is something we usually do not have an excess of on
>>>>> projects.
>>>>>
>>>>> Without surmounting the personal security issue, great questions
>>> may
>>>>> yield little value.
>>>>>
>>>>> Chad Eaves
>>>
>>> ---------------------
>>>>>>> Original Post...
>>> On Thu, Apr 24, 2008 at 6:08 PM, Simon Kirk scrum@
>>> wrote:
>>>
>>> Hi all.
>>>
>>> We're going through performance reviews at the moment and I've been
>>> trying really hard to move away from the traditional small-company
>>> quick chat, pat on the back and on-you-go for another year "review"
>>> process that has been my experience for the companies I've worked at
>>> before.
>>>
>>> On the other hand I abhorred the thought of going down an ultra-
>>> bureaucratic HR-style route such as I imagine happens in big
>>> companies. Instead some Googling turned up this, which so far
>>> seems to
>>> be going well:
>>> http://runningagile.com/2008/01/22/review-process-for-agile-team-members/
>>> (really it's Jeff Sutherland's original posting on an Agile Team
>>> review process, but with some additional quotes at the start and a
>>> bit
>>> of tidying).
>>>
>>> Now, I was thinking about how I as the Scrum Master could get
>>> reviewed
>>> by my team - if 360 degree feedback is good for them, surely it's
>>> good
>>> for me? One of my team also asked for an opportunity to "review the
>>> reviewer", but nowhere can I find good examples of how a Scrum
>>> Master
>>> can be evaluated, let alone by his or her team.
>>>
>>> For instance, taking the above URL as context, I'm not sure what the
>>> right questions are the team should be asked about me.
>>>
>>> Has anybody got any pointers, I'd really appreciate the help?
>>>
>>> Thanks,
>>> Simon
>>>
>>> ps. No more yearly reviews, either: I've taken this opportunity to
>>> move to two monthly, despite the additional overhead. If anybody has
>>> any comments on that I'd be happy to hear them, too.
>>>
>>> pps. Yes, we do Sprint retrospectives: they're brilliant, but
>>> sometimes they lack the one-on-one that people need occasionally,
>>> ime.
>>> Again, any comments feel free.
>>>
>>>
>>
>
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...
> ! Groups Links
>
>
>

#29005 From: "MacKilby" <mckilby@...>
Date: Thu May 1, 2008 9:44 am
Subject: Re: Backlog of technical tasks?
MacKilby
Send Email Send Email
 
--- In scrumdevelopment@yahoogroups.com, "Jim Schiel" <schiel@...> wrote:

> >
> > Bottom line -- technical debt is no different than anything else
on the
> > backlog. Don't treat it like a second class citizen -- it's always
going to
> > be there and everyone should get used to it being there.
> >

Agreed... and now let me share more of the story that prompted the
question.

When I implied a large technical debt, I was thinking of those
companies that had legacy code bases to deal with.  One group I know
solved that problem of dealing with legacy debt by incorporating the
"payment plan" into the backlog.  That is, because they had a large
technical debt with their legacy codebase, the team and PO agreed that
they would try to include a certain percentage of technical debt
stories in each sprint until debt was paid down below a certain
threshold and they made this team ground rule visible.  So not only
did they make their commitment to the debt visible in the backlog, but
they also made the payment plan toward improved quality visible to
stakeholders by keeping the groundrules visible.

So I agree that technical debt should be balanced with other factors
the PO must consider and that balancing should be made visible through
the project backlog and the methods to prioritize the backlog.

Mark Kilby

#29006 From: George Dinwiddie <lists@...>
Date: Thu May 1, 2008 11:14 am
Subject: Re: Re: Backlog of technical tasks?
gdinwiddie
Send Email Send Email
 
MacKilby wrote:
> --- In scrumdevelopment@yahoogroups.com, "Jim Schiel" <schiel@...> wrote:
>
>>> Bottom line -- technical debt is no different than anything else
> on the
>>> backlog. Don't treat it like a second class citizen -- it's always
> going to
>>> be there and everyone should get used to it being there.
>>>
>
> Agreed... and now let me share more of the story that prompted the
> question.
>
> When I implied a large technical debt, I was thinking of those
> companies that had legacy code bases to deal with.

In that situation, I recommend AGAINST scheduling paying down technical
debt as separate items from the user stories.  Not only does the
work-without-new-functionality look bad to the Product Owner, you may
find yourself cleaning up code that never needs to be touched.

I've always found it possible to refactor and pay down technical debt in
the course of adding new features.  As you touch legacy code, you leave
it a little cleaner and easier to use than it was before.  One big
benefit of approaching it that way is that you're cleaning precisely in
the areas that are most affecting the new work.

I will grant that it takes some time to learn the skills of cleaning up
as you go, but I'd also posit that if you don't learn those skills,
you're likely creating new technical debt in your new code by not
refactoring it to be as clean as possible before declaring the story
done.  Treating the paydown of technical debt as a project, with some
upfront design followed by implementation doesn't seem to teach these
skills.  Treating the paydown of technical debt as a tax on everything
you do, doing a little bit anytime you touch the code seems to produce
the skills to not only reduce old debt, but avoid adding new debt.

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

#29007 From: "Jim Schiel" <schiel@...>
Date: Thu May 1, 2008 11:55 am
Subject: Re: Re: Backlog of technical tasks?
jimschiel
Send Email Send Email
 
I would add that having a significant technical debt on legacy code is probably very common and I think I'll add something to George's thoughts that were probably behind the pattern he recommended. "Pay down" (were we to give it a name) should be done with a lot of attention given to the business value derived from completing certain technical debt stories. There's a lot of risk associated with touching (changing) code. The old adage: "If it ain't broke, don't fix it." might apply here -- if the legacy code works, consider carefully whether or not there's sufficient value (i.e., reduction in risk) in changing the code to complete a technical debt story, and, as George said, if you can do it in combination with a value-adding feature story -- great!
 
I suppose this also reintroduces the concept of "good enough" that Jim Fosdick talked about yesterday. That being said, I'll stop here rather than risk repeating someone else.
 
Jim Schiel
CST, Danube Technologies
On Thu, May 1, 2008 at 7:14 AM, George Dinwiddie <lists@...> wrote:

MacKilby wrote:
> --- In scrumdevelopment@yahoogroups.com, "Jim Schiel" <schiel@...> wrote:
>
>>> Bottom line -- technical debt is no different than anything else
> on the
>>> backlog. Don't treat it like a second class citizen -- it's always
> going to
>>> be there and everyone should get used to it being there.
>>>
>
> Agreed... and now let me share more of the story that prompted the
> question.
>
> When I implied a large technical debt, I was thinking of those
> companies that had legacy code bases to deal with.

In that situation, I recommend AGAINST scheduling paying down technical
debt as separate items from the user stories. Not only does the
work-without-new-functionality look bad to the Product Owner, you may
find yourself cleaning up code that never needs to be touched.

I've always found it possible to refactor and pay down technical debt in
the course of adding new features. As you touch legacy code, you leave
it a little cleaner and easier to use than it was before. One big
benefit of approaching it that way is that you're cleaning precisely in
the areas that are most affecting the new work.

I will grant that it takes some time to learn the skills of cleaning up
as you go, but I'd also posit that if you don't learn those skills,
you're likely creating new technical debt in your new code by not
refactoring it to be as clean as possible before declaring the story
done. Treating the paydown of technical debt as a project, with some
upfront design followed by implementation doesn't seem to teach these
skills. Treating the paydown of technical debt as a tax on everything
you do, doing a little bit anytime you touch the code seems to produce
the skills to not only reduce old debt, but avoid adding new debt.

- George

--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------



#29008 From: "Dillon Weyer" <dillon.weyer@...>
Date: Thu May 1, 2008 1:32 pm
Subject: RE: Re: Backlog of technical tasks?
dmweyer
Send Email Send Email
 

As a PO, I used the exact method described by George. The way we factored it into the sprints is that the developers would include additional time per user story to ensure that on top of implementing the user story, the code was also refactored at the same time. This has proved to produce fewer bugs while still delivering an acceptable level of value to the business. In the past, majority of the bugs came from refactored code.

 

Dillon Weyer

 


From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Jim Schiel
Sent: 01 May 2008 12:56
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Re: Backlog of technical tasks?

 

I would add that having a significant technical debt on legacy code is probably very common and I think I'll add something to George's thoughts that were probably behind the pattern he recommended. "Pay down" (were we to give it a name) should be done with a lot of attention given to the business value derived from completing certain technical debt stories. There's a lot of risk associated with touching (changing) code. The old adage: "If it ain't broke, don't fix it." might apply here -- if the legacy code works, consider carefully whether or not there's sufficient value (i.e., reduction in risk) in changing the code to complete a technical debt story, and, as George said, if you can do it in combination with a value-adding feature story -- great!
 
I suppose this also reintroduces the concept of "good enough" that Jim Fosdick talked about yesterday. That being said, I'll stop here rather than risk repeating someone else.
 
Jim Schiel
CST, Danube Technologies

On Thu, May 1, 2008 at 7:14 AM, George Dinwiddie <lists@idiacomputing.com> wrote:

MacKilby wrote:
> --- In scrumdevelopment@yahoogroups.com, "Jim Schiel" <schiel@...> wrote:
>
>>> Bottom line -- technical debt is no different than anything else
> on the
>>> backlog. Don't treat it like a second class citizen -- it's always
> going to
>>> be there and everyone should get used to it being there.
>>>
>
> Agreed... and now let me share more of the story that prompted the
> question.
>
> When I implied a large technical debt, I was thinking of those
> companies that had legacy code bases to deal with.

In that situation, I recommend AGAINST scheduling paying down technical
debt as separate items from the user stories. Not only does the
work-without-new-functionality look bad to the Product Owner, you may
find yourself cleaning up code that never needs to be touched.

I've always found it possible to refactor and pay down technical debt in
the course of adding new features. As you touch legacy code, you leave
it a little cleaner and easier to use than it was before. One big
benefit of approaching it that way is that you're cleaning precisely in
the areas that are most affecting the new work.

I will grant that it takes some time to learn the skills of cleaning up
as you go, but I'd also posit that if you don't learn those skills,
you're likely creating new technical debt in your new code by not
refactoring it to be as clean as possible before declaring the story
done. Treating the paydown of technical debt as a project, with some
upfront design followed by implementation doesn't seem to teach these
skills. Treating the paydown of technical debt as a tax on everything
you do, doing a little bit anytime you touch the code seems to produce
the skills to not only reduce old debt, but avoid adding new debt.

- George

--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------

 


#29009 From: David A Barrett <dave.barrett@...>
Date: Thu May 1, 2008 4:00 pm
Subject: Re: Backlog of technical tasks?
barrettdab
Send Email Send Email
 
>"...on the sly" ? Words are powerful, and that short phrase comes across
>as a massive value judgment. I don't think anyone on this thread
>suggested being invisible, sly, devious or underhand in any way -- nor
>even implied it. Speaking for myself, it is quite the contrary; I
>always have teams call out technical debt loud and clear. How a team
>handles its technical debt should otherwise be its own concern.
>Different methods work differently for different teams.

Tobias,

I was a little startled to see such a strong reaction to this phrase.  It's
not like I haven't ever said outrageous things to prod people into paying
attention, but I don't think I was doing that here.

I guess the crux of it is that I haven't seen anything in this thread yet
that convinces me that technical debt related tasks enjoy any special
status that would make them exempt from the normal "Put it the the Backlog
--> Prioritize it --> Select it for a Sprint" process that any other tasks
go through.  Yah, they're technical.  But it's systems development, so
everything is technical.  I'm sure that there's lots of "New Feature" type
PB items that the PO doesn't really understand either, like when a business
partner decides to change to a new communications protocol so your EDI
module needs to be modified to remain compatible.  You wouldn't leave that
off the PB, would you?

As to "...on the sly".  I don't know.  I can only see two ways to look at
building in slack time to deal with Technical Debt tasks not prioritized
through the PB.  The first is that the developers couldn't convince the PO
of the importance of the Technical Debt tasks and aren't willing to concede
on the issue.  So they are going to do them anyways because they feel they
know best (and they may be right).  But now it has to be off the
books...and on the sly.

The second scenario has been alluded to in some other posts in this thread.
The Team feels that this aspect is part of the "How" of development, and
only they have the right to address the issue.  Maybe it's a power thing or
a politics or corporate culture thing - I dunno.  Maybe the Team feels that
they "own" the technical debt because they created it in the first place -
so it's a guilt/problem ownership thing.  Maybe they feel that the
Technical Debt is a fallout from the Agile "Just Good Enough" approach, so
it's a process thing and should be dealt with by tweaking the process.  So
the Technical Debt stuff in this case would still be off the books, but I
guess it wouldn't necessarily be on the sly - although I still wouldn't be
sure that it was a good thing.

Maybe I'm missing something.  I probably am.  The second kind of scenario
didn't really occur to me until I read some of the later posts.  Now that I
think about it I can see it happening.  But I don't think it should be
happening.  I mean, if there is an issue with the system it should be
brought to the attention of the  PO and some sort of agreement reached
about how it will be resolved, and if you are going to do that then you
might as well list it in the PB.  Even if the agreement is that the Team is
given X number of man-days a Sprint to deal with these items at their own
discretion, I have trouble seeing how you wouldn't be better off having
them in the PB.

So when I wrote it, "...on the sly" wasn't even a little value judgement.
Just a statement of fact as I saw it, and I didn't intend for it to have
any other baggage attached.

Dave Barrett,
Lawyers' Professional Indemnity Company

#29010 From: "Rob Park" <robert.d.park@...>
Date: Thu May 1, 2008 4:32 pm
Subject: Re: Re: Backlog of technical tasks?
rpark68
Send Email Send Email
 
I believe the crux of the issue is that it can be hard to justify technical stories in terms of business value.  If you can't make that justification, you can't prioritize it as part of the backlog. 
 
E.g. Why does the customer want/need me to refactor xyz() into class J?
 
We all know the technical debt needs to be worked down, so some are saying just put it on the side and handle it as overhead via slack.
 
On a healthy team, we handled as much debt as we could with each story as the story touched it. 
On a not yet healthy team, we are putting them on the sprint directly, because in fact it's easier to justify the customer value when you're having issues.
 
.rob.

#29011 From: "banshee858" <cnett858@...>
Date: Thu May 1, 2008 4:36 pm
Subject: Re: Scrum / Agile Guidelines and Checklist
banshee858
Send Email Send Email
 
>
> I agree, when the document states what the team members expect from
> each other, and when all the team members agree that it is the right
> thing to do, and agree on the content of the document. That is, when
> the document is the *result* of a conversation between all the
> affected people.
>
> That's not what I understood Michael's situation to be. It sounded to
> me as if the document codified what the team expected from "outside"
> members, and as if those possibly even hadn't been asked whether they
> wanted such a documented, and as if the document came *before* the
> conversation with all those affected. To the amount that this
> impression is correct, it would trouble me.
>
We don't know that.  This could be the first draft or a starting point
for the discussion.  A lot of people do not understand what Scrum is
or how it works day-to-day, describing that makes things clear.

FWIW, it is a little detailed for my taste and could be boiled down to
a few key principles that remind us of the details.  Much like a user
story reminds us of the details of the requirements.

Carlton

#29012 From: Michael Wollin <yahoo@...>
Date: Thu May 1, 2008 6:46 pm
Subject: Re: Re: Scrum / Agile Guidelines and Checklist
mdwollin
Send Email Send Email
 
This document is for “inside,” if you include PO’s who are really internal proxies for the actual customers. It is a continuation of an ongoing conversation and a strawman draft offered up for comment by the development team. Among its purposes, it tries to reassure the developers that they are not being asked to estimate or commit to implementing poorly defined stories.

The document is a response to continued confusion on the team’s part (PO, SM, developers, and QA – i.e., everybody). Each individual member seems to take away something different. Sometimes you just have to write it down in order to get everyone to “hear green when you say green.”

Ultimately, it’s all about building trust. Scrum explicitly intends to give the team a great deal of empowerment and control. It values team morale, job satisfaction and fun. We are not there. We are not near there. But we did not start from scratch, and Rome wasn’t built in a day.


On 5/1/08 3:34 AM, "Ilja Preuss" <it@...> wrote:

MacKilby wrote:

> That being said, I have no problem if this document is a charter for
> an individual team.  Some teams I've found do need this codification
> at the start, but it ends up becoming a disposable document as trust
> builds on the team (and I'm thinking PO, SM, and developers when I say
> team).

I agree, when the document states what the team members expect from each
other, and when all the team members agree that it is the right thing to
do, and agree on the content of the document. That is, when the document
is the *result* of a conversation between all the affected people.

That's not what I understood Michael's situation to be. It sounded to me
as if the document codified what the team expected from "outside"
members, and as if those possibly even hadn't been asked whether they
wanted such a documented, and as if the document came *before* the
conversation with all those affected. To the amount that this impression
is correct, it would trouble me.

Cheers, Ilja

#29013 From: "Tobias Mayer" <tobias.mayer@...>
Date: Thu May 1, 2008 7:37 pm
Subject: Re: Backlog of technical tasks?
tobias.mayer
Send Email Send Email
 
This is a very interesting thread, with lots of different ideas.  Two recent comments have helped me to clarify my thoughts on this:

> I've always found it possible to refactor and pay down technical debt in  the course of adding new features. As you touch legacy code, you leave  it a little cleaner and easier to use than it was before. -- George Dinwiddie

> On a healthy team, we handled as much debt as we could with each story as the story touched it.  -- Rob Park

Technical debt should be handled as part of a story, wherever possible.

The reason I do not like technical debt/clean up work to be on the Product Backlog is because the items are almost exclusively "how" items.   As soon as you put "how" items on the Product Backlog, then in my opinion you are not leveraging the power of Scrum but are slipping back into micro-management mode.

A team should always be calling out technical debt items, and keeping them as a task list.  These are tasks that will often become tasks for a particular story, but other times they will cross over multiple stories and just have to be attacked independently.   The latter case is rarer, and allowing slack time for such work is sometimes necessary. 

For me this issue really does come down to "what" versus "how".   Focusing only on what the customer wants is one of the hardest things to get PO's to understand when they are moving from creating PRDs to creating Scrum Product Backlogs.  If we continue to advise POs that everything should be on the backlog, the separation between "what" and "how" becomes messy, and things begin to spiral out of control.  I have seen this.

Technical tasks do NOT belong on the Product Backlog.

Tobias



--- In scrumdevelopment@yahoogroups.com, "Rob Park" <robert.d.park@...> wrote:
>
> I believe the crux of the issue is that it can be hard to justify technical stories in terms of business value. If you can't make that justification, you can't prioritize it as part of the backlog.
>
> E.g. Why does the customer want/need me to refactor xyz() into class J?
>
> We all know the technical debt needs to be worked down, so some are saying just put it on the side and handle it as overhead via slack.
>
> On a healthy team, we handled as much debt as we could with each story as the story touched it. On a not yet healthy team, we are putting them on the sprint directly, because in fact it's easier to justify the customer value when you're having issues.
>
> .rob.
>

#29014 From: "Tobias Mayer" <tobias.mayer@...>
Date: Thu May 1, 2008 8:18 pm
Subject: Re: Backlog of technical tasks?
tobias.mayer
Send Email Send Email
 
Hi Dave,

> As to "...on the sly". I don't know. I can only see two ways to look at building in slack time to deal with Technical Debt tasks not prioritized through the PB...

This is the crux of the issue for me.  Technical debt tasks should never be prioritized through the Product Backlog.  They are tasks.  They are "how" things.  They do not belong on the Product Backlog.  Developers need to find a way to complete those tasks in relation to an appropriate story.   If they cannot, there are times they may have to do them anyway. 

So build in slack time, that way it is transparent, and if the PO knows he only has 80% (or whatever) of the sprint for new stories he will prioritize accordingly.  It keeps it real simple.

And keeping the technical debt as a separate (visible) list reminds everyone that some stories will be much bigger than they at first appear.

Tobias



--- In scrumdevelopment@yahoogroups.com, David A Barrett <dave.barrett@...> wrote:
>
>
> >"...on the sly" ? Words are powerful, and that short phrase comes across
> >as a massive value judgment. I don't think anyone on this thread
> >suggested being invisible, sly, devious or underhand in any way -- nor
> >even implied it. Speaking for myself, it is quite the contrary; I
> >always have teams call out technical debt loud and clear. How a team
> >handles its technical debt should otherwise be its own concern.
> >Different methods work differently for different teams.
>
> Tobias,
>
> I was a little startled to see such a strong reaction to this phrase. It's
> not like I haven't ever said outrageous things to prod people into paying
> attention, but I don't think I was doing that here.
>
> I guess the crux of it is that I haven't seen anything in this thread yet
> that convinces me that technical debt related tasks enjoy any special
> status that would make them exempt from the normal "Put it the the Backlog
> --> Prioritize it --> Select it for a Sprint" process that any other tasks
> go through. Yah, they're technical. But it's systems development, so
> everything is technical. I'm sure that there's lots of "New Feature" type
> PB items that the PO doesn't really understand either, like when a business
> partner decides to change to a new communications protocol so your EDI
> module needs to be modified to remain compatible. You wouldn't leave that
> off the PB, would you?
>
> As to "...on the sly". I don't know. I can only see two ways to look at
> building in slack time to deal with Technical Debt tasks not prioritized
> through the PB. The first is that the developers couldn't convince the PO
> of the importance of the Technical Debt tasks and aren't willing to concede
> on the issue. So they are going to do them anyways because they feel they
> know best (and they may be right). But now it has to be off the
> books...and on the sly.
>
> The second scenario has been alluded to in some other posts in this thread.
> The Team feels that this aspect is part of the "How" of development, and
> only they have the right to address the issue. Maybe it's a power thing or
> a politics or corporate culture thing - I dunno. Maybe the Team feels that
> they "own" the technical debt because they created it in the first place -
> so it's a guilt/problem ownership thing. Maybe they feel that the
> Technical Debt is a fallout from the Agile "Just Good Enough" approach, so
> it's a process thing and should be dealt with by tweaking the process. So
> the Technical Debt stuff in this case would still be off the books, but I
> guess it wouldn't necessarily be on the sly - although I still wouldn't be
> sure that it was a good thing.
>
> Maybe I'm missing something. I probably am. The second kind of scenario
> didn't really occur to me until I read some of the later posts. Now that I
> think about it I can see it happening. But I don't think it should be
> happening. I mean, if there is an issue with the system it should be
> brought to the attention of the PO and some sort of agreement reached
> about how it will be resolved, and if you are going to do that then you
> might as well list it in the PB. Even if the agreement is that the Team is
> given X number of man-days a Sprint to deal with these items at their own
> discretion, I have trouble seeing how you wouldn't be better off having
> them in the PB.
>
> So when I wrote it, "...on the sly" wasn't even a little value judgement.
> Just a statement of fact as I saw it, and I didn't intend for it to have
> any other baggage attached.
>
> Dave Barrett,
> Lawyers' Professional Indemnity Company
>

#29015 From: Ilja Preuss <it@...>
Date: Thu May 1, 2008 8:42 pm
Subject: Re: Re: Scrum / Agile Guidelines and Checklist
ipreussde
Send Email Send Email
 
banshee858 wrote:
>> I agree, when the document states what the team members expect from
>> each other, and when all the team members agree that it is the right
>> thing to do, and agree on the content of the document. That is, when
>> the document is the *result* of a conversation between all the
>> affected people.
>>
>> That's not what I understood Michael's situation to be. It sounded to
>> me as if the document codified what the team expected from "outside"
>> members, and as if those possibly even hadn't been asked whether they
>> wanted such a documented, and as if the document came *before* the
>> conversation with all those affected. To the amount that this
>> impression is correct, it would trouble me.
>>
> We don't know that.

Correct. That's what I tried to express.

  > This could be the first draft or a starting point
> for the discussion.

In my experience, a document is seldom a good starting point for a
discussion. And if it is supposed to be, it doesn't make much sense to
get it *right*, anyway - in that case, we are simply the wrong people to
get input from.

  > A lot of people do not understand what Scrum is
> or how it works day-to-day, describing that makes things clear.

And one of the base tenets of Agile - and therefore I guess also Scrum -
is that face-to-face conversation is ways more effective than written
communication. If we believe that to be true, we probably should act
that way, too, shouldn't we?

> FWIW, it is a little detailed for my taste and could be boiled down to
> a few key principles that remind us of the details.  Much like a user
> story reminds us of the details of the requirements.

I like that analogy! :)

Cheers, Ilja

#29016 From: "David H." <dmalloc@...>
Date: Thu May 1, 2008 8:48 pm
Subject: Re: Re: Scrum / Agile Guidelines and Checklist
sebi13556
Send Email Send Email
 
e?
>
>  > FWIW, it is a little detailed for my taste and could be boiled down to
>  > a few key principles that remind us of the details. Much like a user
>  > story reminds us of the details of the requirements.
>
I thought User Stories remind us to have a conversation and as such
they are always still a little ambiguous...?

-d
--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

#29017 From: "Tobias Mayer" <tobias.mayer@...>
Date: Thu May 1, 2008 9:00 pm
Subject: Re: Scrum / Agile Guidelines and Checklist
tobias.mayer
Send Email Send Email
 
A little off-track perhaps, but this thread reminds me of an organization that I worked with about eighteen months ago.  The team members there created a charter for themselves, to indicate their sense of responsibility to the organization and the Scrum process.  This is it:

Framework: We commit to following Agile principles to the best of our ability using the whole Scrum framework.
Quality: We commit to building quality into our products at every stage of their development and to continuously review and improve our techniques for achieving this.
People: We are professionals and have a responsibility to respect each other, act honestly, communicate openly and assist/seek assistance where appropriate.
Process: We commit to working with the organization to define a minimal process to guide our activities over the duration of each sprint, empowering teams to get the job done.
Growth: As individuals, we commit to enhancing and furthering our knowledge and to share that knowledge, as appropriate, with others at [this_company].

I like the simplicity of this, and the fact it was generated by three teams, collaboratively. I also like that it is non-prescriptive and focuses on values rather than detailed tasks and activities.  The blog post I wrote about how this charter emerged is here:  Spiderman Says...

A document like this is certainly a starting point for conversation.  I am not sure that the document Michael Wollin proposed will have that effect, mainly because I am not convinced people will even read it. 

Tobias



--- In scrumdevelopment@yahoogroups.com, Ilja Preuss <it@...> wrote:
>
> banshee858 wrote:
> >> I agree, when the document states what the team members expect from
> >> each other, and when all the team members agree that it is the right
> >> thing to do, and agree on the content of the document. That is, when
> >> the document is the *result* of a conversation between all the
> >> affected people.
> >>
> >> That's not what I understood Michael's situation to be. It sounded to
> >> me as if the document codified what the team expected from "outside"
> >> members, and as if those possibly even hadn't been asked whether they
> >> wanted such a documented, and as if the document came *before* the
> >> conversation with all those affected. To the amount that this
> >> impression is correct, it would trouble me.
> >>
> > We don't know that.
>
> Correct. That's what I tried to express.
>
> > This could be the first draft or a starting point
> > for the discussion.
>
> In my experience, a document is seldom a good starting point for a
> discussion. And if it is supposed to be, it doesn't make much sense to
> get it *right*, anyway - in that case, we are simply the wrong people to
> get input from.
>
> > A lot of people do not understand what Scrum is
> > or how it works day-to-day, describing that makes things clear.
>
> And one of the base tenets of Agile - and therefore I guess also Scrum -
> is that face-to-face conversation is ways more effective than written
> communication. If we believe that to be true, we probably should act
> that way, too, shouldn't we?
>
> > FWIW, it is a little detailed for my taste and could be boiled down to
> > a few key principles that remind us of the details. Much like a user
> > story reminds us of the details of the requirements.
>
> I like that analogy! :)
>
> Cheers, Ilja
>

#29018 From: Ilja Preuss <it@...>
Date: Thu May 1, 2008 9:00 pm
Subject: Re: Re: Scrum / Agile Guidelines and Checklist
ipreussde
Send Email Send Email
 
Michael Wollin wrote:
> This document is for “inside,” if you include PO’s who are really
> internal proxies for the actual customers. It is a continuation of an
> ongoing conversation and a strawman draft offered up for comment by the
> development team.

OK, perhaps I misunderstood some of your previous statements. To the
amount that this document just captures the results of your discussions
in the Whole Team, that sounds good to me, in principle.

In the rest of this post, I will comment on the form of the document,
and ignore the content for now.

I would probably try to get it a bit shorter, to boil it down to a list
of essential working agreements. When it gets too long (say, more than
seven bullet points that apply to my working), I'm not able to keep them
in my head.

I prefer working agreements stated in a way as if I'm already doing
those things. The first of your points is already close:

"We will use the Wiki to capture stories, and details in the story."

Just remove the "will": "We use the Wiki to capture stories, and details
in the story."

Taking another example:

"The minimum basic details must be entered into a user story at least 24
hours prior to the sprint planning meeting by the product owner.  If
not, there is no requirement for the team to assess the story (they can
if they want to, but do not have to)."

I would reformulate that again to fit the above pattern:

"The product owner enters the minimum basic details into a user story at
least 24 hours prior to the sprint planning meeting."

I'm uncomfortable with that second sentence, for a number of reasons. It
has a strong defensive, threatening and divisive feel to me, and
destroys the energizing effect the first statement could have. Therefore
I would just scrap it.

I hope you this helps.

Cheers, Ilja

#29019 From: Ilja Preuss <it@...>
Date: Thu May 1, 2008 9:03 pm
Subject: Re: Re: Scrum / Agile Guidelines and Checklist
ipreussde
Send Email Send Email
 
David H. wrote:
> e?
>>  > FWIW, it is a little detailed for my taste and could be boiled down to
>>  > a few key principles that remind us of the details. Much like a user
>>  > story reminds us of the details of the requirements.
>>
> I thought User Stories remind us to have a conversation and as such
> they are always still a little ambiguous...?

I think that's what Carlton tried to say: the story (card) doesn't
*contain* the details, it is just a token to help us remember the
details that we got from somewhere else (discussions, acceptance tests,
etc.)

Cheers, Ilja

#29020 From: Michael Wollin <yahoo@...>
Date: Thu May 1, 2008 9:50 pm
Subject: Re: Re: Scrum / Agile Guidelines and Checklist
mdwollin
Send Email Send Email
 
Sure does help. Feel free to suggest more.


On 5/1/08 5:00 PM, "Ilja Preuss" <it@...> wrote:

> Michael Wollin wrote:
>> This document is for ³inside,² if you include PO¹s who are really
>> internal proxies for the actual customers. It is a continuation of an
>> ongoing conversation and a strawman draft offered up for comment by the
>> development team.
>
> OK, perhaps I misunderstood some of your previous statements. To the
> amount that this document just captures the results of your discussions
> in the Whole Team, that sounds good to me, in principle.
>
> In the rest of this post, I will comment on the form of the document,
> and ignore the content for now.
>
> I would probably try to get it a bit shorter, to boil it down to a list
> of essential working agreements. When it gets too long (say, more than
> seven bullet points that apply to my working), I'm not able to keep them
> in my head.
>
> I prefer working agreements stated in a way as if I'm already doing
> those things. The first of your points is already close:
>
> "We will use the Wiki to capture stories, and details in the story."
>
> Just remove the "will": "We use the Wiki to capture stories, and details
> in the story."
>
> Taking another example:
>
> "The minimum basic details must be entered into a user story at least 24
> hours prior to the sprint planning meeting by the product owner.  If
> not, there is no requirement for the team to assess the story (they can
> if they want to, but do not have to)."
>
> I would reformulate that again to fit the above pattern:
>
> "The product owner enters the minimum basic details into a user story at
> least 24 hours prior to the sprint planning meeting."
>
> I'm uncomfortable with that second sentence, for a number of reasons. It
> has a strong defensive, threatening and divisive feel to me, and
> destroys the energizing effect the first statement could have. Therefore
> I would just scrap it.
>
> I hope you this helps.
>
> Cheers, Ilja
>
> ------------------------------------
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@...! Groups Links
>
>
>

#29021 From: "Kane Mar" <kane_sfo@...>
Date: Thu May 1, 2008 10:12 pm
Subject: Re: Backlog of technical tasks?
kane_sfo
Send Email Send Email
 
--- In scrumdevelopment@yahoogroups.com, "Stephen Bobick" <sbobick2@...> wrote:
>
> If the organization ignores the Team repeatedly - a Team who predicts
> failure if they aren't listened to regarding technical debt and an
> unmaintable code base, and the organization drives the Team over a cliff,
> well, why not point that out?

I have no issue with making things visible. I think that transparency/visibility
is good and
healthy for teams and I would encourage that. We are in violent agreement on
this point.

I do however have an issue with finding fault. The quote from Mike D "When it
crashes
down you will have the documentation to help management find a new PO," read (to
me)
as if as thought he was advocating using the Backlog to attribute fault should a
project
not work out. This is something that I don't agree with because, when projects
go bad, I
believe it's everyone's responsibility.

Having said all that, I could well have interpreted Mike's words incorrectly, or
considered
them out of context, which is why I asked the questions that I did.

Best regards,
Kane Mar
b: http://KaneMar.com
b: http://SeattleScrum.org
w: http://www.Danube.com

#29022 From: "Stephen Bobick" <sbobick2@...>
Date: Thu May 1, 2008 10:26 pm
Subject: Re: Re: Backlog of technical tasks?
sbobick2
Send Email Send Email
 
On Thu, May 1, 2008 at 3:12 PM, Kane Mar <kane_sfo@...> wrote:
> This is something that I don't agree with because, when projects go bad, I
> believe it's everyone's responsibility
>

That's just not true.  I like the analogy of the Team as a Ferrari and
the PO as a driver.  If the PO drives the Ferrari off the cliff, who
is to "blame"?  OK, the Team is an animate entity, with members who
can speak up, but the fact remains that the Team can make their point
about technical debt until they are blue in the face, but if the PO
purposely forbids the Team from doing what it takes to reduce the
technical debt, then there is a lot more blame to go to the PO - if
not *all* the blame.

-- Stephen

#29023 From: Mitch Lacey <mitch.lacey@...>
Date: Thu May 1, 2008 11:24 pm
Subject: RE: Re: Backlog of technical tasks?
mglacey
Send Email Send Email
 

. If the PO drives the Ferrari off the cliff, who
is to "blame"?

 

This is easy – the PO.

 

I use this analogy in all my CSM classes. The team is the engine, the ScrumMaster is the oil in the engine, the PO is the one providing fuel and setting direction (aka driving).

 

The Product Owner is the single wringable neck and is responsible to both the customer and the team (who is a stakeholder). If the team raises the issues of increasing technical debt and the PO does not listen, bad PO. If the team does not raise the issues, bad team.

 

Kane, don’t mix responsibility with accountability. Everyone (PO/Team/SM) is responsible. One person, the PO, is accountable.

 

-Mitch

 

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Stephen Bobick
Sent: Thursday, May 01, 2008 3:27 PM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Re: Backlog of technical tasks?

 

On Thu, May 1, 2008 at 3:12 PM, Kane Mar <kane_sfo@...> wrote:
> This is something that I don't agree with because, when projects go bad, I
> believe it's everyone's responsibility
>

That's just not true. I like the analogy of the Team as a Ferrari and
the PO as a driver. If the PO drives the Ferrari off the cliff, who
is to "blame"? OK, the Team is an animate entity, with members who
can speak up, but the fact remains that the Team can make their point
about technical debt until they are blue in the face, but if the PO
purposely forbids the Team from doing what it takes to reduce the
technical debt, then there is a lot more blame to go to the PO - if
not *all* the blame.

-- Stephen


#29024 From: George Dinwiddie <lists@...>
Date: Thu May 1, 2008 11:40 pm
Subject: Re: Re: Backlog of technical tasks?
gdinwiddie
Send Email Send Email
 
Stephen Bobick wrote:
> On Thu, May 1, 2008 at 3:12 PM, Kane Mar <kane_sfo@...> wrote:
>> This is something that I don't agree with because, when projects go bad, I
>> believe it's everyone's responsibility
>>
>
> That's just not true.  I like the analogy of the Team as a Ferrari and
> the PO as a driver.  If the PO drives the Ferrari off the cliff, who
> is to "blame"?  OK, the Team is an animate entity, with members who
> can speak up, but the fact remains that the Team can make their point
> about technical debt until they are blue in the face, but if the PO
> purposely forbids the Team from doing what it takes to reduce the
> technical debt, then there is a lot more blame to go to the PO - if
> not *all* the blame.

I've never seen the product owner put technical debt into the code.
I've also never seen a PO forbid the team from writing code that they
can continue to build upon, though I have seen teams that didn't yet
know how to write code in that fashion.

I /have/ seen a PO ask a team to cut corners to meet a deadline.  That's
a case where it's really helpful for the team to have someone who's good
at dealing with other people--and especially helpful to have good
technical skills such as TDD and refactoring.

I would /expect/ a PO to forbid a team to go off refactoring without
simultaneously producing business value.

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

#29025 From: "Kane Mar" <kane_sfo@...>
Date: Fri May 2, 2008 12:22 am
Subject: Re: Backlog of technical tasks?
kane_sfo
Send Email Send Email
 
--- In scrumdevelopment@yahoogroups.com, "Stephen Bobick" <sbobick2@...> wrote:
>
> On Thu, May 1, 2008 at 3:12 PM, Kane Mar <kane_sfo@...> wrote:
> > This is something that I don't agree with because, when projects go bad, I
> > believe it's everyone's responsibility
> >
>
> That's just not true.  I like the analogy of the Team as a Ferrari and
> the PO as a driver.  If the PO drives the Ferrari off the cliff, who
> is to "blame"?

The usual version of this analogy is that the PO is the navigator and not the
drive. I'd
prefer to move away from analogies because I don't believe it's helpful.

>OK, the Team is an animate entity, with members who
> can speak up, but the fact remains that the Team can make their point
> about technical debt until they are blue in the face, but if the PO
> purposely forbids the Team from doing what it takes to reduce the
> technical debt, then there is a lot more blame to go to the PO - if
> not *all* the blame.

I would suggest that a better approach would be for the team to reduce technical
debt by
leaving all legacy code in better condition than they found it. Over time they
will improve
those parts of the system subject to the most change. Not only that, by doing
this they
don't ask the PO to choose between quality and functionality. There is no
question of the
PO "forbidding" the team from doing what it takes to reduce the technical debt.
Just my
thoughts.

Best regards,
Kane Mar
b: http://KaneMar.com
b: http://SeattleScrum.org
w: http://www.Danube.com

#29026 From: "Kane Mar" <kane_sfo@...>
Date: Fri May 2, 2008 12:27 am
Subject: Re: Backlog of technical tasks?
kane_sfo
Send Email Send Email
 
--- In scrumdevelopment@yahoogroups.com, Mitch Lacey <mitch.lacey@...> wrote:
> Kane, don't mix responsibility with accountability. Everyone (PO/Team/SM) is
responsible. One person, the PO, is accountable.

Isn't this just a re-arrangement of my own words "... when projects go bad, I
believe it's
everyone's responsibility"?

I think we're in violent agreement, unless the same words mean something
different
(which they very well could do ... low bandwidth means of communication and all
that).

Best regards,
Kane Mar
b: http://KaneMar.com
b: http://SeattleScrum.org
w: http://www.Danube.com


> On Thu, May 1, 2008 at 3:12 PM, Kane Mar
<kane_sfo@...<mailto:kane_sfo%40yahoo.com>> wrote:
> > This is something that I don't agree with because, when projects go bad, I
> > believe it's everyone's responsibility
> >
>
> That's just not true. I like the analogy of the Team as a Ferrari and
> the PO as a driver. If the PO drives the Ferrari off the cliff, who
> is to "blame"? OK, the Team is an animate entity, with members who
> can speak up, but the fact remains that the Team can make their point
> about technical debt until they are blue in the face, but if the PO
> purposely forbids the Team from doing what it takes to reduce the
> technical debt, then there is a lot more blame to go to the PO - if
> not *all* the blame.
>
> -- Stephen
>

#29027 From: "Stephen Bobick" <sbobick2@...>
Date: Fri May 2, 2008 12:27 am
Subject: Re: Re: Backlog of technical tasks?
sbobick2
Send Email Send Email
 
On Thu, May 1, 2008 at 5:22 PM, Kane Mar <kane_sfo@...> wrote:
>  I would suggest that a better approach would be for the team to reduce
> technical debt by
>  leaving all legacy code in better condition than they found it. Over time
> they will improve
>  those parts of the system subject to the most change. Not only that, by
> doing this they
>  don't ask the PO to choose between quality and functionality. There is no
> question of the
>  PO "forbidding" the team from doing what it takes to reduce the technical
> debt. Just my
>  thoughts.

Sprint Planning Meeting:
PO:  How much would this backlog item cost?
Team:  5 units
PO:  5??? Why so much
Team:  we need to  fix some technical debt, write unit tests, refactor
PO:  What if you don't do the latter, and just get the story done?
Team:  well, we really need to address all these issues.  We've put
them off for months, and really recommend fixing things as we go along
here.
PO:  I understand, but we need to release and we need all the
features, and right now they add up to too many points for the Team's
velocity.  If you hold off on reducing the technical debt, how many
points is it?
Team:  well, maybe 3.  But we really need to do this work.
PO:  I've heard your concern.  I want you to hold off on that.
ScrumMaster:  OK, I'll put down 3 points.

Happens all the time.

-- Stephen

#29028 From: "Mike james" <tish4@...>
Date: Fri May 2, 2008 12:37 am
Subject: Image
tish4@...
Send Email Send Email
 
Hello, Does anyone know who has the copyright to the black and white image of the scrum picture?  I was hoping to use it in a childrens book I have written. 
 
Hope you are well.
Mike.

#29029 From: "Kane Mar" <kane_sfo@...>
Date: Fri May 2, 2008 12:38 am
Subject: Re: Backlog of technical tasks?
kane_sfo
Send Email Send Email
 
--- In scrumdevelopment@yahoogroups.com, "MacKilby" <mckilby@...> wrote:
>
> --- In scrumdevelopment@yahoogroups.com, "Jim Schiel" <schiel@> wrote:
>
> > >
> > > Bottom line -- technical debt is no different than anything else
> on the
> > > backlog. Don't treat it like a second class citizen -- it's always
> going to
> > > be there and everyone should get used to it being there.
> > >
>
> Agreed... and now let me share more of the story that prompted the
> question.
>
> When I implied a large technical debt, I was thinking of those
> companies that had legacy code bases to deal with.  One group I know
> solved that problem of dealing with legacy debt by incorporating the
> "payment plan" into the backlog.  That is, because they had a large
> technical debt with their legacy codebase, the team and PO agreed that
> they would try to include a certain percentage of technical debt
> stories in each sprint until debt was paid down below a certain
> threshold and they made this team ground rule visible.  So not only
> did they make their commitment to the debt visible in the backlog, but
> they also made the payment plan toward improved quality visible to
> stakeholders by keeping the groundrules visible.
>
> So I agree that technical debt should be balanced with other factors
> the PO must consider and that balancing should be made visible through
> the project backlog and the methods to prioritize the backlog.

I'd like to re-iterate what George has said. He has managed to eloquently say
the words
that I've been struggling for especially when he says: "I've always found it
possible to
refactor and pay down technical debt in the course of adding new features. As
you touch
legacy code, you leave it a little cleaner and easier to use than it was
before."

I very much like the analogy of a sales tax (aka GST, VAT etc) rather than a
mortgage
repayment analogy. When I buy a coffee at Starbucks is cost me about $3.50 and
then I
have to add on a 9.5% sales tax.

I pay this tax at the same time as I purchase the coffee. I don't wait until the
end of the
year and pay all my sales taxes separately. It's all part of my spending. And
so, I feel it
should be with technical debt ... something that the team always needs to do and
should
not be considered separate from their day to day activities.

Best regards,
Kane Mar
b: http://KaneMar.com
b: http://SeattleScrum.org
w: http://www.Danube.com

Messages 29000 - 29029 of 56953   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help