Loading ...
Sorry, an error occurred while loading the content.

RE: [scrumdevelopment] Sort of OT: Responding to hostile mgmt in meetings

Expand Messages
  • Jim Cloughley
    I m not sure who the Product Owner is here. If management is the Product Owner and they don t want to spend any more money on the project, this is their
    Message 1 of 9 , Oct 27, 2005
    • 0 Attachment
      I'm not sure who the Product Owner is here. If 'management' is the Product
      Owner and they don't want to spend any more money on the project, this is
      their right. However, they should be accountable to some extent to explain
      why they are no longer funding this project and instead others.

      It sounds like 'management' is willing to spend a bit more money to address
      some remaining issues but they are doing so reluctantly. It seems
      appropriate to have a meeting with the Product Owners and the users.
      Hopefully they aren't on this mailing list so they won't know that I'm
      suggesting you have a sprint planning meeting (don't call it that if
      Agile/Scrum is a no-no).

      During the sprint planning meeting, add to the sprint backlog those items
      that are most critical and follow through with estimating them. You will
      then have a reasonable amount of work to do for a particular date. If the
      users still have outstanding issues or all their issues are not addressed in
      this sprint, talk about it then.

      Maybe 'management' will see that the requests are valid and allow additional
      sprints. Maybe 'management' will say you have this much time and force the
      customers to choose what is essential that fits in the time they have. Not
      sure. At least with all parties represented in the meeting, 'dev' will not
      be the mediator between the two and instead appear as the humble servant
      happily working on whatever fits in the time you have as decided by the two
      other parties.

      Jim


      -----Original Message-----
      From: scrumdevelopment@yahoogroups.com
      [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
      Sent: Wednesday, October 26, 2005 8:31 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Sort of OT: Responding to hostile mgmt in
      meetings

      On Wednesday, October 26, 2005, at 8:13:46 PM, Greg Akins wrote:

      > That's just it. I "know" that during this meeting the
      > users will rattle off all their issues (Again, they
      > like the app; but aren't happy that we left them with
      > spotty support). And I'll have to settle on some
      > arbitrary deadline, after which we'll be pulled off
      > the project again because mgmt will think the project
      > is "complete".

      That would be bad. Short iterations with delivery to the customer
      would show that was happening, and perhaps they'd call the boss and
      bring pressure to bear.

      Also, for metaphorical reasons, maybe read this. It's not exactly
      your deal, but the notion of setting things completely aside may
      work for you at another level.

      http://www.xprogramming.com/xpmag/PetitionTheKing.htm

      Ron Jeffries
      www.XProgramming.com
      Don't confuse more precise with better. -- Brian Marick



      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...
      Yahoo! Groups Links
    • Greg Akins
      ... OK, that seems like a good approach. I think that will work. Two problems I m going to run into. First is that most of the outstanding items are bugs .
      Message 2 of 9 , Oct 27, 2005
      • 0 Attachment
        --- Jim Cloughley <jcloughley@...>
        wrote:
        > During the sprint planning meeting, add to the
        > sprint backlog those items
        > that are most critical and follow through with
        > estimating them. You will
        > then have a reasonable amount of work to do for a
        > particular date. If the
        > users still have outstanding issues or all their
        > issues are not addressed in
        > this sprint, talk about it then.

        OK, that seems like a good approach. I think that
        will work.

        Two problems I'm going to run into. First is that
        most of the outstanding items are "bugs". That's
        because we didn't have good acceptance tests. In
        fact, the customer, during acceptance testing, said,
        "It seems to work OK, we'll find out when it's in
        production".

        I think I really need to highlight the aspect of "Done
        means Done".

        Also, several bugs can't be duplicated. And I'm not
        sure how I can estmate completion time on those.

        >
        > Maybe 'management' will see that the requests are
        > valid and allow additional
        > sprints. Maybe 'management' will say you have this
        > much time and force the
        > customers to choose what is essential that fits in
        > the time they have. Not
        > sure. At least with all parties represented in the
        > meeting, 'dev' will not
        > be the mediator between the two and instead appear
        > as the humble servant
        > happily working on whatever fits in the time you
        > have as decided by the two
        > other parties.
        >
        > Jim
        >
      • Jim Cloughley
        It seems from the beginning, you should have been a little more rigid on the acceptance tests. We ll find out in production is the exact reason you re in
        Message 3 of 9 , Oct 27, 2005
        • 0 Attachment
          It seems from the beginning, you should have been a little more rigid on the
          acceptance tests. "We'll find out in production" is the exact reason you're
          in the situation you are in now.

          You will be estimating and daily updates can help with assessing progress
          and adjusting estimates. At any point (daily) you could raise a red flag
          stating that what was initially assessed as 1 day is now 1 week due to
          uncovering something. Sure your estimate was wrong but the power is having
          the ability to react. Do you defer this item? Do you continue to work on
          it but something else falls of the list? This decision is done by the
          Product Owner. Usually involvement in the process helps because people can
          see that dev isn't screwing around, they can see that the work can be
          tricky, you're trying your best, etc. This results in a better appreciation
          for the team and that can't hurt.

          With regard to issues that are hard to reproduce...

          How accessible are your users? Can you sit at their desk to see the bug
          happen? Can you WebEx to see the bug happen if they're remote? Can they
          screen snap the steps from login to where the issue occurs? Something must
          differ between the two systems. Version of software (grin), OS, platform,
          patch level, user security, exact set of steps in test case. Something must
          have been missed.

          Despite not being able to reproduce the bug, you should be able to get some
          kind of feel for the problem. If a list is not displaying the correct
          elements, it could be the call from the database is not returning the
          correct elements, it could be during the unmarshal of the reply into a data
          structure that could be wrong. It could be the model used by the UI is
          populated incorrectly. Maybe the UI component isn't refreshing correctly
          because of an uncaught exception. If you have unit tests around each of
          these places, you could review your set of tests to see if any are
          potentially missing. If you have unit tests and they all pass, then this
          should point you away from some areas and suggest you look somewhere else.

          Again, not knowing anything about the system, it's hard to suggest an
          approach. Last, as described by the user, can you think of reasons why the
          program could behave that way? Does that lead you to a particular area of
          code? Does that code have good tests? Is the code familiar and typically
          easy to fix? Etc, etc.

          Jim

          -----Original Message-----
          From: scrumdevelopment@yahoogroups.com
          [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Greg Akins
          Sent: Thursday, October 27, 2005 9:40 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] Sort of OT: Responding to hostile mgmt in
          meetings



          --- Jim Cloughley <jcloughley@...>
          wrote:
          > During the sprint planning meeting, add to the
          > sprint backlog those items
          > that are most critical and follow through with
          > estimating them. You will
          > then have a reasonable amount of work to do for a
          > particular date. If the
          > users still have outstanding issues or all their
          > issues are not addressed in
          > this sprint, talk about it then.

          OK, that seems like a good approach. I think that
          will work.

          Two problems I'm going to run into. First is that
          most of the outstanding items are "bugs". That's
          because we didn't have good acceptance tests. In
          fact, the customer, during acceptance testing, said,
          "It seems to work OK, we'll find out when it's in
          production".

          I think I really need to highlight the aspect of "Done
          means Done".

          Also, several bugs can't be duplicated. And I'm not
          sure how I can estmate completion time on those.

          >
          > Maybe 'management' will see that the requests are
          > valid and allow additional
          > sprints. Maybe 'management' will say you have this
          > much time and force the
          > customers to choose what is essential that fits in
          > the time they have. Not
          > sure. At least with all parties represented in the
          > meeting, 'dev' will not
          > be the mediator between the two and instead appear
          > as the humble servant
          > happily working on whatever fits in the time you
          > have as decided by the two
          > other parties.
          >
          > Jim
          >




          To Post a message, send it to: scrumdevelopment@...
          To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@...
          Yahoo! Groups Links
        • Greg Akins
          ... Amen. I pushed on this; but only made a little progress. ... One problem is that anytime I talk about an estimate changing my manager goes nuts. It s
          Message 4 of 9 , Oct 27, 2005
          • 0 Attachment
            --- Jim Cloughley <jcloughley@...>
            wrote:

            > It seems from the beginning, you should have been a
            > little more rigid on the
            > acceptance tests. "We'll find out in production" is
            > the exact reason you're
            > in the situation you are in now.

            Amen. I pushed on this; but only made a little
            progress.

            >
            > You will be estimating and daily updates can help
            > with assessing progress
            > and adjusting estimates. At any point (daily) you
            > could raise a red flag
            > stating that what was initially assessed as 1 day is
            > now 1 week due to
            > uncovering something. Sure your estimate was wrong
            > but the power is having
            > the ability to react. Do you defer this item? Do
            > you continue to work on
            > it but something else falls of the list? This
            > decision is done by the
            > Product Owner. Usually involvement in the process
            > helps because people can
            > see that dev isn't screwing around, they can see
            > that the work can be
            > tricky, you're trying your best, etc. This results
            > in a better appreciation
            > for the team and that can't hurt.

            One problem is that anytime I talk about an estimate
            changing my manager goes nuts. It's pretty
            disincenting to deal with that. The users are great;
            but I'm discouraged from being completing transparent
            because of the environment.

            >
            > With regard to issues that are hard to reproduce...
            >
            > How accessible are your users? Can you sit at their
            > desk to see the bug
            > happen? Can you WebEx to see the bug happen if
            > they're remote? Can they
            > screen snap the steps from login to where the issue
            > occurs? Something must
            > differ between the two systems. Version of software
            > (grin), OS, platform,
            > patch level, user security, exact set of steps in
            > test case. Something must
            > have been missed.
            >
            > Despite not being able to reproduce the bug, you
            > should be able to get some
            > kind of feel for the problem. If a list is not
            > displaying the correct
            > elements, it could be the call from the database is
            > not returning the
            > correct elements, it could be during the unmarshal
            > of the reply into a data
            > structure that could be wrong. It could be the
            > model used by the UI is
            > populated incorrectly. Maybe the UI component isn't
            > refreshing correctly
            > because of an uncaught exception. If you have unit
            > tests around each of
            > these places, you could review your set of tests to
            > see if any are
            > potentially missing. If you have unit tests and
            > they all pass, then this
            > should point you away from some areas and suggest
            > you look somewhere else.

            You're absolutely right. I just think that I won't be
            able to sit in a meeting and say "I'm not sure how
            long it will take, I'll have to sit with the users for
            a few days until I can get a better idea"

            >
            > Again, not knowing anything about the system, it's
            > hard to suggest an
            > approach. Last, as described by the user, can you
            > think of reasons why the
            > program could behave that way? Does that lead you
            > to a particular area of
            > code? Does that code have good tests? Is the code
            > familiar and typically
            > easy to fix? Etc, etc.

            Lots of "bad" unit tests (I am still learning TDD; and
            that project suffered as a result). Test coverage is
            decent, but there are lots of gaps because most of my
            unit tests look more like integration tests than unit
            tests.
          Your message has been successfully submitted and would be delivered to recipients shortly.