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

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
>
>
>

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
>
>
>

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

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
>
>
>

--- 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

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
   ----------------------------------------------------------------------

>"...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

>
> 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

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

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

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

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

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

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
>
>
>

--- 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

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

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
   ----------------------------------------------------------------------

--- 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

--- 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
>

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

--- 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