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

sprint tangle

Expand Messages
  • Jean Richardson
    Two weeks ago I stepped into a Team during the their Planning Day and over the next few days helped the Developer/Scrum Master, who had been none-too-gleefully
    Message 1 of 5 , Mar 31, 2013
    • 0 Attachment

      Two weeks ago I stepped into a Team during the their Planning Day and over the next few days helped the Developer/Scrum Master, who had been none-too-gleefully inhabiting two roles for several months, transition back into a full time Team member role.  I’ll be spending a few sprints helping this Team step up their practices while the company looks for a Scrum Master to backfill.  Then I’ll move on to another Team in the org.

       

      This org has a pretty rough reputation and a high turnover rate.  Quite a bit is broken, including the way the backlog is built stories are written, groomed, and tasked, and commitments are made.  At this point, I’m looking for a way to salvage the sprint, boost the Team’s morale, and not break Scrum.  The current state of things is such that rapidly improving across the board is the best goal.  Okay, maybe not completely everything at once, but you get my drift.

       

      The org is aligned such that reasonably renegotiating what is in the sprint is not synonymous with failure.  And, on Planning Day, I did the step-in-front-of-a-speeding-train move of pointing out the Team’s right to not accept stories that are not ready to bring into the sprint, which drastically cut the commitment they were poised to make.  However, what has become clear in the last couple of weeks is that the Team is at sea about what it needs to know to actually do work on a story.

       

      As of last Thursday, it became clear that, while we can measure our newly minted Done Criteria against the state of the stories to determine how close to done we actually are, the original stories are not necessarily in line with the work that needed to be done.  So, for instance, one story was structured such that it really focused on doing a requirements doc and getting signoff from the business.  Now the Team understands that the entire cycle happens within a given sprint and the only person they need signoff from is the Product Owner.

       

      Tomorrow we’ll be actively engaging with the Product Owner WRT how to renegotiate to salvage the sprint.  What I’m struggling with is where the line is in the muddle between maintaining appropriate quality controls and integrity and fostering the success that is possible.  At the most extreme, this could come down to re-casting stories and tasks at this point.

       

      Keep in mind that this work group has had a practice of backwards engineering story points based on actual hours at the end of the sprint, assuming stories span sprints, and doing most of the testing outside the sprint in an IV&V fashion—among other things.

       

      Thoughts?  This Team seems poised for failure again, but they’ve been learning and applying things like real troopers for the last week and a half. It seems regrettable that the sprint should be a total failure, AND learning is necessary.

       

      --- Jean

       

      gate.site.jpg


      Jean Richardson

      Azure Gate Consulting

      ~ Repatterning the Human Experience of Work

       

      AzureGate.net

      (503) 788-8998

      Jean@...

       

       

       

    • Mark Graybill
      Quick question, how many people are on the team and how do members get assigned to tasks? Your following statement is curious to me: between maintaining
      Message 2 of 5 , Apr 1 12:05 AM
      • 0 Attachment

        Quick question, how many people are on the team and how do members get assigned to tasks?

         

        Your following statement is curious to me: between maintaining appropriate quality controls and integrity and fostering the success that is possible  In my book, the three should be synonymous.  Perhaps the discrepancy lies in the value paradigm?  Also, I would be focused on delivering value rather than not breaking Scrum. 

         

        I asked the founders – they don’t know why Scrum works, and we’d be delusional if we believe following Scrum perfectly to whatever eccentric view of “purely” is employed, will work for everyone.  Not understanding that the subjective intelligence of the biological systems (people) that implement Scrum is what makes it work not that it is a silver bullet may make it hard to rise above the distraction created in the worry about Scrum purity. If religiously following Scrum fails to deliver value, you probably lost sight of the value. 

         

        I sense also from what you wrote that complexity might be an issue.  If I were in your shoes, though only have meager data, I would find if complexity was not handled and if so why.  Are you using an arbitrary unit  of measure for sizing, or are you using some sort of time concept? 

         

        If time, I strongly recommend moving to measuring sizing.  Here is why: http://scrumscience.blogspot.com/2011/03/one-reason-time-forecasts-are-so.html  I recommend “story points”.

         

        How long are your sprints?  I recommend 2 weeks but if 1 month, I would keep all tasks under two weeks. I would start by calculating the floor of the two-week velocity value and making sure stories sized too close to or higher than the 2-week velocity value are broken down.

         

        I’ve also seen change being an issue.  Moving from the customer’s mind to a comprehensive and complete list of user stories isn’t a given, and to think that such is so, is a return to the same notion as waterfall.   One big roadblock I’ve seen is failure to embrace change as  a normal process in Scrum or not handling it well.

         

        Finally, I also sense the team culture might not have really distilled into the Agile paradigm, which can be very difficult when the managerial culture isn’t compatible.

         

        I know this is abstract and much of the usual, but I found it important to keep the eye on the ball and head in the game rather than being distracted worrying about sidelines.

         

         

        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Jean Richardson
        Sent: Sunday, March 31, 2013 10:57 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] sprint tangle

         

         

        Two weeks ago I stepped into a Team during the their Planning Day and over the next few days helped the Developer/Scrum Master, who had been none-too-gleefully inhabiting two roles for several months, transition back into a full time Team member role.  I’ll be spending a few sprints helping this Team step up their practices while the company looks for a Scrum Master to backfill.  Then I’ll move on to another Team in the org.

         

        This org has a pretty rough reputation and a high turnover rate.  Quite a bit is broken, including the way the backlog is built stories are written, groomed, and tasked, and commitments are made.  At this point, I’m looking for a way to salvage the sprint, boost the Team’s morale, and not break Scrum.  The current state of things is such that rapidly improving across the board is the best goal.  Okay, maybe not completely everything at once, but you get my drift.

         

        The org is aligned such that reasonably renegotiating what is in the sprint is not synonymous with failure.  And, on Planning Day, I did the step-in-front-of-a-speeding-train move of pointing out the Team’s right to not accept stories that are not ready to bring into the sprint, which drastically cut the commitment they were poised to make.  However, what has become clear in the last couple of weeks is that the Team is at sea about what it needs to know to actually do work on a story.

         

        As of last Thursday, it became clear that, while we can measure our newly minted Done Criteria against the state of the stories to determine how close to done we actually are, the original stories are not necessarily in line with the work that needed to be done.  So, for instance, one story was structured such that it really focused on doing a requirements doc and getting signoff from the business.  Now the Team understands that the entire cycle happens within a given sprint and the only person they need signoff from is the Product Owner.

         

        Tomorrow we’ll be actively engaging with the Product Owner WRT how to renegotiate to salvage the sprint.  What I’m struggling with is where the line is in the muddle between maintaining appropriate quality controls and integrity and fostering the success that is possible.  At the most extreme, this could come down to re-casting stories and tasks at this point.

         

        Keep in mind that this work group has had a practice of backwards engineering story points based on actual hours at the end of the sprint, assuming stories span sprints, and doing most of the testing outside the sprint in an IV&V fashion—among other things.

         

        Thoughts?  This Team seems poised for failure again, but they’ve been learning and applying things like real troopers for the last week and a half. It seems regrettable that the sprint should be a total failure, AND learning is necessary.

         

        --- Jean

         

        gate.site.jpg


        Jean Richardson

        Azure Gate Consulting

        ~ Repatterning the Human Experience of Work

         

        AzureGate.net

        (503) 788-8998

        Jean@...

         

         

         

      • srinivas chillara
        Hello Jean,I commented on your blog (unrelated).  It looks as though the team s capability should be improved. I use capability in a very broad manner.
        Message 3 of 5 , Apr 1 5:13 AM
        • 0 Attachment
          Hello Jean,
          I commented on your blog (unrelated). 

          It looks as though the team's capability should be improved. I use capability in a very broad manner. Therefore a couple of points to make:

          1) In my classes/coaching I give the example of a tennis player who needs to improve his serve. At the moment his serve is neither fast nor accurate. To be competitive both aspects must improve. However the way to do it is to lead with improving accuracy.

          So the team needs to do better on DoD (quality/reliability) and then slowly improve on speed. So maybe a graded DoD, which improves over (say 4 sprints) time, and then meeting two relatively modest targets. 

          2) This is not so much a suggestion as a pointer to my blog article. I don't think there is anything there you don't know, but it's just possible you have some handy lines to buttress your arguments at: http://ceezone.wordpress.com/2011/11/01/commitment-under-pressure/

          Overall any improvement which is visible, will improve morale, which is of course a big plus.

          Hope some of this helps somewhat.

          I salute your intent to repair the difficult situation.

          cheers
          Srinivas
          http://ceezone.wordpress.com
          www.scrumcoach.co.in







          --- On Mon, 1/4/13, Jean Richardson <jean@...> wrote:

          From: Jean Richardson <jean@...>
          Subject: [scrumdevelopment] sprint tangle
          To: scrumdevelopment@yahoogroups.com
          Date: Monday, 1 April, 2013, 9:26 AM

           

          Two weeks ago I stepped into a Team during the their Planning Day and over the next few days helped the Developer/Scrum Master, who had been none-too-gleefully inhabiting two roles for several months, transition back into a full time Team member role.  I’ll be spending a few sprints helping this Team step up their practices while the company looks for a Scrum Master to backfill.  Then I’ll move on to another Team in the org.

           

          This org has a pretty rough reputation and a high turnover rate.  Quite a bit is broken, including the way the backlog is built stories are written, groomed, and tasked, and commitments are made.  At this point, I’m looking for a way to salvage the sprint, boost the Team’s morale, and not break Scrum.  The current state of things is such that rapidly improving across the board is the best goal.  Okay, maybe not completely everything at once, but you get my drift.

           

          The org is aligned such that reasonably renegotiating what is in the sprint is not synonymous with failure.  And, on Planning Day, I did the step-in-front-of-a-speeding-train move of pointing out the Team’s right to not accept stories that are not ready to bring into the sprint, which drastically cut the commitment they were poised to make.  However, what has become clear in the last couple of weeks is that the Team is at sea about what it needs to know to actually do work on a story.

           

          As of last Thursday, it became clear that, while we can measure our newly minted Done Criteria against the state of the stories to determine how close to done we actually are, the original stories are not necessarily in line with the work that needed to be done.  So, for instance, one story was structured such that it really focused on doing a requirements doc and getting signoff from the business.  Now the Team understands that the entire cycle happens within a given sprint and the only person they need signoff from is the Product Owner.

           

          Tomorrow we’ll be actively engaging with the Product Owner WRT how to renegotiate to salvage the sprint.  What I’m struggling with is where the line is in the muddle between maintaining appropriate quality controls and integrity and fostering the success that is possible.  At the most extreme, this could come down to re-casting stories and tasks at this point.

           

          Keep in mind that this work group has had a practice of backwards engineering story points based on actual hours at the end of the sprint, assuming stories span sprints, and doing most of the testing outside the sprint in an IV&V fashion—among other things.

           

          Thoughts?  This Team seems poised for failure again, but they’ve been learning and applying things like real troopers for the last week and a half. It seems regrettable that the sprint should be a total failure, AND learning is necessary.

           

          --- Jean

           

          gate.site.jpg


          Jean Richardson

          Azure Gate Consulting

          ~ Repatterning the Human Experience of Work

           

          AzureGate.net

          (503) 788-8998

          Jean@...

           

           

           

        • Gil Broza
          Jean, It sounds to me that the team could use some quick wins. Those are usually to be had from properly splitting stories (using evolutionary design
          Message 4 of 5 , Apr 1 7:02 AM
          • 0 Attachment
            Jean,

            It sounds to me that the team could use some quick wins. Those are usually to be had from properly splitting stories (using evolutionary design thinking), working in short cycles (1-2 weeks), and effectively closing the feedback loop with the product owner. Quick wins are tangible examples of getting to done and they build teamwork and energy. Whether you break Scrum or not is less important, IMHO, than for the team to demonstrate to themselves that they can build working software by coming together.

            However, quick wins lose their edge if the team has no incentive to get to done. That happens when there's no prospect for releasing that done code anytime soon. If your team is working within a framework that deploys to production every few months, you may well need to have a meeting with the entire Agile team to help them see the value of getting-to-done despite lengthy product cycles. A simulation might help.

            All the best,

            Gil Broza
            Author, "The Human Side of Agile: How to Help Your Team Deliver"
          • Wouter Lagerweij
            Hi Jean, Always a difficult situation. You see so many improvement opportunities, but they also take time and effort to learn by the team. I would be hesitant
            Message 5 of 5 , Apr 1 2:16 PM
            • 0 Attachment
              Hi Jean,

              Always a difficult situation. You see so many improvement opportunities, but they also take time and effort to learn by the team.

              I would be hesitant re-defining the definition of done for stories that have been taken into the sprint. The DoD should be current state, and not aspirational. At the very least, also include the definition of ready, stating explicitly what you expect of stories to be taken into a sprint. 

              In this situation I'd probably (every team is different...) try to negotiate the PO to deliver (much) less this sprint, using the old criteria of 'done', and spend extra time with him and the team to groom for the next one. Use that to teach about functional splitting of stories, acceptance criteria/examples, etc. And to show the PO the amount of work currently ending up in the team. Take those stories into the next sprint, but not too many. Then start delivering.

              Wouter




              On Mon, Apr 1, 2013 at 5:56 AM, Jean Richardson <jean@...> wrote:
               

              Two weeks ago I stepped into a Team during the their Planning Day and over the next few days helped the Developer/Scrum Master, who had been none-too-gleefully inhabiting two roles for several months, transition back into a full time Team member role.  I’ll be spending a few sprints helping this Team step up their practices while the company looks for a Scrum Master to backfill.  Then I’ll move on to another Team in the org.

               

              This org has a pretty rough reputation and a high turnover rate.  Quite a bit is broken, including the way the backlog is built stories are written, groomed, and tasked, and commitments are made.  At this point, I’m looking for a way to salvage the sprint, boost the Team’s morale, and not break Scrum.  The current state of things is such that rapidly improving across the board is the best goal.  Okay, maybe not completely everything at once, but you get my drift.

               

              The org is aligned such that reasonably renegotiating what is in the sprint is not synonymous with failure.  And, on Planning Day, I did the step-in-front-of-a-speeding-train move of pointing out the Team’s right to not accept stories that are not ready to bring into the sprint, which drastically cut the commitment they were poised to make.  However, what has become clear in the last couple of weeks is that the Team is at sea about what it needs to know to actually do work on a story.

               

              As of last Thursday, it became clear that, while we can measure our newly minted Done Criteria against the state of the stories to determine how close to done we actually are, the original stories are not necessarily in line with the work that needed to be done.  So, for instance, one story was structured such that it really focused on doing a requirements doc and getting signoff from the business.  Now the Team understands that the entire cycle happens within a given sprint and the only person they need signoff from is the Product Owner.

               

              Tomorrow we’ll be actively engaging with the Product Owner WRT how to renegotiate to salvage the sprint.  What I’m struggling with is where the line is in the muddle between maintaining appropriate quality controls and integrity and fostering the success that is possible.  At the most extreme, this could come down to re-casting stories and tasks at this point.

               

              Keep in mind that this work group has had a practice of backwards engineering story points based on actual hours at the end of the sprint, assuming stories span sprints, and doing most of the testing outside the sprint in an IV&V fashion—among other things.

               

              Thoughts?  This Team seems poised for failure again, but they’ve been learning and applying things like real troopers for the last week and a half. It seems regrettable that the sprint should be a total failure, AND learning is necessary.

               

              --- Jean

               

              gate.site.jpg


              Jean Richardson

              Azure Gate Consulting

              ~ Repatterning the Human Experience of Work

               

              AzureGate.net

              (503) 788-8998

              Jean@...

               

               

               




              --
              Wouter Lagerweij         | wouter@...
            Your message has been successfully submitted and would be delivered to recipients shortly.