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

Looking for Advise on Standup, burndown, and tracking progress

Expand Messages
  • tony_t_tubbs
    Management s desire has been and is to use ScrumWorks so they can run reports so they can see progress. The team often feels like this is forcing a tool that
    Message 1 of 25 , Apr 16, 2012
    • 0 Attachment
      Management's desire has been and is to use ScrumWorks so they can run reports so they can see progress. The team often feels like this is forcing a tool that doesn't always fit. Our current situation is a POC sprint that has a lot of R&D to do. We do not know hours like we might otherwise. We have estimated story points relative to each other. We know when we start, and we know when and what MUST be done - a functioning POC of specific key concepts and business functions by June 1 as proof we can do a full implementation.

      Really, the POC containing the stories we've identified MUST be done. Whatever that takes. Longer hours or what not. The management wants hours in scrumworks so they can see if we are on track or not. I've suggested burndown only stores, or perhaps story points. (Which doesn't fit into ScrumWorks reporting I guess) They claim this is too high level to make adjustments, that being off track will not show in the chart until it's too late. By then longer hours or adding people or whatever will just be too late.

      Note that I personally, and expect many of you, would put this scenario into ScrumButt category. Assuming there's nothing I can do about that for the moment, please advise what I can actually do to best meet the needs/desires. If it can be done in a way that could convince management there's a better way, then all the better for me and my fellow developers.

      Thanks,
      TT
    • Andrew Burrows
      Hey Tony, Are the total story points for all the work that needs to be done by June 1st possible with the existing team without working overtime? If so, I d
      Message 2 of 25 , Apr 16, 2012
      • 0 Attachment
        Hey Tony,

        Are the total story points for all the work that needs to be done by June 1st possible with the existing team without working overtime? If so, I'd work on helping management track your team's progress through your build iterations. Could you describe your current sprint review process?

        Andrew

        On Mon, Apr 16, 2012 at 12:41 PM, tony_t_tubbs <tony_t_tubbs@...> wrote:
         

        Management's desire has been and is to use ScrumWorks so they can run reports so they can see progress. The team often feels like this is forcing a tool that doesn't always fit. Our current situation is a POC sprint that has a lot of R&D to do. We do not know hours like we might otherwise. We have estimated story points relative to each other. We know when we start, and we know when and what MUST be done - a functioning POC of specific key concepts and business functions by June 1 as proof we can do a full implementation.

        Really, the POC containing the stories we've identified MUST be done. Whatever that takes. Longer hours or what not. The management wants hours in scrumworks so they can see if we are on track or not. I've suggested burndown only stores, or perhaps story points. (Which doesn't fit into ScrumWorks reporting I guess) They claim this is too high level to make adjustments, that being off track will not show in the chart until it's too late. By then longer hours or adding people or whatever will just be too late.

        Note that I personally, and expect many of you, would put this scenario into ScrumButt category. Assuming there's nothing I can do about that for the moment, please advise what I can actually do to best meet the needs/desires. If it can be done in a way that could convince management there's a better way, then all the better for me and my fellow developers.

        Thanks,
        TT




        --
        Andrew Burrows
        Managing Producer, Large Animal Games
        Call me: 212-989-4312
        Follow me: @readytoscrumble

      • tony_t_tubbs
        Because this is a POC with a fair amount of R&D involved, it is hard to say if we can get things done without overtime or not. The gut feel is that there is a
        Message 3 of 25 , Apr 16, 2012
        • 0 Attachment
          Because this is a POC with a fair amount of R&D involved, it is hard to say if we can get things done without overtime or not. The gut feel is that there is a risk that we cannot.

          Sprint review is another struggle, but we do talk about what went well and what didn't. The things that didn't so far seem to fit into one of two categories - environment or standups. We are slowing addressing items in both cases, but these still are the biggest areas of impact.



          --- In scrumdevelopment@yahoogroups.com, Andrew Burrows <andy@...> wrote:
          >
          > Hey Tony,
          >
          > Are the total story points for all the work that needs to be done by June
          > 1st possible with the existing team without working overtime? If so, I'd
          > work on helping management track your team's progress through your build
          > iterations. Could you describe your current sprint review process?
          >
          > Andrew
          >
          > On Mon, Apr 16, 2012 at 12:41 PM, tony_t_tubbs <tony_t_tubbs@...>wrote:
          >
          > > **
          > >
          > >
          > > Management's desire has been and is to use ScrumWorks so they can run
          > > reports so they can see progress. The team often feels like this is forcing
          > > a tool that doesn't always fit. Our current situation is a POC sprint that
          > > has a lot of R&D to do. We do not know hours like we might otherwise. We
          > > have estimated story points relative to each other. We know when we start,
          > > and we know when and what MUST be done - a functioning POC of specific key
          > > concepts and business functions by June 1 as proof we can do a full
          > > implementation.
          > >
          > > Really, the POC containing the stories we've identified MUST be done.
          > > Whatever that takes. Longer hours or what not. The management wants hours
          > > in scrumworks so they can see if we are on track or not. I've suggested
          > > burndown only stores, or perhaps story points. (Which doesn't fit into
          > > ScrumWorks reporting I guess) They claim this is too high level to make
          > > adjustments, that being off track will not show in the chart until it's too
          > > late. By then longer hours or adding people or whatever will just be too
          > > late.
          > >
          > > Note that I personally, and expect many of you, would put this scenario
          > > into ScrumButt category. Assuming there's nothing I can do about that for
          > > the moment, please advise what I can actually do to best meet the
          > > needs/desires. If it can be done in a way that could convince management
          > > there's a better way, then all the better for me and my fellow developers.
          > >
          > > Thanks,
          > > TT
          > >
          > >
          > >
          >
          >
          >
          > --
          > Andrew Burrows
          > Managing Producer, Large Animal Games
          > Call me: 212-989-4312
          > Follow me: @readytoscrumble
          > We're Hiring: http://largeanimal.com/jobs
          >
        • Bret Wortman
          I may be alone here, but... POC? Definition in this context, please? I can t get past Point Of Contact . *Bret Wortman***
          Message 4 of 25 , Apr 16, 2012
          • 0 Attachment
            I may be alone here, but... POC? Definition in this context, please? I can't get past "Point Of Contact".


            Bret Wortman



            On Mon, Apr 16, 2012 at 1:27 PM, tony_t_tubbs <tony_t_tubbs@...> wrote:
             

            Because this is a POC with a fair amount of R&D involved, it is hard to say if we can get things done without overtime or not. The gut feel is that there is a risk that we cannot.

            Sprint review is another struggle, but we do talk about what went well and what didn't. The things that didn't so far seem to fit into one of two categories - environment or standups. We are slowing addressing items in both cases, but these still are the biggest areas of impact.



            --- In scrumdevelopment@yahoogroups.com, Andrew Burrows <andy@...> wrote:
            >
            > Hey Tony,
            >
            > Are the total story points for all the work that needs to be done by June
            > 1st possible with the existing team without working overtime? If so, I'd
            > work on helping management track your team's progress through your build
            > iterations. Could you describe your current sprint review process?
            >
            > Andrew
            >
            > On Mon, Apr 16, 2012 at 12:41 PM, tony_t_tubbs <tony_t_tubbs@...>wrote:
            >
            > > **

            > >
            > >
            > > Management's desire has been and is to use ScrumWorks so they can run
            > > reports so they can see progress. The team often feels like this is forcing
            > > a tool that doesn't always fit. Our current situation is a POC sprint that
            > > has a lot of R&D to do. We do not know hours like we might otherwise. We
            > > have estimated story points relative to each other. We know when we start,
            > > and we know when and what MUST be done - a functioning POC of specific key
            > > concepts and business functions by June 1 as proof we can do a full
            > > implementation.
            > >
            > > Really, the POC containing the stories we've identified MUST be done.
            > > Whatever that takes. Longer hours or what not. The management wants hours
            > > in scrumworks so they can see if we are on track or not. I've suggested
            > > burndown only stores, or perhaps story points. (Which doesn't fit into
            > > ScrumWorks reporting I guess) They claim this is too high level to make
            > > adjustments, that being off track will not show in the chart until it's too
            > > late. By then longer hours or adding people or whatever will just be too
            > > late.
            > >
            > > Note that I personally, and expect many of you, would put this scenario
            > > into ScrumButt category. Assuming there's nothing I can do about that for
            > > the moment, please advise what I can actually do to best meet the
            > > needs/desires. If it can be done in a way that could convince management
            > > there's a better way, then all the better for me and my fellow developers.
            > >
            > > Thanks,
            > > TT
            > >
            > >
            > >
            >
            >
            >
            > --
            > Andrew Burrows
            > Managing Producer, Large Animal Games
            > Call me: 212-989-4312
            > Follow me: @readytoscrumble
            > We're Hiring: http://largeanimal.com/jobs
            >


          • tony_t_tubbs
            Sorry, Proof of concept.
            Message 5 of 25 , Apr 16, 2012
            • 0 Attachment
              Sorry,
              Proof of concept.

              --- In scrumdevelopment@yahoogroups.com, Bret Wortman <bret@...> wrote:
              >
              > I may be alone here, but... POC? Definition in this context, please? I
              > can't get past "Point Of Contact".
              >
              >
              > *Bret Wortman***
              >
              >
              >
              > On Mon, Apr 16, 2012 at 1:27 PM, tony_t_tubbs <tony_t_tubbs@...>wrote:
              >
              > > **
              > >
              > >
              > > Because this is a POC with a fair amount of R&D involved, it is hard to
              > > say if we can get things done without overtime or not. The gut feel is that
              > > there is a risk that we cannot.
              > >
              > > Sprint review is another struggle, but we do talk about what went well and
              > > what didn't. The things that didn't so far seem to fit into one of two
              > > categories - environment or standups. We are slowing addressing items in
              > > both cases, but these still are the biggest areas of impact.
              > >
              > >
              > > --- In scrumdevelopment@yahoogroups.com, Andrew Burrows <andy@> wrote:
              > > >
              > > > Hey Tony,
              > > >
              > > > Are the total story points for all the work that needs to be done by June
              > > > 1st possible with the existing team without working overtime? If so, I'd
              > > > work on helping management track your team's progress through your build
              > > > iterations. Could you describe your current sprint review process?
              > > >
              > > > Andrew
              > > >
              > > > On Mon, Apr 16, 2012 at 12:41 PM, tony_t_tubbs <tony_t_tubbs@>wrote:
              > > >
              > > > > **
              > >
              > > > >
              > > > >
              > > > > Management's desire has been and is to use ScrumWorks so they can run
              > > > > reports so they can see progress. The team often feels like this is
              > > forcing
              > > > > a tool that doesn't always fit. Our current situation is a POC sprint
              > > that
              > > > > has a lot of R&D to do. We do not know hours like we might otherwise.
              > > We
              > > > > have estimated story points relative to each other. We know when we
              > > start,
              > > > > and we know when and what MUST be done - a functioning POC of specific
              > > key
              > > > > concepts and business functions by June 1 as proof we can do a full
              > > > > implementation.
              > > > >
              > > > > Really, the POC containing the stories we've identified MUST be done.
              > > > > Whatever that takes. Longer hours or what not. The management wants
              > > hours
              > > > > in scrumworks so they can see if we are on track or not. I've suggested
              > > > > burndown only stores, or perhaps story points. (Which doesn't fit into
              > > > > ScrumWorks reporting I guess) They claim this is too high level to make
              > > > > adjustments, that being off track will not show in the chart until
              > > it's too
              > > > > late. By then longer hours or adding people or whatever will just be
              > > too
              > > > > late.
              > > > >
              > > > > Note that I personally, and expect many of you, would put this scenario
              > > > > into ScrumButt category. Assuming there's nothing I can do about that
              > > for
              > > > > the moment, please advise what I can actually do to best meet the
              > > > > needs/desires. If it can be done in a way that could convince
              > > management
              > > > > there's a better way, then all the better for me and my fellow
              > > developers.
              > > > >
              > > > > Thanks,
              > > > > TT
              > > > >
              > > > >
              > > > >
              > > >
              > > >
              > > >
              > > > --
              > > > Andrew Burrows
              > > > Managing Producer, Large Animal Games
              > > > Call me: 212-989-4312
              > > > Follow me: @readytoscrumble
              > > > We're Hiring: http://largeanimal.com/jobs
              > > >
              > >
              > >
              > >
              >
            • Bret Wortman
              I should have gotten that. Thanks. Makes perfect sense in context. *Bret Wortman***
              Message 6 of 25 , Apr 16, 2012
              • 0 Attachment
                I should have gotten that. Thanks. Makes perfect sense in context.


                Bret Wortman



                On Mon, Apr 16, 2012 at 1:42 PM, tony_t_tubbs <tony_t_tubbs@...> wrote:
                 

                Sorry,
                Proof of concept.



                --- In scrumdevelopment@yahoogroups.com, Bret Wortman <bret@...> wrote:
                >
                > I may be alone here, but... POC? Definition in this context, please? I
                > can't get past "Point Of Contact".
                >
                >
                > *Bret Wortman***
                >
                >
                >
                > On Mon, Apr 16, 2012 at 1:27 PM, tony_t_tubbs <tony_t_tubbs@...>wrote:
                >
                > > **

                > >
                > >
                > > Because this is a POC with a fair amount of R&D involved, it is hard to
                > > say if we can get things done without overtime or not. The gut feel is that
                > > there is a risk that we cannot.
                > >
                > > Sprint review is another struggle, but we do talk about what went well and
                > > what didn't. The things that didn't so far seem to fit into one of two
                > > categories - environment or standups. We are slowing addressing items in
                > > both cases, but these still are the biggest areas of impact.
                > >
                > >
                > > --- In scrumdevelopment@yahoogroups.com, Andrew Burrows <andy@> wrote:
                > > >
                > > > Hey Tony,
                > > >
                > > > Are the total story points for all the work that needs to be done by June
                > > > 1st possible with the existing team without working overtime? If so, I'd
                > > > work on helping management track your team's progress through your build
                > > > iterations. Could you describe your current sprint review process?
                > > >
                > > > Andrew
                > > >
                > > > On Mon, Apr 16, 2012 at 12:41 PM, tony_t_tubbs <tony_t_tubbs@>wrote:

                > > >
                > > > > **
                > >
                > > > >
                > > > >
                > > > > Management's desire has been and is to use ScrumWorks so they can run
                > > > > reports so they can see progress. The team often feels like this is
                > > forcing
                > > > > a tool that doesn't always fit. Our current situation is a POC sprint
                > > that
                > > > > has a lot of R&D to do. We do not know hours like we might otherwise.
                > > We
                > > > > have estimated story points relative to each other. We know when we
                > > start,
                > > > > and we know when and what MUST be done - a functioning POC of specific
                > > key
                > > > > concepts and business functions by June 1 as proof we can do a full
                > > > > implementation.
                > > > >
                > > > > Really, the POC containing the stories we've identified MUST be done.
                > > > > Whatever that takes. Longer hours or what not. The management wants
                > > hours
                > > > > in scrumworks so they can see if we are on track or not. I've suggested
                > > > > burndown only stores, or perhaps story points. (Which doesn't fit into
                > > > > ScrumWorks reporting I guess) They claim this is too high level to make
                > > > > adjustments, that being off track will not show in the chart until
                > > it's too
                > > > > late. By then longer hours or adding people or whatever will just be
                > > too
                > > > > late.
                > > > >
                > > > > Note that I personally, and expect many of you, would put this scenario
                > > > > into ScrumButt category. Assuming there's nothing I can do about that
                > > for
                > > > > the moment, please advise what I can actually do to best meet the
                > > > > needs/desires. If it can be done in a way that could convince
                > > management
                > > > > there's a better way, then all the better for me and my fellow
                > > developers.
                > > > >
                > > > > Thanks,
                > > > > TT
                > > > >
                > > > >
                > > > >
                > > >
                > > >
                > > >
                > > > --
                > > > Andrew Burrows
                > > > Managing Producer, Large Animal Games
                > > > Call me: 212-989-4312
                > > > Follow me: @readytoscrumble
                > > > We're Hiring: http://largeanimal.com/jobs
                > > >
                > >
                > >
                > >
                >


              • RonJeffries
                Hi Tony, ... And you feel that overtime will actually make you get done, and done better? Ron Jeffries www.XProgramming.com There s no word for accountability
                Message 7 of 25 , Apr 16, 2012
                • 0 Attachment
                  Hi Tony,

                  On Apr 16, 2012, at 1:27 PM, tony_t_tubbs wrote:

                  Because this is a POC with a fair amount of R&D involved, it is hard to say if we can get things done without overtime or not.  The gut feel is that there is a risk that we cannot

                  And you feel that overtime will actually make you get done, and done better?

                  Ron Jeffries
                  www.XProgramming.com
                  There's no word for accountability in Finnish. 
                  Accountability is something that is left when responsibility has been subtracted. 
                  --Pasi Sahlberg

                • tony_t_tubbs
                  Can t say that for sure. It could mean we are still getting paid on June 2nd though. :D I ve suggested we get a coach to work with us on becoming a mature
                  Message 8 of 25 , Apr 16, 2012
                  • 0 Attachment
                    Can't say that for sure. It could mean we are still getting paid on June 2nd though. :D

                    I've suggested we get a coach to work with us on becoming a mature scrum team/organization. As it is, we send folks to 2 day CSM training and then it's trial by fire. Though I believe we have the right folks in all the proper rolls (except for maybe a proper PO), and we all share a desire to do it 'right', it's just slow going as we are teams of mostly people new to this process.

                    One of the things I personally struggle with, and what I think your comment is getting to, is how to manage the theory of 'the book' with the reality of the situation. If the PO says 'The agreement is A, B and C must be done by June 1, you figure out how to get it done', then you figure it out, yes?

                    --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                    >
                    > Hi Tony,
                    >
                    > On Apr 16, 2012, at 1:27 PM, tony_t_tubbs wrote:
                    >
                    > > Because this is a POC with a fair amount of R&D involved, it is hard to say if we can get things done without overtime or not. The gut feel is that there is a risk that we cannot
                    >
                    >
                    > And you feel that overtime will actually make you get done, and done better?
                    >
                    > Ron Jeffries
                    > www.XProgramming.com
                    > There's no word for accountability in Finnish.
                    > Accountability is something that is left when responsibility has been subtracted.
                    > --Pasi Sahlberg
                    >
                  • Andrew Burrows
                    Hey Tony, It seems like you know that you re going to need to work overtime to complete this work... would you agree with that? It also sounds like your team
                    Message 9 of 25 , Apr 16, 2012
                    • 0 Attachment
                      Hey Tony,

                      It seems like you know that you're going to need to work overtime to complete this work... would you agree with that? It also sounds like your team is willing to do whatever and improve and strive to be better, which is fantastic.

                      The reason I originally asked about sprint review was that I'd recommend establishing these meetings and inviting all those managers who count your hours. I would ask them to evaluate your product and direction. Instead of looking at it in terms of "you are 20 hours behind where you said you would be, we need another engineer", have them bring the discussion around to "I like this part of the product, in a week from now do you think we can be here? What about if we add a resource?" I would focus their attention on the product that is being built, and tracking progress that way.

                      As far as what your PO says about getting A,B and C done by a certain date... sure, you can figure out how to get it done. You can get anything done by June 1st without working overtime. It may not be what the PO wants, though. If your PO is really being as dismissive as it seems in your statement, I would guess that your PO knows you can't do it without considerable overtime and would rather you come to the decision of working late without them having to ask you to.

                      Andrew

                      On Mon, Apr 16, 2012 at 2:22 PM, tony_t_tubbs <tony_t_tubbs@...> wrote:
                       

                      Can't say that for sure. It could mean we are still getting paid on June 2nd though. :D

                      I've suggested we get a coach to work with us on becoming a mature scrum team/organization. As it is, we send folks to 2 day CSM training and then it's trial by fire. Though I believe we have the right folks in all the proper rolls (except for maybe a proper PO), and we all share a desire to do it 'right', it's just slow going as we are teams of mostly people new to this process.

                      One of the things I personally struggle with, and what I think your comment is getting to, is how to manage the theory of 'the book' with the reality of the situation. If the PO says 'The agreement is A, B and C must be done by June 1, you figure out how to get it done', then you figure it out, yes?



                      --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                      >
                      > Hi Tony,
                      >
                      > On Apr 16, 2012, at 1:27 PM, tony_t_tubbs wrote:
                      >
                      > > Because this is a POC with a fair amount of R&D involved, it is hard to say if we can get things done without overtime or not. The gut feel is that there is a risk that we cannot
                      >
                      >
                      > And you feel that overtime will actually make you get done, and done better?
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > There's no word for accountability in Finnish.
                      > Accountability is something that is left when responsibility has been subtracted.
                      > --Pasi Sahlberg
                      >




                      --
                      Andrew Burrows
                      Managing Producer, Large Animal Games
                      Call me: 212-989-4312
                      Follow me: @readytoscrumble

                    • RonJeffries
                      Hi Tony, ... Actually, no. It is the PO s job to manage scope so as to deliver the best possible product (highest possible value) by the due date. Teams
                      Message 10 of 25 , Apr 16, 2012
                      • 0 Attachment
                        Hi Tony,

                        On Apr 16, 2012, at 2:22 PM, tony_t_tubbs wrote:

                        If the PO says 'The agreement is A, B and C must be done by June 1, you figure out how to get it done', then you figure it out, yes?

                        Actually, no. It is the PO's job to manage scope so as to deliver the best possible product (highest possible value) by the due date.

                        Teams generally produce X amount of work per unit time. The PO's job is to choose the specific items that produce the best product by the deadline.

                        Teams generally do not produce more and better work by working more hours. Generally, overtime produces inferior work, and, quite often, less overall. It is possible -- there is not general agreement on this -- that a team can get more done, for a little while, working more hours. My own experience causes me to doubt this very strongly.

                        If I had to hit a deadline, I'd put effort into thinning down the stories. Your PO, as you suspect, is not doing the PO's job. He or she is just cracking the whip and setting you up to be the fall guys. I'd not be loving that were it me. In fact, I've been there many times, and it didn't ever turn out as well as making good scope decisions would have.

                        Good luck ... for now you just have to gut it through, I guess ...

                        Ron Jeffries
                        www.XProgramming.com
                        Everything that needs to be said has already been said.
                        But since no one was listening, everything must be said again. -- Andre Gide

                      • tony_t_tubbs
                        I read these forums often, and know you consistently in evangelizing this point of view. I completely agree that going doing things this way will undoubtedly
                        Message 11 of 25 , Apr 16, 2012
                        • 0 Attachment
                          I read these forums often, and know you consistently in evangelizing this point of view. I completely agree that going doing things this way will undoubtedly lead to a better product and code base in the end.

                          We have raised concerns, and made requests. These have gone all the way to The Board. There's no time or budget there to help us out. As such, we've reduced scope to the minimum it is believed the market will accept (we all believe do diligence was done here). At the same time there is a race to market, and end of year is a key date for that. At the end of all that the situation is that A, B and C must be done by June 1 so that D - N can be done by Dec. 31. M - Z have been postponed to be completed through 2014.

                          I guess I'm saying we as a team and PO are in agreement that we have defined the best product possible by the due date - one that provides the minimum necessary to enter the market next year.

                          Entering the market as late as 2Q next year could be too late. This is where I get lost between what is advocated by the books vs what I see day after day, year after year. I'm not suggesting you're wrong. I expect you have seen and experienced something different than I have. This is where I think a coach would really help us. We seem stuck in our box unable to see how to bridge the gap between these seemingly conflicting goals.

                          TT


                          --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                          >
                          > Hi Tony,
                          >
                          > On Apr 16, 2012, at 2:22 PM, tony_t_tubbs wrote:
                          >
                          > > If the PO says 'The agreement is A, B and C must be done by June 1, you figure out how to get it done', then you figure it out, yes?
                          >
                          >
                          > Actually, no. It is the PO's job to manage scope so as to deliver the best possible product (highest possible value) by the due date.
                          >
                          > Teams generally produce X amount of work per unit time. The PO's job is to choose the specific items that produce the best product by the deadline.
                          >
                          > Teams generally do not produce more and better work by working more hours. Generally, overtime produces inferior work, and, quite often, less overall. It is possible -- there is not general agreement on this -- that a team can get more done, for a little while, working more hours. My own experience causes me to doubt this very strongly.
                          >
                          > If I had to hit a deadline, I'd put effort into thinning down the stories. Your PO, as you suspect, is not doing the PO's job. He or she is just cracking the whip and setting you up to be the fall guys. I'd not be loving that were it me. In fact, I've been there many times, and it didn't ever turn out as well as making good scope decisions would have.
                          >
                          > Good luck ... for now you just have to gut it through, I guess ...
                          >
                          > Ron Jeffries
                          > www.XProgramming.com
                          > Everything that needs to be said has already been said.
                          > But since no one was listening, everything must be said again. -- Andre Gide
                          >
                        • tony_t_tubbs
                          We have done these things. It s even happened that our management got a sense of the technical debt that had built up so the past couple of sprints have been
                          Message 12 of 25 , Apr 16, 2012
                          • 0 Attachment
                            We have done these things. It's even happened that our management got a sense of the technical debt that had built up so the past couple of sprints have been a concerted effort to bring that down. All without us as developers even asking.

                            As I just explained in a reply to Ron, we feel we've exhausted all avenues of help and scoped things down to the minimum we need to enter the market. I did not intend to imply management was dismissive. We feel we have more support from this management structure for following an agile process more than any we've done before (we are spinning up a new division in the financial market)



                            --- In scrumdevelopment@yahoogroups.com, Andrew Burrows <andy@...> wrote:
                            >
                            > Hey Tony,
                            >
                            > It seems like you know that you're going to need to work overtime to
                            > complete this work... would you agree with that? It also sounds like your
                            > team is willing to do whatever and improve and strive to be better, which
                            > is fantastic.
                            >
                            > The reason I originally asked about sprint review was that I'd recommend
                            > establishing these meetings and inviting all those managers who count your
                            > hours. I would ask them to evaluate your product and direction. Instead of
                            > looking at it in terms of "you are 20 hours behind where you said you would
                            > be, we need another engineer", have them bring the discussion around to "I
                            > like this part of the product, in a week from now do you think we can be
                            > here? What about if we add a resource?" I would focus their attention on
                            > the product that is being built, and tracking progress that way.
                            >
                            > As far as what your PO says about getting A,B and C done by a certain
                            > date... sure, you can figure out how to get it done. You can get anything
                            > done by June 1st without working overtime. It may not be what the PO wants,
                            > though. If your PO is really being as dismissive as it seems in your
                            > statement, I would guess that your PO knows you can't do it without
                            > considerable overtime and would rather you come to the decision of working
                            > late without them having to ask you to.
                            >
                            > Andrew
                            >
                            > On Mon, Apr 16, 2012 at 2:22 PM, tony_t_tubbs <tony_t_tubbs@...>wrote:
                            >
                            > > **
                            > >
                            > >
                            > > Can't say that for sure. It could mean we are still getting paid on June
                            > > 2nd though. :D
                            > >
                            > > I've suggested we get a coach to work with us on becoming a mature scrum
                            > > team/organization. As it is, we send folks to 2 day CSM training and then
                            > > it's trial by fire. Though I believe we have the right folks in all the
                            > > proper rolls (except for maybe a proper PO), and we all share a desire to
                            > > do it 'right', it's just slow going as we are teams of mostly people new to
                            > > this process.
                            > >
                            > > One of the things I personally struggle with, and what I think your
                            > > comment is getting to, is how to manage the theory of 'the book' with the
                            > > reality of the situation. If the PO says 'The agreement is A, B and C must
                            > > be done by June 1, you figure out how to get it done', then you figure it
                            > > out, yes?
                            > >
                            > >
                            > > --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@>
                            > > wrote:
                            > > >
                            > > > Hi Tony,
                            > > >
                            > > > On Apr 16, 2012, at 1:27 PM, tony_t_tubbs wrote:
                            > > >
                            > > > > Because this is a POC with a fair amount of R&D involved, it is hard
                            > > to say if we can get things done without overtime or not. The gut feel is
                            > > that there is a risk that we cannot
                            > > >
                            > > >
                            > > > And you feel that overtime will actually make you get done, and done
                            > > better?
                            > > >
                            > > > Ron Jeffries
                            > > > www.XProgramming.com
                            > > > There's no word for accountability in Finnish.
                            > > > Accountability is something that is left when responsibility has been
                            > > subtracted.
                            > > > --Pasi Sahlberg
                            > > >
                            > >
                            > >
                            > >
                            >
                            >
                            >
                            > --
                            > Andrew Burrows
                            > Managing Producer, Large Animal Games
                            > Call me: 212-989-4312
                            > Follow me: @readytoscrumble
                            > We're Hiring: http://largeanimal.com/jobs
                            >
                          • RonJeffries
                            Hi TOny, ... It s not my point of view . It s the real, true, actual definition of Scrum. (It is also my point of view as it happens.) ... OK ... ... How
                            Message 13 of 25 , Apr 16, 2012
                            • 0 Attachment
                              Hi TOny,

                              On Apr 16, 2012, at 3:19 PM, tony_t_tubbs wrote:

                              I read these forums often, and know you consistently in evangelizing this point of view.  I completely agree that going doing things this way will undoubtedly lead to a better product and code base in the end.

                              It's not my "point of view". It's the real, true, actual definition of Scrum. (It is also my point of view as it happens.)

                              We have raised concerns, and made requests.  These have gone all the way to The Board.  There's no time or budget there to help us out.  As such, we've reduced scope to the minimum it is believed the market will accept (we all believe do diligence was done here).  At the same time there is a race to market, and end of year is a key date for that. At the end of all that the situation is that A, B and C must be done by June 1 so that D - N can be done by Dec. 31.  M - Z have been postponed to be completed through 2014.  

                              OK ...

                              I guess I'm saying we as a team and PO are in agreement that we have defined the best product possible by the due date - one that provides the minimum necessary to enter the market next year.

                              How confident are you, personally, that this is possible? If you're not totally confident (and it sounds like you are not), then what else should you, and the company, be doing?

                              Or (as is likely in my opinion) will the company really not explode into bits when, as seems quite possible, the team delivers somewhat too little, somewhat too late? And if the company really will not explode into bits, what, looking back from that date, would have produced a better result than "work overtime"?

                              Entering the market as late as 2Q next year could be too late.  This is where I get lost between what is advocated by the books vs what I see day after day, year after year.  I'm not suggesting you're wrong.  I expect you have seen and experienced something different than I have.  This is where I think a coach would really help us.  We seem stuck in our box unable to see how to bridge the gap between these seemingly conflicting goals.

                              These are the main possibilities I can see:

                              • Overtime will make you go fast enough to get what you need. There are a number of Very Big Assumptions in this one. First, that overtime will make you go faster, not slower, between now and June. Science, and experience, are against you on this one. Second, that if overtime does make you go faster, it will make you go enough faster that stopping steering now, in April, and just running like hell until June will do the job. What are the odds of that?
                              • These features, as currently defined, are the absolute minimum viable product. Think how good you'd have to be, as a company, to have gotten it exactly right, with nothing capable of being thinned down, and nothing needing a bit of ramping up. And, if you are that good, so that you're all that confident, why not add in one or two very very good contract developers to help you. Not crappy beginners, but gods of programming. I could recommend some.
                              • Overtime will not get us where we're aiming. This is incredibly likely to be true. So likely that you, your team, and your company need to do some serious risk management.
                              • This isn't the minimum viable product. This is also incredibly likely to be true. So likely that your organization needs to find a way to create some slack, and some information, between now and then.

                              I have been in your situation many times in my half century in this business. Never once was overtime the best thing to do, in retrospect, though we did it many times. The result, every time, was that we produced less code, of lower quality, than we would have otherwise. The result, every time, was that people suffered and, almost always, the company lost good people who quit when they became aware of the disrespect that lies beneath "someone made this promise, your job is to make it happen". 

                              My guess is that you're caught in this trap now and there is no way out but to bull it through. It's quite possible that you'll get enough done to survive. It's quite possible that you'll stay in business one way or another. Almost always, that's what happens.

                              It's unfortunate that when we do something heroic and survive it, we tend to conclude that only by doing heroic things can we survive, and that if we were only more heroic we might even thrive.

                              In my experience, nothing could be less true. We survive the heroism, and we survive the inferior work that heroics make us produce, and when we reflect later, we realize that we could, therefore, have done more work, better work, with less pain, by working smarter, rather than harder.

                              We both know you're going to go ahead and do this. I hope at the other end, whatever happens, you'll think about it and come back and tell us about it.

                              Good luck ...
                              If not now, when? -- Rabbi Hillel

                            • tony_t_tubbs
                              Right, I know it s the real, true, actual SCRUM definition. I meant to say that you personally evangelize it well, that you personally don t waffle from it.
                              Message 14 of 25 , Apr 16, 2012
                              • 0 Attachment
                                Right, I know it's the real, true, actual SCRUM definition. I meant to say that you personally evangelize it well, that you personally don't waffle from it. I am aware that you do not stand alone either, so didn't mean to imply that this was your point of view and yours alone.

                                We feel there is a real chance we can get done what we need to get done by years end. Especially if things go a planned, but we all know that rarely happens though. Still, we do not expect a worse case scenario either.

                                You would also be correct in saying the company wouldn't implode or explode, but there is a chance this new division could. Probably not this time, as there's great potential here, but we will not be forgiven indefinably either. It truly is important for the life of this division to get to market in a timely manner.

                                Otherwise, you've given some good thought to think about. Hope I can come back by years end and say we made it, or are at least still in a job.

                                Thanks again,
                                TT


                                --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                                >
                                > Hi TOny,
                                >
                                > On Apr 16, 2012, at 3:19 PM, tony_t_tubbs wrote:
                                >
                                > > I read these forums often, and know you consistently in evangelizing this point of view. I completely agree that going doing things this way will undoubtedly lead to a better product and code base in the end.
                                >
                                > It's not my "point of view". It's the real, true, actual definition of Scrum. (It is also my point of view as it happens.)
                                > >
                                > > We have raised concerns, and made requests. These have gone all the way to The Board. There's no time or budget there to help us out. As such, we've reduced scope to the minimum it is believed the market will accept (we all believe do diligence was done here). At the same time there is a race to market, and end of year is a key date for that. At the end of all that the situation is that A, B and C must be done by June 1 so that D - N can be done by Dec. 31. M - Z have been postponed to be completed through 2014.
                                >
                                > OK ...
                                > >
                                > > I guess I'm saying we as a team and PO are in agreement that we have defined the best product possible by the due date - one that provides the minimum necessary to enter the market next year.
                                >
                                > How confident are you, personally, that this is possible? If you're not totally confident (and it sounds like you are not), then what else should you, and the company, be doing?
                                >
                                > Or (as is likely in my opinion) will the company really not explode into bits when, as seems quite possible, the team delivers somewhat too little, somewhat too late? And if the company really will not explode into bits, what, looking back from that date, would have produced a better result than "work overtime"?
                                > >
                                > > Entering the market as late as 2Q next year could be too late. This is where I get lost between what is advocated by the books vs what I see day after day, year after year. I'm not suggesting you're wrong. I expect you have seen and experienced something different than I have. This is where I think a coach would really help us. We seem stuck in our box unable to see how to bridge the gap between these seemingly conflicting goals.
                                >
                                >
                                > These are the main possibilities I can see:
                                >
                                > Overtime will make you go fast enough to get what you need. There are a number of Very Big Assumptions in this one. First, that overtime will make you go faster, not slower, between now and June. Science, and experience, are against you on this one. Second, that if overtime does make you go faster, it will make you go enough faster that stopping steering now, in April, and just running like hell until June will do the job. What are the odds of that?
                                > These features, as currently defined, are the absolute minimum viable product. Think how good you'd have to be, as a company, to have gotten it exactly right, with nothing capable of being thinned down, and nothing needing a bit of ramping up. And, if you are that good, so that you're all that confident, why not add in one or two very very good contract developers to help you. Not crappy beginners, but gods of programming. I could recommend some.
                                > Overtime will not get us where we're aiming. This is incredibly likely to be true. So likely that you, your team, and your company need to do some serious risk management.
                                > This isn't the minimum viable product. This is also incredibly likely to be true. So likely that your organization needs to find a way to create some slack, and some information, between now and then.
                                >
                                > I have been in your situation many times in my half century in this business. Never once was overtime the best thing to do, in retrospect, though we did it many times. The result, every time, was that we produced less code, of lower quality, than we would have otherwise. The result, every time, was that people suffered and, almost always, the company lost good people who quit when they became aware of the disrespect that lies beneath "someone made this promise, your job is to make it happen".
                                >
                                > My guess is that you're caught in this trap now and there is no way out but to bull it through. It's quite possible that you'll get enough done to survive. It's quite possible that you'll stay in business one way or another. Almost always, that's what happens.
                                >
                                > It's unfortunate that when we do something heroic and survive it, we tend to conclude that only by doing heroic things can we survive, and that if we were only more heroic we might even thrive.
                                >
                                > In my experience, nothing could be less true. We survive the heroism, and we survive the inferior work that heroics make us produce, and when we reflect later, we realize that we could, therefore, have done more work, better work, with less pain, by working smarter, rather than harder.
                                >
                                > We both know you're going to go ahead and do this. I hope at the other end, whatever happens, you'll think about it and come back and tell us about it.
                                >
                                > Good luck ...
                                >
                                > Ron Jeffries
                                > www.XProgramming.com
                                > If not now, when? -- Rabbi Hillel
                                >
                              • RonJeffries
                                ... If it really is, won t a more active engagement with the product side thinkers give you a better shot? ... Me too ... :) Ron Jeffries www.XProgramming.com
                                Message 15 of 25 , Apr 16, 2012
                                • 0 Attachment

                                  On Apr 16, 2012, at 4:01 PM, tony_t_tubbs wrote:

                                  You would also be correct in saying the company wouldn't implode or explode, but there is a chance this new division could.  Probably not this time, as there's great potential here, but we will not be forgiven indefinably either.  It truly is important for the life of this division to get to market in a timely manner.  

                                  If it really is, won't a more active engagement with the product side thinkers give you a better shot?

                                  Otherwise, you've given some good thought to think about.  Hope I can come back by years end and say we made it, or are at least still in a job.

                                  Me too ... :)

                                  Ron Jeffries
                                  www.XProgramming.com
                                  I try to Zen through it and keep my voice very mellow and low.
                                  Inside I am screaming and have a machine gun.
                                  Yin and Yang I figure.
                                    -- Tom Jeffries

                                • Adam Sroka
                                  Hi Tony: I think you re in more or less the same situation as a lot of people. It saddens me to see so many companies pursue the perceived benefits of Agile
                                  Message 16 of 25 , Apr 16, 2012
                                  • 0 Attachment
                                    Hi Tony:

                                    I think you're in more or less the same situation as a lot of people. 

                                    It saddens me to see so many companies pursue the perceived benefits of Agile and then undermine it by refusing to revisit basic planning practices. 

                                    If you know exactly what you are going to build and exactly when you are going to deliver it, and you're sticking to that plan come hell or high water even if your people's personal lives have to suffer, then why on Earth would you bother with Scrum? You're just adding overhead and rejecting all of the benefits! 

                                    On Mon, Apr 16, 2012 at 1:01 PM, tony_t_tubbs <tony_t_tubbs@...> wrote:
                                     

                                    Right, I know it's the real, true, actual SCRUM definition. I meant to say that you personally evangelize it well, that you personally don't waffle from it. I am aware that you do not stand alone either, so didn't mean to imply that this was your point of view and yours alone.

                                    We feel there is a real chance we can get done what we need to get done by years end. Especially if things go a planned, but we all know that rarely happens though. Still, we do not expect a worse case scenario either.

                                    You would also be correct in saying the company wouldn't implode or explode, but there is a chance this new division could. Probably not this time, as there's great potential here, but we will not be forgiven indefinably either. It truly is important for the life of this division to get to market in a timely manner.

                                    Otherwise, you've given some good thought to think about. Hope I can come back by years end and say we made it, or are at least still in a job.

                                    Thanks again,


                                    TT

                                    --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                                    >
                                    > Hi TOny,
                                    >
                                    > On Apr 16, 2012, at 3:19 PM, tony_t_tubbs wrote:
                                    >
                                    > > I read these forums often, and know you consistently in evangelizing this point of view. I completely agree that going doing things this way will undoubtedly lead to a better product and code base in the end.
                                    >
                                    > It's not my "point of view". It's the real, true, actual definition of Scrum. (It is also my point of view as it happens.)
                                    > >
                                    > > We have raised concerns, and made requests. These have gone all the way to The Board. There's no time or budget there to help us out. As such, we've reduced scope to the minimum it is believed the market will accept (we all believe do diligence was done here). At the same time there is a race to market, and end of year is a key date for that. At the end of all that the situation is that A, B and C must be done by June 1 so that D - N can be done by Dec. 31. M - Z have been postponed to be completed through 2014.
                                    >
                                    > OK ...
                                    > >
                                    > > I guess I'm saying we as a team and PO are in agreement that we have defined the best product possible by the due date - one that provides the minimum necessary to enter the market next year.
                                    >
                                    > How confident are you, personally, that this is possible? If you're not totally confident (and it sounds like you are not), then what else should you, and the company, be doing?
                                    >
                                    > Or (as is likely in my opinion) will the company really not explode into bits when, as seems quite possible, the team delivers somewhat too little, somewhat too late? And if the company really will not explode into bits, what, looking back from that date, would have produced a better result than "work overtime"?
                                    > >
                                    > > Entering the market as late as 2Q next year could be too late. This is where I get lost between what is advocated by the books vs what I see day after day, year after year. I'm not suggesting you're wrong. I expect you have seen and experienced something different than I have. This is where I think a coach would really help us. We seem stuck in our box unable to see how to bridge the gap between these seemingly conflicting goals.
                                    >
                                    >
                                    > These are the main possibilities I can see:
                                    >
                                    > Overtime will make you go fast enough to get what you need. There are a number of Very Big Assumptions in this one. First, that overtime will make you go faster, not slower, between now and June. Science, and experience, are against you on this one. Second, that if overtime does make you go faster, it will make you go enough faster that stopping steering now, in April, and just running like hell until June will do the job. What are the odds of that?
                                    > These features, as currently defined, are the absolute minimum viable product. Think how good you'd have to be, as a company, to have gotten it exactly right, with nothing capable of being thinned down, and nothing needing a bit of ramping up. And, if you are that good, so that you're all that confident, why not add in one or two very very good contract developers to help you. Not crappy beginners, but gods of programming. I could recommend some.
                                    > Overtime will not get us where we're aiming. This is incredibly likely to be true. So likely that you, your team, and your company need to do some serious risk management.
                                    > This isn't the minimum viable product. This is also incredibly likely to be true. So likely that your organization needs to find a way to create some slack, and some information, between now and then.
                                    >
                                    > I have been in your situation many times in my half century in this business. Never once was overtime the best thing to do, in retrospect, though we did it many times. The result, every time, was that we produced less code, of lower quality, than we would have otherwise. The result, every time, was that people suffered and, almost always, the company lost good people who quit when they became aware of the disrespect that lies beneath "someone made this promise, your job is to make it happen".
                                    >
                                    > My guess is that you're caught in this trap now and there is no way out but to bull it through. It's quite possible that you'll get enough done to survive. It's quite possible that you'll stay in business one way or another. Almost always, that's what happens.
                                    >
                                    > It's unfortunate that when we do something heroic and survive it, we tend to conclude that only by doing heroic things can we survive, and that if we were only more heroic we might even thrive.
                                    >
                                    > In my experience, nothing could be less true. We survive the heroism, and we survive the inferior work that heroics make us produce, and when we reflect later, we realize that we could, therefore, have done more work, better work, with less pain, by working smarter, rather than harder.
                                    >
                                    > We both know you're going to go ahead and do this. I hope at the other end, whatever happens, you'll think about it and come back and tell us about it.
                                    >
                                    > Good luck ...
                                    >
                                    > Ron Jeffries
                                    > www.XProgramming.com
                                    > If not now, when? -- Rabbi Hillel
                                    >


                                  • Dave Rooney
                                    ... Have you heard about or read The Lean Startup? May be worth having a look: http://theleanstartup.com/ As Ron said, what you (your org) believe to be the
                                    Message 17 of 25 , Apr 16, 2012
                                    • 0 Attachment
                                      On 12-04-16 3:38 PM, tony_t_tubbs wrote:
                                      ...we feel we've exhausted all avenues of help and scoped things down to the minimum we need to enter the market.

                                      Have you heard about or read The Lean Startup?  May be worth having a look:

                                      http://theleanstartup.com/

                                      As Ron said, what you (your org) believe to be the minimum quite likely isn't.  What criteria were used to determine "the minimum to enter the market"?  How does the product management group measure whether their assertions are correct or not (and to what degree)?

                                      Dave...
                                      Dave Rooney | Agile Coach and Co-founder
                                      Westboro Systems - Agile Coaching, Training, Organizational Transformation.
                                      Blog | Twitter | LinkedIn | Phone: +1.855.AGILE123 (244.5312)

                                    • tony_t_tubbs
                                      Exactly! Though I do think we have all the right motivations, so think we ll get there eventually. Just takes time to mature.
                                      Message 18 of 25 , Apr 16, 2012
                                      • 0 Attachment
                                        Exactly! Though I do think we have all the right motivations, so think we'll get there eventually. Just takes time to mature.




                                        --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                                        >
                                        > Hi Tony:
                                        >
                                        > I think you're in more or less the same situation as a lot of people.
                                        >
                                        > It saddens me to see so many companies pursue the perceived benefits of
                                        > Agile and then undermine it by refusing to revisit basic planning
                                        > practices.
                                        >
                                        > If you know exactly what you are going to build and exactly when you are
                                        > going to deliver it, and you're sticking to that plan come hell or high
                                        > water even if your people's personal lives have to suffer, then why on
                                        > Earth would you bother with Scrum? You're just adding overhead and
                                        > rejecting all of the benefits!
                                        >
                                      • Adam Sroka
                                        Well, the one benefit I d be surprised if you weren t already seeing is that you have to talk to each other more frequently and about more of the right
                                        Message 19 of 25 , Apr 16, 2012
                                        • 0 Attachment
                                          Well, the one benefit I'd be surprised if you weren't already seeing is that you have to talk to each other more frequently and about more of the "right things." That's huge, but it's really just a preview of what Agile is all about. Hopefully you have the patience and/or help that you need to move forward from here though. Good luck ;-) 

                                          On Mon, Apr 16, 2012 at 3:45 PM, tony_t_tubbs <tony_t_tubbs@...> wrote:
                                           

                                          Exactly! Though I do think we have all the right motivations, so think we'll get there eventually. Just takes time to mature.



                                          --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                                          >
                                          > Hi Tony:
                                          >
                                          > I think you're in more or less the same situation as a lot of people.
                                          >
                                          > It saddens me to see so many companies pursue the perceived benefits of
                                          > Agile and then undermine it by refusing to revisit basic planning
                                          > practices.
                                          >
                                          > If you know exactly what you are going to build and exactly when you are
                                          > going to deliver it, and you're sticking to that plan come hell or high
                                          > water even if your people's personal lives have to suffer, then why on
                                          > Earth would you bother with Scrum? You're just adding overhead and
                                          > rejecting all of the benefits!
                                          >


                                        • Mark Levison
                                          Tony - I ve only time to write a short reply and you deserve a lengthy one. Some observations. You comment that we evangelize and are dogmatic. Perhaps, but
                                          Message 20 of 25 , Apr 16, 2012
                                          • 0 Attachment
                                            Tony - I've only time to write a short reply and you deserve a lengthy one. Some observations. You comment that we evangelize and are dogmatic. Perhaps, but its also our experience of what works best in these situations. Its funny you said you wanted to hire a coach. Some of the best in the business offer their help for free, the same advice you could pay for :-). If you don't like the advice pay me for a week, but the advice won't likely change much, I will just be gentle.

                                            Your options
                                            1. Keep down your current path, work overtime and accumulate Technical Debt (please introduce your Management to the idea see:    http://www.infoq.com/articles/technical-debt-levison and http://agilepainrelief.com/notesfromatooluser/2012/02/scrummaster-talesstop-digging-new-holes.html - blatant self promotion). My experience says that once you've done more than one week of overtime you become less productive than if you just worked normal hours.
                                            2. I've never built a product where we really knew what we needed up front, Scrum works to help discover this as fast as possible. However Scrum only works if the Product Owner does their job well, prioritizes and prunes the Product Backlog. Constantly seeks input from the customers to ensure that they're building the right product.
                                            3. In your case why not release Software every two weeks and get feedback from real customers? Certain you're not ready? See: Elizabeth Hendrickson on  http://testobsessed.com/blog/2011/04/23/minimally-viable/ how she discovered new directions for her site entaggle.
                                            4. Replace the Product Owner with someone who is prepared to engage (sometimes a great tactic).
                                            Yes I'm being blunt and pushy, its only because time is short and I have small business to run. Answering questions on this forum doesn't help my students or clients. Net result you get brief feedback.

                                            Cheers
                                            Mark

                                            On Mon, Apr 16, 2012 at 2:22 PM, tony_t_tubbs <tony_t_tubbs@...> wrote:
                                             

                                            Can't say that for sure. It could mean we are still getting paid on June 2nd though. :D

                                            I've suggested we get a coach to work with us on becoming a mature scrum team/organization. As it is, we send folks to 2 day CSM training and then it's trial by fire. Though I believe we have the right folks in all the proper rolls (except for maybe a proper PO), and we all share a desire to do it 'right', it's just slow going as we are teams of mostly people new to this process.

                                            One of the things I personally struggle with, and what I think your comment is getting to, is how to manage the theory of 'the book' with the reality of the situation. If the PO says 'The agreement is A, B and C must be done by June 1, you figure out how to get it done', then you figure it out, yes?



                                            --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                                            >
                                            > Hi Tony,
                                            >
                                            > On Apr 16, 2012, at 1:27 PM, tony_t_tubbs wrote:
                                            >
                                            > > Because this is a POC with a fair amount of R&D involved, it is hard to say if we can get things done without overtime or not. The gut feel is that there is a risk that we cannot
                                            >
                                            >
                                            > And you feel that overtime will actually make you get done, and done better?
                                            >
                                            > Ron Jeffries
                                            > www.XProgramming.com
                                            > There's no word for accountability in Finnish.
                                            > Accountability is something that is left when responsibility has been subtracted.
                                            > --Pasi Sahlberg
                                            >


                                          • tony_t_tubbs
                                            Thanks Mark. I can tell I ve not been clear. I never, ever meant to imply I was not appreciative of the feedback here, or that I wanted to keep looking until
                                            Message 21 of 25 , Apr 17, 2012
                                            • 0 Attachment
                                              Thanks Mark. I can tell I've not been clear. I never, ever meant to imply I was not appreciative of the feedback here, or that I wanted to keep looking until I found someone who said what I wanted to hear. I'd be thrilled to have any on here as a coach. I *want* to have the experience you guys talk about, just haven't had the pleasure.

                                              So, don't hold back or be gentle on my account. I appreciate and desire the facts, however brutal they may be. Really! I found this thread helpful, not a let down in any way.

                                              Thanks to you and all again,
                                              TT


                                              --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@...> wrote:
                                              >
                                              > Tony - I've only time to write a short reply and you deserve a lengthy one.
                                              > Some observations. You comment that we evangelize and are dogmatic.
                                              > Perhaps, but its also our experience of what works best in these
                                              > situations. Its funny you said you wanted to hire a coach. Some of the best
                                              > in the business offer their help for free, the same advice you could pay
                                              > for :-). If you don't like the advice pay me for a week, but the advice
                                              > won't likely change much, I will just be gentle.
                                              >
                                              > Your options
                                              >
                                              > 1. Keep down your current path, work overtime and accumulate Technical
                                              > Debt (please introduce your Management to the idea see:
                                              > http://www.infoq.com/articles/technical-debt-levison and
                                              > http://agilepainrelief.com/notesfromatooluser/2012/02/scrummaster-talesstop-digging-new-holes.html
                                              > -
                                              > blatant self promotion). My experience says that once you've done more than
                                              > one week of overtime you become less productive than if you just worked
                                              > normal hours.
                                              > 2. I've never built a product where we really knew what we needed up
                                              > front, Scrum works to help discover this as fast as possible. However Scrum
                                              > only works if the Product Owner does their job well, prioritizes and prunes
                                              > the Product Backlog. Constantly seeks input from the customers to ensure
                                              > that they're building the right product.
                                              > 3. In your case why not release Software every two weeks and get
                                              > feedback from real customers? Certain you're not ready? See: Elizabeth
                                              > Hendrickson on
                                              > http://testobsessed.com/blog/2011/04/23/minimally-viable/ how
                                              > she discovered new directions for her site entaggle.
                                              > 4. Replace the Product Owner with someone who is prepared to engage
                                              > (sometimes a great tactic).
                                              >
                                              > Yes I'm being blunt and pushy, its only because time is short and I have
                                              > small business to run. Answering questions on this forum doesn't help my
                                              > students or clients. Net result you get brief feedback.
                                              >
                                              > Cheers
                                              > Mark
                                              >
                                              > On Mon, Apr 16, 2012 at 2:22 PM, tony_t_tubbs <tony_t_tubbs@...>wrote:
                                              >
                                              > > **
                                              > >
                                              > >
                                              > > Can't say that for sure. It could mean we are still getting paid on June
                                              > > 2nd though. :D
                                              > >
                                              > > I've suggested we get a coach to work with us on becoming a mature scrum
                                              > > team/organization. As it is, we send folks to 2 day CSM training and then
                                              > > it's trial by fire. Though I believe we have the right folks in all the
                                              > > proper rolls (except for maybe a proper PO), and we all share a desire to
                                              > > do it 'right', it's just slow going as we are teams of mostly people new to
                                              > > this process.
                                              > >
                                              > > One of the things I personally struggle with, and what I think your
                                              > > comment is getting to, is how to manage the theory of 'the book' with the
                                              > > reality of the situation. If the PO says 'The agreement is A, B and C must
                                              > > be done by June 1, you figure out how to get it done', then you figure it
                                              > > out, yes?
                                              > >
                                              > >
                                              > > --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@>
                                              > > wrote:
                                              > > >
                                              > > > Hi Tony,
                                              > > >
                                              > > > On Apr 16, 2012, at 1:27 PM, tony_t_tubbs wrote:
                                              > > >
                                              > > > > Because this is a POC with a fair amount of R&D involved, it is hard
                                              > > to say if we can get things done without overtime or not. The gut feel is
                                              > > that there is a risk that we cannot
                                              > > >
                                              > > >
                                              > > > And you feel that overtime will actually make you get done, and done
                                              > > better?
                                              > > >
                                              > > > Ron Jeffries
                                              > > > www.XProgramming.com
                                              > > > There's no word for accountability in Finnish.
                                              > > > Accountability is something that is left when responsibility has been
                                              > > subtracted.
                                              > > > --Pasi Sahlberg
                                              > > >
                                              > >
                                              > >
                                              > >
                                              >
                                            • woynam
                                              Another nugget. There s no point in delivering a product to market if you can t sustain the pace once it becomes a smashing success. By working overtime,
                                              Message 22 of 25 , Apr 17, 2012
                                              • 0 Attachment
                                                'Another nugget.

                                                There's no point in delivering a product to market if you can't sustain the pace once it becomes a smashing success.

                                                By working overtime, you'll accumulate technical debt, and you'll be behind the eight ball indefinitely. We've all seen this numerous times. If you're (i.e. the company) willing to accept mediocre code now, the pressure will be the same for future releases.

                                                There are plenty of examples of companies that couldn't deliver version 2.0, because version 1.0 was a house of cards. It would be much better to deliver a quality product with fewer features, or the same features a bit later, than deliver what you think is a minimum feature set on a codebase that will be difficult to build upon.

                                                Here be dragons.

                                                Mark


                                                --- In scrumdevelopment@yahoogroups.com, "tony_t_tubbs" <tony_t_tubbs@...> wrote:
                                                >
                                                > Thanks Mark. I can tell I've not been clear. I never, ever meant to imply I was not appreciative of the feedback here, or that I wanted to keep looking until I found someone who said what I wanted to hear. I'd be thrilled to have any on here as a coach. I *want* to have the experience you guys talk about, just haven't had the pleasure.
                                                >
                                                > So, don't hold back or be gentle on my account. I appreciate and desire the facts, however brutal they may be. Really! I found this thread helpful, not a let down in any way.
                                                >
                                                > Thanks to you and all again,
                                                > TT
                                                >
                                                >
                                                > --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@> wrote:
                                                > >
                                                > > Tony - I've only time to write a short reply and you deserve a lengthy one.
                                                > > Some observations. You comment that we evangelize and are dogmatic.
                                                > > Perhaps, but its also our experience of what works best in these
                                                > > situations. Its funny you said you wanted to hire a coach. Some of the best
                                                > > in the business offer their help for free, the same advice you could pay
                                                > > for :-). If you don't like the advice pay me for a week, but the advice
                                                > > won't likely change much, I will just be gentle.
                                                > >
                                                > > Your options
                                                > >
                                                > > 1. Keep down your current path, work overtime and accumulate Technical
                                                > > Debt (please introduce your Management to the idea see:
                                                > > http://www.infoq.com/articles/technical-debt-levison and
                                                > > http://agilepainrelief.com/notesfromatooluser/2012/02/scrummaster-talesstop-digging-new-holes.html
                                                > > -
                                                > > blatant self promotion). My experience says that once you've done more than
                                                > > one week of overtime you become less productive than if you just worked
                                                > > normal hours.
                                                > > 2. I've never built a product where we really knew what we needed up
                                                > > front, Scrum works to help discover this as fast as possible. However Scrum
                                                > > only works if the Product Owner does their job well, prioritizes and prunes
                                                > > the Product Backlog. Constantly seeks input from the customers to ensure
                                                > > that they're building the right product.
                                                > > 3. In your case why not release Software every two weeks and get
                                                > > feedback from real customers? Certain you're not ready? See: Elizabeth
                                                > > Hendrickson on
                                                > > http://testobsessed.com/blog/2011/04/23/minimally-viable/ how
                                                > > she discovered new directions for her site entaggle.
                                                > > 4. Replace the Product Owner with someone who is prepared to engage
                                                > > (sometimes a great tactic).
                                                > >
                                                > > Yes I'm being blunt and pushy, its only because time is short and I have
                                                > > small business to run. Answering questions on this forum doesn't help my
                                                > > students or clients. Net result you get brief feedback.
                                                > >
                                                > > Cheers
                                                > > Mark
                                                > >
                                                > > On Mon, Apr 16, 2012 at 2:22 PM, tony_t_tubbs <tony_t_tubbs@>wrote:
                                                > >
                                                > > > **
                                                > > >
                                                > > >
                                                > > > Can't say that for sure. It could mean we are still getting paid on June
                                                > > > 2nd though. :D
                                                > > >
                                                > > > I've suggested we get a coach to work with us on becoming a mature scrum
                                                > > > team/organization. As it is, we send folks to 2 day CSM training and then
                                                > > > it's trial by fire. Though I believe we have the right folks in all the
                                                > > > proper rolls (except for maybe a proper PO), and we all share a desire to
                                                > > > do it 'right', it's just slow going as we are teams of mostly people new to
                                                > > > this process.
                                                > > >
                                                > > > One of the things I personally struggle with, and what I think your
                                                > > > comment is getting to, is how to manage the theory of 'the book' with the
                                                > > > reality of the situation. If the PO says 'The agreement is A, B and C must
                                                > > > be done by June 1, you figure out how to get it done', then you figure it
                                                > > > out, yes?
                                                > > >
                                                > > >
                                                > > > --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@>
                                                > > > wrote:
                                                > > > >
                                                > > > > Hi Tony,
                                                > > > >
                                                > > > > On Apr 16, 2012, at 1:27 PM, tony_t_tubbs wrote:
                                                > > > >
                                                > > > > > Because this is a POC with a fair amount of R&D involved, it is hard
                                                > > > to say if we can get things done without overtime or not. The gut feel is
                                                > > > that there is a risk that we cannot
                                                > > > >
                                                > > > >
                                                > > > > And you feel that overtime will actually make you get done, and done
                                                > > > better?
                                                > > > >
                                                > > > > Ron Jeffries
                                                > > > > www.XProgramming.com
                                                > > > > There's no word for accountability in Finnish.
                                                > > > > Accountability is something that is left when responsibility has been
                                                > > > subtracted.
                                                > > > > --Pasi Sahlberg
                                                > > > >
                                                > > >
                                                > > >
                                                > > >
                                                > >
                                                >
                                              • Alan Dayley
                                                +1. Well said, Mark. Alan
                                                Message 23 of 25 , Apr 17, 2012
                                                • 0 Attachment
                                                  +1.  Well said, Mark.

                                                  Alan

                                                  On Tue, Apr 17, 2012 at 7:10 AM, woynam <woyna@...> wrote:
                                                   


                                                  'Another nugget.

                                                  There's no point in delivering a product to market if you can't sustain the pace once it becomes a smashing success.

                                                  By working overtime, you'll accumulate technical debt, and you'll be behind the eight ball indefinitely. We've all seen this numerous times. If you're (i.e. the company) willing to accept mediocre code now, the pressure will be the same for future releases.

                                                  There are plenty of examples of companies that couldn't deliver version 2.0, because version 1.0 was a house of cards. It would be much better to deliver a quality product with fewer features, or the same features a bit later, than deliver what you think is a minimum feature set on a codebase that will be difficult to build upon.

                                                  Here be dragons.

                                                  Mark



                                                • merceroz
                                                  TT I wanted to focus in on the reporting progress part of your question. From the sounds of it you have a PBL which outlines the stories to be delivered. You
                                                  Message 24 of 25 , Apr 17, 2012
                                                  • 0 Attachment
                                                    TT

                                                    I wanted to focus in on the reporting progress part of your question.

                                                    From the sounds of it you have a PBL which outlines the stories to be delivered. You mention points, so presumably you have or could work out, a rough sizing for each story. So as you say you could track the story and / or point burndown to track progress.

                                                    However you say that management "claim this is too high level to make adjustments, that being off track will not show in the chart until it's too late." I would focus in on what this means. If you work with short 1 week sprints, you've got six sprints to go, and can provide relevant feedback to management on a weekly basis. In addition, assuming you're tracking tasks through a sprint burndown, you can provide relevant feedback on a daily basis.

                                                    This is probably nothing new to you. Hence my question about how what management want, and why do they feel the additional overhead they are asking for will give a better insight into what's going on. Why doesn't a daily update on tasks, and weekly update on points and stories not provide what they want?

                                                    One thing I've found is that providing management with a picture can short cut a lot of discussion. Even if the picture is based on the information they've already rejected! They don't need to take the time to understand your argument about why what you're suggesting will work - they can just look at the picture and see it tells them what they want to know.

                                                    I'm a fan of this approach - http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown.

                                                    In reality requirements will evolve and the scope will change - more so as it's a POC / R&D project. This style of burndown clarifies the difference between scope changing and the external perception that a team is not delivering. Which not only sounds like it would be useful in your situation, but puts you, the team and the PO in a better position to make decisions that are likely to lead to success.

                                                    Hope this helps.

                                                    Gareth

                                                    --- In scrumdevelopment@yahoogroups.com, "tony_t_tubbs" <tony_t_tubbs@...> wrote:
                                                    >
                                                    > Management's desire has been and is to use ScrumWorks so they can run reports so they can see progress. The team often feels like this is forcing a tool that doesn't always fit. Our current situation is a POC sprint that has a lot of R&D to do. We do not know hours like we might otherwise. We have estimated story points relative to each other. We know when we start, and we know when and what MUST be done - a functioning POC of specific key concepts and business functions by June 1 as proof we can do a full implementation.
                                                    >
                                                    > Really, the POC containing the stories we've identified MUST be done. Whatever that takes. Longer hours or what not. The management wants hours in scrumworks so they can see if we are on track or not. I've suggested burndown only stores, or perhaps story points. (Which doesn't fit into ScrumWorks reporting I guess) They claim this is too high level to make adjustments, that being off track will not show in the chart until it's too late. By then longer hours or adding people or whatever will just be too late.
                                                    >
                                                    > Note that I personally, and expect many of you, would put this scenario into ScrumButt category. Assuming there's nothing I can do about that for the moment, please advise what I can actually do to best meet the needs/desires. If it can be done in a way that could convince management there's a better way, then all the better for me and my fellow developers.
                                                    >
                                                    > Thanks,
                                                    > TT
                                                    >
                                                  • Michael James
                                                    As one of the ScrumWorks developers years ago, I want to chime in here. We never ever ever intended the metrics to be abused in the manner Tony s management
                                                    Message 25 of 25 , Apr 17, 2012
                                                    • 0 Attachment
                                                      As one of the ScrumWorks developers years ago, I want to chime in here.

                                                      We never ever ever intended the metrics to be abused in the manner Tony's management seems to insist on.  The Sprint Burndown Chart, if used at all, is to help the team's self organization, not give management reasons to intervene.  People outside the team should visit the team's Sprint Review Meeting to see the actual product!  Why would you prefer a bunch of derived numbers over an actual tested product demo you can touch and feel for yourself?  That's like prefering pornography over actual sex!

                                                      The tool does generate the Mike Cohn style converging/diverging release burndown (or up) charts Gareth refers to below.  I've found them useful when definition of *done* is sufficiently rigorous.  But they're never the main thing.  Scrum is about unleashing team self organization; perhaps we were naive in hoping organizations would use our tool this way.

                                                      --mj
                                                      (Michael)


                                                      On Apr 17, 2012, at 10:56 PM, "merceroz" <gareth.mercer@...> wrote:

                                                       

                                                      TT

                                                      I wanted to focus in on the reporting progress part of your question.

                                                      From the sounds of it you have a PBL which outlines the stories to be delivered. You mention points, so presumably you have or could work out, a rough sizing for each story. So as you say you could track the story and / or point burndown to track progress.

                                                      However you say that management "claim this is too high level to make adjustments, that being off track will not show in the chart until it's too late." I would focus in on what this means. If you work with short 1 week sprints, you've got six sprints to go, and can provide relevant feedback to management on a weekly basis. In addition, assuming you're tracking tasks through a sprint burndown, you can provide relevant feedback on a daily basis.

                                                      This is probably nothing new to you. Hence my question about how what management want, and why do they feel the additional overhead they are asking for will give a better insight into what's going on. Why doesn't a daily update on tasks, and weekly update on points and stories not provide what they want?

                                                      One thing I've found is that providing management with a picture can short cut a lot of discussion. Even if the picture is based on the information they've already rejected! They don't need to take the time to understand your argument about why what you're suggesting will work - they can just look at the picture and see it tells them what they want to know.

                                                      I'm a fan of this approach - http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown.

                                                      In reality requirements will evolve and the scope will change - more so as it's a POC / R&D project. This style of burndown clarifies the difference between scope changing and the external perception that a team is not delivering. Which not only sounds like it would be useful in your situation, but puts you, the team and the PO in a better position to make decisions that are likely to lead to success.

                                                      Hope this helps.

                                                      Gareth

                                                      --- In scrumdevelopment@yahoogroups.com, "tony_t_tubbs" <tony_t_tubbs@...> wrote:
                                                      >
                                                      > Management's desire has been and is to use ScrumWorks so they can run reports so they can see progress. The team often feels like this is forcing a tool that doesn't always fit. Our current situation is a POC sprint that has a lot of R&D to do. We do not know hours like we might otherwise. We have estimated story points relative to each other. We know when we start, and we know when and what MUST be done - a functioning POC of specific key concepts and business functions by June 1 as proof we can do a full implementation.
                                                      >
                                                      > Really, the POC containing the stories we've identified MUST be done. Whatever that takes. Longer hours or what not. The management wants hours in scrumworks so they can see if we are on track or not. I've suggested burndown only stores, or perhaps story points. (Which doesn't fit into ScrumWorks reporting I guess) They claim this is too high level to make adjustments, that being off track will not show in the chart until it's too late. By then longer hours or adding people or whatever will just be too late.
                                                      >
                                                      > Note that I personally, and expect many of you, would put this scenario into ScrumButt category. Assuming there's nothing I can do about that for the moment, please advise what I can actually do to best meet the needs/desires. If it can be done in a way that could convince management there's a better way, then all the better for me and my fellow developers.
                                                      >
                                                      > Thanks,
                                                      > TT
                                                      >

                                                    Your message has been successfully submitted and would be delivered to recipients shortly.