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

Re: [scrumdevelopment] Team member doesn't see value in index card approach

Expand Messages
  • mpkirby
    ... One of the things we ve started doing at the start of a release is re-establishing team norms. We ve got 30 people and the scrum teams change somewhat
    Message 1 of 24 , Mar 30 4:15 AM
    • 0 Attachment
      Bil Simser wrote:
      >
      > So he stands alone in his view in the team but that's not a good thing.
      > However I'm not about to ditch the whole thing as everyone else feels it has
      > value, the one team member just considers it a nuisance and says its causing
      > him to be feel like he's wasting his time which makes me feel like I have to
      > remove this impediment but not sure how.
      >
      >
      >
      > Just wondering if anyone else has had similar issues and how they dealt with
      > it?
      >
      >

      One of the things we've started doing at the start of a release is
      re-establishing team norms. We've got 30 people and the scrum teams
      change somewhat each release depending on the feature content.

      What we have found is that if you give the team a chance to be "vocal"
      about what their norms are, then often the lone programmers who don't
      want to conform will conform because of Peer pressure. But you need the
      peer walking up to him and saying "Come on buddy. We've all got to do
      things we don't like for the good of the team."

      If that doesn't work, don't let the team ostracize him (right away).
      Then you have a talk with him at a management level (I'm assuming you
      are the manager). If that doesn't work a friendly conversation with the
      next level management about what his goals are. Does he understand the
      vision of the organization. Does he need help in finding a place or job
      where the group is more aligned with his personal objectives.

      Team norms are really important to making a team run smoothly.

      Mike
    • Tobias Mayer
      Hi Bil, As you imply, having data in two places is always a bad idea. If I were a developer on that team, I would have a hard time with this too. Bob s
      Message 2 of 24 , Mar 30 4:57 AM
      • 0 Attachment
        Hi Bil,

        As you imply, having data in two places is always a bad idea.  If I were a developer on that team, I would have a hard time with this too.  Bob's suggestion of shielding the team from the electronic tool and having the SM update it is a good one, and one that I have used successfully too.  But sometimes the electronic alternative just isn't necessary; we only think it is because that's what we are used to.  It's part of the "that's just what we do here" syndrome.  So...

        > I don’t know if I can sell doing tasks without artifact tracking digitally.
        Can you say more about that?  Who are you "selling" to?

        Tobias

        PS thanks Ken, for inviting me back to this forum.  Good to be here.


        --- In scrumdevelopment@yahoogroups.com, "Bob Schatz" <bobschatz@...> wrote:
        >
        > Hi Bil,
        >
        > I love the task boards and see the difference in the team dynamics
        > when they use it in their daily Scrum. I really push teams to try
        > these and I can say that they ALL see the value in doing this.
        > Sometimes when the team does not do good sprint planning, they loose
        > the value in the tasks and therefore the board. It has to mean
        > something, and they have to own it. It's the same symptom as when a
        > team tells me that they're not having good daily scrums. I also think
        > the board serves as the information radiator for people outside the
        > team. It provides the visibility, transparency, and helps build trust.
        > So it goes way beyond the feelings of a single developer.
        >
        > Perhaps you might consider taking the responsibility for online update
        > away from the team and have the Scrum Master do that based on data
        > from the board. Now, for the team it's not a choice, or dual entry. I
        > have coached teams to do this in the past and it seems to work.
        >
        > I also sense that there are some additional undercurrents operating in
        > the case you've presented.
        >
        > Bob Schatz
        > Agile Infusion
        > www.agileinfusion.com
        >
        >
        > --- In scrumdevelopment@yahoogroups.com, Bil Simser bsimser@ wrote:
        > >
        > > Hi guys,
        > >
        > >
        > >
        > > I have a bit of a problem that a team member brought up today which I'm
        > > looking for some ideas on how to handle. His comment was that he
        > felt the
        > > index card approach of having tasks on the wall was a waste of time
        > and was
        > > just getting in his way.
        > >
        > >
        > >
        > > A little background. We're using Visual Studio Team System with the
        > > Conchango plug-in to track the work items, produce burndown charts,
        > etc. as
        > > it houses our source code as well. I also setup post-it notes on our
        > scrum
        > > wall for people to work from. Yes, it's redundant and dual-entry. If
        > someone
        > > grabs a task from the wall, they're supposed to enter the
        > information in TFS
        > > as well. I don't know if I can sell doing tasks without artifact
        > tracking
        > > digitally.
        > >
        > >
        > >
        > > As myself and another SM pointed out to the team member, the wall
        > was there
        > > for a purpose besides duplicating what was in TFS. It was a conversation
        > > piece. Our daily stand-ups take place around the wall, people grab a
        > sticky
        > > from the Not Started section and put it in play in the In Progress
        > section
        > > or move it along or drop it into the Done area. I'm a visual guy and
        > I can
        > > see over the course of the sprint how the stickies move from one
        > side to the
        > > other, and it's a team motivator (as a side note, at some point I
        > want to
        > > take daily pics of the wall and then have an animated view of it).
        > We also
        > > use it for looking at the immediate state of the project, although
        > the team
        > > member says he can look at TFS and get the same thing. I don't agree.
        > >
        > >
        > >
        > > So he stands alone in his view in the team but that's not a good thing.
        > > However I'm not about to ditch the whole thing as everyone else
        > feels it has
        > > value, the one team member just considers it a nuisance and says its
        > causing
        > > him to be feel like he's wasting his time which makes me feel like I
        > have to
        > > remove this impediment but not sure how.
        > >
        > >
        > >
        > > Just wondering if anyone else has had similar issues and how they
        > dealt with
        > > it?
        > >
        > >
        > >
        > > Thanks.
        > >
        >
      • Nicholas Cancelliere
        Ask this team member if all the right people can see the tasks in Visual Studio. Having your tasks and burndown on the wall provide visibility to * everyone*.
        Message 3 of 24 , Mar 30 5:38 AM
        • 0 Attachment
           
          Ask this team member if all the right people can see the tasks in Visual Studio.  Having your tasks and burndown on the wall provide visibility to everyone.  Anyone can wander in and observe where the team is at any given moment.  The goal here is transparency.
           
          I guess the question could be asked around the double entry - is that necessary?  Do you need to enter your tasks into Visual Studio if you already have them written on cards?  What's the advantage of having them written in Visual Studio?  (I already stated some possible advantages of the cards.)  If Visual Studio provides the same level of transparency as the physical cards on a wall - then great!
           
          I'd say if everyone who needs to know, and be in the known, has access to the tasks and burndown chart in Visual Studio - then maybe for your stand-up you just use a projector and project those stories out of Visual Studio onto the wall for queues in your discussion.
           
          Here's another idea.  Take the team into a different room for the stand-up -- away from their cards.  Have them use Visual Studio only.  See if they find it as easy to know where they are.  Then retrospect on that experience.
           
          Just some ideas.  If you're doing double entry it would feel to me like you're letting your tools and process get in the way of individuals and interactions.  Have the team examine why they are doing what they're doing and how does it help them organize and get their work done.  (Ie. is the benefit from doing the double entry worth it, and do team members feel it's a good and efficient practice?)  
           
          Personally I don't find anything useful with double entry - it always creates double the work.  I would either stick with the cards and ditch tasks in VS, or go with VS and ditch the cards.  Again it's a question of accessibility, transparency, etc.
           
           
          Nicholas


           
          On 3/29/07, Bil Simser <bsimser@...> wrote:

          Hi guys,

           

          I have a bit of a problem that a team member brought up today which I'm looking for some ideas on how to handle. His comment was that he felt the index card approach of having tasks on the wall was a waste of time and was just getting in his way.

           

          A little background. We're using Visual Studio Team System with the Conchango plug-in to track the work items, produce burndown charts, etc. as it houses our source code as well. I also setup post-it notes on our scrum wall for people to work from. Yes, it's redundant and dual-entry. If someone grabs a task from the wall, they're supposed to enter the information in TFS as well. I don't know if I can sell doing tasks without artifact tracking digitally.

           

          As myself and another SM pointed out to the team member, the wall was there for a purpose besides duplicating what was in TFS. It was a conversation piece. Our daily stand-ups take place around the wall, people grab a sticky from the Not Started section and put it in play in the In Progress section or move it along or drop it into the Done area. I'm a visual guy and I can see over the course of the sprint how the stickies move from one side to the other, and it's a team motivator (as a side note, at some point I want to take daily pics of the wall and then have an animated view of it). We also use it for looking at the immediate state of the project, although the team member says he can look at TFS and get the same thing. I don't agree.

           

          So he stands alone in his view in the team but that's not a good thing. However I'm not about to ditch the whole thing as everyone else feels it has value, the one team member just considers it a nuisance and says its causing him to be feel like he's wasting his time which makes me feel like I have to remove this impediment but not sure how.

           

          Just wondering if anyone else has had similar issues and how they dealt with it?

           

          Thanks.




          --
          Nicholas Cancelliere, Austin TX
          " Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." -- J.R.R. Tolkien
        • Bil Simser
          Tobias, Thanks for the info. As for the selling feature the environment is corporate and as such, if management has it s way (I m just the SM/Architect/mentor)
          Message 4 of 24 , Mar 30 5:53 AM
          • 0 Attachment
            Tobias,

            Thanks for the info. As for the selling feature the environment is
            corporate and as such, if management has it's way (I'm just the
            SM/Architect/mentor) they would have everyone enter their time
            tracking in 10 different systems and then fill out a spreadsheet to
            print off and submit.

            One of the biggest problems with an Agile approach to delivering
            software with Scrum (and this was identified by Uncle Bob at an
            Agile Universe a few years back) is that there's no empherical
            proof. Everyone on this list knows waterfall doesn't work, but we
            can't prove that Scrum does. We can cite examples and success
            stories, and there are many, but the hard proof isn't there.

            The place I'm at right now has heard about Agile, given me the
            ability to introduce Scrum (and other Agile practices, but mostly
            Scrum) in order to "be better at delivering software". The biggest
            challenge is that IS takes too long to deliver. I dont' think I'm
            going to solve that problem with Scrum, but at the very least I can
            show frequent inspection and value with what we are delivering, and
            along the way using TDD and other techniques we can improve quality.
            However all of this comes to evidence. To me, management wants to
            see project 1 delivered in traditional approach (waterfall-ish) and
            then same project delivered with same team using Scrum approach then
            measure success.

            Getting back to the original question about who am I selling a
            project completely managed by index cards alone, it's upper
            management. They cannot grasp tracking a project unless there's a
            spreadsheet, database, electronic tool, or whatever behind it. The
            idea of a bunch of post-it notes on a wall being the tracking
            mechism isn't something they can connect with. Hope that answers
            your question (and others might jump in to talk about things I've
            brought up about the enviroment here). It's not optimal and upper
            management doesn't quite get "it" (it being the use of Scrum to
            manage the delivery of software). They know what it is, they see the
            value, but they're still clinging to spreadsheets and databases and
            time tracking systems as they spit out weekly reports and discuss
            priorities of projects. An undertaking I'm looking to change, but
            it's a long journey.

            Okay, this is a little off topic with the original thread but a good
            conversation none the less.

            --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer"
            <tobyanon@...> wrote:
            >
            > Hi Bil,
            >
            > As you imply, having data in two places is always a bad idea. If
            I were
            > a developer on that team, I would have a hard time with this too.
            Bob's
            > suggestion of shielding the team from the electronic tool and
            having the
            > SM update it is a good one, and one that I have used successfully
            too.
            > But sometimes the electronic alternative just isn't necessary; we
            only
            > think it is because that's what we are used to. It's part of the
            > "that's just what we do here" syndrome. So...
            >
            > > I don’t know if I can sell doing tasks without artifact
            > tracking digitally.
            > Can you say more about that? Who are you "selling" to?
          • Nicholas Cancelliere
            There are a few comparison studies out there actually that show how a Waterfall team takes more people, more lines of code, and more time to produce few
            Message 5 of 24 , Mar 30 6:29 AM
            • 0 Attachment
              There are a few comparison studies out there actually that show how a
              Waterfall team takes more people, more lines of code, and more time to
              produce few features than a Scrum team that's got less members, less
              lines of code, in the same amount of time.

              You can find one in Mike Cohn's book I believe, I forget off hand
              which one.  I'll try to poke around today and find a PDF article I got
              floating around somewhere.

              Still at the end of the day a study isn't going to do much for you -
              except maybe thumb your nose at the managers who say "there is no
              proof it works," it's hard when you don't have full buy in from the
              top -- trust me I know.  :-)
               

              Nicholas



              On 3/30/07, Bil Simser <bsimser@...> wrote:
              >
              > The place I'm at right now has heard about Agile, given me the
              > ability to introduce Scrum (and other Agile practices, but mostly
              > Scrum) in order to "be better at delivering software". The biggest
              > challenge is that IS takes too long to deliver. I dont' think I'm
              > going to solve that problem with Scrum, but at the very least I can
              > show frequent inspection and value with what we are delivering, and
              > along the way using TDD and other techniques we can improve quality.
              > However all of this comes to evidence. To me, management wants to
              > see project 1 delivered in traditional approach (waterfall-ish) and
              > then same project delivered
            • dnicolet99
              ... I ve heard this sort of criticism many times, but I ve never - not once - heard *anyone* specify exactly what they would consider hard proof; not even
              Message 6 of 24 , Mar 30 7:50 AM
              • 0 Attachment
                --- In scrumdevelopment@yahoogroups.com, "Bil Simser" <bsimser@...>
                wrote:
                >
                > We can cite examples and success
                > stories, and there are many, but the hard proof isn't there.

                I've heard this sort of criticism many times, but I've never - not
                once - heard *anyone* specify exactly what they would consider "hard
                proof;" not even when I've asked them explicitly to explain what
                they are looking for, and held my pen at the ready to take notes.

                They *say* "hard proof" but they're really talking about their own
                personal subjective impressions. That is a hard barrier to cross.

                Ironically, the same people tend to overlook, ignore, or deny the
                mountains of statistical evidence that traditional (that is, non-
                agile) methods *don't* work. Given a historical success rate of
                waterfall-style SDLC methods in the range of 16% - 29%, one could
                expect better results by wagering the company on a single throw of
                craps.

                >
                >To me, management wants to
                > see project 1 delivered in traditional approach (waterfall-ish)
                and
                > then same project delivered with same team using Scrum approach
                then
                > measure success.

                To you - does that mean you're speculating about what management
                wants to see? Have you asked them what they want to see? If you're
                lucky, they don't even *know* what they want to see, and you can
                teach them what they ought to want to see, and then show it to
                them. ;-)

                At my previous employer we undertook a bottom-up introduction of
                agile methods in a traditional organization. Since there's no way to
                do a project two ways and compare apples to apples, the way we
                developed comparative data was to ask our customers to put in a
                formal request for each project with the traditional IT department,
                without mentioning that they already intended to have our group do
                the work. We then had the official bid from the IT department, which
                represented a best-case outcome based on their waterfall process. At
                the end of each agile project, we presented comparative results to
                management based on the IT department's *estimated* delivery
                compared with our *actual* delivery. Not exactly apples to apples,
                but credible.

                On average we delivered about nine times the *real* (financial)
                value as the IT department's *estimated* best-case result would have
                been. The single best comparison came out at 27 times the value. Our
                worst project, which had a number of difficulties throughout, still
                delivered about 4 times the value of the IT department's best
                estimate. A lot of that is "funny" numbers - avoidance of
                opportunity cost due to faster delivery, etc., but it's the kind of
                thing executives relate to. Maybe that sort of approach would work
                in your case, too.

                > Getting back to the original question about who am I selling a
                > project completely managed by index cards alone, it's upper
                > management. They cannot grasp tracking a project unless there's a
                > spreadsheet, database, electronic tool, or whatever behind it. The
                > idea of a bunch of post-it notes on a wall being the tracking
                > mechism isn't something they can connect with. Hope that answers
                > your question (and others might jump in to talk about things I've
                > brought up about the enviroment here). It's not optimal and upper
                > management doesn't quite get "it" (it being the use of Scrum to
                > manage the delivery of software). They know what it is, they see
                the
                > value, but they're still clinging to spreadsheets and databases
                and
                > time tracking systems as they spit out weekly reports and discuss
                > priorities of projects. An undertaking I'm looking to change, but
                > it's a long journey.

                Burndown charts and earned value charts can be produced with
                spreadsheet programs pretty easily. Part of your presentation to
                management should include the idea that tracking "time spent on
                tasks" is not relevant to this style of work, and doesn't actually
                give them any useful information. It may take some time to wean them
                from this sort of data.

                If they're concerned about visibility of project status, there are
                all kinds of tools to help with that. VSTS can hook up to
                SharePoint, if your company is a POM (Prisoner of Microsoft).
                Otherwise, there are free or cheap tools that function very well as
                information radiators, such as XPlanner, eXPlainPMT, or even Jira.
                It can be burdensome, but doesn't have to be.

                Dave
              • Michael Dobbins
                This is an interesting discussion. I see the value of having something physical to move around and interact with. I also see the value of keeping that info in
                Message 7 of 24 , Mar 30 8:14 AM
                • 0 Attachment
                  This is an interesting discussion.

                  I see the value of having something physical to move around and interact
                  with. I also see the value of keeping that info in digital form. I also
                  don't like duplication (update twice, keeping in sync problems.) How about a
                  tool and equipment where you can keep the information digital and project it
                  on the team wall for standup meetings and keeping it visible in the team
                  room through out the day. With the right drag and drop features it could
                  pretty well mimic the index card approach. It could also be usefull to keep
                  syncronization between members of a team not phyisically co-located and many
                  are trying to do.

                  mike
                • Christian Gruber
                  If management needs summaries for their weekly status, can you sell that you submit weekly roll-ups based on your own accumulation of daily data? In other
                  Message 8 of 24 , Mar 30 9:09 AM
                  • 0 Attachment
                    If management needs summaries for their weekly status, can you "sell"
                    that you submit weekly roll-ups based on your own accumulation of
                    daily data? In other words, the team is freed from extra data entry
                    - you're not maintaining duplicates, but you maintain only enough to
                    roll-up for their status on a project basis? Just look at what their
                    actual requirements are, avoiding for a moment their implementation
                    recommendations, as regards tracking and stats, and provide them
                    transparency in their final format.

                    One downside to this approach, regrettably, is that the data gathered
                    from a truly agile process wouldn't include the burn-up time-spent
                    data that managers traditionally like to see. If they extrapolate
                    from burn-down, there'll be a lot of "what the heck are you spending
                    time on?" conversations, because a 10 point task can become a 15
                    point task after three days in the queue, and these numbers, while
                    quite sane in a burn-down, can look entirely crazy to traditional
                    "burn-up" people.

                    Any suggestions for how to handle that (without doing the duplicate
                    time entry)?

                    Christian.

                    On Mar 30, 2007, at 8:53 AM, Bil Simser wrote:

                    > They know what it is, they see the
                    > value, but they're still clinging to spreadsheets and databases and
                    > time tracking systems as they spit out weekly reports and discuss
                    > priorities of projects.
                    christian gruber + cgruber@... + bus 905.640.1119 + mob
                    416.998.6023
                    process coach and architect + ISRÁFÍL CONSULTING SERVICES
                  • Nicholas Cancelliere
                    http://www.possibility.com/epowiki/Wiki.jsp?page=ProjectStatsOnWaterfallVsAgile There you go. It s one example - but that s the emperical evidence you might
                    Message 9 of 24 , Mar 30 10:29 AM
                    • 0 Attachment
                      http://www.possibility.com/epowiki/Wiki.jsp?page=ProjectStatsOnWaterfallVsAgile

                      There you go. It's one example - but that's the "emperical" evidence
                      you might be seeking. Again I don't know that this sort of approach
                      ever does good to convince anyone.

                      Good luck!
                      Nicholas

                      On 3/30/07, Nicholas Cancelliere <nickaustin74@...> wrote:
                      > There are a few comparison studies out there actually that show how a
                      > Waterfall team takes more people, more lines of code, and more time to
                      > produce few features than a Scrum team that's got less members, less
                      > lines of code, in the same amount of time.
                      >
                      > You can find one in Mike Cohn's book I believe, I forget off hand
                      > which one. I'll try to poke around today and find a PDF article I got
                      > floating around somewhere.
                      >
                      > Still at the end of the day a study isn't going to do much for you -
                      > except maybe thumb your nose at the managers who say "there is no
                      > proof it works," it's hard when you don't have full buy in from the
                      > top -- trust me I know. :-)
                      >
                      >
                      > Nicholas
                      >
                      >
                      >
                      > On 3/30/07, Bil Simser <bsimser@...> wrote:
                      > >
                      > > The place I'm at right now has heard about Agile, given me the
                      > > ability to introduce Scrum (and other Agile practices, but mostly
                      > > Scrum) in order to "be better at delivering software". The biggest
                      > > challenge is that IS takes too long to deliver. I dont' think I'm
                      > > going to solve that problem with Scrum, but at the very least I can
                      > > show frequent inspection and value with what we are delivering, and
                      > > along the way using TDD and other techniques we can improve quality.
                      > > However all of this comes to evidence. To me, management wants to
                      > > see project 1 delivered in traditional approach (waterfall-ish) and
                      > > then same project delivered


                      --
                      Nicholas Cancelliere, Austin TX
                      " Do not meddle in the affairs of Wizards, for they are subtle and
                      quick to anger." -- J.R.R. Tolkien
                    • Alan Dayley
                      ... This is a great idea and fits what you describe. http://cardmeeting.com/ However, I don t think it can be self-hosted yet. My work environment would not
                      Message 10 of 24 , Mar 30 10:48 AM
                      • 0 Attachment
                        On Fri, March 30, 2007 8:14 am, Michael Dobbins wrote:
                        > This is an interesting discussion.
                        >
                        > I see the value of having something physical to move around and interact
                        > with. I also see the value of keeping that info in digital form. I also
                        > don't like duplication (update twice, keeping in sync problems.) How about
                        > a
                        > tool and equipment where you can keep the information digital and project
                        > it
                        > on the team wall for standup meetings and keeping it visible in the team
                        > room through out the day. With the right drag and drop features it could
                        > pretty well mimic the index card approach. It could also be usefull to
                        > keep
                        > syncronization between members of a team not phyisically co-located and
                        > many
                        > are trying to do.
                        >
                        > mike

                        This is a great idea and fits what you describe. http://cardmeeting.com/

                        However, I don't think it can be self-hosted yet. My work environment
                        would not allow project data to be hosted offsite. I am watching this
                        project very attentively in the hope that it can eventually be hosted on
                        my own server.

                        Alan
                      • Aaron Korver
                        It seems to me that all of these suggestions above are practicing the Art of the Possible . If you haven t already done this exercise with the team, perhaps
                        Message 11 of 24 , Mar 30 2:25 PM
                        • 0 Attachment
                          It seems to me that all of these suggestions above are practicing the "Art of the Possible".  If you haven't already done this exercise with the team, perhaps it would be a good time for it?

                          Thanks,
                          Aaron Korver
                        • Mike Cohn
                          The example is given in User Stories Applied for Agile Software Development. The relevant comparison metrics are: waterfall team: up to 100 developers Scrum
                          Message 12 of 24 , Mar 30 3:17 PM
                          • 0 Attachment
                            The example is given in "User Stories Applied for Agile Software Development." The relevant comparison metrics are:

                            waterfall team: up to 100 developers
                            Scrum team with user stories: 6-12 people

                            Waterfall team: 540 person months
                            Scrum team: 54 person months

                            Waterfall team: 9 calendar months
                            Scrum team: 12 calendar months

                            Lines of code (for what they're worth):
                            Waterfall: 120 per developer-month
                            Scrum: 840 per developer-month

                            The waterfall application was never released and was completely scrapped. The Scrum project was done by a company that had purchased the company that had failed at the waterfall project. While the acquiring company owned the code, none of it was used. Two developers were familiar with Scrum. The project was done across three cities. 

                            This case study was presented at XP Agile Universe 2003. You can download the slides for that presentation from http://www.mountaingoatsoftware.com/presentation/access/36
                            The slides covering this case study start on page 63.

                            Regards,
                            Mike Cohn
                            Author:
                              Agile Estimating and Planning
                              User Stories Applied
                            www.mountaingoatsoftware.com


                            On Mar 30, 2007, at 7:29 AM, Nicholas Cancelliere wrote:


                            There are a few comparison studies out there actually that show how a
                            Waterfall team takes more people, more lines of code, and more time to
                            produce few features than a Scrum team that's got less members, less
                            lines of code, in the same amount of time.

                            You can find one in Mike Cohn's book I believe, I forget off hand
                            which one.  I'll try to poke around today and find a PDF article I got
                            floating around somewhere.

                            Still at the end of the day a study isn't going to do much for you -
                            except maybe thumb your nose at the managers who say "there is no
                            proof it works," it's hard when you don't have full buy in from the
                            top -- trust me I know.  :-)
                             

                            Nicholas



                            On 3/30/07, Bil Simser <bsimser@gmail.com> wrote:
                            >
                            > The place I'm at right now has heard about Agile, given me the
                            > ability to introduce Scrum (and other Agile practices, but mostly
                            > Scrum) in order to "be better at delivering software". The biggest
                            > challenge is that IS takes too long to deliver. I dont' think I'm
                            > going to solve that problem with Scrum, but at the very least I can
                            > show frequent inspection and value with what we are delivering, and
                            > along the way using TDD and other techniques we can improve quality.
                            > However all of this comes to evidence. To me, management wants to
                            > see project 1 delivered in traditional approach (waterfall-ish) and
                            > then same project delivered


                          • jay_conne
                            Hi Bob & Bill, I agree with you Bob on the dynamics of the Daily Scrum around the task board. I get my teams to commit to update the physical media no later
                            Message 13 of 24 , Mar 30 7:31 PM
                            • 0 Attachment
                              Hi Bob & Bill,

                              I agree with you Bob on the dynamics of the Daily Scrum around the
                              task board. I get my teams to commit to update the physical media no
                              later than 5 minutes before the stand-up. Then the talk in the
                              meeting is more focused - not about the updating. Like you do, I
                              updated the online form that did the calculating and charted the
                              burndown automatically, which then was posted for all to see.

                              I found that doubters were quick converts - the experience spoke for
                              itself. The interaction among the team members was contageous and
                              even engaged the introverts with an intereaction model they could
                              understand and value.

                              Jay
                              www.jconne.com

                              --- In scrumdevelopment@yahoogroups.com, "Bob Schatz" <bobschatz@...>
                              wrote:
                              >
                              > Hi Bill,
                              >
                              > I love the task boards and see the difference in the team dynamics
                              > when they use it in their daily Scrum. I really push teams to try
                              > these and I can say that they ALL see the value in doing this.
                              > Sometimes when the team does not do good sprint planning, they loose
                              > the value in the tasks and therefore the board. It has to mean
                              > something, and they have to own it. It's the same symptom as when a
                              > team tells me that they're not having good daily scrums. I also think
                              > the board serves as the information radiator for people outside the
                              > team. It provides the visibility, transparency, and helps build trust.
                              > So it goes way beyond the feelings of a single developer.
                              >
                              > Perhaps you might consider taking the responsibility for online update
                              > away from the team and have the Scrum Master do that based on data
                              > from the board. Now, for the team it's not a choice, or dual entry. I
                              > have coached teams to do this in the past and it seems to work.
                              >
                              > I also sense that there are some additional undercurrents operating in
                              > the case you've presented.
                              >
                              > Bob Schatz
                              > Agile Infusion
                              > www.agileinfusion.com
                              >
                              >
                              > --- In scrumdevelopment@yahoogroups.com, Bil Simser <bsimser@> wrote:
                              > >
                              > > Hi guys,
                              > >
                              > >
                              > >
                              > > I have a bit of a problem that a team member brought up today
                              which I'm
                              > > looking for some ideas on how to handle. His comment was that he
                              > felt the
                              > > index card approach of having tasks on the wall was a waste of time
                              > and was
                              > > just getting in his way.
                              > >
                              > >
                              > >
                              > > A little background. We're using Visual Studio Team System with the
                              > > Conchango plug-in to track the work items, produce burndown charts,
                              > etc. as
                              > > it houses our source code as well. I also setup post-it notes on our
                              > scrum
                              > > wall for people to work from. Yes, it's redundant and dual-entry. If
                              > someone
                              > > grabs a task from the wall, they're supposed to enter the
                              > information in TFS
                              > > as well. I don't know if I can sell doing tasks without artifact
                              > tracking
                              > > digitally.
                              > >
                              > >
                              > >
                              > > As myself and another SM pointed out to the team member, the wall
                              > was there
                              > > for a purpose besides duplicating what was in TFS. It was a
                              conversation
                              > > piece. Our daily stand-ups take place around the wall, people grab a
                              > sticky
                              > > from the Not Started section and put it in play in the In Progress
                              > section
                              > > or move it along or drop it into the Done area. I'm a visual guy and
                              > I can
                              > > see over the course of the sprint how the stickies move from one
                              > side to the
                              > > other, and it's a team motivator (as a side note, at some point I
                              > want to
                              > > take daily pics of the wall and then have an animated view of it).
                              > We also
                              > > use it for looking at the immediate state of the project, although
                              > the team
                              > > member says he can look at TFS and get the same thing. I don't agree.
                              > >
                              > >
                              > >
                              > > So he stands alone in his view in the team but that's not a good
                              thing.
                              > > However I'm not about to ditch the whole thing as everyone else
                              > feels it has
                              > > value, the one team member just considers it a nuisance and says its
                              > causing
                              > > him to be feel like he's wasting his time which makes me feel like I
                              > have to
                              > > remove this impediment but not sure how.
                              > >
                              > >
                              > >
                              > > Just wondering if anyone else has had similar issues and how they
                              > dealt with
                              > > it?
                              > >
                              > >
                              > >
                              > > Thanks.
                              > >
                              >
                            • Doug Swartz
                              ... Do you have good understanding of where he feels he is wasting his time? Is it really the cards he is objecting to? Or, is he objecting to the time taken
                              Message 14 of 24 , Mar 31 7:15 AM
                              • 0 Attachment
                                Thursday, March 29, 2007, 8:05:21 PM, Bil Simser wrote:

                                > So he stands alone in his view in the team but that's not a good thing.
                                > However I'm not about to ditch the whole thing as everyone else feels it has
                                > value, the one team member just considers it a nuisance and says its causing
                                > him to be feel like he's wasting his time which makes me feel like I have to
                                > remove this impediment but not sure how.

                                Do you have good understanding of where he feels he is wasting
                                his time? Is it really the cards he is objecting to? Or, is he
                                objecting to the time taken in the morning meeting itself?
                                Or...?

                                Unless you're doing something different than what I would
                                expect, I can't see how updating "his" cards on the wall would
                                take more than 5 minutes a day.

                                Perhaps he doesn't care about the big picture, and sees
                                spending time understanding where the rest of the team is, as
                                wasted time.

                                To remove his impediment, you might need to spend some more
                                time getting to the reasons "under the under", for his
                                objections.


                                --

                                Doug Swartz
                                daswartz@...
                              • Laurent Bossavit
                                Bill, ... Inspect and adapt. You could ask a few data questions: - whose time is being wasted by using index cards ? - how much time ? From what you wrote, I
                                Message 15 of 24 , Mar 31 7:20 AM
                                • 0 Attachment
                                  Bill,
                                  > I have a bit of a problem that a team member brought up today which
                                  > I’m looking for some ideas on how to handle. His comment was that
                                  > he felt the index card approach of having tasks on the wall was a
                                  > waste of time and was just getting in his way.
                                  Inspect and adapt. You could ask a few data questions:
                                  - whose time is being wasted by using index cards ?
                                  - how much time ?

                                  From what you wrote, I gather you agree that there is redundancy,
                                  yet your feeling is that this is well compensated by time savings in
                                  daily planning.

                                  You could always experiment. Use a stopwatch to time your planning
                                  sessions and stand-ups. Stop using the wall display and cards for one
                                  sprint, measure how long your sessions now take. In the sprint
                                  retrospective, present those findings along with "subjective"
                                  evaluations from all team members.

                                  Then at that point the team would decide... How would you feel, and
                                  how would the team feel, about the team deciding for itself, based on
                                  such an experiment ?

                                  Laurent Bossavit
                                  laurent@...
                                • Tobias Mayer
                                  Hi Bil, Sorry for the delayed reply (no home access at the moment). To state the obvious, you have a bigger problem than one of process; you have a culture
                                  Message 16 of 24 , Apr 2, 2007
                                  • 0 Attachment
                                    Hi Bil,

                                    Sorry for the delayed reply (no home access at the moment).

                                    To state the obvious, you have a bigger problem than one of process; you have a culture problem.   This is common to so many organizations trying to implement Scrum: the mindeset of those running the organization -- and of the organization itself, as an entity, is in total oppositon to the core Agile principles. 

                                    Implementing Scrum won't change that, although Scrum, if properly understood,  does give you the tools to effect change.  Agile Governance is a much newer field than Agile Development.  I'd like to recommend that you read this article on Holacracy to get some ideas to begin socializing change within your organization.  How you approach such socialization is entirely dependent on your context, of course, but some of the ideas given in this paper may be helpful.

                                    Disclaimer: I am currently working with a company who are pioneering the Holacratic approach.
                                    Dis-disclaimer: I am working here exactly because I believe in the approach.

                                    Tobias


                                    Bil Simser <bsimser@...> wrote:
                                    Tobias,

                                    Thanks for the info. As for the selling feature the environment is
                                    corporate and as such, if management has it's way (I'm just the
                                    SM/Architect/mentor) they would have everyone enter their time
                                    tracking in 10 different systems and then fill out a spreadsheet to
                                    print off and submit.

                                    One of the biggest problems with an Agile approach to delivering
                                    software with Scrum (and this was identified by Uncle Bob at an
                                    Agile Universe a few years back) is that there's no empherical
                                    proof. Everyone on this list knows waterfall doesn't work, but we
                                    can't prove that Scrum does. We can cite examples and success
                                    stories, and there are many, but the hard proof isn't there.

                                    The place I'm at right now has heard about Agile, given me the
                                    ability to introduce Scrum (and other Agile practices, but mostly
                                    Scrum) in order to "be better at delivering software". The biggest
                                    challenge is that IS takes too long to deliver. I dont' think I'm
                                    going to solve that problem with Scrum, but at the very least I can
                                    show frequent inspection and value with what we are delivering, and
                                    along the way using TDD and other techniques we can improve quality.
                                    However all of this comes to evidence. To me, management wants to
                                    see project 1 delivered in traditional approach (waterfall-ish) and
                                    then same project delivered with same team using Scrum approach then
                                    measure success.

                                    Getting back to the original question about who am I selling a
                                    project completely managed by index cards alone, it's upper
                                    management. They cannot grasp tracking a project unless there's a
                                    spreadsheet, database, electronic tool, or whatever behind it. The
                                    idea of a bunch of post-it notes on a wall being the tracking
                                    mechism isn't something they can connect with. Hope that answers
                                    your question (and others might jump in to talk about things I've
                                    brought up about the enviroment here). It's not optimal and upper
                                    management doesn't quite get "it" (it being the use of Scrum to
                                    manage the delivery of software). They know what it is, they see the
                                    value, but they're still clinging to spreadsheets and databases and
                                    time tracking systems as they spit out weekly reports and discuss
                                    priorities of projects. An undertaking I'm looking to change, but
                                    it's a long journey.

                                    Okay, this is a little off topic with the original thread but a good
                                    conversation none the less.

                                    --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer"
                                    wrote:
                                    >
                                    > Hi Bil,
                                    >
                                    > As you imply, having data in two places is always a bad idea. If
                                    I were
                                    > a developer on that team, I would have a hard time with this too.
                                    Bob's
                                    > suggestion of shielding the team from the electronic tool and
                                    having the
                                    > SM update it is a good one, and one that I have used successfully
                                    too.
                                    > But sometimes the electronic alternative just isn't necessary; we
                                    only
                                    > think it is because that's what we are used to. It's part of the
                                    > "that's just what we do here" syndrome. So...
                                    >
                                    > > I don’t know if I can sell doing tasks without artifact
                                    > tracking digitally.
                                    > Can you say more about that? Who are you "selling" to?





                                    To Post a message, send it to: scrumdevelopment@...
                                    To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                                    Yahoo! 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:
                                    mailto:scrumdevelopment-digest@yahoogroups.com
                                    mailto: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/


                                  • Michael Dobbins
                                    ... process; you have a culture problem. This is common to so many organizations trying to implement Scrum: the mindeset of those running the organization --
                                    Message 17 of 24 , Apr 3, 2007
                                    • 0 Attachment
                                      --- In scrumdevelopment@yahoogroups.com, Tobias Mayer <tobyanon@...>
                                      wrote:
                                      >
                                      > Hi Bil,
                                      >
                                      > Sorry for the delayed reply (no home access at the moment).
                                      >
                                      > To state the obvious, you have a bigger problem than one of
                                      process; you have a culture problem. This is common to so many
                                      organizations trying to implement Scrum: the mindeset of those
                                      running the organization -- and of the organization itself, as an
                                      entity, is in total oppositon to the core Agile principles.
                                      >
                                      > Implementing Scrum won't change that, although Scrum, if properly
                                      understood, does give you the tools to effect change. Agile
                                      Governance is a much newer field than Agile Development. I'd like to
                                      recommend that you read this article on Holacracy to get some ideas
                                      to begin socializing change within your organization. How you
                                      approach such socialization is entirely dependent on your context, of
                                      course, but some of the ideas given in this paper may be helpful.
                                      >
                                      > Disclaimer: I am currently working with a company who are
                                      pioneering the Holacratic approach.
                                      > Dis-disclaimer: I am working here exactly because I believe in the
                                      approach.
                                      >
                                      > Tobias

                                      The links didn't show up on the text only digest version I receive.
                                      For others receiving text posts, the link to the article is:
                                      http://www.holacracy.org/downloads/CutterHolacracyArticle.pdf

                                      Great article.
                                      mike
                                    • Ken Schwaber
                                      Tobias, A pleasure having you here, Ken _____ From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Tobias Mayer Sent:
                                      Message 18 of 24 , Apr 8, 2007
                                      • 0 Attachment

                                        Tobias,

                                        A pleasure having you here,

                                        Ken

                                         


                                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Tobias Mayer
                                        Sent: Friday, March 30, 2007 8:00 AM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: [SPAM] [scrumdevelopment] Re: Team member doesn't see value in index card approach

                                         

                                        Hi Bil,

                                        As you imply, having data in two places is always a bad idea.  If I were a developer on that team, I would have a hard time with this too.  Bob's suggestion of shielding the team from the electronic tool and having the SM update it is a good one, and one that I have used successfully too.  But sometimes the electronic alternative just isn't necessary; we only think it is because that's what we are used to.  It's part of the "that's just what we do here" syndrome.  So...

                                        > I don’t know if I can sell doing tasks without artifact tracking digitally.
                                        Can you say more about that?  Who are you "selling" to?

                                        Tobias

                                        PS thanks Ken, for inviting me back to this forum.  Good to be here.


                                        --- In scrumdevelopment@ yahoogroups. com , "Bob Schatz" <bobschatz@.. .> wrote:

                                        >
                                        > Hi Bil,
                                        >
                                        > I love the task boards and see the difference in the team dynamics
                                        > when they use it in their daily Scrum. I really push teams to try
                                        > these and I can say that they ALL see the value in doing this.
                                        > Sometimes when the team does not do good sprint planning, they loose
                                        > the value in the tasks and therefore the board. It has to mean
                                        > something, and they have to own it. It's the same symptom as when a
                                        > team tells me that they're not having good daily scrums. I also think
                                        > the board serves as the information radiator for people outside the
                                        > team. It provides the visibility, transparency, and helps build trust.
                                        > So it goes way beyond the feelings of a single developer.
                                        >
                                        > Perhaps you might consider taking the responsibility for online update
                                        > away from the team and have the Scrum Master do that based on data
                                        > from the board. Now, for the team it's not a choice, or dual entry. I
                                        > have coached teams to do this in the past and it seems to work.
                                        >
                                        > I also sense that there are some additional undercurrents operating in
                                        > the case you've presented.
                                        >
                                        > Bob Schatz
                                        > Agile Infusion
                                        > www.agileinfusion. com
                                        >
                                        >
                                        > --- In scrumdevelopment@ yahoogroups. com ,
                                        Bil Simser bsimser@ wrote:
                                        > >
                                        > > Hi guys,
                                        > >
                                        > >
                                        > >
                                        > > I have a bit of a problem that a team member brought up today which
                                        I'm
                                        > > looking for some ideas on how to handle. His comment was that he
                                        > felt the
                                        > > index card approach of having tasks on the wall was a waste of time
                                        > and was
                                        > > just getting in his way.
                                        > >
                                        > >
                                        > >
                                        > > A little background. We're using Visual Studio Team System with the
                                        > > Conchango plug-in to track the work items, produce burndown charts,
                                        > etc. as
                                        > > it houses our source code as well. I also setup post-it notes on our
                                        > scrum
                                        > > wall for people to work from. Yes, it's redundant and dual-entry. If
                                        > someone
                                        > > grabs a task from the wall, they're supposed to enter the
                                        > information in TFS
                                        > > as well. I don't know if I can sell doing tasks without artifact
                                        > tracking
                                        > > digitally.
                                        > >
                                        > >
                                        > >
                                        > > As myself and another SM pointed out to the team member, the wall
                                        > was there
                                        > > for a purpose besides duplicating what was in TFS. It was a
                                        conversation
                                        > > piece. Our daily stand-ups take place around the wall, people grab a
                                        > sticky
                                        > > from the Not Started section and put it in play in the In Progress
                                        > section
                                        > > or move it along or drop it into the Done area. I'm a visual guy and
                                        > I can
                                        > > see over the course of the sprint how the stickies move from one
                                        > side to the
                                        > > other, and it's a team motivator (as a side note, at some point I
                                        > want to
                                        > > take daily pics of the wall and then have an animated view of it).
                                        > We also
                                        > > use it for looking at the immediate state of the project, although
                                        > the team
                                        > > member says he can look at TFS and get the same thing. I don't agree.
                                        > >
                                        > >
                                        > >
                                        > > So he stands alone in his view in the team but that's not a good
                                        thing.
                                        > > However I'm not about to ditch the whole thing as everyone else
                                        > feels it has
                                        > > value, the one team member just considers it a nuisance and says its
                                        > causing
                                        > > him to be feel like he's wasting his time which makes me feel like I
                                        > have to
                                        > > remove this impediment but not sure how.
                                        > >
                                        > >
                                        > >
                                        > > Just wondering if anyone else has had similar issues and how they
                                        > dealt with
                                        > > it?
                                        > >
                                        > >
                                        > >
                                        > > Thanks.
                                        > >
                                        >

                                      • Ilja Preuss
                                        ... While this might be an OK compromise when you absolutely have to have software doing it, it is far from being the same as using index cards. There is a lot
                                        Message 19 of 24 , Apr 9, 2007
                                        • 0 Attachment
                                          Michael Dobbins schrieb:
                                          > How about a
                                          > tool and equipment where you can keep the information digital and project it
                                          > on the team wall for standup meetings and keeping it visible in the team
                                          > room through out the day. With the right drag and drop features it could
                                          > pretty well mimic the index card approach.

                                          While this might be an OK compromise when you absolutely have to have
                                          software doing it, it is far from being the same as using index cards.
                                          There is a lot of power in being able to grab a card physically, writing
                                          on it in total free form, stacking them, laying them on a table, tearing
                                          them up etc. They also have an incredibly high graphics resolution... ;)

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