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

Sprint Planning Strategy for Disadvantaged Team

Expand Messages
  • andre_simones
    We are currently in the midst of implementing Scrum on a pretty large project. Below are some of the disadvantages we are experiencing now. - The code base is
    Message 1 of 13 , Nov 29, 2007
    • 0 Attachment
      We are currently in the midst of implementing Scrum on a pretty large project. Below are
      some of the disadvantages we are experiencing now.

      - The code base is about 10 years old and is pretty big.
      - All of the original developers are gone. The majority of the developers have been
      working on the project less than a year.
      - The entire QA team is comprised of new hires, many only 2-3 months tenured. Many of
      them are new to QA.
      - The full functionality of the product is not fully understood by anyone.
      - The poor quality of the code is profound. TDD is nearly impossible, and a re-
      architecture is inevitable (but this is down the road), as the code base is PowerBuilder
      (wow, its hard to find PowerBuilder resources).

      The list goes on, but these are the key points that impact the Sprint Planning session.

      It took a while, but we found a strong product owner who created a prioritized product
      backlog. After this, we attempted to have a sprint planning session. It was pretty painful.
      In my previous teams, the team members were all very knowledgeable about the code
      base and its functionality. In addition, the code was structured pretty well, so the PBL
      could be decomposed relatively easily in one sitting.

      In this sprint planning session, the team thought of decomposing these features (stories)
      into 16 hour or less tasks as a ridiculous notion. They kept saying that they would have to
      perform analysis to do this decomposition. They absolutely had no clue how to
      decompose.

      I was deeply troubled after this. A long conversation with one of the senior engineers
      (who is pro-scrum) revealed that the extreme poor code quality requires analysis of the
      current code to occur to decompose. As an example, there was one feature that was
      estimated at about 50 hours. I asked the engineer to decompose this into smaller pieces.
      That decomposition took almost a full day. Wow. I was shocked.

      This means that the way the sprint planning session is conducted will have to be adjusted.
      Right now, the team will not be able to sit in a room and decompose these tasks in one
      planning session. I am leaning towards having a pre-planning session. Where the team
      assigns "homework" to themselves, to come prepared for the sprint planning session for
      the purpose of coming up with a sprint backlog and a commitment. Over time, as the
      team becomes more experienced, I think that this will get better.

      I'd love to hear some thoughts of some of those who've been in this situation before.

      Andre
    • Andreas Thiel
      Hi Andre, as it s often the case, Scrum makes problems just visible - Scrum itself is not the problem. I would let the team go through this painful phase. By
      Message 2 of 13 , Nov 29, 2007
      • 0 Attachment
        Hi Andre,

        as it's often the case, Scrum makes problems just visible - Scrum
        itself is not the problem.

        I would let the team go through this painful phase. By and by the
        decomposition will go smoother. Without decomposition your sprint
        planning will remain meaningless.

        Did you think about spikes to improve the estimations and the
        knowledge about the code base?

        Regards,
        Andreas

        --- In scrumdevelopment@yahoogroups.com, "andre_simones"
        <scrumdevelopment@...> wrote:
        >
        > We are currently in the midst of implementing Scrum on a pretty
        large project. Below are
        > some of the disadvantages we are experiencing now.
        >
        > - The code base is about 10 years old and is pretty big.
        > - All of the original developers are gone. The majority of the
        developers have been
        > working on the project less than a year.
        > - The entire QA team is comprised of new hires, many only 2-3
        months tenured. Many of
        > them are new to QA.
        > - The full functionality of the product is not fully understood by
        anyone.
        > - The poor quality of the code is profound. TDD is nearly
        impossible, and a re-
        > architecture is inevitable (but this is down the road), as the
        code base is PowerBuilder
        > (wow, its hard to find PowerBuilder resources).
        >
        > The list goes on, but these are the key points that impact the
        Sprint Planning session.
        >
        > It took a while, but we found a strong product owner who created a
        prioritized product
        > backlog. After this, we attempted to have a sprint planning
        session. It was pretty painful.
        > In my previous teams, the team members were all very knowledgeable
        about the code
        > base and its functionality. In addition, the code was structured
        pretty well, so the PBL
        > could be decomposed relatively easily in one sitting.
        >
        > In this sprint planning session, the team thought of decomposing
        these features (stories)
        > into 16 hour or less tasks as a ridiculous notion. They kept
        saying that they would have to
        > perform analysis to do this decomposition. They absolutely had no
        clue how to
        > decompose.
        >
        > I was deeply troubled after this. A long conversation with one of
        the senior engineers
        > (who is pro-scrum) revealed that the extreme poor code quality
        requires analysis of the
        > current code to occur to decompose. As an example, there was one
        feature that was
        > estimated at about 50 hours. I asked the engineer to decompose
        this into smaller pieces.
        > That decomposition took almost a full day. Wow. I was shocked.
        >
        > This means that the way the sprint planning session is conducted
        will have to be adjusted.
        > Right now, the team will not be able to sit in a room and
        decompose these tasks in one
        > planning session. I am leaning towards having a pre-planning
        session. Where the team
        > assigns "homework" to themselves, to come prepared for the sprint
        planning session for
        > the purpose of coming up with a sprint backlog and a commitment.
        Over time, as the
        > team becomes more experienced, I think that this will get better.
        >
        > I'd love to hear some thoughts of some of those who've been in
        this situation before.
        >
        > Andre
        >
      • Pierre Mengal
        (dawn gmail that don t let me reduce the quote...) Hi Andre, I m wondering why you say TDD is nearly impossible ? You should reconsider this. Pierre On Nov
        Message 3 of 13 , Nov 29, 2007
        • 0 Attachment
          (dawn gmail that don't let me reduce the quote...)
           
          Hi Andre,
           
          I'm wondering why you say "TDD is nearly impossible" ?
           
          You should reconsider this.
           
          Pierre

          On Nov 29, 2007 9:13 AM, andre_simones <scrumdevelopment@...> wrote:

          We are currently in the midst of implementing Scrum on a pretty large project. Below are
          some of the disadvantages we are experiencing now.

          - The code base is about 10 years old and is pretty big.
          - All of the original developers are gone. The majority of the developers have been
          working on the project less than a year.
          - The entire QA team is comprised of new hires, many only 2-3 months tenured. Many of
          them are new to QA.
          - The full functionality of the product is not fully understood by anyone.
          - The poor quality of the code is profound. TDD is nearly impossible, and a re-
          architecture is inevitable (but this is down the road), as the code base is PowerBuilder
          (wow, its hard to find PowerBuilder resources).

          The list goes on, but these are the key points that impact the Sprint Planning session.

          It took a while, but we found a strong product owner who created a prioritized product
          backlog. After this, we attempted to have a sprint planning session. It was pretty painful.
          In my previous teams, the team members were all very knowledgeable about the code
          base and its functionality. In addition, the code was structured pretty well, so the PBL
          could be decomposed relatively easily in one sitting.

          In this sprint planning session, the team thought of decomposing these features (stories)
          into 16 hour or less tasks as a ridiculous notion. They kept saying that they would have to
          perform analysis to do this decomposition. They absolutely had no clue how to
          decompose.

          I was deeply troubled after this. A long conversation with one of the senior engineers
          (who is pro-scrum) revealed that the extreme poor code quality requires analysis of the
          current code to occur to decompose. As an example, there was one feature that was
          estimated at about 50 hours. I asked the engineer to decompose this into smaller pieces.
          That decomposition took almost a full day. Wow. I was shocked.

          This means that the way the sprint planning session is conducted will have to be adjusted.
          Right now, the team will not be able to sit in a room and decompose these tasks in one
          planning session. I am leaning towards having a pre-planning session. Where the team
          assigns "homework" to themselves, to come prepared for the sprint planning session for
          the purpose of coming up with a sprint backlog and a commitment. Over time, as the
          team becomes more experienced, I think that this will get better.

          I'd love to hear some thoughts of some of those who've been in this situation before.

          Andre


        • George Dinwiddie
          ... I think your current strategy of spending a day analyzing stories is probably a good one, given the circumstances. If possible, I would do that analysis
          Message 4 of 13 , Nov 29, 2007
          • 0 Attachment
            andre_simones wrote:
            > We are currently in the midst of implementing Scrum on a pretty large project. Below are
            > some of the disadvantages we are experiencing now.
            >
            > - The code base is about 10 years old and is pretty big.
            > - All of the original developers are gone. The majority of the developers have been
            > working on the project less than a year.
            > - The entire QA team is comprised of new hires, many only 2-3 months tenured. Many of
            > them are new to QA.
            > - The full functionality of the product is not fully understood by anyone.
            > - The poor quality of the code is profound. TDD is nearly impossible, and a re-
            > architecture is inevitable (but this is down the road), as the code base is PowerBuilder
            > (wow, its hard to find PowerBuilder resources).
            >
            > The list goes on, but these are the key points that impact the Sprint Planning session.

            I think your current strategy of spending a day analyzing stories is
            probably a good one, given the circumstances. If possible, I would do
            that analysis in groups (one group, or several small groups that are
            arranged differently each sprint). This will help prevent the analyzer
            getting "stuck," will help spread the knowledge that is uncovered, and
            will enable people to give each other moral support on a discouraging task.

            As with any legacy project, I would first work to get the code under
            *some sort* of tests to guard against gross breakage. This will allow
            the code to be refactored, slowly, to make it easier to work with.
            Sticking with a Big Ball Of Mud is not generally feasible if you want to
            continue development.

            I agree with Pierre--don't write off TDD. I don't know Powerbuilder,
            but I know that people have figured out how to TDD almost anything. It
            may not be easy or pretty, but I think it's likely possible.

            Whatever you do, do NOT expect velocity to be very high. You've got a
            small band of developers/testers who have been given an extraordinarily
            difficult task and asked them to be heros. The odds against them are
            extremely high. Schedule pressure will only make it higher.

            Instead, focus on teambuilding and successes. Watch carefully, and
            applaud the small successes. (Diana Larsen gave an excellent session on
            Appreciative Leadership at this year's AYE Conference. Be especially
            supportive. Allow plenty of time for learning and skill building.

            Build up the team, and the team will take care of the velocity. If
            *you* focus on the velocity, you'll likely get nowhere.

            Good luck with this. If things go well, it will get better over time.
            The changes will be imperceptible at first, but one day you'll look back
            and be surprised at how far you've come. (Keep some artifacts to bring
            out on that day to remind people where the project started.)

            - George

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • William Wake
            ... Treasure that! ... I don t think this is an uncommon reaction even in with fairly experienced people and a decent codebase. Sounds like you re fighting
            Message 5 of 13 , Nov 29, 2007
            • 0 Attachment
              On Nov 29, 2007 3:13 AM, andre_simones <scrumdevelopment@...> wrote:
              > We are currently in the midst of implementing Scrum on a pretty large
              > project. Below are
              > some of the disadvantages we are experiencing now. [nasty list omitted:)]
              > It took a while, but we found a strong product owner who created a
              > prioritized product backlog.
              Treasure that!

              > In this sprint planning session, the team thought of decomposing these
              > features (stories) into 16 hour or less tasks as a ridiculous notion. They
              > kept saying that they would have to perform analysis to do this decomposition.
              > They absolutely had no clue how to decompose.

              I don't think this is an uncommon reaction even in with fairly
              experienced people and a decent codebase. Sounds like you're fighting
              both that and real ignorance of where things go & how they fit in.

              > I was deeply troubled after this. A long conversation with one of the senior
              > engineers (who is pro-scrum) revealed that the extreme poor code quality requires
              > analysis of the current code to occur to decompose. As an example, there was one
              > feature that was estimated at about 50 hours. I asked the engineer to decompose
              > this into smaller pieces. That decomposition took almost a full day. Wow. I was shocked.

              Are they all this bad?

              One of the things not emphasized is that there often is a bit of
              feed-forward/anticipatory work for the next iteration. I think Mike
              Cohn speaks of "5% for the future" (e.g., ~2 hrs/week/person). (Though
              I don't normally expect this to be an 8-hour chunk:) It may be that
              the challenges you have necessitate a higher number.

              What I'd anticipate is that as you go into each area for the first
              time, you might have to pay for some bigger exploration (perhaps as
              somebody else suggested, in the form of a spike). But I'd hope that
              some of this would ease up over time.

              > This means that the way the sprint planning session is conducted will have
              > to be adjusted. Right now, the team will not be able to sit in a room and
              > decompose these tasks in one planning session. I am leaning towards
              > having a pre-planning session. Where the team assigns "homework" to
              > themselves, to come prepared for the sprint planning session for
              > the purpose of coming up with a sprint backlog and a commitment. Over time,
              > as the team becomes more experienced, I think that this will get better.

              I think that's true (that they need some time to think about next
              sprint). If the stories are reasonably well understood, you might be
              able to forgo a specific meeting and just have some stories that are
              "background research for ____", timeboxed, fed into the current
              sprint.

              In general I think teams are better off with a little ramp-up where
              they understand the stories that are coming next. (That's not always
              possible.) This can allow some of that pre-work to happen in "between"
              times.

              The amount of prep your team required (in at least that one case) does
              seem excessive though, and I'd guard against letting that dominate
              your process. Timebox the investigation work with "not quite enough"
              time. (You don't want to develop some two-cycle waterfall process -
              spend the investigation work only on "risky"/"big"/"spooky" stories
              that need it.)

              Recognize that sometimes you'll task out a story one way, and find out
              that you need to change the tasks once you get into it. That's ok -
              the team is committing to the stories, not the particular tasks.
              Rarely, the team will dramatically under-estimate something severely
              enought that the sprint warrants canceling. Again, that's ok. (Not
              every sprint though:)

              You want to see the team operate on the edge a little bit, not moving
              tentatively out of a fear that they must have a perfect design, a
              perfect task plan, and perfect estimates or else the sprint planning
              is worthless.

              Good luck!
              --
              Bill Wake William.Wake@... www.xp123.com
            • woynam
              Check out Working Effectively with Legacy Code by Michael Feathers. Mark ... large project. Below are ... developers have been ... tenured. Many of ...
              Message 6 of 13 , Nov 29, 2007
              • 0 Attachment
                Check out "Working Effectively with Legacy Code" by Michael Feathers.

                Mark


                --- In scrumdevelopment@yahoogroups.com, "andre_simones"
                <scrumdevelopment@...> wrote:
                >
                > We are currently in the midst of implementing Scrum on a pretty
                large project. Below are
                > some of the disadvantages we are experiencing now.
                >
                > - The code base is about 10 years old and is pretty big.
                > - All of the original developers are gone. The majority of the
                developers have been
                > working on the project less than a year.
                > - The entire QA team is comprised of new hires, many only 2-3 months
                tenured. Many of
                > them are new to QA.
                > - The full functionality of the product is not fully understood by
                anyone.
                > - The poor quality of the code is profound. TDD is nearly
                impossible, and a re-
                > architecture is inevitable (but this is down the road), as the code
                base is PowerBuilder
                > (wow, its hard to find PowerBuilder resources).
                >
                > The list goes on, but these are the key points that impact the
                Sprint Planning session.
                >
                > It took a while, but we found a strong product owner who created a
                prioritized product
                > backlog. After this, we attempted to have a sprint planning
                session. It was pretty painful.
                > In my previous teams, the team members were all very knowledgeable
                about the code
                > base and its functionality. In addition, the code was structured
                pretty well, so the PBL
                > could be decomposed relatively easily in one sitting.
                >
                > In this sprint planning session, the team thought of decomposing
                these features (stories)
                > into 16 hour or less tasks as a ridiculous notion. They kept saying
                that they would have to
                > perform analysis to do this decomposition. They absolutely had no
                clue how to
                > decompose.
                >
                > I was deeply troubled after this. A long conversation with one of
                the senior engineers
                > (who is pro-scrum) revealed that the extreme poor code quality
                requires analysis of the
                > current code to occur to decompose. As an example, there was one
                feature that was
                > estimated at about 50 hours. I asked the engineer to decompose this
                into smaller pieces.
                > That decomposition took almost a full day. Wow. I was shocked.
                >
                > This means that the way the sprint planning session is conducted
                will have to be adjusted.
                > Right now, the team will not be able to sit in a room and decompose
                these tasks in one
                > planning session. I am leaning towards having a pre-planning
                session. Where the team
                > assigns "homework" to themselves, to come prepared for the sprint
                planning session for
                > the purpose of coming up with a sprint backlog and a commitment.
                Over time, as the
                > team becomes more experienced, I think that this will get better.
                >
                > I'd love to hear some thoughts of some of those who've been in this
                situation before.
                >
                > Andre
                >
              • andre_simones
                I didn t. But that is definitely something that should be pursued. Another additional piece to this is how the feature is described. There is a spec that
                Message 7 of 13 , Nov 29, 2007
                • 0 Attachment
                  I didn't. But that is definitely something that should be pursued. Another additional piece
                  to this is how the feature is described. There is a "spec" that is attached to each feature.
                  Many times, this spec is very verbose, and yet vague. It transitions from "what" to do to
                  "how" to do it somewhat randomly. So, there isn't a real solid understanding of what
                  should be built from the customer perspective. We'll have to rely on lots of conversations
                  for a full understanding.

                  I "think" that at times the complexity and loose understanding of the requirement will
                  make spikes difficult to practice, however, I think that this would still be very valuable.
                  Thank you for asking this question!


                  --- In scrumdevelopment@yahoogroups.com, "Andreas Thiel" <andreas.thiel@...> wrote:
                  >
                  > Hi Andre,
                  >
                  > as it's often the case, Scrum makes problems just visible - Scrum
                  > itself is not the problem.
                  >
                  > I would let the team go through this painful phase. By and by the
                  > decomposition will go smoother. Without decomposition your sprint
                  > planning will remain meaningless.
                  >
                  > Did you think about spikes to improve the estimations and the
                  > knowledge about the code base?
                  >
                  > Regards,
                  > Andreas
                  >
                  > --- In scrumdevelopment@yahoogroups.com, "andre_simones"
                  > <scrumdevelopment@> wrote:
                  > >
                  > > We are currently in the midst of implementing Scrum on a pretty
                  > large project. Below are
                  > > some of the disadvantages we are experiencing now.
                  > >
                  > > - The code base is about 10 years old and is pretty big.
                  > > - All of the original developers are gone. The majority of the
                  > developers have been
                  > > working on the project less than a year.
                  > > - The entire QA team is comprised of new hires, many only 2-3
                  > months tenured. Many of
                  > > them are new to QA.
                  > > - The full functionality of the product is not fully understood by
                  > anyone.
                  > > - The poor quality of the code is profound. TDD is nearly
                  > impossible, and a re-
                  > > architecture is inevitable (but this is down the road), as the
                  > code base is PowerBuilder
                  > > (wow, its hard to find PowerBuilder resources).
                  > >
                  > > The list goes on, but these are the key points that impact the
                  > Sprint Planning session.
                  > >
                  > > It took a while, but we found a strong product owner who created a
                  > prioritized product
                  > > backlog. After this, we attempted to have a sprint planning
                  > session. It was pretty painful.
                  > > In my previous teams, the team members were all very knowledgeable
                  > about the code
                  > > base and its functionality. In addition, the code was structured
                  > pretty well, so the PBL
                  > > could be decomposed relatively easily in one sitting.
                  > >
                  > > In this sprint planning session, the team thought of decomposing
                  > these features (stories)
                  > > into 16 hour or less tasks as a ridiculous notion. They kept
                  > saying that they would have to
                  > > perform analysis to do this decomposition. They absolutely had no
                  > clue how to
                  > > decompose.
                  > >
                  > > I was deeply troubled after this. A long conversation with one of
                  > the senior engineers
                  > > (who is pro-scrum) revealed that the extreme poor code quality
                  > requires analysis of the
                  > > current code to occur to decompose. As an example, there was one
                  > feature that was
                  > > estimated at about 50 hours. I asked the engineer to decompose
                  > this into smaller pieces.
                  > > That decomposition took almost a full day. Wow. I was shocked.
                  > >
                  > > This means that the way the sprint planning session is conducted
                  > will have to be adjusted.
                  > > Right now, the team will not be able to sit in a room and
                  > decompose these tasks in one
                  > > planning session. I am leaning towards having a pre-planning
                  > session. Where the team
                  > > assigns "homework" to themselves, to come prepared for the sprint
                  > planning session for
                  > > the purpose of coming up with a sprint backlog and a commitment.
                  > Over time, as the
                  > > team becomes more experienced, I think that this will get better.
                  > >
                  > > I'd love to hear some thoughts of some of those who've been in
                  > this situation before.
                  > >
                  > > Andre
                  > >
                  >
                • Roy Morien
                  The fact of life seems to be that your specs are verbose and vague. So? How is that different to most specs ? It just seems to me that you grab each spec
                  Message 8 of 13 , Nov 29, 2007
                  • 0 Attachment
                    The fact of life seems to be that your 'specs' are verbose and vague. So? How is that different to most 'specs'?

                    It just seems to me that you grab each 'spec' and focus on it, have whatever conversations you need to clarify the situation, tease out some realistic user stories, then start the usual agile cycle of including them in the Product Backlog, prioritese them, select them into the Sprint Backlog when appropriate, and ... the rest can be history. One by One, sprint by sprint, day by day ...

                    This, no doubt, will be a hard slog ... but when you are up to you a**e in alligators, as the saying goes, .... hmmm ... not sure what next, except to just say you have a hard, probably slow, slog ahead of you, that must be taken step-by-step ... start at the beginning, proceed through the middle, to ultimately arrive at the end. Scrum is not going to guarantee success, but it does provide you with a way to go about untangling your tangle, more successfully than trying to do BSUF (variously meaning Big Solution UP Front, and BullS**t Up Front :)
                     
                    Regards,
                    Roy Morien


                    To: scrumdevelopment@yahoogroups.com
                    From: scrumdevelopment@...
                    Date: Thu, 29 Nov 2007 17:07:08 +0000
                    Subject: [scrumdevelopment] Re: Sprint Planning Strategy for Disadvantaged Team

                    I didn't. But that is definitely something that should be pursued. Another additional piece
                    to this is how the feature is described. There is a "spec" that is attached to each feature.
                    Many times, this spec is very verbose, and yet vague. It transitions from "what" to do to
                    "how" to do it somewhat randomly. So, there isn't a real solid understanding of what
                    should be built from the customer perspective. We'll have to rely on lots of conversations
                    for a full understanding.

                    I "think" that at times the complexity and loose understanding of the requirement will
                    make spikes difficult to practice, however, I think that this would still be very valuable.
                    Thank you for asking this question!

                    --- In scrumdevelopment@ yahoogroups. com, "Andreas Thiel" <andreas.thiel@ ...> wrote:
                    >
                    > Hi Andre,
                    >
                    > as it's often the case, Scrum makes problems just visible - Scrum
                    > itself is not the problem.
                    >
                    > I would let the team go through this painful phase. By and by the
                    > decomposition will go smoother. Without decomposition your sprint
                    > planning will remain meaningless.
                    >
                    > Did you think about spikes to improve the estimations and the
                    > knowledge about the code base?
                    >
                    > Regards,
                    > Andreas
                    >
                    > --- In scrumdevelopment@ yahoogroups. com, "andre_simones"
                    > <scrumdevelopment@ > wrote:
                    > >
                    > > We are currently in the midst of implementing Scrum on a pretty
                    > large project. Below are
                    > > some of the disadvantages we are experiencing now.
                    > >
                    > > - The code base is about 10 years old and is pretty big.
                    > > - All of the original developers are gone. The majority of the
                    > developers have been
                    > > working on the project less than a year.
                    > > - The entire QA team is comprised of new hires, many only 2-3
                    > months tenured. Many of
                    > > them are new to QA.
                    > > - The full functionality of the product is not fully understood by
                    > anyone.
                    > > - The poor quality of the code is profound. TDD is nearly
                    > impossible, and a re-
                    > > architecture is inevitable (but this is down the road), as the
                    > code base is PowerBuilder
                    > > (wow, its hard to find PowerBuilder resources).
                    > >
                    > > The list goes on, but these are the key points that impact the
                    > Sprint Planning session.
                    > >
                    > > It took a while, but we found a strong product owner who created a
                    > prioritized product
                    > > backlog. After this, we attempted to have a sprint planning
                    > session. It was pretty painful.
                    > > In my previous teams, the team members were all very knowledgeable
                    > about the code
                    > > base and its functionality. In addition, the code was structured
                    > pretty well, so the PBL
                    > > could be decomposed relatively easily in one sitting.
                    > >
                    > > In this sprint planning session, the team thought of decomposing
                    > these features (stories)
                    > > into 16 hour or less tasks as a ridiculous notion. They kept
                    > saying that they would have to
                    > > perform analysis to do this decomposition. They absolutely had no
                    > clue how to
                    > > decompose.
                    > >
                    > > I was deeply troubled after this. A long conversation with one of
                    > the senior engineers
                    > > (who is pro-scrum) revealed that the extreme poor code quality
                    > requires analysis of the
                    > > current code to occur to decompose. As an example, there was one
                    > feature that was
                    > > estimated at about 50 hours. I asked the engineer to decompose
                    > this into smaller pieces.
                    > > That decomposition took almost a full day. Wow. I was shocked.
                    > >
                    > > This means that the way the sprint planning session is conducted
                    > will have to be adjusted.
                    > > Right now, the team will not be able to sit in a room and
                    > decompose these tasks in one
                    > > planning session. I am leaning towards having a pre-planning
                    > session. Where the team
                    > > assigns "homework" to themselves, to come prepared for the sprint
                    > planning session for
                    > > the purpose of coming up with a sprint backlog and a commitment.
                    > Over time, as the
                    > > team becomes more experienced, I think that this will get better.
                    > >
                    > > I'd love to hear some thoughts of some of those who've been in
                    > this situation before.
                    > >
                    > > Andre
                    > >
                    >




                    Check our comprehensive Salary Centre Overpaid or Underpaid?
                  • Andreas Thiel
                    Hi Andre, conversations about requirements are definitely a good thing. Why capture requirements in form of vague specs ? If the specs are vague, you might
                    Message 9 of 13 , Nov 30, 2007
                    • 0 Attachment
                      Hi Andre,

                      conversations about requirements are definitely a good thing. Why
                      capture requirements in form of vague "specs"? If the specs are
                      vague, you might take adavantages by taking a look at acceptance
                      tests (e.g. with FIT/FitNesse). These are "executable" requirements,
                      understandable by business folks.

                      Perhaps the granularity of your "features" is an issue, too. Too
                      coarse grained reqs make it hard to grasp and implement them in a
                      single iteration. Did you take a look at user stories (I'd recommend
                      Mike Cohn's definitive book for that)?

                      Regards,
                      Andreas

                      > > Did you think about spikes to improve the estimations and the
                      > > knowledge about the code base?
                      >
                      > I didn't. But that is definitely something that should be
                      pursued. Another additional piece
                      > to this is how the feature is described. There is a "spec" that
                      is attached to each feature.
                      > Many times, this spec is very verbose, and yet vague. It
                      transitions from "what" to do to
                      > "how" to do it somewhat randomly. So, there isn't a real solid
                      understanding of what
                      > should be built from the customer perspective. We'll have to rely
                      on lots of conversations
                      > for a full understanding.
                      >
                      > I "think" that at times the complexity and loose understanding of
                      the requirement will
                      > make spikes difficult to practice, however, I think that this
                      would still be very valuable.
                      > Thank you for asking this question!
                      >
                      >
                    • scrum yahoo
                      Our goal is to transition to user stories. I used them on my previous projects. I think we are now at a point where can start talking about transitioning.
                      Message 10 of 13 , Nov 30, 2007
                      • 0 Attachment
                        Our goal is to transition to user stories.  I used them on my previous projects.

                        I think we are now at a point where can start talking about transitioning.  This will be a
                        long road, however.  We have a big bucket of specs that have been written over the last
                        year (or two, maybe three), and most of the people who wrote the specs are gone.

                        Thanks for bringing up FIT..this is something that has been in the back of my mind that
                        needs to be at the forefront...

                        This will be FUN!!



                        On 11/30/07, Andreas Thiel <andreas.thiel@...> wrote:

                        Hi Andre,

                        conversations about requirements are definitely a good thing. Why
                        capture requirements in form of vague "specs"? If the specs are
                        vague, you might take adavantages by taking a look at acceptance
                        tests (e.g. with FIT/FitNesse). These are "executable" requirements,
                        understandable by business folks.

                        Perhaps the granularity of your "features" is an issue, too. Too
                        coarse grained reqs make it hard to grasp and implement them in a
                        single iteration. Did you take a look at user stories (I'd recommend
                        Mike Cohn's definitive book for that)?

                        Regards,
                        Andreas

                        > > Did you think about spikes to improve the estimations and the
                        > > knowledge about the code base?
                        >
                        > I didn't. But that is definitely something that should be
                        pursued. Another additional piece
                        > to this is how the feature is described. There is a "spec" that
                        is attached to each feature.
                        > Many times, this spec is very verbose, and yet vague. It
                        transitions from "what" to do to
                        > "how" to do it somewhat randomly. So, there isn't a real solid
                        understanding of what
                        > should be built from the customer perspective. We'll have to rely
                        on lots of conversations
                        > for a full understanding.
                        >
                        > I "think" that at times the complexity and loose understanding of
                        the requirement will
                        > make spikes difficult to practice, however, I think that this
                        would still be very valuable.
                        > Thank you for asking this question!
                        >
                        >


                      • Jeff Myers
                        This sounds like a perfect situation for Sprint 0, Your first sprint should be all about understanding the project/code. You don t mention your sprint duration
                        Message 11 of 13 , Dec 3, 2007
                        • 0 Attachment
                          This sounds like a perfect situation for Sprint 0,
                           
                          Your first sprint should be all about understanding the project/code.
                           
                          You don't mention your sprint duration but I don't think that really matters in this instance.
                           
                          you also don't mention the actual number of team members. 
                           
                          If this was my team/project I would sit down on the first day and try and break the project down into areas, you don't describe the product bu I am going to make the assumption that the functionality can be broken down into at least 5 general areas.
                           
                          Depending on team size I would try to put two people on every section for the deconstruction, pairing senior developer with Jr developers or QA.
                           
                          Target being that at the end of the Scrum the team has an understanding of the existing code and will know how to develop the rest of the plan.
                           
                          I know this is massively oversimplified but I don't know how you can have a meaningful conversation with the Project Owner about schedule until this step is taken.
                           
                          jeff

                           
                          On 11/29/07, andre_simones <scrumdevelopment@...> wrote:

                          We are currently in the midst of implementing Scrum on a pretty large project. Below are
                          some of the disadvantages we are experiencing now.

                          - The code base is about 10 years old and is pretty big.
                          - All of the original developers are gone. The majority of the developers have been
                          working on the project less than a year.
                          - The entire QA team is comprised of new hires, many only 2-3 months tenured. Many of
                          them are new to QA.
                          - The full functionality of the product is not fully understood by anyone.
                          - The poor quality of the code is profound. TDD is nearly impossible, and a re-
                          architecture is inevitable (but this is down the road), as the code base is PowerBuilder
                          (wow, its hard to find PowerBuilder resources).

                          The list goes on, but these are the key points that impact the Sprint Planning session.

                          It took a while, but we found a strong product owner who created a prioritized product
                          backlog. After this, we attempted to have a sprint planning session. It was pretty painful.
                          In my previous teams, the team members were all very knowledgeable about the code
                          base and its functionality. In addition, the code was structured pretty well, so the PBL
                          could be decomposed relatively easily in one sitting.

                          In this sprint planning session, the team thought of decomposing these features (stories)
                          into 16 hour or less tasks as a ridiculous notion. They kept saying that they would have to
                          perform analysis to do this decomposition. They absolutely had no clue how to
                          decompose.

                          I was deeply troubled after this. A long conversation with one of the senior engineers
                          (who is pro-scrum) revealed that the extreme poor code quality requires analysis of the
                          current code to occur to decompose. As an example, there was one feature that was
                          estimated at about 50 hours. I asked the engineer to decompose this into smaller pieces.
                          That decomposition took almost a full day. Wow. I was shocked.

                          This means that the way the sprint planning session is conducted will have to be adjusted.
                          Right now, the team will not be able to sit in a room and decompose these tasks in one
                          planning session. I am leaning towards having a pre-planning session. Where the team
                          assigns "homework" to themselves, to come prepared for the sprint planning session for
                          the purpose of coming up with a sprint backlog and a commitment. Over time, as the
                          team becomes more experienced, I think that this will get better.

                          I'd love to hear some thoughts of some of those who've been in this situation before.

                          Andre


                        • David A Barrett
                          One of the basic ideas of Agile is that you put off doing things you don t need to do until you really need to do them. So I wouldn t embark on any pre-project
                          Message 12 of 13 , Dec 4, 2007
                          • 0 Attachment
                            One of the basic ideas of Agile is that you put off doing things you don't
                            need to do until you really need to do them.

                            So I wouldn't embark on any pre-project to learn all about the existing
                            code before you start.

                            Chances are, at the beginning the choices between including this high
                            priority item, or that critical item aren't going to be particularly
                            profound. It will follow that the estimates aren't going to be a crucial
                            element in prioritizing. No one will care if the 50 hour item breaks down
                            into 8 tasks averaging 6 hours or 4 averaging 11 or whatever. Put some
                            ballpark numbers up just so you can get an idea how big a bite you think
                            you can take in Sprint 1.

                            The idea is that as you go along, you'll get a better feel for what it
                            takes. The programmers will get more familiar with the system and the
                            estimating will get faster, easier and more accurate. By the time anyone
                            really starts to care about the estimates, they'll be good enough. At the
                            beginning though, the best thing for the Team is produce something.
                            Anything. Even the wrong thing, as long as it's well done, complete,
                            tested and potentially implementable.

                            If they're producing stuff, then they're not disavantaged any more.


                            Dave Barrett,
                            Lawyers' Professional Indemnity Company
                          • Martin Schapendonk
                            ... Is the team aware of the fact that an estimate is just... an estimate? No harm is done if it turns out to be wrong, but the team will learn to better
                            Message 13 of 13 , Dec 5, 2007
                            • 0 Attachment
                              On 11/29/07, andre_simones <scrumdevelopment@...> wrote:
                              > I was deeply troubled after this. A long conversation with one of the senior engineers
                              > (who is pro-scrum) revealed that the extreme poor code quality requires analysis of the
                              > current code to occur to decompose. As an example, there was one feature that was
                              > estimated at about 50 hours. I asked the engineer to decompose this into smaller pieces.
                              > That decomposition took almost a full day. Wow. I was shocked.

                              Is the team aware of the fact that an estimate is just... an estimate?
                              No harm is done if it turns out to be wrong, but the team will learn
                              to better estimate next time.

                              Have you considered using story points? These funny
                              estimating-thingies are especially useful when it's hard to imagine
                              every task upfront. Read Mike Cohn's book "Agile Estimating and
                              Planning".

                              Basically, you look at the product backlog and pick one of the
                              smallest stories. Let's call that 2 story points. All other stories
                              also get point values: if it seems twice as big, it's 4 points. Rule
                              of thumb is: the larger the story, the less precise the estimate.
                              Therefore, use for example the Fibonacci sequence to estimate stories
                              (1, 2, 3, 5, 8, 13, 21, 34, etc..).

                              The advantage is that you don't have to think of tasks and hours, just
                              "how big do we think this is".

                              The first Sprints the team may find out that it over- or
                              under-committed, but this will level out as they learn to know the
                              system, the code base, the product owner, etc...

                              Hope this is of any use to you.

                              Regards,
                              Martin

                              --
                              Martin Schapendonk, martin@...
                            Your message has been successfully submitted and would be delivered to recipients shortly.