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

Re: Story - QA Score

Expand Messages
  • Brian
    I think there s a combination of multiple incorrect practices which have been going on...to be honest. - Developers tackling too many Stories - Focus on
    Message 1 of 14 , Dec 31, 2010
    • 0 Attachment
      I think there's a combination of multiple incorrect practices which have been going on...to be honest.
      - Developers tackling too many Stories
      - Focus on Functionality, not incorporating Visuals/Treatment
      - Dev Team not Project focused
      - Dev Team lacking required WPF coding experience

      The Retrospectives are active discussions, but they are repeating. Everyone recognizes the problems, but I guess we're still trying to improve our Iterative practices. Many of the discussions, which involved high bug counts which need to be eliminated, repeated. However, consequences for not succeeding in the goals were never implemented, and that area is outside my control.

      Take multiple iterations of trying to scale back with quantity of Stories, but seeing no improvements, plus a frustrated Exec Branch, and you get discussions for a Story Quality Score to grade Dev performance.

      However, I think I have successfully talked them into a different path. We're going to take 1 Iteration and get caught up with all Bugs and lingering issues. The following Iteration, I'm creating a very transparent Bug Burn Down Monitoring Chart.

      I've also worked hand-in-hand, walking the Dev Team through the Stories. I'm taking it a step further to facilitate proper Story production by only handing over the specific Stories they will start with in the Iteration. Once one is noted as Done (a shipable product), I'll provide the next Story. This should eliminate working on too many at one time. That will happen for the Iteration after next, when they're back to Stories.

      The expertise of the Dev Team has improved and we have a couple more on the way. To be honest, I think we may be in good shape. Proof is in the pudding of course, but I believe I was able to keep the Exec's at bay one last time. If Dev Team doesn't follow what I've outline, they will get the butts kicked next time.


      Thanks for everyone's feedback BTW.
      -Brian

      --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@...> wrote:
      >
      > Hi Brian
      >
      > As has already been asked/stated, I to would be interested to know how this conversation/issue played out at the retrospective(s).
      >
      > It is within the gift of the team to work out how to resolve whatever quality issue there maybe, I would say it is their responsibility also.
      >
      > How has the issue manifest itself to execs if your defintion of done/done includes all the levels of QA you mention?
      >
      > Best of luck
      >
      > Sean
      >
      >
      > --- In scrumdevelopment@yahoogroups.com, "Brian" <bplawlor34@> wrote:
      > >
      > > I guess I should elaborate a little bit more, however, I think you all have expressed the concern I was looking for to utilize as ammo back up the ladder.
      > >
      > > We have 4-week Iterations; which includes QA. We do Unit and Buddy testing, as well as all the regular QA, integration, regression testing. We do not have automated scripts yet, but will have in a month.
      > >
      > > It does sound like the Exec's will push for some sort of "Story Quality Score". I'm not sure I can stop that. But, I may be able to sway them towards focusing on the Story itself... avoiding individual grading.
      > >
      > > We'll see...
      > >
      > > Thanks to all of you for taking the time to lend your advice. Our Company has by migrating towards being more Agile after working in a Waterfall environment for 30 years. I guess we have some growing pains to work through still.
      > >
      > > -Brian
      > >
      >
    • peterskeide
      It may be that I m overreacting to your choice of words, but I get a bit worried when you write things like consequences for not succeeding in the
      Message 2 of 14 , Jan 3, 2011
      • 0 Attachment
        It may be that I'm overreacting to your choice of words, but I get a bit worried when you write things like "consequences for not succeeding in the (retrospective) goals" and "they will get the butts kicked next time".

        If you are changing your development process from a phased/waterfall type to agile and at the same time introducing a new technology, a lot of people have to relearn how to do parts of their work. To ease the "pain" of such a transition, safety in the workplace is very important. Failure must be acceptable; a source of information to be used for process improvement.

        I get the impression that some of your management do not think this way. Consider very carefully if you have sufficient management support at the right level for the agile initiative. Also, try to gauge the level of managements understanding of what makes scrum/agile work. If managers are still thinking about individual developer performance benchmarks, it is a clear sign of the need for coaching at a different level than development.

        --- In scrumdevelopment@yahoogroups.com, "Brian" <bplawlor34@...> wrote:
        >
        > I think there's a combination of multiple incorrect practices which have been going on...to be honest.
        > - Developers tackling too many Stories
        > - Focus on Functionality, not incorporating Visuals/Treatment
        > - Dev Team not Project focused
        > - Dev Team lacking required WPF coding experience
        >
        > The Retrospectives are active discussions, but they are repeating. Everyone recognizes the problems, but I guess we're still trying to improve our Iterative practices. Many of the discussions, which involved high bug counts which need to be eliminated, repeated. However, consequences for not succeeding in the goals were never implemented, and that area is outside my control.
        >
        > Take multiple iterations of trying to scale back with quantity of Stories, but seeing no improvements, plus a frustrated Exec Branch, and you get discussions for a Story Quality Score to grade Dev performance.
        >
        > However, I think I have successfully talked them into a different path. We're going to take 1 Iteration and get caught up with all Bugs and lingering issues. The following Iteration, I'm creating a very transparent Bug Burn Down Monitoring Chart.
        >
        > I've also worked hand-in-hand, walking the Dev Team through the Stories. I'm taking it a step further to facilitate proper Story production by only handing over the specific Stories they will start with in the Iteration. Once one is noted as Done (a shipable product), I'll provide the next Story. This should eliminate working on too many at one time. That will happen for the Iteration after next, when they're back to Stories.
        >
        > The expertise of the Dev Team has improved and we have a couple more on the way. To be honest, I think we may be in good shape. Proof is in the pudding of course, but I believe I was able to keep the Exec's at bay one last time. If Dev Team doesn't follow what I've outline, they will get the butts kicked next time.
        >
        >
        > Thanks for everyone's feedback BTW.
        > -Brian
        >
        > --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@> wrote:
        > >
        > > Hi Brian
        > >
        > > As has already been asked/stated, I to would be interested to know how this conversation/issue played out at the retrospective(s).
        > >
        > > It is within the gift of the team to work out how to resolve whatever quality issue there maybe, I would say it is their responsibility also.
        > >
        > > How has the issue manifest itself to execs if your defintion of done/done includes all the levels of QA you mention?
        > >
        > > Best of luck
        > >
        > > Sean
        > >
        > >
        > > --- In scrumdevelopment@yahoogroups.com, "Brian" <bplawlor34@> wrote:
        > > >
        > > > I guess I should elaborate a little bit more, however, I think you all have expressed the concern I was looking for to utilize as ammo back up the ladder.
        > > >
        > > > We have 4-week Iterations; which includes QA. We do Unit and Buddy testing, as well as all the regular QA, integration, regression testing. We do not have automated scripts yet, but will have in a month.
        > > >
        > > > It does sound like the Exec's will push for some sort of "Story Quality Score". I'm not sure I can stop that. But, I may be able to sway them towards focusing on the Story itself... avoiding individual grading.
        > > >
        > > > We'll see...
        > > >
        > > > Thanks to all of you for taking the time to lend your advice. Our Company has by migrating towards being more Agile after working in a Waterfall environment for 30 years. I guess we have some growing pains to work through still.
        > > >
        > > > -Brian
        > > >
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.