baby steps towards owning nothing

[D.André Dhondt]

OK, just checking in here for a second opinion--I just walked away from something that was hard to let go of. Is owning nothing/letting go really what I'm supposed to do here, when I think that the outcome is going to be negative? I buy into the idea of letting people learn from their mistakes--but that's in a dev environment... in the past I drew the line with prod systems...

So, there was a prod reporting issue caused by a bug. It turns out that the dev team responsible for this bug found it, and upon asking I found out that it can definitely happen again.  Their conclusion is that since the bug is configuration-based, all they have to do is fix the config... but not right now. That makes me nervous for two reasons--since the reporting issue was subtle, I have no confidence anyone will notice it again, and to me this whole category of errors needs to be eliminated--the design needs to be changed so that the next time there's a failure like this it's obvious so the config can be fixed immediately.  The second reason I'm nervous is that there's no closure to the issue--I asked when they'd make this configuration change and they say it will be fixed before the next time we run the report (which is unknown at this point, but at least 4 weeks away).

Aargh!  What do I do?

--
D. André Dhondt
mobile: 215-805-0819
skype: d.andre.dhondt

twitter: adhondt   http://dhondtsayitsagile.blogspot.com/

Support low-cost conferences -- http://AgileTour.org/
If you're in the area, join Agile Philly http://www.AgilePhilly.com

[Yves Hanoulle]

what is the worse thing that can happen?

2011/6/14 D.André Dhondt <d.andre...@gmail.com>

--

Yves Hanoulle 
Phone 00 32 467 43 38 32

Skype YvesHanoulle
Blog: www.Hanoulle.be
Agile Games: http://www.AgileGames.org 
Coaching Question Of the Day: http://twitter.com/Retroflection

[Andreas Leidig]

Hi D.André,

have you asked them:

- Why they want to do it this way?

- What will be the consequences if the forget to fix the bug? 

Is this an in house project or a sold product? One installation or multiple?

Of course I can see your point that this makes you nervous. Did you tell them that? - I guess they don't feel nervous. Why is that?

I hope I don't have too many questions...

Sharing your despair,

Andreas

[Mark Levison]

How can you help them see the impact of their choices?

What single question could you ask to reframe their thinking?

How can you help them fail sooner?

Cheers
Mark Levison

Mark Levison | Agile Pain Relief Consulting | Certified Scrum Trainer
Agile Editor @ InfoQ | Blog | Twitter | Office: (613) 862-2538
Recent Entries: Story Slicing How Small is Small Enough, Why use an Agile Coach

[Jon Kern]

did they at least enter something into the issue tracker to fix it? if
not, that is very sloppy...

also, unless it is a horrid error, it should be prioritized like
anything else.

(on my current production apps, for non-urgent fixes, if the cost of the
fix is very small, and the cost of documenting and talking about it two
weeks from now is bigger, i often just fix it in the dev branch and am
done with it.)

jon
blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

D.Andr� Dhondt said the following on 6/14/11 3:17 PM:

> OK, just checking in here for a second opinion--I just walked away
> from something that was hard to let go of. Is owning nothing/letting
> go really what I'm supposed to do here, when I think that the outcome
> is going to be negative? I buy into the idea of letting people learn
> from their mistakes--but that's in a dev environment... in the past I
> drew the line with prod systems...
>
> So, there was a prod reporting issue caused by a bug. It turns out
> that the dev team responsible for this bug found it, and upon asking I
> found out that it can definitely happen again. Their conclusion is
> that since the bug is configuration-based, all they have to do is fix
> the config... but not right now. That makes me nervous for two
> reasons--since the reporting issue was subtle, I have no confidence
> anyone will notice it again, and to me this whole category of errors
> needs to be eliminated--the design needs to be changed so that the
> next time there's a failure like this it's obvious so the config can
> be fixed immediately. The second reason I'm nervous is that there's
> no closure to the issue--I asked when they'd make this configuration
> change and they say it will be fixed before the next time we run the
> report (which is unknown at this point, but at least 4 weeks away).
>
> Aargh! What do I do?
>
>
>
> --

> D. Andr� Dhondt

[George Dinwiddie]

Andre,

Some good replies, already. It's hard to offer good advice without
knowing the people and the context. Is this a normal way for them to
act? Has something like this happened before? What happened then? Is
there a product owner or similar for this system? If so, is that person
being kept in the loop? How does that person react to bad news?

I suspect that I, also, would try to help them make an explicit
decision, instead of an implicit one out of habit. Perhaps some of
these questions, or variations, would be good ones to pose to them. I
often ask myself, "What would Dale ask?"

- George

On 6/14/11 3:17 PM, D.André Dhondt wrote:
> OK, just checking in here for a second opinion--I just walked away from
> something that was hard to let go of. Is owning nothing/letting go
> really what I'm supposed to do here, when I think that the outcome is
> going to be negative? I buy into the idea of letting people learn from
> their mistakes--but that's in a dev environment... in the past I drew
> the line with prod systems...
>
> So, there was a prod reporting issue caused by a bug. It turns out that
> the dev team responsible for this bug found it, and upon asking I found
> out that it can definitely happen again. Their conclusion is that since
> the bug is configuration-based, all they have to do is fix the config...
> but not right now. That makes me nervous for two reasons--since the
> reporting issue was subtle, I have no confidence anyone will notice it
> again, and to me this whole category of errors needs to be
> eliminated--the design needs to be changed so that the next time there's
> a failure like this it's obvious so the config can be fixed immediately.
> The second reason I'm nervous is that there's no closure to the
> issue--I asked when they'd make this configuration change and they
> say it will be fixed before the next time we run the report (which is
> unknown at this point, but at least 4 weeks away).
>
> Aargh! What do I do?

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

[Matteo Vaccari]

On Tue, Jun 14, 2011 at 9:17 PM, D.André Dhondt <d.andre...@gmail.com> wrote:

OK, just checking in here for a second opinion--I just walked away from something that was hard to let go of. Is owning nothing/letting go really what I'm supposed to do here, when I think that the outcome is going to be negative? I buy into the idea of letting people learn from their mistakes--but that's in a dev environment... in the past I drew the line with prod systems...

So, there was a prod reporting issue caused by a bug. It turns out that the dev team responsible for this bug found it, and upon asking I found out that it can definitely happen again.  Their conclusion is that since the bug is configuration-based, all they have to do is fix the config... but not right now. That makes me nervous for two reasons--since the reporting issue was subtle, I have no confidence anyone will notice it again, and to me this whole category of errors needs to be eliminated--the design needs to be changed so that the next time there's a failure like this it's obvious so the config can be fixed immediately.  The second reason I'm nervous is that there's no closure to the issue--I asked when they'd make this configuration change and they say it will be fixed before the next time we run the report (which is unknown at this point, but at least 4 weeks away).

Aargh!  What do I do?

I relate to this feeling :-)

How does this fit with your overall coaching goals for this
team/organization?  Like, is this a recurring problem?  Did they keep
similar promises in the past?  Can you place this incident in a wider
context?  Do they have lots of bugs?  Is this their worst problem at this
time?

Matteo