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

How do I help my team be more agile?

Expand Messages
  • Griner, Jennie
    Some quick background, my group decided to implement an agile approach on our last release. Ignoring any work that was done before this decision was made, we
    Message 1 of 14 , Feb 25 12:45 PM
    • 0 Attachment

      Some quick background, my group decided to implement an agile approach on our last release.  Ignoring any work that was done before this decision was made, we had 13 month long sprints, followed by four additional months of panic mode testing and bug fixing.  I had done my research on what I thought agile meant for us, and would try to bring up things that weren’t really agile, and was ignored.  Needless to say, we basically did a waterfall with some mini waterfalls in the middle (if you can even consider it that because we hadn’t even fixed bugs as we came across them, they were all saved for those last four months).

       

      So, the powers that be have gotten together after a retrospective of that release and decided that things weren’t agile, and we’re going to actually be agile this time.  However, it appears to me that they still can’t get some of the older ways of doing things out of their systems.  We still have to have the requirements for a story fully documented (though they did change the DoD to say “agreed on” rather than “signed off” and they did change the item regarding Use Case and User Interface to include the words “if needed.”

       

      Management still insists on fully detailed test cases that can then be passed on to a tester on the regression team in later iterations, but we can’t leave the job of writing it to the regression tester, so the test member of the team must complete this prior to the end of the sprint, even though we know that things could continue to change up until the end.  This is after a test strategy must be completed along with test scenarios (high level test cases) for that sprint.

       

      As for bug fixes, it’s hard to tell as we’re halfway into our first sprint, and I don’t think we’ve received a single build with the new code in it.  The DoD does say that the bug fixes will be made, but it did for our last release as well.  The team as a whole does seem to have made a commitment to follow the DoD much better this time, so that is a plus.

       

      But how do I approach some of these issues?  I’ve asked for formal Scrum training (which no one in our group has received yet, which I think it part of the issue), and some training has been set up, but as far as I know, I am not going to receive it.  I feel like I need to be heard, but at the same time I need to make sure that my duty to my Scrum team (as is currently defined) isn’t skipped out on either.  Am I just stuck with how someone else has decided things are?

       

      Jennifer L. Griner, MCP, MCDBA

      Quality Control Specialist, ProSystem fx Engagement

      CCH, a WoltersKluwer business

    • Steve Ropa
      HI Jennie, There are a few things that come to my mind here. One is that you very well might want to bring in some outside help in the way of a consultant,
      Message 2 of 14 , Feb 25 2:37 PM
      • 0 Attachment
        HI Jennie,
         
        There are a few things that come to my mind here.  One is that you very well might want to bring in some outside help in the way of a consultant, but I won't go down that path.
         
        This feels like a classic case of "we want to be agile but not change how we do things".  That is very hard to overcome, but here are a few thoughts.  These thoughts are based only on what you have stated here, so I reserve the right to be totally wrong!
         
        1.  I get the feeling that your stories are very large.  The fact that the stories have requirements enough to need to be fully documents, or to be able to compare them to Use Cases, makes me think the stories are large.  See if you can't go through an exercise in slicing them into much smaller segments.
        2.  On the subject of size, I would also suggest decreasing the length of your iterations dramatically.  Many of us have found 1-2 weeks to be the best sizes of iterations.  In the case of teams that are struggling, the amount of thought that goes into fitting these smaller iterations is extraordinarily valuable.  A case like what you describe leads me to suggest one week iterations.
        3.  Lastly, I would like to hear more about the regression team and the test cases that are passed on to them.  Is there a way we can automate the acceptance and unit tests, thus removing most of the need for a "regression phase"?
         
        Regards,
        Steve

        Sent: Thursday, February 25, 2010 1:45 PM
        Subject: [scrumdevelopment] How do I help my team be more agile?

         

        Some quick background, my group decided to implement an agile approach on our last release.  Ignoring any work that was done before this decision was made, we had 13 month long sprints, followed by four additional months of panic mode testing and bug fixing.  I had done my research on what I thought agile meant for us, and would try to bring up things that weren’t really agile, and was ignored.  Needless to say, we basically did a waterfall with some mini waterfalls in the middle (if you can even consider it that because we hadn’t even fixed bugs as we came across them, they were all saved for those last four months).

        So, the powers that be have gotten together after a retrospective of that release and decided that things weren’t agile, and we’re going to actually be agile this time.  However, it appears to me that they still can’t get some of the older ways of doing things out of their systems.  We still have to have the requirements for a story fully documented (though they did change the DoD to say “agreed on” rather than “signed off” and they did change the item regarding Use Case and User Interface to include the words “if needed.”

        Management still insists on fully detailed test cases that can then be passed on to a tester on the regression team in later iterations, but we can’t leave the job of writing it to the regression tester, so the test member of the team must complete this prior to the end of the sprint, even though we know that things could continue to change up until the end.  This is after a test strategy must be completed along with test scenarios (high level test cases) for that sprint.

        As for bug fixes, it’s hard to tell as we’re halfway into our first sprint, and I don’t think we’ve received a single build with the new code in it.  The DoD does say that the bug fixes will be made, but it did for our last release as well.  The team as a whole does seem to have made a commitment to follow the DoD much better this time, so that is a plus.

        But how do I approach some of these issues?  I’ve asked for formal Scrum training (which no one in our group has received yet, which I think it part of the issue), and some training has been set up, but as far as I know, I am not going to receive it.  I feel like I need to be heard, but at the same time I need to make sure that my duty to my Scrum team (as is currently defined) isn’t skipped out on either.  Am I just stuck with how someone else has decided things are?

        Jennifer L. Griner, MCP, MCDBA

        Quality Control Specialist, ProSystem fx Engagement

        CCH, a WoltersKluwer business

      • PeteCRuth@aol.com
        Your powers that be may be employing the age-old management strategy of appearing to be supportive by offering concessions instead of commitment.
        Message 3 of 14 , Feb 25 2:54 PM
        • 0 Attachment
           
           
          Your "powers that be" may be employing the age-old management strategy of appearing to be supportive by offering concessions instead of commitment. Transitioning to agile methods is tough enough for many organizations without having to retain unnecessary practices that end up costing far more time and effort than they are possible worth. Unless they understand how and why agile methods improve the development process, it's unlikely they'll commit fully to them. Commitment without understanding is often a prelude to potentially terminal misunderstandings, and if this is the case, finding ways to avoid getting blowback on their clothes will be high on their list of priorities if things begin to fall apart.
           
          Regards,
           
          Pete
           
          In a message dated 2/25/2010 12:47:01 P.M. Pacific Standard Time, jennifer.griner@... writes:
           

          Some quick background, my group decided to implement an agile approach on our last release.  Ignoring any work that was done before this decision was made, we had 13 month long sprints, followed by four additional months of panic mode testing and bug fixing.  I had done my research on what I thought agile meant for us, and would try to bring up things that weren’t really agile, and was ignored.  Needless to say, we basically did a waterfall with some mini waterfalls in the middle (if you can even consider it that because we hadn’t even fixed bugs as we came across them, they were all saved for those last four months).

          So, the powers that be have gotten together after a retrospective of that release and decided that things weren’t agile, and we’re going to actually be agile this time.  However, it appears to me that they still can’t get some of the older ways of doing things out of their systems.  We still have to have the requirements for a story fully documented (though they did change the DoD to say “agreed on” rather than “signed off” and they did change the item regarding Use Case and User Interface to include the words “if needed.”

          Management still insists on fully detailed test cases that can then be passed on to a tester on the regression team in later iterations, but we can’t leave the job of writing it to the regression tester, so the test member of the team must complete this prior to the end of the sprint, even though we know that things could continue to change up until the end.  This is after a test strategy must be completed along with test scenarios (high level test cases) for that sprint.

          As for bug fixes, it’s hard to tell as we’re halfway into our first sprint, and I don’t think we’ve received a single build with the new code in it.  The DoD does say that the bug fixes will be made, but it did for our last release as well.  The team as a whole does seem to have made a commitment to follow the DoD much better this time, so that is a plus.

          But how do I approach some of these issues?  I’ve asked for formal Scrum training (which no one in our group has received yet, which I think it part of the issue), and some training has been set up, but as far as I know, I am not going to receive it.  I feel like I need to be heard, but at the same time I need to make sure that my duty to my Scrum team (as is currently defined) isn’t skipped out on either.  Am I just stuck with how someone else has decided things are?

          Jennifer L. Griner, MCP, MCDBA

          Quality Control Specialist, ProSystem fx Engagement

          CCH, a WoltersKluwer business

        • Archer, Jonathan
          Something I have seen be quite valuable in my own organization is the lunch and learn - we find a good video about a pertinent topic (release planning,
          Message 4 of 14 , Feb 25 3:17 PM
          • 0 Attachment

            Something I have seen be quite valuable in my own organization is the “lunch and learn” – we find a good video about a pertinent topic (release planning, sprint planning, testing, estimating) and watch it together, over lunch and then discuss.

             

            What I read below sounds like an “understanding” / “education” problem and the watch & discuss approach is a nice subtle way to get people thinking about new ideas. You can go from those conversations to “shall we give that a try in the next sprint?” quite easily…

             

            Jon

             


            From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Griner, Jennie
            Sent: Thursday, February 25, 2010 1:45 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] How do I help my team be more agile?

             

             

            Some quick background, my group decided to implement an agile approach on our last release.  Ignoring any work that was done before this decision was made, we had 13 month long sprints, followed by four additional months of panic mode testing and bug fixing.  I had done my research on what I thought agile meant for us, and would try to bring up things that weren’t really agile, and was ignored.  Needless to say, we basically did a waterfall with some mini waterfalls in the middle (if you can even consider it that because we hadn’t even fixed bugs as we came across them, they were all saved for those last four months).

             

            So, the powers that be have gotten together after a retrospective of that release and decided that things weren’t agile, and we’re going to actually be agile this time.  However, it appears to me that they still can’t get some of the older ways of doing things out of their systems.  We still have to have the requirements for a story fully documented (though they did change the DoD to say “agreed on” rather than “signed off” and they did change the item regarding Use Case and User Interface to include the words “if needed.”

             

            Management still insists on fully detailed test cases that can then be passed on to a tester on the regression team in later iterations, but we can’t leave the job of writing it to the regression tester, so the test member of the team must complete this prior to the end of the sprint, even though we know that things could continue to change up until the end.  This is after a test strategy must be completed along with test scenarios (high level test cases) for that sprint.

             

            As for bug fixes, it’s hard to tell as we’re halfway into our first sprint, and I don’t think we’ve received a single build with the new code in it.  The DoD does say that the bug fixes will be made, but it did for our last release as well.  The team as a whole does seem to have made a commitment to follow the DoD much better this time, so that is a plus.

             

            But how do I approach some of these issues?  I’ve asked for formal Scrum training (which no one in our group has received yet, which I think it part of the issue), and some training has been set up, but as far as I know, I am not going to receive it.  I feel like I need to be heard, but at the same time I need to make sure that my duty to my Scrum team (as is currently defined) isn’t skipped out on either.  Am I just stuck with how someone else has decided things are?

             

            Jennifer L. Griner, MCP, MCDBA

            Quality Control Specialist, ProSystem fx Engagement

            CCH, a WoltersKluwer business

          • Hillel Glazer
            Hi Jennifer, Why did anyone in your organization want to implement an agile approach in the first place? Normally, organizations that perceive the need to
            Message 5 of 14 , Feb 25 3:33 PM
            • 0 Attachment
              Hi Jennifer,

              Why did anyone in your organization want to "implement an agile approach" in the first place?  Normally, organizations that perceive the "need" to pursue agile approaches are doing so to not repeat past failures (project, product, morale, etc.) and to pursue specific, tangible, qualitative or quantitative benefits they're not getting/seeing with how they're doing things now (or in the past).  So... what was/is your organization's reason?

              With these reasons articulated, you can look for "things you don't like" or "things you don't want to do again", understand what causes them, then find the lean/agile alternatives (if there are any).  This is where Pete points out that change might need to happen.  To avoid the things you don't want to show up in the future, you'll be changing that which causes those things going forward.  Such changes will frequently involve breaking some paradigms and resetting some expectations.  If you get push-back, you know it's a Quixotic effort and your call whether to keep pursuit or not.

              And it's also another potentially telling use of words... "implement an agile approach".  I may be reading too much into it, but I've seen this phrase used when organizations were looking for some silver bullet to solve various, sundry and weakly-understood but deep seated issues.  To your organization, how is the phrase "do things in a more lean and agile way" different from "implement an agile approach"?  If it's not different, then ignore this paragraph.  On the other hand, if you immediately sense dread and resistance, then you're back out there with Don Quixote.  "Do things in a more lean and agile way" is a much more robust pursuit and takes a lot of commitment, self-awareness and honest introspection.  "Implement and agile approach" sounds more like Dilbert's Pointy-Haired boss telling Dilbert to "do more with agile" believing it's an automatic and magic pill to skimp on resources and time and still product a quality product. 

              The most effective way towards "implement[ing] an agile approach" is to adopt lean and agile principles, then get to work "leaning-out" the waste in your organization and development practices.  Whether you implement Scrum or not is not the issue.  Fully embracing Scrum is more than daily stand-ups, time-boxed iterations, and having a backlog.  Though, once fully embraced, Scrum is a lot like the "gateway drug" to agile.  If your system is immune to the benefits of all-out Scrum, it's likely immune to anything agile or lean.

              OK... so...having said all this... your team may be hampered by the nature of the agreements you have with your customers.  It's not that you can't be lean, agile, or using Scrum with government contracts, it's just that you will have to re-frame some of the typical agile/Scrum practices to compensate for the likely lack of a present customer, the likely a-priori agreement on scope, the likely pre-determination of project "phases".  Please understand, you don't have to abandon agile/Scrum practices, you just need to re-orient your work so that you can still deliver expected deliverables but that you produce them following the beat of your own drummer, not the government's.

              Good luck!

              Cheers!
              -->>  Hillel
              --
              Hillel Glazer, Principal & CEO
              Entinex, Inc.
              Process can't fix stupid.(TM)

              www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
              O-


              On Thu, Feb 25, 2010 at 5:54 PM, <PeteCRuth@...> wrote:


               
               
              Your "powers that be" may be employing the age-old management strategy of appearing to be supportive by offering concessions instead of commitment. Transitioning to agile methods is tough enough for many organizations without having to retain unnecessary practices that end up costing far more time and effort than they are possible worth. Unless they understand how and why agile methods improve the development process, it's unlikely they'll commit fully to them. Commitment without understanding is often a prelude to potentially terminal misunderstandings, and if this is the case, finding ways to avoid getting blowback on their clothes will be high on their list of priorities if things begin to fall apart.
               
              Regards,
               
              Pete
               
              In a message dated 2/25/2010 12:47:01 P.M. Pacific Standard Time, jennifer.griner@... writes:
               

              Some quick background, my group decided to implement an agile approach on our last release.  Ignoring any work that was done before this decision was made, we had 13 month long sprints, followed by four additional months of panic mode testing and bug fixing.  I had done my research on what I thought agile meant for us, and would try to bring up things that weren’t really agile, and was ignored.  Needless to say, we basically did a waterfall with some mini waterfalls in the middle (if you can even consider it that because we hadn’t even fixed bugs as we came across them, they were all saved for those last four months).

              So, the powers that be have gotten together after a retrospective of that release and decided that things weren’t agile, and we’re going to actually be agile this time.  However, it appears to me that they still can’t get some of the older ways of doing things out of their systems.  We still have to have the requirements for a story fully documented (though they did change the DoD to say “agreed on” rather than “signed off” and they did change the item regarding Use Case and User Interface to include the words “if needed.”

              Management still insists on fully detailed test cases that can then be passed on to a tester on the regression team in later iterations, but we can’t leave the job of writing it to the regression tester, so the test member of the team must complete this prior to the end of the sprint, even though we know that things could continue to change up until the end.  This is after a test strategy must be completed along with test scenarios (high level test cases) for that sprint.

              As for bug fixes, it’s hard to tell as we’re halfway into our first sprint, and I don’t think we’ve received a single build with the new code in it.  The DoD does say that the bug fixes will be made, but it did for our last release as well.  The team as a whole does seem to have made a commitment to follow the DoD much better this time, so that is a plus.

              But how do I approach some of these issues?  I’ve asked for formal Scrum training (which no one in our group has received yet, which I think it part of the issue), and some training has been set up, but as far as I know, I am not going to receive it.  I feel like I need to be heard, but at the same time I need to make sure that my duty to my Scrum team (as is currently defined) isn’t skipped out on either.  Am I just stuck with how someone else has decided things are?

              Jennifer L. Griner, MCP, MCDBA

              Quality Control Specialist, ProSystem fx Engagement

              CCH, a WoltersKluwer business




            • Griner, Jennie
              ... well might want to bring in some outside help in the way of a consultant, but I won t go down that path. I believe that this is actually the plan, so
              Message 6 of 14 , Feb 26 7:58 AM
              • 0 Attachment

                >

                style='font-family:"Calibri","sans-serif"'>HI Jennie,

                 

                >

                style='font-family:"Calibri","sans-serif"'>There are a few things that come to my mind here.  One is that you very well might want to bring in some outside help in the way of a consultant, but I won't go down that path.

                 

                I believe that this is actually the plan, so hopefully this will help.  Maybe if someone else that they’re paying a ton of money says these things, then they’ll believe them and maybe try to implement it.  We’re shooting to have them come in and help us through our second sprint.  They’ll be working with two of our sprint teams and then those teams will help pass on the new insights to the rest of the team.  I believe we’re getting someone from Rally to come in.  Does anyone have any experience with their consulting work?

                 

                >

                style='font-family:"Calibri","sans-serif"'>This feels like a classic case of "we want to be agile but not change how we do things".  That is very hard to overcome, but here are a few thoughts.  These thoughts are based only on what you have stated here, so I reserve the right to be totally wrong!

                 

                >

                style='font-family:"Calibri","sans-serif"'>1.  I get the feeling that your stories are very large.  The fact that the stories have requirements enough to need to be fully documents, or to be able to compare them to Use Cases, makes me think the stories are large.  See if you can't go through an exercise in slicing them into much smaller segments.

                 

                During the pre planning (at least for the team that I’m on), the designer took some time to come up with a draft of the requirements.  Each detailed requirement became a story.  For example, “I want to access a pane” is one of our stories.  To me that seems small enough, but what’s happening is that that team is taking on four stories this sprint, and then really kind of working on them in as one entity (or two, since there are really two pairs of stories that go together).  So then the requirements document is fleshed out further with the work that we’re doing within the sprint.

                 

                >

                style='font-family:"Calibri","sans-serif"'>2.  On the subject of size, I would also suggest decreasing the length of your iterations dramatically.  Many of us have found 1-2 weeks to be the best sizes of iterations.  In the case of teams that are struggling, the amount of thought that goes into fitting these smaller iterations is extraordinarily valuable.  A case like what you describe leads me to suggest one week iterations.

                 

                Looking back at the project plan, our sprint is supposed to only be 13 days long, and ending today, which is definitely not going to happen.  Maybe they combined sprint 1 and 2, which would make it 27 days long rather than the 13 and 14 originally planned, which may have worked better.  I think I read in an email yesterday about the critical thinking working much better in shorter sprints, since you don’t have time to waste, you make the most of your time.  I think that this is a great idea, and I’ll see if I can pass any of that information on.  Of course, now I have to dig into the whole sprint was supposed to end today, but there’s been no communication regarding changes to that.  Hrm…

                 

                >

                style='font-family:"Calibri","sans-serif"'>3.  Lastly, I would like to hear more about the regression team and the test cases that are passed on to them.  Is there a way we can automate the acceptance and unit tests, thus removing most of the need for a "regression phase"?

                 

                Our testing team has been split into two mini-teams: Enhancement Testers and Regression Testers.  The enhancement testers will be members of the scrum team and responsible for testing the enhancements.  The regression testers will “sprint” alongside the enhancement testers, but they’ll test the areas of the product not undergoing any changes.

                 

                We continually try automation, but we seem to have troubles actually getting it to really work for us.  We’ve been able to automate the testing of the portions of our product that don’t change much, so that the regression testing can be performed much quicker than by a manual tester, but those tests still come after the fact.  We had white-box testers with our last release, and I thought we were supposed to have them with this release, but I haven’t heard anything about that team.  Also, going along with my original comments, of bugs not being fixed, the bugs that the white-box testers wrote up weren’t being fixed any sooner than the bugs found by the manual testers, which most likely ended up with a duplication of bugs.  One bug would be written up twice, once from the code side, and once from the UI side.  I’m not sure what the developer does as far as unit testing, so I don’t know how much may be automated.  Are there any good resources for automating the acceptance testing?  I think part of the issue is that we’re having a hard time seeing how to automate something that isn’t stable.  Most likely it’s a case of the tools that we’re using.  They take so much work to code the tests, that we can’t waste time when things are changing.

                 

                >

                style='font-family:"Calibri","sans-serif"'>Regards,

                >

                style='font-family:"Calibri","sans-serif"'>Steve

                 

                Thanks for your feedback Steve.  I’m really excited about how I see agile working, and would love to really feel like we were actually moving towards it.  My fear is that we’re going to continue to have waterfalls in each sprint, but I’m trying to be hopeful.

                 

                At one point in our last release, I actually got called into a conference room and told that I needed to quit asking to be invited to meeting that I wasn’t supposed to be in.  The meeting in particular was a meeting where the development team was discussing how they were going to implement the infrastructure of our new product.  In the end, the infrastructure wasn’t implemented the way we were told it would be, so we found a lot of issues late in the game.  We thought it was going to work one way, as that’s how it was supposed to work on paper, but when they discussed it, they ended up choosing a different way.  The original way didn’t leave a huge risk in a certain area, but the actual implementation did.  We didn’t know, so we hadn’t tested it as in depth as we would have, had we known how they had done it.  But I was in trouble for wanting to be in the meetings where they were discussing it.

                 

                 

                Sent: Thursday, February 25, 2010 1:45 PM

                Subject: [scrumdevelopment] How do I help my team be more agile?

                 

                 

                Some quick background, my group decided to implement an agile approach on our last release.  Ignoring any work that was done before this decision was made, we had 13 month long sprints, followed by four additional months of panic mode testing and bug fixing.  I had done my research on what I thought agile meant for us, and would try to bring up things that weren’t really agile, and was ignored.  Needless to say, we basically did a waterfall with some mini waterfalls in the middle (if you can even consider it that because we hadn’t even fixed bugs as we came across them, they were all saved for those last four months).

                So, the powers that be have gotten together after a retrospective of that release and decided that things weren’t agile, and we’re going to actually be agile this time.  However, it appears to me that they still can’t get some of the older ways of doing things out of their systems.  We still have to have the requirements for a story fully documented (though they did change the DoD to say “agreed on” rather than “signed off” and they did change the item regarding Use Case and User Interface to include the words “if needed.”

                Management still insists on fully detailed test cases that can then be passed on to a tester on the regression team in later iterations, but we can’t leave the job of writing it to the regression tester, so the test member of the team must complete this prior to the end of the sprint, even though we know that things could continue to change up until the end.  This is after a test strategy must be completed along with test scenarios (high level test cases) for that sprint.

                As for bug fixes, it’s hard to tell as we’re halfway into our first sprint, and I don’t think we’ve received a single build with the new code in it.  The DoD does say that the bug fixes will be made, but it did for our last release as well.  The team as a whole does seem to have made a commitment to follow the DoD much better this time, so that is a plus.

                But how do I approach some of these issues?  I’ve asked for formal Scrum training (which no one in our group has received yet, which I think it part of the issue), and some training has been set up, but as far as I know, I am not going to receive it.  I feel like I need to be heard, but at the same time I need to make sure that my duty to my Scrum team (as is currently defined) isn’t skipped out on either.  Am I just stuck with how someone else has decided things are?

                Jennifer L. Griner, MCP, MCDBA

                Quality Control Specialist, ProSystem fx Engagement

                CCH, a WoltersKluwer business

              • Griner, Jennie
                ... approach in the first place? Normally, organizations that perceive the need to pursue agile approaches are doing so to not repeat past failures
                Message 7 of 14 , Feb 26 8:51 AM
                • 0 Attachment

                  >Hi Jennifer,

                  >Why did anyone in

                  your organization want to "implement an agile approach" in the first place?  Normally, organizations that perceive the "need" to pursue agile approaches are doing so to not repeat past failures (project, product, morale, etc.) and to pursue specific, tangible, qualitative or quantitative benefits they're not getting/seeing with how they're doing things now (or in the past).  So... what was/is your organization's reason?

                   

                  That’s a really good question, and it’s going to take some digging for me to find the actual answer to it.  Here’s the trouble, my understand is that our organization as a whole is looking to adopt agile, and our group is not the first to try these methods.  I’m not sure how to figure out who the person is that decided that this was the way to go.  I have a feeling, though, that they’ve decided to “go agile” because it’s the thing to do.

                   

                  >With these reasons articulated, you can look for "things you don't like" or "things you don't want to do again", understand what causes them, then find the lean/agile alternatives (if there are any).  This is where Pete points out that change might need to happen.  To avoid the things you don't want to show up in the future, you'll be changing that which causes those things going forward.  Such changes will frequently involve breaking some paradigms and resetting some expectations.  If you get push-back, you know it's a Quixotic effort and your call whether to keep pursuit or not.

                   

                  To respond to Pete, I think part of the problem is that the agile adoption is coming from the top down, rather than from the bottom up.  I have a feeling that things would be working better if we, as the development team, said we want to do things more agile.  Though then we may have the push back that you mention below, where the powers that be don’t understand it and don’t see the benefit to it.  In our case, the powers that be have said that we’re doing this.  However, I think that they still don’t understand it, so they’ve told us that we have to do it, and we’re kind of drowning since no one really had a good grasp of what we wanted to do when we started.

                   

                  >And it's also another potentially telling use of words... "implement an agile approach".  I may be reading too much into it, but I've seen this phrase used when organizations were looking for some silver bullet to solve various, sundry and weakly-understood but deep seated issues.  To your organization, how is the phrase "do things in a more lean and agile way" different from "implement an agile approach"?  If it's not different, then ignore this paragraph.  On the other hand, if you immediately sense dread and resistance, then you're back out there with Don Quixote.  "Do things in a more lean and agile way" is a much more robust pursuit and takes a lot of commitment, self-awareness and honest introspection.  "Implement and agile approach" sounds more like Dilbert's Pointy-Haired boss telling Dilbert to "do more with agile" believing it's an automatic and magic pill to skimp on resources and time and still product a quality product. 

                   

                  I think that this paragraph is 100% accurate.

                   

                  >The most effective way towards "implement[ing] an agile approach" is to adopt lean and agile principles, then get to work "leaning-out" the waste in your organization and development practices.  Whether you implement Scrum or not is not the issue.  Fully embracing Scrum is more than daily stand-ups, time-boxed iterations, and having a backlog.  Though, once fully embraced, Scrum is a lot like the "gateway drug" to agile.  If your system is immune to the benefits of all-out Scrum, it's likely immune to anything agile or lean.

                   

                  It feels like our team is going through the motions.  As you say, just doing daily meetings, sprints, and keeping a backlog.  I don’t think most people have the actual mindset required to be open to change.

                   

                  >OK... so...having said all this... your team may be hampered by the nature of the agreements you have with your customers.  It's not that you can't be lean, agile, or using Scrum with government contracts, it's just that you will have to re-frame some of the typical agile/Scrum practices to compensate for the likely lack of a present customer, the likely a-priori agreement on scope, the likely pre-determination of project "phases".  Please understand, you don't have to abandon agile/Scrum practices, you just need to re-orient your work so that you can still deliver expected deliverables but that you produce them following the beat of your own drummer, not the government's.

                   

                  This makes total sense.  We’re dealing with product managers that have made promises to our corporate clients, but I think it has the same effect as if it were a government (or any other) contract.

                   

                  >Good luck!


                  Cheers!
                  -->>  Hillel
                  --
                  Hillel Glazer, Principal & CEO
                  Entinex, Inc.
                  Process can't fix stupid.(TM)

                  www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
                  O-

                  On Thu, Feb 25, 2010 at 5:54 PM, <PeteCRuth@...> wrote:

                   

                   

                   

                  Your "powers that be" may be employing the age-old management strategy of appearing to be supportive by offering concessions instead of commitment. Transitioning to agile methods is tough enough for many organizations without having to retain unnecessary practices that end up costing far more time and effort than they are possible worth. Unless they understand how and why agile methods improve the development process, it's unlikely they'll commit fully to them. Commitment without understanding is often a prelude to potentially terminal misunderstandings, and if this is the case, finding ways to avoid getting blowback on their clothes will be high on their list of priorities if things begin to fall apart.

                   

                  Regards,

                   

                  Pete

                   

                  In a message dated 2/25/2010 12:47:01 P.M. Pacific Standard Time, jennifer.griner@... writes:

                   

                  Some quick background, my group decided to implement an agile approach on our last release.  Ignoring any work that was done before this decision was made, we had 13 month long sprints, followed by four additional months of panic mode testing and bug fixing.  I had done my research on what I thought agile meant for us, and would try to bring up things that weren’t really agile, and was ignored.  Needless to say, we basically did a waterfall with some mini waterfalls in the middle (if you can even consider it that because we hadn’t even fixed bugs as we came across them, they were all saved for those last four months).

                  So, the powers that be have gotten together after a retrospective of that release and decided that things weren’t agile, and we’re going to actually be agile this time.  However, it appears to me that they still can’t get some of the older ways of doing things out of their systems.  We still have to have the requirements for a story fully documented (though they did change the DoD to say “agreed on” rather than “signed off” and they did change the item regarding Use Case and User Interface to include the words “if needed.”

                  Management still insists on fully detailed test cases that can then be passed on to a tester on the regression team in later iterations, but we can’t leave the job of writing it to the regression tester, so the test member of the team must complete this prior to the end of the sprint, even though we know that things could continue to change up until the end.  This is after a test strategy must be completed along with test scenarios (high level test cases) for that sprint.

                  As for bug fixes, it’s hard to tell as we’re halfway into our first sprint, and I don’t think we’ve received a single build with the new code in it.  The DoD does say that the bug fixes will be made, but it did for our last release as well.  The team as a whole does seem to have made a commitment to follow the DoD much better this time, so that is a plus.

                  But how do I approach some of these issues?  I’ve asked for formal Scrum training (which no one in our group has received yet, which I think it part of the issue), and some training has been set up, but as far as I know, I am not going to receive it.  I feel like I need to be heard, but at the same time I need to make sure that my duty to my Scrum team (as is currently defined) isn’t skipped out on either.  Am I just stuck with how someone else has decided things are?

                  Jennifer L. Griner, MCP, MCDBA

                  Quality Control Specialist, ProSystem fx Engagement

                  CCH, a WoltersKluwer business

                   

                   

                • Griner, Jennie
                  This sounds like a FANTASTIC idea. I ll see what I can do. Jennifer L. Griner, MCP, MCDBA Quality Control Specialist, ProSystem fx Engagement CCH, a
                  Message 8 of 14 , Feb 26 8:57 AM
                  • 0 Attachment

                    This sounds like a FANTASTIC idea.  I’ll see what I can do.

                     

                    Jennifer L. Griner, MCP, MCDBA

                    Quality Control Specialist, ProSystem fx Engagement

                    CCH, a WoltersKluwer business

                     

                    From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Archer, Jonathan
                    Sent: Thursday, February 25, 2010 5:17 PM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: RE: [scrumdevelopment] How do I help my team be more agile?

                     

                     

                    Something I have seen be quite valuable in my own organization is the “lunch and learn” – we find a good video about a pertinent topic (release planning, sprint planning, testing, estimating) and watch it together, over lunch and then discuss 

                    What I read below sounds like an “understanding” / “education” problem and the watch & discuss approach is a nice subtle way to get people thinking about new ideas. You can go from those conversations to “shall we give that a try in the next sprint?” quite easily…

                     Jon


                    From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Griner, Jennie
                    Sent: Thursday, February 25, 2010 1:45 PM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: [scrumdevelopment] How do I help my team be more agile?

                     

                     

                    Some quick background, my group decided to implement an agile approach on our last release.  Ignoring any work that was done before this decision was made, we had 13 month long sprints, followed by four additional months of panic mode testing and bug fixing.  I had done my research on what I thought agile meant for us, and would try to bring up things that weren’t really agile, and was ignored.  Needless to say, we basically did a waterfall with some mini waterfalls in the middle (if you can even consider it that because we hadn’t even fixed bugs as we came across them, they were all saved for those last four months).

                     

                    So, the powers that be have gotten together after a retrospective of that release and decided that things weren’t agile, and we’re going to actually be agile this time.  However, it appears to me that they still can’t get some of the older ways of doing things out of their systems.  We still have to have the requirements for a story fully documented (though they did change the DoD to say “agreed on” rather than “signed off” and they did change the item regarding Use Case and User Interface to include the words “if needed.”

                     

                    Management still insists on fully detailed test cases that can then be passed on to a tester on the regression team in later iterations, but we can’t leave the job of writing it to the regression tester, so the test member of the team must complete this prior to the end of the sprint, even though we know that things could continue to change up until the end.  This is after a test strategy must be completed along with test scenarios (high level test cases) for that sprint.

                     

                    As for bug fixes, it’s hard to tell as we’re halfway into our first sprint, and I don’t think we’ve received a single build with the new code in it.  The DoD does say that the bug fixes will be made, but it did for our last release as well.  The team as a whole does seem to have made a commitment to follow the DoD much better this time, so that is a plus.

                     

                    But how do I approach some of these issues?  I’ve asked for formal Scrum training (which no one in our group has received yet, which I think it part of the issue), and some training has been set up, but as far as I know, I am not going to receive it.  I feel like I need to be heard, but at the same time I need to make sure that my duty to my Scrum team (as is currently defined) isn’t skipped out on either.  Am I just stuck with how someone else has decided things are?

                     

                    Jennifer L. Griner, MCP, MCDBA

                    Quality Control Specialist, ProSystem fx Engagement

                    CCH, a WoltersKluwer business

                  • Hillel Glazer
                    Gaad-zukes, Jennie! I was reading your reply to Steve and my eyes started to bleed. In my head, every few sentences I was hearing that sound effect of the
                    Message 9 of 14 , Feb 26 12:21 PM
                    • 0 Attachment
                      Gaad-zukes, Jennie!

                      I was reading your reply to Steve and my eyes started to bleed.  In my head, every few sentences I was hearing that sound effect of the needle scraping across a record (an effect many of today's developers have NEVER heard in real life and in a few years anyone who recognizes it on hearing or can even parse the verbal description of it will be chasing grandchildren!).

                      Anyway... I've worked with companies who have worked with Rally consultants and the results are pretty good.  Obviously it nearly always means the organization is using Rally's tool, but that's neither here nor there and possibly a good thing.  I didn't hear the needle-scraping thing when you noted this.

                      However, on a lot of the other stuff, I was quite worried for your organization.  If I had to give a "field diagnosis" in the absence of other data or deeper analysis, I would say that there are several interacting attributes your organization is experiencing, irrespective of the likely concern that leadership/management want change but don't know effective ways of getting it.

                      From what you describe and knowing nothing else, your organization exhibits symptoms of one that lacks:
                      - clearly articulated and widely agreed-upon development work flows
                      - several basic engineering (or software-engineering-specific) disciplines
                      - several basic tenets of product management
                      - clear articulation of testing scope, roles, and goals
                      - a product evolution/promotion/release pattern that prevents wrong product from getting too far
                      - much of any internalization of how to realize the benefits of iterative and incremental development.

                      Quite basically, Steve's right, you really need some coaching.  And you're right, it might have to be expensive.

                      Good luck!

                      Cheers!
                      -->>  Hillel
                      --
                      Hillel Glazer, Principal & CEO
                      Entinex, Inc.
                      Process can't fix stupid.(TM)

                      www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
                      O-


                      On Fri, Feb 26, 2010 at 11:51 AM, Griner, Jennie <jennifer.griner@...> wrote:


                      >Hi Jennifer,

                      >Why did anyone in your organization want to "implement an agile approach" in the first place?  Normally, organizations that perceive the "need" to pursue agile approaches are doing so to not repeat past failures (project, product, morale, etc.) and to pursue specific, tangible, qualitative or quantitative benefits they're not getting/seeing with how they're doing things now (or in the past).  So... what was/is your organization's reason?

                       

                      That’s a really good question, and it’s going to take some digging for me to find the actual answer to it.  Here’s the trouble, my understand is that our organization as a whole is looking to adopt agile, and our group is not the first to try these methods.  I’m not sure how to figure out who the person is that decided that this was the way to go.  I have a feeling, though, that they’ve decided to “go agile” because it’s the thing to do.

                       

                      >With these reasons articulated, you can look for "things you don't like" or "things you don't want to do again", understand what causes them, then find the lean/agile alternatives (if there are any).  This is where Pete points out that change might need to happen.  To avoid the things you don't want to show up in the future, you'll be changing that which causes those things going forward.  Such changes will frequently involve breaking some paradigms and resetting some expectations.  If you get push-back, you know it's a Quixotic effort and your call whether to keep pursuit or not.

                       

                      To respond to Pete, I think part of the problem is that the agile adoption is coming from the top down, rather than from the bottom up.  I have a feeling that things would be working better if we, as the development team, said we want to do things more agile.  Though then we may have the push back that you mention below, where the powers that be don’t understand it and don’t see the benefit to it.  In our case, the powers that be have said that we’re doing this.  However, I think that they still don’t understand it, so they’ve told us that we have to do it, and we’re kind of drowning since no one really had a good grasp of what we wanted to do when we started.

                       

                      >And it's also another potentially telling use of words... "implement an agile approach".  I may be reading too much into it, but I've seen this phrase used when organizations were looking for some silver bullet to solve various, sundry and weakly-understood but deep seated issues.  To your organization, how is the phrase "do things in a more lean and agile way" different from "implement an agile approach"?  If it's not different, then ignore this paragraph.  On the other hand, if you immediately sense dread and resistance, then you're back out there with Don Quixote.  "Do things in a more lean and agile way" is a much more robust pursuit and takes a lot of commitment, self-awareness and honest introspection.  "Implement and agile approach" sounds more like Dilbert's Pointy-Haired boss telling Dilbert to "do more with agile" believing it's an automatic and magic pill to skimp on resources and time and still product a quality product. 

                       

                      I think that this paragraph is 100% accurate.

                       

                      >The most effective way towards "implement[ing] an agile approach" is to adopt lean and agile principles, then get to work "leaning-out" the waste in your organization and development practices.  Whether you implement Scrum or not is not the issue.  Fully embracing Scrum is more than daily stand-ups, time-boxed iterations, and having a backlog.  Though, once fully embraced, Scrum is a lot like the "gateway drug" to agile.  If your system is immune to the benefits of all-out Scrum, it's likely immune to anything agile or lean.

                       

                      It feels like our team is going through the motions.  As you say, just doing daily meetings, sprints, and keeping a backlog.  I don’t think most people have the actual mindset required to be open to change.

                       

                      >OK... so...having said all this... your team may be hampered by the nature of the agreements you have with your customers.  It's not that you can't be lean, agile, or using Scrum with government contracts, it's just that you will have to re-frame some of the typical agile/Scrum practices to compensate for the likely lack of a present customer, the likely a-priori agreement on scope, the likely pre-determination of project "phases".  Please understand, you don't have to abandon agile/Scrum practices, you just need to re-orient your work so that you can still deliver expected deliverables but that you produce them following the beat of your own drummer, not the government's.

                       

                      This makes total sense.  We’re dealing with product managers that have made promises to our corporate clients, but I think it has the same effect as if it were a government (or any other) contract.

                       

                      >Good luck!


                      Cheers!
                      -->>  Hillel
                      --
                      Hillel Glazer, Principal & CEO
                      Entinex, Inc.
                      Process can't fix stupid.(TM)

                      www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
                      O-

                      On Thu, Feb 25, 2010 at 5:54 PM, <PeteCRuth@...> wrote:

                       

                       

                       

                      Your "powers that be" may be employing the age-old management strategy of appearing to be supportive by offering concessions instead of commitment. Transitioning to agile methods is tough enough for many organizations without having to retain unnecessary practices that end up costing far more time and effort than they are possible worth. Unless they understand how and why agile methods improve the development process, it's unlikely they'll commit fully to them. Commitment without understanding is often a prelude to potentially terminal misunderstandings, and if this is the case, finding ways to avoid getting blowback on their clothes will be high on their list of priorities if things begin to fall apart.

                       

                      Regards,

                       

                      Pete

                       

                      In a message dated 2/25/2010 12:47:01 P.M. Pacific Standard Time, jennifer.griner@... writes:

                       

                      Some quick background, my group decided to implement an agile approach on our last release.  Ignoring any work that was done before this decision was made, we had 13 month long sprints, followed by four additional months of panic mode testing and bug fixing.  I had done my research on what I thought agile meant for us, and would try to bring up things that weren’t really agile, and was ignored.  Needless to say, we basically did a waterfall with some mini waterfalls in the middle (if you can even consider it that because we hadn’t even fixed bugs as we came across them, they were all saved for those last four months).

                      So, the powers that be have gotten together after a retrospective of that release and decided that things weren’t agile, and we’re going to actually be agile this time.  However, it appears to me that they still can’t get some of the older ways of doing things out of their systems.  We still have to have the requirements for a story fully documented (though they did change the DoD to say “agreed on” rather than “signed off” and they did change the item regarding Use Case and User Interface to include the words “if needed.”

                      Management still insists on fully detailed test cases that can then be passed on to a tester on the regression team in later iterations, but we can’t leave the job of writing it to the regression tester, so the test member of the team must complete this prior to the end of the sprint, even though we know that things could continue to change up until the end.  This is after a test strategy must be completed along with test scenarios (high level test cases) for that sprint.

                      As for bug fixes, it’s hard to tell as we’re halfway into our first sprint, and I don’t think we’ve received a single build with the new code in it.  The DoD does say that the bug fixes will be made, but it did for our last release as well.  The team as a whole does seem to have made a commitment to follow the DoD much better this time, so that is a plus.

                      But how do I approach some of these issues?  I’ve asked for formal Scrum training (which no one in our group has received yet, which I think it part of the issue), and some training has been set up, but as far as I know, I am not going to receive it.  I feel like I need to be heard, but at the same time I need to make sure that my duty to my Scrum team (as is currently defined) isn’t skipped out on either.  Am I just stuck with how someone else has decided things are?

                      Jennifer L. Griner, MCP, MCDBA

                      Quality Control Specialist, ProSystem fx Engagement

                      CCH, a WoltersKluwer business

                       

                       




                    • JackM
                      I have not read any of the responses, so I apologize if I repeat what someone else has said already. I would really try to push for a coach to come in for a
                      Message 10 of 14 , Feb 26 6:46 PM
                      • 0 Attachment
                        I have not read any of the responses, so I apologize if I repeat what someone else has said already.

                        I would really try to push for a coach to come in for a short while to help the team to change their habits.

                        Additionally there are some really good videos online by Ken Schwabber, Jeff Sutherland, Mike Cohn. Try to get the team to watch them, do a couple lunch and learns. The one video in particular that I found incredibly inspirational was ken's google tech talk.

                        Try baby steps, even one developer at a time. Get one developer on your side, get him to work with qa upfront to define acceptance tests. Get some early wins, this will help others to see the way.

                        Jack
                        www.agilebuddy.com
                        twitter.com/agilebuddy
                        blog.agilebuddy.com

                        --- In scrumdevelopment@yahoogroups.com, "Griner, Jennie" <jennifer.griner@...> wrote:
                        >
                        > Some quick background, my group decided to implement an agile approach
                        > on our last release. Ignoring any work that was done before this
                        > decision was made, we had 13 month long sprints, followed by four
                        > additional months of panic mode testing and bug fixing. I had done my
                        > research on what I thought agile meant for us, and would try to bring up
                        > things that weren't really agile, and was ignored. Needless to say, we
                        > basically did a waterfall with some mini waterfalls in the middle (if
                        > you can even consider it that because we hadn't even fixed bugs as we
                        > came across them, they were all saved for those last four months).
                        >
                        >
                        >
                        > So, the powers that be have gotten together after a retrospective of
                        > that release and decided that things weren't agile, and we're going to
                        > actually be agile this time. However, it appears to me that they still
                        > can't get some of the older ways of doing things out of their systems.
                        > We still have to have the requirements for a story fully documented
                        > (though they did change the DoD to say "agreed on" rather than "signed
                        > off" and they did change the item regarding Use Case and User Interface
                        > to include the words "if needed."
                        >
                        >
                        >
                        > Management still insists on fully detailed test cases that can then be
                        > passed on to a tester on the regression team in later iterations, but we
                        > can't leave the job of writing it to the regression tester, so the test
                        > member of the team must complete this prior to the end of the sprint,
                        > even though we know that things could continue to change up until the
                        > end. This is after a test strategy must be completed along with test
                        > scenarios (high level test cases) for that sprint.
                        >
                        >
                        >
                        > As for bug fixes, it's hard to tell as we're halfway into our first
                        > sprint, and I don't think we've received a single build with the new
                        > code in it. The DoD does say that the bug fixes will be made, but it
                        > did for our last release as well. The team as a whole does seem to have
                        > made a commitment to follow the DoD much better this time, so that is a
                        > plus.
                        >
                        >
                        >
                        > But how do I approach some of these issues? I've asked for formal Scrum
                        > training (which no one in our group has received yet, which I think it
                        > part of the issue), and some training has been set up, but as far as I
                        > know, I am not going to receive it. I feel like I need to be heard, but
                        > at the same time I need to make sure that my duty to my Scrum team (as
                        > is currently defined) isn't skipped out on either. Am I just stuck with
                        > how someone else has decided things are?
                        >
                        >
                        >
                        > Jennifer L. Griner, MCP, MCDBA
                        >
                        > Quality Control Specialist, ProSystem fx Engagement
                        >
                        > CCH, a WoltersKluwer business
                        >
                      • Jeff Anderson
                        Jennie Forget about Agile for a second, your management is forcing your team teams to do some fundamentally dysfunctional things, focus on that. Ask your team
                        Message 11 of 14 , Feb 26 7:18 PM
                        • 0 Attachment
                          Jennie

                          Forget about Agile for a second, your management is forcing your team
                          teams to do some fundamentally dysfunctional things, focus on that.

                          Ask your team members if they feel there is a better approach to
                          working, and how they can remove the biggest impediments. Push those
                          ideas up to management and demand an action plan. If this falls on
                          deaf ears than there is no point in pursuing *agile* practices, your
                          management isn't even equipped to listen to the people who are
                          responsible for building the product...

                          Get your team used to feeling like they can bring up new ideas to
                          improve and actually get permission to change things.


                          On 2/26/10, Hillel Glazer <agilecmmi@...> wrote:
                          > Gaad-zukes, Jennie!
                          >
                          > I was reading your reply to Steve and my eyes started to bleed. In my head,
                          > every few sentences I was hearing that sound effect of the needle scraping
                          > across a record (an effect many of today's developers have NEVER heard in
                          > real life and in a few years anyone who recognizes it on hearing or can even
                          > parse the verbal description of it will be chasing grandchildren!).
                          >
                          > Anyway... I've worked with companies who have worked with Rally consultants
                          > and the results are pretty good. Obviously it nearly always means the
                          > organization is using Rally's tool, but that's neither here nor there and
                          > possibly a good thing. I didn't hear the needle-scraping thing when you
                          > noted this.
                          >
                          > However, on a lot of the other stuff, I was quite worried for your
                          > organization. If I had to give a "field diagnosis" in the absence of other
                          > data or deeper analysis, I would say that there are several interacting
                          > attributes your organization is experiencing, irrespective of the likely
                          > concern that leadership/management want change but don't know effective ways
                          > of getting it.
                          >
                          > From what you describe and knowing nothing else, your organization exhibits
                          > symptoms of one that lacks:
                          > - clearly articulated and widely agreed-upon development work flows
                          > - several basic engineering (or software-engineering-specific) disciplines
                          > - several basic tenets of product management
                          > - clear articulation of testing scope, roles, and goals
                          > - a product evolution/promotion/release pattern that prevents wrong product
                          > from getting too far
                          > - much of any internalization of how to realize the benefits of iterative
                          > and incremental development.
                          >
                          > Quite basically, Steve's right, you really need some coaching. And you're
                          > right, it might have to be expensive.
                          >
                          > Good luck!
                          >
                          > Cheers!
                          > -->> Hillel
                          > --
                          > Hillel Glazer, Principal & CEO
                          > Entinex, Inc.
                          > Process can't fix stupid.(TM)
                          >
                          > www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
                          > O-
                          >
                          >
                          > On Fri, Feb 26, 2010 at 11:51 AM, Griner, Jennie <
                          > jennifer.griner@...> wrote:
                          >
                          >>
                          >>
                          >> >Hi Jennifer,
                          >>
                          >> >Why did anyone in your organization want to "implement an agile approach"
                          >> in the first place? Normally, organizations that perceive the "need" to
                          >> pursue agile approaches are doing so to not repeat past failures (project,
                          >> product, morale, etc.) and to pursue specific, tangible, qualitative or
                          >> quantitative benefits they're not getting/seeing with how they're doing
                          >> things now (or in the past). So... what was/is your organization's
                          >> reason?
                          >>
                          >>
                          >>
                          >> That’s a really good question, and it’s going to take some digging for me
                          >> to find the actual answer to it. Here’s the trouble, my understand is
                          >> that
                          >> our organization as a whole is looking to adopt agile, and our group is
                          >> not
                          >> the first to try these methods. I’m not sure how to figure out who the
                          >> person is that decided that this was the way to go. I have a feeling,
                          >> though, that they’ve decided to “go agile” because it’s the thing to do.
                          >>
                          >>
                          >>
                          >> >With these reasons articulated, you can look for "things you don't like"
                          >> or "things you don't want to do again", understand what causes them, then
                          >> find the lean/agile alternatives (if there are any). This is where Pete
                          >> points out that change might need to happen. To avoid the things you
                          >> don't
                          >> want to show up in the future, you'll be changing that which causes those
                          >> things going forward. Such changes will frequently involve breaking some
                          >> paradigms and resetting some expectations. If you get push-back, you know
                          >> it's a Quixotic effort and your call whether to keep pursuit or not.
                          >>
                          >>
                          >>
                          >> To respond to Pete, I think part of the problem is that the agile adoption
                          >> is coming from the top down, rather than from the bottom up. I have a
                          >> feeling that things would be working better if we, as the development
                          >> team,
                          >> said we want to do things more agile. Though then we may have the push
                          >> back
                          >> that you mention below, where the powers that be don’t understand it and
                          >> don’t see the benefit to it. In our case, the powers that be have said
                          >> that
                          >> we’re doing this. However, I think that they still don’t understand it,
                          >> so
                          >> they’ve told us that we have to do it, and we’re kind of drowning since no
                          >> one really had a good grasp of what we wanted to do when we started.
                          >>
                          >>
                          >>
                          >> >And it's also another potentially telling use of words... "implement an
                          >> agile approach". I may be reading too much into it, but I've seen this
                          >> phrase used when organizations were looking for some silver bullet to
                          >> solve
                          >> various, sundry and weakly-understood but deep seated issues. To your
                          >> organization, how is the phrase "do things in a more lean and agile way"
                          >> different from "implement an agile approach"? If it's not different, then
                          >> ignore this paragraph. On the other hand, if you immediately sense dread
                          >> and resistance, then you're back out there with Don Quixote. "Do things
                          >> in
                          >> a more lean and agile way" is a much more robust pursuit and takes a lot
                          >> of
                          >> commitment, self-awareness and honest introspection. "Implement and agile
                          >> approach" sounds more like Dilbert's Pointy-Haired boss telling Dilbert to
                          >> "do more with agile" believing it's an automatic and magic pill to skimp
                          >> on
                          >> resources and time and still product a quality product.
                          >>
                          >>
                          >>
                          >> I think that this paragraph is 100% accurate.
                          >>
                          >>
                          >>
                          >> >The most effective way towards "implement[ing] an agile approach" is to
                          >> adopt lean and agile principles, then get to work "leaning-out" the waste
                          >> in
                          >> your organization and development practices. Whether you implement Scrum
                          >> or
                          >> not is not the issue. Fully embracing Scrum is more than daily stand-ups,
                          >> time-boxed iterations, and having a backlog. Though, once fully embraced,
                          >> Scrum is a lot like the "gateway drug" to agile. If your system is immune
                          >> to the benefits of all-out Scrum, it's likely immune to anything agile or
                          >> lean.
                          >>
                          >>
                          >>
                          >> It feels like our team is going through the motions. As you say, just
                          >> doing daily meetings, sprints, and keeping a backlog. I don’t think most
                          >> people have the actual mindset required to be open to change.
                          >>
                          >>
                          >>
                          >> >OK... so...having said all this... your team may be hampered by the
                          >> nature of the agreements you have with your customers. It's not that you
                          >> can't be lean, agile, or using Scrum with government contracts, it's just
                          >> that you will have to re-frame some of the typical agile/Scrum practices
                          >> to
                          >> compensate for the likely lack of a present customer, the likely a-priori
                          >> agreement on scope, the likely pre-determination of project "phases".
                          >> Please understand, you don't have to abandon agile/Scrum practices, you
                          >> just need to re-orient your work so that you can still deliver expected
                          >> deliverables but that you produce them following the beat of your own
                          >> drummer, not the government's.
                          >>
                          >>
                          >>
                          >> This makes total sense. We’re dealing with product managers that have
                          >> made
                          >> promises to our corporate clients, but I think it has the same effect as
                          >> if
                          >> it were a government (or any other) contract.
                          >>
                          >>
                          >>
                          >> >Good luck!
                          >>
                          >>
                          >> Cheers!
                          >> -->> Hillel
                          >> --
                          >> Hillel Glazer, Principal & CEO
                          >> Entinex, Inc.
                          >> Process can't fix stupid.(TM)
                          >>
                          >> www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
                          >> O-
                          >>
                          >> On Thu, Feb 25, 2010 at 5:54 PM, <PeteCRuth@...> wrote:
                          >>
                          >>
                          >>
                          >>
                          >>
                          >>
                          >>
                          >> Your "powers that be" may be employing the age-old management strategy of
                          >> appearing to be supportive by offering concessions instead of commitment.
                          >> Transitioning to agile methods is tough enough for many organizations
                          >> without having to retain unnecessary practices that end up costing far
                          >> more
                          >> time and effort than they are possible worth. Unless they understand how
                          >> and
                          >> why agile methods improve the development process, it's unlikely they'll
                          >> commit fully to them. Commitment without understanding is often a prelude
                          >> to
                          >> potentially terminal misunderstandings, and if this is the case, finding
                          >> ways to avoid getting blowback on their clothes will be high on their list
                          >> of priorities if things begin to fall apart.
                          >>
                          >>
                          >>
                          >> Regards,
                          >>
                          >>
                          >>
                          >> Pete
                          >>
                          >>
                          >>
                          >> In a message dated 2/25/2010 12:47:01 P.M. Pacific Standard Time,
                          >> jennifer.griner@... writes:
                          >>
                          >>
                          >>
                          >> Some quick background, my group decided to implement an agile approach on
                          >> our last release. Ignoring any work that was done before this decision
                          >> was
                          >> made, we had 13 month long sprints, followed by four additional months of
                          >> panic mode testing and bug fixing. I had done my research on what I
                          >> thought
                          >> agile meant for us, and would try to bring up things that weren’t really
                          >> agile, and was ignored. Needless to say, we basically did a waterfall
                          >> with
                          >> some mini waterfalls in the middle (if you can even consider it that
                          >> because
                          >> we hadn’t even fixed bugs as we came across them, they were all saved for
                          >> those last four months).
                          >>
                          >> So, the powers that be have gotten together after a retrospective of that
                          >> release and decided that things weren’t agile, and we’re going to actually
                          >> be agile this time. However, it appears to me that they still can’t get
                          >> some of the older ways of doing things out of their systems. We still
                          >> have
                          >> to have the requirements for a story fully documented (though they did
                          >> change the DoD to say “agreed on” rather than “signed off” and they did
                          >> change the item regarding Use Case and User Interface to include the words
                          >> “if needed.”
                          >>
                          >> Management still insists on fully detailed test cases that can then be
                          >> passed on to a tester on the regression team in later iterations, but we
                          >> can’t leave the job of writing it to the regression tester, so the test
                          >> member of the team must complete this prior to the end of the sprint, even
                          >> though we know that things could continue to change up until the end.
                          >> This
                          >> is after a test strategy must be completed along with test scenarios (high
                          >> level test cases) for that sprint.
                          >>
                          >> As for bug fixes, it’s hard to tell as we’re halfway into our first
                          >> sprint,
                          >> and I don’t think we’ve received a single build with the new code in it.
                          >> The DoD does say that the bug fixes will be made, but it did for our last
                          >> release as well. The team as a whole does seem to have made a commitment
                          >> to
                          >> follow the DoD much better this time, so that is a plus.
                          >>
                          >> But how do I approach some of these issues? I’ve asked for formal Scrum
                          >> training (which no one in our group has received yet, which I think it
                          >> part
                          >> of the issue), and some training has been set up, but as far as I know, I
                          >> am
                          >> not going to receive it. I feel like I need to be heard, but at the same
                          >> time I need to make sure that my duty to my Scrum team (as is currently
                          >> defined) isn’t skipped out on either. Am I just stuck with how someone
                          >> else
                          >> has decided things are?
                          >>
                          >> Jennifer L. Griner, MCP, MCDBA
                          >>
                          >> Quality Control Specialist, ProSystem *fx* Engagement
                          >>
                          >> CCH, a WoltersKluwer business
                          >>
                          >>
                          >>
                          >>
                          >>
                          >>
                          >>
                          >>
                          >>
                          >

                          --
                          Sent from my mobile device

                          Jeff Anderson

                          http://agileconsulting.blogspot.com/
                        • Hillel Glazer
                          Wow, Jeff, that was beautiful! Jennie... what *he* said! Cheers! -- Hillel -- Hillel Glazer, Principal & CEO Entinex, Inc. Process can t fix stupid.(TM)
                          Message 12 of 14 , Feb 26 9:01 PM
                          • 0 Attachment
                            Wow, Jeff, that was beautiful!

                            Jennie... what *he* said!

                            Cheers!
                            -->>  Hillel
                            --
                            Hillel Glazer, Principal & CEO
                            Entinex, Inc.
                            Process can't fix stupid.(TM)

                            www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
                            O-


                            On Fri, Feb 26, 2010 at 10:18 PM, Jeff Anderson <Thomasjeffreyandersontwin@...> wrote:
                            Jennie

                            Forget about Agile for a second, your management is forcing your team
                            teams to do some fundamentally dysfunctional things, focus on that.

                            Ask your team members if they feel there is a better approach to
                            working, and how they can remove the biggest impediments. Push those
                            ideas up to management and demand an action plan. If this falls on
                            deaf ears than there is no point in pursuing *agile* practices, your
                            management isn't even equipped to listen to the people who are
                            responsible for building the product...

                            Get your team used to feeling like they can bring up new ideas to
                            improve and actually get permission to change things.


                            On 2/26/10, Hillel Glazer <agilecmmi@...> wrote:
                            > Gaad-zukes, Jennie!
                            >
                            > I was reading your reply to Steve and my eyes started to bleed.  In my head,
                            > every few sentences I was hearing that sound effect of the needle scraping
                            > across a record (an effect many of today's developers have NEVER heard in
                            > real life and in a few years anyone who recognizes it on hearing or can even
                            > parse the verbal description of it will be chasing grandchildren!).
                            >
                            > Anyway... I've worked with companies who have worked with Rally consultants
                            > and the results are pretty good.  Obviously it nearly always means the
                            > organization is using Rally's tool, but that's neither here nor there and
                            > possibly a good thing.  I didn't hear the needle-scraping thing when you
                            > noted this.
                            >
                            > However, on a lot of the other stuff, I was quite worried for your
                            > organization.  If I had to give a "field diagnosis" in the absence of other
                            > data or deeper analysis, I would say that there are several interacting
                            > attributes your organization is experiencing, irrespective of the likely
                            > concern that leadership/management want change but don't know effective ways
                            > of getting it.
                            >
                            > From what you describe and knowing nothing else, your organization exhibits
                            > symptoms of one that lacks:
                            > - clearly articulated and widely agreed-upon development work flows
                            > - several basic engineering (or software-engineering-specific) disciplines
                            > - several basic tenets of product management
                            > - clear articulation of testing scope, roles, and goals
                            > - a product evolution/promotion/release pattern that prevents wrong product
                            > from getting too far
                            > - much of any internalization of how to realize the benefits of iterative
                            > and incremental development.
                            >
                            > Quite basically, Steve's right, you really need some coaching.  And you're
                            > right, it might have to be expensive.
                            >
                            > Good luck!
                            >
                            > Cheers!
                            > -->>  Hillel
                            > --
                            > Hillel Glazer, Principal & CEO
                            > Entinex, Inc.
                            > Process can't fix stupid.(TM)
                            >
                            > www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
                            > O-
                            >
                            >
                            > On Fri, Feb 26, 2010 at 11:51 AM, Griner, Jennie <
                            > jennifer.griner@...> wrote:
                            >
                            >>
                            >>
                            >>   >Hi Jennifer,
                            >>
                            >> >Why did anyone in your organization want to "implement an agile approach"
                            >> in the first place?  Normally, organizations that perceive the "need" to
                            >> pursue agile approaches are doing so to not repeat past failures (project,
                            >> product, morale, etc.) and to pursue specific, tangible, qualitative or
                            >> quantitative benefits they're not getting/seeing with how they're doing
                            >> things now (or in the past).  So... what was/is your organization's
                            >> reason?
                            >>
                            >>
                            >>
                            >> That’s a really good question, and it’s going to take some digging for me
                            >> to find the actual answer to it.  Here’s the trouble, my understand is
                            >> that
                            >> our organization as a whole is looking to adopt agile, and our group is
                            >> not
                            >> the first to try these methods.  I’m not sure how to figure out who the
                            >> person is that decided that this was the way to go.  I have a feeling,
                            >> though, that they’ve decided to “go agile” because it’s the thing to do.
                            >>
                            >>
                            >>
                            >> >With these reasons articulated, you can look for "things you don't like"
                            >> or "things you don't want to do again", understand what causes them, then
                            >> find the lean/agile alternatives (if there are any).  This is where Pete
                            >> points out that change might need to happen.  To avoid the things you
                            >> don't
                            >> want to show up in the future, you'll be changing that which causes those
                            >> things going forward.  Such changes will frequently involve breaking some
                            >> paradigms and resetting some expectations.  If you get push-back, you know
                            >> it's a Quixotic effort and your call whether to keep pursuit or not.
                            >>
                            >>
                            >>
                            >> To respond to Pete, I think part of the problem is that the agile adoption
                            >> is coming from the top down, rather than from the bottom up.  I have a
                            >> feeling that things would be working better if we, as the development
                            >> team,
                            >> said we want to do things more agile.  Though then we may have the push
                            >> back
                            >> that you mention below, where the powers that be don’t understand it and
                            >> don’t see the benefit to it.  In our case, the powers that be have said
                            >> that
                            >> we’re doing this.  However, I think that they still don’t understand it,
                            >> so
                            >> they’ve told us that we have to do it, and we’re kind of drowning since no
                            >> one really had a good grasp of what we wanted to do when we started.
                            >>
                            >>
                            >>
                            >> >And it's also another potentially telling use of words... "implement an
                            >> agile approach".  I may be reading too much into it, but I've seen this
                            >> phrase used when organizations were looking for some silver bullet to
                            >> solve
                            >> various, sundry and weakly-understood but deep seated issues.  To your
                            >> organization, how is the phrase "do things in a more lean and agile way"
                            >> different from "implement an agile approach"?  If it's not different, then
                            >> ignore this paragraph.  On the other hand, if you immediately sense dread
                            >> and resistance, then you're back out there with Don Quixote.  "Do things
                            >> in
                            >> a more lean and agile way" is a much more robust pursuit and takes a lot
                            >> of
                            >> commitment, self-awareness and honest introspection.  "Implement and agile
                            >> approach" sounds more like Dilbert's Pointy-Haired boss telling Dilbert to
                            >> "do more with agile" believing it's an automatic and magic pill to skimp
                            >> on
                            >> resources and time and still product a quality product.
                            >>
                            >>
                            >>
                            >> I think that this paragraph is 100% accurate.
                            >>
                            >>
                            >>
                            >> >The most effective way towards "implement[ing] an agile approach" is to
                            >> adopt lean and agile principles, then get to work "leaning-out" the waste
                            >> in
                            >> your organization and development practices.  Whether you implement Scrum
                            >> or
                            >> not is not the issue.  Fully embracing Scrum is more than daily stand-ups,
                            >> time-boxed iterations, and having a backlog.  Though, once fully embraced,
                            >> Scrum is a lot like the "gateway drug" to agile.  If your system is immune
                            >> to the benefits of all-out Scrum, it's likely immune to anything agile or
                            >> lean.
                            >>
                            >>
                            >>
                            >> It feels like our team is going through the motions.  As you say, just
                            >> doing daily meetings, sprints, and keeping a backlog.  I don’t think most
                            >> people have the actual mindset required to be open to change.
                            >>
                            >>
                            >>
                            >> >OK... so...having said all this... your team may be hampered by the
                            >> nature of the agreements you have with your customers.  It's not that you
                            >> can't be lean, agile, or using Scrum with government contracts, it's just
                            >> that you will have to re-frame some of the typical agile/Scrum practices
                            >> to
                            >> compensate for the likely lack of a present customer, the likely a-priori
                            >> agreement on scope, the likely pre-determination of project "phases".
                            >>  Please understand, you don't have to abandon agile/Scrum practices, you
                            >> just need to re-orient your work so that you can still deliver expected
                            >> deliverables but that you produce them following the beat of your own
                            >> drummer, not the government's.
                            >>
                            >>
                            >>
                            >> This makes total sense.  We’re dealing with product managers that have
                            >> made
                            >> promises to our corporate clients, but I think it has the same effect as
                            >> if
                            >> it were a government (or any other) contract.
                            >>
                            >>
                            >>
                            >> >Good luck!
                            >>
                            >>
                            >> Cheers!
                            >> -->>  Hillel
                            >> --
                            >> Hillel Glazer, Principal & CEO
                            >> Entinex, Inc.
                            >> Process can't fix stupid.(TM)
                            >>
                            >> www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
                            >> O-
                            >>
                            >>  On Thu, Feb 25, 2010 at 5:54 PM, <PeteCRuth@...> wrote:
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >> Your "powers that be" may be employing the age-old management strategy of
                            >> appearing to be supportive by offering concessions instead of commitment.
                            >> Transitioning to agile methods is tough enough for many organizations
                            >> without having to retain unnecessary practices that end up costing far
                            >> more
                            >> time and effort than they are possible worth. Unless they understand how
                            >> and
                            >> why agile methods improve the development process, it's unlikely they'll
                            >> commit fully to them. Commitment without understanding is often a prelude
                            >> to
                            >> potentially terminal misunderstandings, and if this is the case, finding
                            >> ways to avoid getting blowback on their clothes will be high on their list
                            >> of priorities if things begin to fall apart.
                            >>
                            >>
                            >>
                            >> Regards,
                            >>
                            >>
                            >>
                            >> Pete
                            >>
                            >>
                            >>
                            >> In a message dated 2/25/2010 12:47:01 P.M. Pacific Standard Time,
                            >> jennifer.griner@... writes:
                            >>
                            >>
                            >>
                            >> Some quick background, my group decided to implement an agile approach on
                            >> our last release.  Ignoring any work that was done before this decision
                            >> was
                            >> made, we had 13 month long sprints, followed by four additional months of
                            >> panic mode testing and bug fixing.  I had done my research on what I
                            >> thought
                            >> agile meant for us, and would try to bring up things that weren’t really
                            >> agile, and was ignored.  Needless to say, we basically did a waterfall
                            >> with
                            >> some mini waterfalls in the middle (if you can even consider it that
                            >> because
                            >> we hadn’t even fixed bugs as we came across them, they were all saved for
                            >> those last four months).
                            >>
                            >> So, the powers that be have gotten together after a retrospective of that
                            >> release and decided that things weren’t agile, and we’re going to actually
                            >> be agile this time.  However, it appears to me that they still can’t get
                            >> some of the older ways of doing things out of their systems.  We still
                            >> have
                            >> to have the requirements for a story fully documented (though they did
                            >> change the DoD to say “agreed on” rather than “signed off” and they did
                            >> change the item regarding Use Case and User Interface to include the words
                            >> “if needed.”
                            >>
                            >> Management still insists on fully detailed test cases that can then be
                            >> passed on to a tester on the regression team in later iterations, but we
                            >> can’t leave the job of writing it to the regression tester, so the test
                            >> member of the team must complete this prior to the end of the sprint, even
                            >> though we know that things could continue to change up until the end.
                            >> This
                            >> is after a test strategy must be completed along with test scenarios (high
                            >> level test cases) for that sprint.
                            >>
                            >> As for bug fixes, it’s hard to tell as we’re halfway into our first
                            >> sprint,
                            >> and I don’t think we’ve received a single build with the new code in it.
                            >> The DoD does say that the bug fixes will be made, but it did for our last
                            >> release as well.  The team as a whole does seem to have made a commitment
                            >> to
                            >> follow the DoD much better this time, so that is a plus.
                            >>
                            >> But how do I approach some of these issues?  I’ve asked for formal Scrum
                            >> training (which no one in our group has received yet, which I think it
                            >> part
                            >> of the issue), and some training has been set up, but as far as I know, I
                            >> am
                            >> not going to receive it.  I feel like I need to be heard, but at the same
                            >> time I need to make sure that my duty to my Scrum team (as is currently
                            >> defined) isn’t skipped out on either.  Am I just stuck with how someone
                            >> else
                            >> has decided things are?
                            >>
                            >> Jennifer L. Griner, MCP, MCDBA
                            >>
                            >> Quality Control Specialist, ProSystem *fx* Engagement
                            >>
                            >> CCH, a WoltersKluwer business
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >

                            --
                            Sent from my mobile device

                            Jeff Anderson

                            http://agileconsulting.blogspot.com/


                            ------------------------------------

                            To Post a message, send it to:   scrumdevelopment@...
                            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                            <*> To visit your group on the web, go to:
                               http://groups.yahoo.com/group/scrumdevelopment/

                            <*> Your email settings:
                               Individual Email | Traditional

                            <*> To change settings online go to:
                               http://groups.yahoo.com/group/scrumdevelopment/join
                               (Yahoo! ID required)

                            <*> To change settings via email:
                               scrumdevelopment-digest@yahoogroups.com
                               scrumdevelopment-fullfeatured@yahoogroups.com

                            <*> To unsubscribe from this group, send an email to:
                               scrumdevelopment-unsubscribe@yahoogroups.com

                            <*> Your use of Yahoo! Groups is subject to:
                               http://docs.yahoo.com/info/terms/


                          • Thomasjeffreyandersontwin@Gmail.com
                            Hillel Thx! :) Jeff Anderson agileconsulting.blogspot.com ... Hillel Thx! :) Jeff Anderson agileconsulting.blogspot.com On Feb 27, 2010, at 12:01 AM, Hillel
                            Message 13 of 14 , Feb 27 8:20 AM
                            • 0 Attachment

                              Hillel

                              Thx! :)
                              Jeff Anderson


                              On Feb 27, 2010, at 12:01 AM, Hillel Glazer <agilecmmi@...> wrote:

                               

                              Wow, Jeff, that was beautiful!


                              Jennie... what *he* said!

                              Cheers!
                              -->>  Hillel
                              --
                              Hillel Glazer, Principal & CEO
                              Entinex, Inc.
                              Process can't fix stupid.(TM)

                              www.entinex. com | www.AgileCMMI. com | www.CMMIFAQ. info
                              O-


                              On Fri, Feb 26, 2010 at 10:18 PM, Jeff Anderson <Thomasjeffreyanders ontwin@gmail. com> wrote:
                              Jennie

                              Forget about Agile for a second, your management is forcing your team
                              teams to do some fundamentally dysfunctional things, focus on that.

                              Ask your team members if they feel there is a better approach to
                              working, and how they can remove the biggest impediments. Push those
                              ideas up to management and demand an action plan. If this falls on
                              deaf ears than there is no point in pursuing *agile* practices, your
                              management isn't even equipped to listen to the people who are
                              responsible for building the product...

                              Get your team used to feeling like they can bring up new ideas to
                              improve and actually get permission to change things.


                              On 2/26/10, Hillel Glazer <agilecmmi@gmail. com> wrote:
                              > Gaad-zukes, Jennie!
                              >
                              > I was reading your reply to Steve and my eyes started to bleed.  In my head,
                              > every few sentences I was hearing that sound effect of the needle scraping
                              > across a record (an effect many of today's developers have NEVER heard in
                              > real life and in a few years anyone who recognizes it on hearing or can even
                              > parse the verbal description of it will be chasing grandchildren! ).
                              >
                              > Anyway... I've worked with companies who have worked with Rally consultants
                              > and the results are pretty good.  Obviously it nearly always means the
                              > organization is using Rally's tool, but that's neither here nor there and
                              > possibly a good thing.  I didn't hear the needle-scraping thing when you
                              > noted this.
                              >
                              > However, on a lot of the other stuff, I was quite worried for your
                              > organization.  If I had to give a "field diagnosis" in the absence of other
                              > data or deeper analysis, I would say that there are several interacting
                              > attributes your organization is experiencing, irrespective of the likely
                              > concern that leadership/manageme nt want change but don't know effective ways
                              > of getting it.
                              >
                              > From what you describe and knowing nothing else, your organization exhibits
                              > symptoms of one that lacks:
                              > - clearly articulated and widely agreed-upon development work flows
                              > - several basic engineering (or software-engineerin g-specific) disciplines
                              > - several basic tenets of product management
                              > - clear articulation of testing scope, roles, and goals
                              > - a product evolution/promotion /release pattern that prevents wrong product
                              > from getting too far
                              > - much of any internalization of how to realize the benefits of iterative
                              > and incremental development.
                              >
                              > Quite basically, Steve's right, you really need some coaching.  And you're
                              > right, it might have to be expensive.
                              >
                              > Good luck!
                              >
                              > Cheers!
                              > -->>  Hillel
                              > --
                              > Hillel Glazer, Principal & CEO
                              > Entinex, Inc.
                              > Process can't fix stupid.(TM)
                              >
                              > www.entinex. com | www.AgileCMMI. com | www.CMMIFAQ. info
                              > O-
                              >
                              >
                              > On Fri, Feb 26, 2010 at 11:51 AM, Griner, Jennie <
                              > jennifer.griner@ wolterskluwer. com> wrote:
                              >
                              >>
                              >>
                              >>   >Hi Jennifer,
                              >>
                              >> >Why did anyone in your organization want to "implement an agile approach"
                              >> in the first place?  Normally, organizations that perceive the "need" to
                              >> pursue agile approaches are doing so to not repeat past failures (project,
                              >> product, morale, etc.) and to pursue specific, tangible, qualitative or
                              >> quantitative benefits they're not getting/seeing with how they're doing
                              >> things now (or in the past).  So... what was/is your organization's
                              >> reason?
                              >>
                              >>
                              >>
                              >> That’s a really good question, and it’s going to take some digging for me
                              >> to find the actual answer to it.  Here’s the trouble, my understand is
                              >> that
                              >> our organization as a whole is looking to adopt agile, and our group is
                              >> not
                              >> the first to try these methods.  I’m not sure how to figure out who the
                              >> person is that decided that this was the way to go.  I have a feeling,
                              >> though, that they’ve decided to “go agile” because it’s the thing to do.
                              >>
                              >>
                              >>
                              >> >With these reasons articulated, you can look for "things you don't like"
                              >> or "things you don't want to do again", understand what causes them, then
                              >> find the lean/agile alternatives (if there are any).  This is where Pete
                              >> points out that change might need to happen.  To avoid the things you
                              >> don't
                              >> want to show up in the future, you'll be changing that which causes those
                              >> things going forward.  Such changes will frequently involve breaking some
                              >> paradigms and resetting some expectations.  If you get push-back, you know
                              >> it's a Quixotic effort and your call whether to keep pursuit or not.
                              >>
                              >>
                              >>
                              >> To respond to Pete, I think part of the problem is that the agile adoption
                              >> is coming from the top down, rather than from the bottom up.  I have a
                              >> feeling that things would be working better if we, as the development
                              >> team,
                              >> said we want to do things more agile.  Though then we may have the push
                              >> back
                              >> that you mention below, where the powers that be don’t understand it and
                              >> don’t see the benefit to it.  In our case, the powers that be have said
                              >> that
                              >> we’re doing this.  However, I think that they still don’t understand it,
                              >> so
                              >> they’ve told us that we have to do it, and we’re kind of drowning since no
                              >> one really had a good grasp of what we wanted to do when we started.
                              >>
                              >>
                              >>
                              >> >And it's also another potentially telling use of words... "implement an
                              >> agile approach".  I may be reading too much into it, but I've seen this
                              >> phrase used when organizations were looking for some silver bullet to
                              >> solve
                              >> various, sundry and weakly-understood but deep seated issues.  To your
                              >> organization, how is the phrase "do things in a more lean and agile way"
                              >> different from "implement an agile approach"?  If it's not different, then
                              >> ignore this paragraph.  On the other hand, if you immediately sense dread
                              >> and resistance, then you're back out there with Don Quixote.  "Do things
                              >> in
                              >> a more lean and agile way" is a much more robust pursuit and takes a lot
                              >> of
                              >> commitment, self-awareness and honest introspection.  "Implement and agile
                              >> approach" sounds more like Dilbert's Pointy-Haired boss telling Dilbert to
                              >> "do more with agile" believing it's an automatic and magic pill to skimp
                              >> on
                              >> resources and time and still product a quality product.
                              >>
                              >>
                              >>
                              >> I think that this paragraph is 100% accurate.
                              >>
                              >>
                              >>
                              >> >The most effective way towards "implement[ing] an agile approach" is to
                              >> adopt lean and agile principles, then get to work "leaning-out" the waste
                              >> in
                              >> your organization and development practices.  Whether you implement Scrum
                              >> or
                              >> not is not the issue.  Fully embracing Scrum is more than daily stand-ups,
                              >> time-boxed iterations, and having a backlog.  Though, once fully embraced,
                              >> Scrum is a lot like the "gateway drug" to agile.  If your system is immune
                              >> to the benefits of all-out Scrum, it's likely immune to anything agile or
                              >> lean.
                              >>
                              >>
                              >>
                              >> It feels like our team is going through the motions.  As you say, just
                              >> doing daily meetings, sprints, and keeping a backlog.  I don’t think most
                              >> people have the actual mindset required to be open to change.
                              >>
                              >>
                              >>
                              >> >OK... so...having said all this... your team may be hampered by the
                              >> nature of the agreements you have with your customers.  It's not that you
                              >> can't be lean, agile, or using Scrum with government contracts, it's just
                              >> that you will have to re-frame some of the typical agile/Scrum practices
                              >> to
                              >> compensate for the likely lack of a present customer, the likely a-priori
                              >> agreement on scope, the likely pre-determination of project "phases".
                              >>  Please understand, you don't have to abandon agile/Scrum practices, you
                              >> just need to re-orient your work so that you can still deliver expected
                              >> deliverables but that you produce them following the beat of your own
                              >> drummer, not the government's.
                              >>
                              >>
                              >>
                              >> This makes total sense.  We’re dealing with product managers that have
                              >> made
                              >> promises to our corporate clients, but I think it has the same effect as
                              >> if
                              >> it were a government (or any other) contract.
                              >>
                              >>
                              >>
                              >> >Good luck!
                              >>
                              >>
                              >> Cheers!
                              >> -->>  Hillel
                              >> --
                              >> Hillel Glazer, Principal & CEO
                              >> Entinex, Inc.
                              >> Process can't fix stupid.(TM)
                              >>
                              >> www.entinex. com | www.AgileCMMI. com | www.CMMIFAQ. info
                              >> O-
                              >>
                              >>  On Thu, Feb 25, 2010 at 5:54 PM, <PeteCRuth@aol. com> wrote:
                              >>
                              >>
                              >>
                              >>
                              >>
                              >>
                              >>
                              >> Your "powers that be" may be employing the age-old management strategy of
                              >> appearing to be supportive by offering concessions instead of commitment.
                              >> Transitioning to agile methods is tough enough for many organizations
                              >> without having to retain unnecessary practices that end up costing far
                              >> more
                              >> time and effort than they are possible worth. Unless they understand how
                              >> and
                              >> why agile methods improve the development process, it's unlikely they'll
                              >> commit fully to them. Commitment without understanding is often a prelude
                              >> to
                              >> potentially terminal misunderstandings, and if this is the case, finding
                              >> ways to avoid getting blowback on their clothes will be high on their list
                              >> of priorities if things begin to fall apart.
                              >>
                              >>
                              >>
                              >> Regards,
                              >>
                              >>
                              >>
                              >> Pete
                              >>
                              >>
                              >>
                              >> In a message dated 2/25/2010 12:47:01 P.M. Pacific Standard Time,
                              >> jennifer.griner@ wolterskluwer. com writes:
                              >>
                              >>
                              >>
                              >> Some quick background, my group decided to implement an agile approach on
                              >> our last release.  Ignoring any work that was done before this decision
                              >> was
                              >> made, we had 13 month long sprints, followed by four additional months of
                              >> panic mode testing and bug fixing.  I had done my research on what I
                              >> thought
                              >> agile meant for us, and would try to bring up things that weren’t really
                              >> agile, and was ignored.  Needless to say, we basically did a waterfall
                              >> with
                              >> some mini waterfalls in the middle (if you can even consider it that
                              >> because
                              >> we hadn’t even fixed bugs as we came across them, they were all saved for
                              >> those last four months).
                              >>
                              >> So, the powers that be have gotten together after a retrospective of that
                              >> release and decided that things weren’t agile, and we’re going to actually
                              >> be agile this time.  However, it appears to me that they still can’t get
                              >> some of the older ways of doing things out of their systems.  We still
                              >> have
                              >> to have the requirements for a story fully documented (though they did
                              >> change the DoD to say “agreed on” rather than “signed off” and they did
                              >> change the item regarding Use Case and User Interface to include the words
                              >> “if needed.”
                              >>
                              >> Management still insists on fully detailed test cases that can then be
                              >> passed on to a tester on the regression team in later iterations, but we
                              >> can’t leave the job of writing it to the regression tester, so the test
                              >> member of the team must complete this prior to the end of the sprint, even
                              >> though we know that things could continue to change up until the end.
                              >> This
                              >> is after a test strategy must be completed along with test scenarios (high
                              >> level test cases) for that sprint.
                              >>
                              >> As for bug fixes, it’s hard to tell as we’re halfway into our first
                              >> sprint,
                              >> and I don’t think we’ve received a single build with the new code in it.
                              >> The DoD does say that the bug fixes will be made, but it did for our last
                              >> release as well.  The team as a whole does seem to have made a commitment
                              >> to
                              >> follow the DoD much better this time, so that is a plus.
                              >>
                              >> But how do I approach some of these issues?  I’ve asked for formal Scrum
                              >> training (which no one in our group has received yet, which I think it
                              >> part
                              >> of the issue), and some training has been set up, but as far as I know, I
                              >> am
                              >> not going to receive it.  I feel like I need to be heard, but at the same
                              >> time I need to make sure that my duty to my Scrum team (as is currently
                              >> defined) isn’t skipped out on either.  Am I just stuck with how someone
                              >> else
                              >> has decided things are?
                              >>
                              >> Jennifer L. Griner, MCP, MCDBA
                              >>
                              >> Quality Control Specialist, ProSystem *fx* Engagement
                              >>
                              >> CCH, a WoltersKluwer business
                              >>
                              >>
                              >>
                              >>
                              >>
                              >>
                              >>
                              >>
                              >>
                              >

                              --
                              Sent from my mobile device

                              Jeff Anderson

                              http://agileconsult ing.blogspot. com/


                              ------------ --------- --------- ------

                              To Post a message, send it to:   scrumdevelopment@eGroups.com
                              To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo ! Groups Links

                              <*> To visit your group on the web, go to:
                                 http://groups.yahoo.com/ group/scrumdevel opment/

                              <*> Your email settings:
                                 Individual Email | Traditional

                              <*> To change settings online go to:
                                 http://groups.yahoo.com/ group/scrumdevel opment/join
                                 (Yahoo! ID required)

                              <*> To change settings via email:
                                 scrumdevelopment- digest@yahoogroups.com
                                 scrumdevelopment- fullfeatured@ yahoogroups. com

                              <*> To unsubscribe from this group, send an email to:
                                 scrumdevelopment- unsubscribe@ yahoogroups. com

                              <*> Your use of Yahoo! Groups is subject to:
                                 http://docs.yahoo.com/ info/terms/


                            • Franz Allan Valencia See
                              I agree on this one. There seems to be a lot of habits to break, and breaking a huge habit would face a lot of resistance. IMHO, start being agile on simple
                              Message 14 of 14 , Mar 1, 2010
                              • 0 Attachment
                                I agree on this one. There seems to be a lot of habits to break, and breaking a huge habit would face a lot of resistance.

                                IMHO, start being agile on simple things first like working closely with your designers and testers. Take a sneak peak on what your designer has (even if it's not finished according to your organisation's standard), talk to him/her (it would be better if you can get your tester involved as well). Then try to verify early on (instead of waiting for x weeks/mos). Or if there's already a ton of things in the requirement already by the time you take a look at it, verify the items there one by one. You don't have to finish all at once before getting a feedback.

                                Also, you can try and do unit testing. That part is usually easy to set up as opposed to full blown automated acceptance testing.

                                Basically, just identify some small things that's wrong and apply agility to it.

                                IMHO, if you can't be agile on the small stuffs, then it's going to be hard being agile as an organisation :-)

                                Cheers,

                                --
                                Franz Allan Valencia See | Java Software Engineer
                                franz.see@...
                                LinkedIn: http://www.linkedin.com/in/franzsee
                                Twitter: http://www.twitter.com/franz_see

                                On Sat, Feb 27, 2010 at 10:46 AM, JackM <jack@...> wrote:
                                 

                                ...
                                Try baby steps, even one developer at a time. Get one developer on your side, get him to work with qa upfront to define acceptance tests. Get some early wins, this will help others to see the way.

                                Jack
                                www.agilebuddy.com
                                twitter.com/agilebuddy
                                blog.agilebuddy.com



                                --- In scrumdevelopment@yahoogroups.com, "Griner, Jennie" <jennifer.griner@...> wrote:
                                >
                                > Some quick background, my group decided to implement an agile approach
                                > on our last release. Ignoring any work that was done before this
                                > decision was made, we had 13 month long sprints, followed by four
                                > additional months of panic mode testing and bug fixing. I had done my
                                > research on what I thought agile meant for us, and would try to bring up
                                > things that weren't really agile, and was ignored. Needless to say, we
                                > basically did a waterfall with some mini waterfalls in the middle (if
                                > you can even consider it that because we hadn't even fixed bugs as we
                                > came across them, they were all saved for those last four months).
                                >
                                >
                                >
                                > So, the powers that be have gotten together after a retrospective of
                                > that release and decided that things weren't agile, and we're going to
                                > actually be agile this time. However, it appears to me that they still
                                > can't get some of the older ways of doing things out of their systems.
                                > We still have to have the requirements for a story fully documented
                                > (though they did change the DoD to say "agreed on" rather than "signed
                                > off" and they did change the item regarding Use Case and User Interface
                                > to include the words "if needed."
                                >
                                >
                                >
                                > Management still insists on fully detailed test cases that can then be
                                > passed on to a tester on the regression team in later iterations, but we
                                > can't leave the job of writing it to the regression tester, so the test
                                > member of the team must complete this prior to the end of the sprint,
                                > even though we know that things could continue to change up until the
                                > end. This is after a test strategy must be completed along with test
                                > scenarios (high level test cases) for that sprint.
                                >
                                >
                                >
                                > As for bug fixes, it's hard to tell as we're halfway into our first
                                > sprint, and I don't think we've received a single build with the new
                                > code in it. The DoD does say that the bug fixes will be made, but it
                                > did for our last release as well. The team as a whole does seem to have
                                > made a commitment to follow the DoD much better this time, so that is a
                                > plus.
                                >
                                >
                                >
                                > But how do I approach some of these issues? I've asked for formal Scrum
                                > training (which no one in our group has received yet, which I think it
                                > part of the issue), and some training has been set up, but as far as I
                                > know, I am not going to receive it. I feel like I need to be heard, but
                                > at the same time I need to make sure that my duty to my Scrum team (as
                                > is currently defined) isn't skipped out on either. Am I just stuck with
                                > how someone else has decided things are?
                                >
                                >
                                >
                                > Jennifer L. Griner, MCP, MCDBA
                                >
                                > Quality Control Specialist, ProSystem fx Engagement
                                >
                                > CCH, a WoltersKluwer business
                                >


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