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

Is there a lack of perceived schedule pressure in Kanban?

Expand Messages
  • timuttormark
    I m experienced with Scrum but just learning about Kanban. There is one aspect of Scrum which I am trying to compare against Kanban, that is the pressure to
    Message 1 of 30 , Jan 30, 2009
      I'm experienced with Scrum but just learning about Kanban. There is
      one aspect of Scrum which I am trying to compare against Kanban, that
      is the pressure to produce as experienced by members of the team.

      In Scrum development the team makes a commitment (to the product
      owners and themselves) to finish a set of stories during each
      iteration. Then each day in the daily standup, team members again
      make commitments to their peers about which task(s) they plan to
      finish that day.

      These regular commitments in Scrum result in a perceived pressure for
      individual team members to produce. This can result from peer
      pressure, integrity (keeping one's word), increased ownership (having
      made the commitments themselves, as opposed to having them dictated by
      management), or simply fear (of appearing not to be pulling one's
      weight relative to the rest of the team). These are all aspects of
      the maxim "deadlines get things done".

      This sense of pressure is not necessarily positive. While it can
      result in increased output by each team member, it can also backfire
      and cause some people to cut corners in the short term (declaring
      tasks as "done" with poor quality or net positive technical debt), and
      to cause others to experience burn-out in the long run.

      How is this reflected in Kanban? I know that some units of work
      (tasks/stories/CRs/whatever) can have individual deadlines. How does
      the lack of other artificial deadlines (created and imposed by other
      processes such as Scrum) help or hinder in Kanban?

      Thanks,
      -- Tim Uttormark
    • Corey Ladas
      Cycle time is the center of the universe. Control charts and histograms are its messengers. Standard work is the foundation of continuous improvement.
      Message 2 of 30 , Jan 30, 2009
        Cycle time is the center of the universe.  Control charts and histograms are its messengers.

        Standard work is the foundation of continuous improvement.  Continuous improvement is continuous.

        Corey


        On Fri, Jan 30, 2009 at 1:05 PM, timuttormark <timuttormark@...> wrote:

        I'm experienced with Scrum but just learning about Kanban. There is
        one aspect of Scrum which I am trying to compare against Kanban, that
        is the pressure to produce as experienced by members of the team.

        In Scrum development the team makes a commitment (to the product
        owners and themselves) to finish a set of stories during each
        iteration. Then each day in the daily standup, team members again
        make commitments to their peers about which task(s) they plan to
        finish that day.

        These regular commitments in Scrum result in a perceived pressure for
        individual team members to produce. This can result from peer
        pressure, integrity (keeping one's word), increased ownership (having
        made the commitments themselves, as opposed to having them dictated by
        management), or simply fear (of appearing not to be pulling one's
        weight relative to the rest of the team). These are all aspects of
        the maxim "deadlines get things done".

        This sense of pressure is not necessarily positive. While it can
        result in increased output by each team member, it can also backfire
        and cause some people to cut corners in the short term (declaring
        tasks as "done" with poor quality or net positive technical debt), and
        to cause others to experience burn-out in the long run.

        How is this reflected in Kanban? I know that some units of work
        (tasks/stories/CRs/whatever) can have individual deadlines. How does
        the lack of other artificial deadlines (created and imposed by other
        processes such as Scrum) help or hinder in Kanban?

        Thanks,
        -- Tim Uttormark


      • David J Anderson
        Hi Tim, It s interesting that you bring this up. Neither Deming nor Goldratt believe in the type of deadline setting, commitment based approach your
        Message 3 of 30 , Feb 1, 2009
          Hi Tim,

          It's interesting that you bring this up. Neither Deming nor Goldratt
          believe in the type of deadline setting, commitment based approach
          your highlighting. The perception is that it leads to a combination of
          fear (on the one hand) and pressure, control and authoritarianism (on
          the other). It also represents "management by objectives" (at a micro
          level) and has a tendency to encourage the customer to audit the
          actual performance against the plan. Deming would have suggested that
          this leads to fear, and Goldratt pointed out that the fear leads to
          inefficiency in the form of padded estimates.

          With kanban we're trying to strike a different bargain and move the
          focus away from individual items and focus more on the performance of
          the organization aggregated across a set of work. Kanban asks the team
          to make it's best effort to deliver against an SLA and measures the
          DDP (Due Date Performance) against that SLA. The goal is to shrink the
          mean cycle time and improve the DDP and if the cycle time is
          sufficiently reduced then reduce the SLA. It offers a combination of
          business agility (measured in cycle time) and
          predictability/reliability measured as DDP.

          With an approach like this the system is tolerant of individual
          failure (on any one item) but focused on organizational performance
          improvement. The pressure is on team performance and the motivation is
          to improve capability in order to improve team performance (on both
          cycle time and reliability).

          The class of service mechanisms in kanban and the pull system driven
          by visual control and discussed at a daily standup allow the team to
          self-organize to the solve the puzzle of how to optimize both cycle
          time and due date performance (against the SLA).

          It's a very different approach than Scrum. In my opinion, Scrum is
          very traditional in this respect. Kanban takes a much more _Agile_
          high trust, failure tolerant, fear free approach. I believe the
          results are more sustainable over the longer term as there is no need
          for heroics with the kanban approach.

          David
          http://www.agilemanagement.net/
          --- In kanbandev@yahoogroups.com, "timuttormark" <timuttormark@...> wrote:
          >
          > I'm experienced with Scrum but just learning about Kanban. There is
          > one aspect of Scrum which I am trying to compare against Kanban, that
          > is the pressure to produce as experienced by members of the team.
          >
          > In Scrum development the team makes a commitment (to the product
          > owners and themselves) to finish a set of stories during each
          > iteration. Then each day in the daily standup, team members again
          > make commitments to their peers about which task(s) they plan to
          > finish that day.
          >
          > These regular commitments in Scrum result in a perceived pressure for
          > individual team members to produce. This can result from peer
          > pressure, integrity (keeping one's word), increased ownership (having
          > made the commitments themselves, as opposed to having them dictated by
          > management), or simply fear (of appearing not to be pulling one's
          > weight relative to the rest of the team). These are all aspects of
          > the maxim "deadlines get things done".
          >
          > This sense of pressure is not necessarily positive. While it can
          > result in increased output by each team member, it can also backfire
          > and cause some people to cut corners in the short term (declaring
          > tasks as "done" with poor quality or net positive technical debt), and
          > to cause others to experience burn-out in the long run.
          >
          > How is this reflected in Kanban? I know that some units of work
          > (tasks/stories/CRs/whatever) can have individual deadlines. How does
          > the lack of other artificial deadlines (created and imposed by other
          > processes such as Scrum) help or hinder in Kanban?
          >
          > Thanks,
          > -- Tim Uttormark
          >
        • Stephen Palmer
          I agree. I hope that any mature agile team would be able to address this sort of dysfunctional behaviour themselves. I don t think process corrects
          Message 4 of 30 , Feb 2, 2009
            I agree. I hope that any mature agile team would be able to address this
            sort of dysfunctional behaviour themselves.
            I don't think process corrects dysfunctional behaviour. At best it helps
            idenitfy it and make it visible.

            Steve

            David J Anderson wrote:
            >
            > Hi Tim,
            >
            > It's interesting that you bring this up. Neither Deming nor Goldratt
            > believe in the type of deadline setting, commitment based approach
            > your highlighting. The perception is that it leads to a combination of
            > fear (on the one hand) and pressure, control and authoritarianism (on
            > the other). It also represents "management by objectives" (at a micro
            > level) and has a tendency to encourage the customer to audit the
            > actual performance against the plan. Deming would have suggested that
            > this leads to fear, and Goldratt pointed out that the fear leads to
            > inefficiency in the form of padded estimates.
            >
            > With kanban we're trying to strike a different bargain and move the
            > focus away from individual items and focus more on the performance of
            > the organization aggregated across a set of work. Kanban asks the team
            > to make it's best effort to deliver against an SLA and measures the
            > DDP (Due Date Performance) against that SLA. The goal is to shrink the
            > mean cycle time and improve the DDP and if the cycle time is
            > sufficiently reduced then reduce the SLA. It offers a combination of
            > business agility (measured in cycle time) and
            > predictability/reliability measured as DDP.
            >
            > With an approach like this the system is tolerant of individual
            > failure (on any one item) but focused on organizational performance
            > improvement. The pressure is on team performance and the motivation is
            > to improve capability in order to improve team performance (on both
            > cycle time and reliability).
            >
            > The class of service mechanisms in kanban and the pull system driven
            > by visual control and discussed at a daily standup allow the team to
            > self-organize to the solve the puzzle of how to optimize both cycle
            > time and due date performance (against the SLA).
            >
            > It's a very different approach than Scrum. In my opinion, Scrum is
            > very traditional in this respect. Kanban takes a much more _Agile_
            > high trust, failure tolerant, fear free approach. I believe the
            > results are more sustainable over the longer term as there is no need
            > for heroics with the kanban approach.
            >
            > David
            > http://www.agilemanagement.net/ <http://www.agilemanagement.net/>
            > --- In kanbandev@yahoogroups.com <mailto:kanbandev%40yahoogroups.com>,
            > "timuttormark" <timuttormark@...> wrote:
            > >
            > > I'm experienced with Scrum but just learning about Kanban. There is
            > > one aspect of Scrum which I am trying to compare against Kanban, that
            > > is the pressure to produce as experienced by members of the team.
            > >
            > > In Scrum development the team makes a commitment (to the product
            > > owners and themselves) to finish a set of stories during each
            > > iteration. Then each day in the daily standup, team members again
            > > make commitments to their peers about which task(s) they plan to
            > > finish that day.
            > >
            > > These regular commitments in Scrum result in a perceived pressure for
            > > individual team members to produce. This can result from peer
            > > pressure, integrity (keeping one's word), increased ownership (having
            > > made the commitments themselves, as opposed to having them dictated by
            > > management), or simply fear (of appearing not to be pulling one's
            > > weight relative to the rest of the team). These are all aspects of
            > > the maxim "deadlines get things done".
            > >
            > > This sense of pressure is not necessarily positive. While it can
            > > result in increased output by each team member, it can also backfire
            > > and cause some people to cut corners in the short term (declaring
            > > tasks as "done" with poor quality or net positive technical debt), and
            > > to cause others to experience burn-out in the long run.
            > >
            > > How is this reflected in Kanban? I know that some units of work
            > > (tasks/stories/CRs/whatever) can have individual deadlines. How does
            > > the lack of other artificial deadlines (created and imposed by other
            > > processes such as Scrum) help or hinder in Kanban?
            > >
            > > Thanks,
            > > -- Tim Uttormark
            > >
            >
            >
          • Clinton Keith
            Hi All, I m helping a friend adopt some lean practices at a company that works in an entirely distributed manner. Right now they use dot project Gantt
            Message 5 of 30 , Feb 2, 2009
              Hi All,

              I'm helping a friend adopt some lean practices at a company that works
              in an entirely distributed manner. Right now they use "dot project"
              Gantt charts to manage schedules for creating complex art assets
              (levels & such for video games). Any advice for tools to help such a
              team transition away from Gantt charts on a distributed team? He'll
              face resistance trying to take too great of a leap at first.

              Thanks,
              Clint
            • Mattias Skarin
              I noticed a clear difference between our Scrum teams and our Kanban ones. While the Scrum teams often accumulated unfinished work until the end of the sprint
              Message 6 of 30 , Feb 3, 2009
                I noticed a clear difference between our Scrum teams and our Kanban ones.
                While the Scrum teams often accumulated unfinished work until the end of the sprint ("feeling the preassure..") the kanban teams saw the problems at a much earlier stage and actively mitigated them. Thus, they did not get into that time squeeze as often as the Scrum teams.

                I have blogged about this (if you care to read)
                Why Kanban can tell you more than Scrum

                Note thought that we acknowledged the existence of a deadline, the Kanban teams did this by writing a deadline/timestamp on the Story given to them.

                /Mattias



              • Landes Eric (CI/AFR2-NA)
                Clint, I did not notice any replies to this, so I will tell you my experiences. When we first started using a kanban approach, the biggest win for us was to
                Message 7 of 30 , Feb 4, 2009
                  Clint,
                  I did not notice any replies to this, so I will tell you my experiences.
                  When we first started using a "kanban" approach, the biggest win for us
                  was to put all the work we had on cards in a visible place. The team
                  then got to see constantly what we were working. Also management could
                  see this every time they came into the teams workspace.

                  So you might want to try just putting up a board, putting all the work
                  up there, and what stage the work is at. We used minimal queues at
                  first (Backlog, WIP, and Transport is what we called them). Today, we
                  have more queues and have evolved to limiting WIP, and to some extent
                  the queues. Highly visible information radiators really help a team and
                  management start to focus on the workflow, and in my case displayed the
                  value of a kanban board to management.

                  Eric Landes
                  Microsoft MVP
                  http://feeds.feedburner.com/aspadvice/lhVO (My Blog)
                  http://www.linkedin.com/in/ericlandes Linked In Profile
                  http://twitter.com/ericlandes Twitter



                  > -----Original Message-----
                  > From: kanbandev@yahoogroups.com
                  > [mailto:kanbandev@yahoogroups.com] On Behalf Of Clinton Keith
                  > Sent: Monday, February 02, 2009 5:35 PM
                  > To: kanbandev@yahoogroups.com
                  > Subject: [kanbandev] Gantt to Kanban transition for distributed teams?
                  >
                  > Hi All,
                  >
                  > I'm helping a friend adopt some lean practices at a company
                  > that works
                  > in an entirely distributed manner. Right now they use "dot
                  > project"
                  > Gantt charts to manage schedules for creating complex art assets
                  > (levels & such for video games). Any advice for tools to
                  > help such a
                  > team transition away from Gantt charts on a distributed team? He'll
                  > face resistance trying to take too great of a leap at first.
                  >
                  > Thanks,
                  > Clint
                  >
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                • Clinton Keith
                  Hi Eric, Thanks for the response. This team is distributed however, so the cards in a visible place approach won t work for them. Are there any tools or
                  Message 8 of 30 , Feb 4, 2009
                    Hi Eric,

                    Thanks for the response.

                    This team is distributed however, so the "cards in a visible place" approach won't work for them.

                    Are there any tools or experiences in doing this on distributed teams?  I know that there are Scrum tools and teams that have done this successfully.

                    Best,
                    Clint



                    On Feb 4, 2009, at 12:01 PM, Landes Eric (CI/AFR2-NA) wrote:


                    Clint, 
                    I did not notice any replies to this, so I will tell you my experiences.
                    When we first started using a "kanban" approach, the biggest win for us
                    was to put all the work we had on cards in a visible place. The team
                    then got to see constantly what we were working. Also management could
                    see this every time they came into the teams workspace. 

                    So you might want to try just putting up a board, putting all the work
                    up there, and what stage the work is at. We used minimal queues at
                    first (Backlog, WIP, and Transport is what we called them). Today, we
                    have more queues and have evolved to limiting WIP, and to some extent
                    the queues. Highly visible information radiators really help a team and
                    management start to focus on the workflow, and in my case displayed the
                    value of a kanban board to management. 

                    Eric Landes
                    Microsoft MVP
                    http://feeds. feedburner. com/aspadvice/ lhVO (My Blog)
                    http://www.linkedin .com/in/ericland es Linked In Profile
                    http://twitter. com/ericlandes Twitter

                    > -----Original Message-----
                    > From: kanbandev@yahoogrou ps.com 
                    > [mailto:kanbandev@yahoogrou ps.com] On Behalf Of Clinton Keith
                    > Sent: Monday, February 02, 2009 5:35 PM
                    > To: kanbandev@yahoogrou ps.com
                    > Subject: [kanbandev] Gantt to Kanban transition for distributed teams?
                    > 
                    > Hi All,
                    > 
                    > I'm helping a friend adopt some lean practices at a company 
                    > that works 
                    > in an entirely distributed manner. Right now they use "dot 
                    > project" 
                    > Gantt charts to manage schedules for creating complex art assets 
                    > (levels & such for video games). Any advice for tools to 
                    > help such a 
                    > team transition away from Gantt charts on a distributed team? He'll 
                    > face resistance trying to take too great of a leap at first.
                    > 
                    > Thanks,
                    > Clint
                    > 
                    > 
                    > 
                    > 
                    > ------------ --------- --------- ------
                    > 
                    > Yahoo! Groups Links
                    > 
                    > 
                    > 
                    > 


                  • Greg Frazer
                    Hi Clint, While doing what we can to co-locate the teams at a particular geographical site, resource constraints concerning off-shored development teams and
                    Message 9 of 30 , Feb 4, 2009
                      Hi Clint,

                      While doing what we can to co-locate the teams at a particular
                      geographical site, resource constraints concerning 'off-shored'
                      development teams and deep scientific expertise (large Pharma,
                      regulatory environment) regularly require us to operate with
                      distributed teams. Generally we focus efforts down to teams of ten
                      people or less, but could include varying splits on any combination of
                      UK, Italy, India, and two sites in the US.

                      Many of our teams are mature in Agile/XP, and early last year
                      recognized that our local Agile process optimizations kept aligning
                      with many of the Lean approaches.

                      However, like you, we have been disappointed with the lack of tool
                      support for distributed teams. Previously, we suffered from lack of
                      alignment on communicating hand-offs, priorities, and resource
                      allocations across sites. We also sought automated, electronic
                      tracking to make data-backed policy changes and informed decisions on
                      where to apply more resources.

                      We verified three half-baked solutions with potential, though none
                      were developed specifically as a kanban visual.
                      Our best recommendation for commonly available tools would be to use
                      Mingle (from Thoughtworks). It is not free, but your ability to
                      customize the card types, states, transitions and visual 'board' to
                      your project team/flow was well thought through and implemented.
                      There is also a plug-in to Jira called GreenHopper (by GreenPepper)
                      that is similar to Jira and close to free.
                      For a lighter-weight option, one of our teams just used a wiki and
                      spreadsheet. A number of others mentioned successfully using this
                      format at Agile 08. We have found this option is simple and easy to
                      optimize for the particular project flow. It is not a solution that
                      scales well to large corporate portfolio management with plenty of
                      editors.

                      A few of us are four months into building a Flex3 on Ruby tool that is
                      explicitly for use to maintain a card board and provide statistics on
                      flow timings and SLAs. We just started using it on our first
                      distributed team two weeks ago. I'll demo this at an open space at
                      the Lean conference in May. We would like to make this generally
                      available, after sufficient feedback and verification, to help support
                      the evolution of Lean in software. Let me know if anyone is as
                      desperate as we were and wants to toss ideas together to help it
                      continue to take form.


                      Cheers,
                      Greg Frazer

                      --- In kanbandev@yahoogroups.com, Clinton Keith <clintonnkeith@...> wrote:
                      >
                      > Hi Eric,
                      >
                      > Thanks for the response.
                      >
                      > This team is distributed however, so the "cards in a visible place"
                      > approach won't work for them.
                      >
                      > Are there any tools or experiences in doing this on distributed
                      > teams? I know that there are Scrum tools and teams that have done
                      > this successfully.
                      >
                      > Best,
                      > Clint
                      >
                      >
                      >
                      > On Feb 4, 2009, at 12:01 PM, Landes Eric (CI/AFR2-NA) wrote:
                      >
                      > >
                      > > Clint,
                      > > I did not notice any replies to this, so I will tell you my
                      > > experiences.
                      > > When we first started using a "kanban" approach, the biggest win for
                      > > us
                      > > was to put all the work we had on cards in a visible place. The team
                      > > then got to see constantly what we were working. Also management could
                      > > see this every time they came into the teams workspace.
                      > >
                      > > So you might want to try just putting up a board, putting all the work
                      > > up there, and what stage the work is at. We used minimal queues at
                      > > first (Backlog, WIP, and Transport is what we called them). Today, we
                      > > have more queues and have evolved to limiting WIP, and to some extent
                      > > the queues. Highly visible information radiators really help a team
                      > > and
                      > > management start to focus on the workflow, and in my case displayed
                      > > the
                      > > value of a kanban board to management.
                      > >
                      > > Eric Landes
                      > > Microsoft MVP
                      > > http://feeds.feedburner.com/aspadvice/lhVO (My Blog)
                      > > http://www.linkedin.com/in/ericlandes Linked In Profile
                      > > http://twitter.com/ericlandes Twitter
                      > >
                      > > > -----Original Message-----
                      > > > From: kanbandev@yahoogroups.com
                      > > > [mailto:kanbandev@yahoogroups.com] On Behalf Of Clinton Keith
                      > > > Sent: Monday, February 02, 2009 5:35 PM
                      > > > To: kanbandev@yahoogroups.com
                      > > > Subject: [kanbandev] Gantt to Kanban transition for distributed
                      > > teams?
                      > > >
                      > > > Hi All,
                      > > >
                      > > > I'm helping a friend adopt some lean practices at a company
                      > > > that works
                      > > > in an entirely distributed manner. Right now they use "dot
                      > > > project"
                      > > > Gantt charts to manage schedules for creating complex art assets
                      > > > (levels & such for video games). Any advice for tools to
                      > > > help such a
                      > > > team transition away from Gantt charts on a distributed team? He'll
                      > > > face resistance trying to take too great of a leap at first.
                      > > >
                      > > > Thanks,
                      > > > Clint
                      > > >
                      > > >
                      > > >
                      > > >
                      > > > ------------------------------------
                      > > >
                      > > > Yahoo! Groups Links
                      > > >
                      > > >
                      > > >
                      > > >
                      > >
                      > >
                      >
                    • Clinton Keith
                      Hi Greg, Thanks for the information. I m shocked at the lack of tools to address this need. I d love to see the tool you are developing at the conference or
                      Message 10 of 30 , Feb 5, 2009
                        Hi Greg,

                        Thanks for the information.  I'm shocked at the lack of tools to address this need.  I'd love to see the tool you are developing at the conference or earlier.

                        Clint


                        On Feb 4, 2009, at 6:03 PM, Greg Frazer wrote:

                        Hi Clint,

                        While doing what we can to co-locate the teams at a particular
                        geographical site, resource constraints concerning 'off-shored'
                        development teams and deep scientific expertise (large Pharma,
                        regulatory environment) regularly require us to operate with
                        distributed teams. Generally we focus efforts down to teams of ten
                        people or less, but could include varying splits on any combination of
                        UK, Italy, India, and two sites in the US.

                        Many of our teams are mature in Agile/XP, and early last year
                        recognized that our local Agile process optimizations kept aligning
                        with many of the Lean approaches.

                        However, like you, we have been disappointed with the lack of tool
                        support for distributed teams. Previously, we suffered from lack of
                        alignment on communicating hand-offs, priorities, and resource
                        allocations across sites. We also sought automated, electronic
                        tracking to make data-backed policy changes and informed decisions on
                        where to apply more resources.

                        We verified three half-baked solutions with potential, though none
                        were developed specifically as a kanban visual.
                        Our best recommendation for commonly available tools would be to use
                        Mingle (from Thoughtworks) . It is not free, but your ability to
                        customize the card types, states, transitions and visual 'board' to
                        your project team/flow was well thought through and implemented.
                        There is also a plug-in to Jira called GreenHopper (by GreenPepper)
                        that is similar to Jira and close to free.
                        For a lighter-weight option, one of our teams just used a wiki and
                        spreadsheet. A number of others mentioned successfully using this
                        format at Agile 08. We have found this option is simple and easy to
                        optimize for the particular project flow. It is not a solution that
                        scales well to large corporate portfolio management with plenty of
                        editors.

                        A few of us are four months into building a Flex3 on Ruby tool that is
                        explicitly for use to maintain a card board and provide statistics on
                        flow timings and SLAs. We just started using it on our first
                        distributed team two weeks ago. I'll demo this at an open space at
                        the Lean conference in May. We would like to make this generally
                        available, after sufficient feedback and verification, to help support
                        the evolution of Lean in software. Let me know if anyone is as
                        desperate as we were and wants to toss ideas together to help it
                        continue to take form.

                        Cheers,
                        Greg Frazer

                        --- In kanbandev@yahoogrou ps.com, Clinton Keith <clintonnkeith@ ...> wrote:
                        >
                        > Hi Eric,
                        > 
                        > Thanks for the response.
                        > 
                        > This team is distributed however, so the "cards in a visible place" 
                        > approach won't work for them.
                        > 
                        > Are there any tools or experiences in doing this on distributed 
                        > teams? I know that there are Scrum tools and teams that have done 
                        > this successfully.
                        > 
                        > Best,
                        > Clint
                        > 
                        > 
                        > 
                        > On Feb 4, 2009, at 12:01 PM, Landes Eric (CI/AFR2-NA) wrote:
                        > 
                        > >
                        > > Clint,
                        > > I did not notice any replies to this, so I will tell you my 
                        > > experiences.
                        > > When we first started using a "kanban" approach, the biggest win for 
                        > > us
                        > > was to put all the work we had on cards in a visible place. The team
                        > > then got to see constantly what we were working. Also management could
                        > > see this every time they came into the teams workspace.
                        > >
                        > > So you might want to try just putting up a board, putting all the work
                        > > up there, and what stage the work is at. We used minimal queues at
                        > > first (Backlog, WIP, and Transport is what we called them). Today, we
                        > > have more queues and have evolved to limiting WIP, and to some extent
                        > > the queues. Highly visible information radiators really help a team 
                        > > and
                        > > management start to focus on the workflow, and in my case displayed 
                        > > the
                        > > value of a kanban board to management.
                        > >
                        > > Eric Landes
                        > > Microsoft MVP
                        > > http://feeds. feedburner. com/aspadvice/ lhVO (My Blog)
                        > > http://www.linkedin .com/in/ericland es Linked In Profile
                        > > http://twitter. com/ericlandes Twitter
                        > >
                        > > > -----Original Message-----
                        > > > From: kanbandev@yahoogrou ps.com
                        > > > [mailto:kanbandev@yahoogrou ps.com] On Behalf Of Clinton Keith
                        > > > Sent: Monday, February 02, 2009 5:35 PM
                        > > > To: kanbandev@yahoogrou ps.com
                        > > > Subject: [kanbandev] Gantt to Kanban transition for distributed 
                        > > teams?
                        > > >
                        > > > Hi All,
                        > > >
                        > > > I'm helping a friend adopt some lean practices at a company
                        > > > that works
                        > > > in an entirely distributed manner. Right now they use "dot
                        > > > project"
                        > > > Gantt charts to manage schedules for creating complex art assets
                        > > > (levels & such for video games). Any advice for tools to
                        > > > help such a
                        > > > team transition away from Gantt charts on a distributed team? He'll
                        > > > face resistance trying to take too great of a leap at first.
                        > > >
                        > > > Thanks,
                        > > > Clint
                        > > >
                        > > >
                        > > >
                        > > >
                        > > > ------------ --------- --------- ------
                        > > >
                        > > > Yahoo! Groups Links
                        > > >
                        > > >
                        > > >
                        > > >
                        > >
                        > >
                        >


                      • Landes Eric (CI/AFR2-NA)
                        Clint, Our group uses Microsofts Team Foundation Server (TFS) for our Lifecycle stuff. We have customized reports etc. for this. Off the shelf I don t know
                        Message 11 of 30 , Feb 6, 2009
                          Clint,
                          Our group uses Microsofts Team Foundation Server (TFS) for our Lifecycle stuff.  We have customized reports etc. for this.  Off the shelf I don't know of anything.  On Codeplex there is something called TFS Sticky Buddy which should visually show you a Kanban.  I have been working on a template for kanban that is currently stuck in me not having time to finish it!   HTH
                           
                          Eric
                           


                          From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On Behalf Of Clinton Keith
                          Sent: Wednesday, February 04, 2009 4:14 PM
                          To: kanbandev@yahoogroups.com
                          Subject: Re: [kanbandev] Gantt to Kanban transition for distributed teams?

                          Hi Eric,

                          Thanks for the response.

                          This team is distributed however, so the "cards in a visible place" approach won't work for them.

                          Are there any tools or experiences in doing this on distributed teams?  I know that there are Scrum tools and teams that have done this successfully.

                          Best,
                          Clint



                          On Feb 4, 2009, at 12:01 PM, Landes Eric (CI/AFR2-NA) wrote:


                          Clint, 
                          I did not notice any replies to this, so I will tell you my experiences.
                          When we first started using a "kanban" approach, the biggest win for us
                          was to put all the work we had on cards in a visible place. The team
                          then got to see constantly what we were working. Also management could
                          see this every time they came into the teams workspace. 

                          So you might want to try just putting up a board, putting all the work
                          up there, and what stage the work is at. We used minimal queues at
                          first (Backlog, WIP, and Transport is what we called them). Today, we
                          have more queues and have evolved to limiting WIP, and to some extent
                          the queues. Highly visible information radiators really help a team and
                          management start to focus on the workflow, and in my case displayed the
                          value of a kanban board to management. 

                          Eric Landes
                          Microsoft MVP
                          http://feeds. feedburner. com/aspadvice/ lhVO (My Blog)
                          http://www.linkedin .com/in/ericland es Linked In Profile
                          http://twitter. com/ericlandes Twitter

                          > -----Original Message-----
                          > From: kanbandev@yahoogrou ps.com 
                          > [mailto:kanbandev@yahoogrou ps.com] On Behalf Of Clinton Keith
                          > Sent: Monday, February 02, 2009 5:35 PM
                          > To: kanbandev@yahoogrou ps.com
                          > Subject: [kanbandev] Gantt to Kanban transition for distributed teams?
                          > 
                          > Hi All,
                          > 
                          > I'm helping a friend adopt some lean practices at a company 
                          > that works 
                          > in an entirely distributed manner. Right now they use "dot 
                          > project" 
                          > Gantt charts to manage schedules for creating complex art assets 
                          > (levels & such for video games). Any advice for tools to 
                          > help such a 
                          > team transition away from Gantt charts on a distributed team? He'll 
                          > face resistance trying to take too great ! of a leap at first.
                          > 
                          > Thanks,
                          > Clint
                          > 
                          > 
                          > 
                          > 
                          > ------------ --------- --------- ------
                          > 
                          > Yahoo! Groups Links
                          > 
                          > 
                          > 
                          > 


                        • David J Anderson
                          I m always curious about this insistence on tracking and management tools being free. Why? Is this because management with the budget for tools simply doesn t
                          Message 12 of 30 , Feb 6, 2009
                            I'm always curious about this insistence on tracking and management
                            tools being free. Why?

                            Is this because management with the budget for tools simply doesn't
                            get it?

                            The evidence is on your side. The single biggest factor in improving
                            the performance of software teams is fixing bad management. You cannot
                            manage without information and you cannot get information without
                            collecting tracking data.

                            So when the ROI is so clear, why do tools need to be free? In theory,
                            I should be willing to pay more for a tracking tool than I'd pay for
                            an IDE because improving the management gives me a bigger boost than
                            improving the efficiency of individual developers.

                            David
                            http://www.agilemanagement.net/

                            --- In kanbandev@yahoogroups.com, Clinton Keith <clintonnkeith@...> wrote:
                            >
                            > Hi Greg,
                            >
                            > Thanks for the information. I'm shocked at the lack of tools to
                            > address this need. I'd love to see the tool you are developing at the
                            > conference or earlier.
                            >
                            > Clint
                            >
                            >
                            > On Feb 4, 2009, at 6:03 PM, Greg Frazer wrote:
                            >
                            > > Hi Clint,
                            > >
                            > > While doing what we can to co-locate the teams at a particular
                            > > geographical site, resource constraints concerning 'off-shored'
                            > > development teams and deep scientific expertise (large Pharma,
                            > > regulatory environment) regularly require us to operate with
                            > > distributed teams. Generally we focus efforts down to teams of ten
                            > > people or less, but could include varying splits on any combination of
                            > > UK, Italy, India, and two sites in the US.
                            > >
                            > > Many of our teams are mature in Agile/XP, and early last year
                            > > recognized that our local Agile process optimizations kept aligning
                            > > with many of the Lean approaches.
                            > >
                            > > However, like you, we have been disappointed with the lack of tool
                            > > support for distributed teams. Previously, we suffered from lack of
                            > > alignment on communicating hand-offs, priorities, and resource
                            > > allocations across sites. We also sought automated, electronic
                            > > tracking to make data-backed policy changes and informed decisions on
                            > > where to apply more resources.
                            > >
                            > > We verified three half-baked solutions with potential, though none
                            > > were developed specifically as a kanban visual.
                            > > Our best recommendation for commonly available tools would be to use
                            > > Mingle (from Thoughtworks). It is not free, but your ability to
                            > > customize the card types, states, transitions and visual 'board' to
                            > > your project team/flow was well thought through and implemented.
                            > > There is also a plug-in to Jira called GreenHopper (by GreenPepper)
                            > > that is similar to Jira and close to free.
                            > > For a lighter-weight option, one of our teams just used a wiki and
                            > > spreadsheet. A number of others mentioned successfully using this
                            > > format at Agile 08. We have found this option is simple and easy to
                            > > optimize for the particular project flow. It is not a solution that
                            > > scales well to large corporate portfolio management with plenty of
                            > > editors.
                            > >
                            > > A few of us are four months into building a Flex3 on Ruby tool that is
                            > > explicitly for use to maintain a card board and provide statistics on
                            > > flow timings and SLAs. We just started using it on our first
                            > > distributed team two weeks ago. I'll demo this at an open space at
                            > > the Lean conference in May. We would like to make this generally
                            > > available, after sufficient feedback and verification, to help support
                            > > the evolution of Lean in software. Let me know if anyone is as
                            > > desperate as we were and wants to toss ideas together to help it
                            > > continue to take form.
                            > >
                            > > Cheers,
                            > > Greg Frazer
                            > >
                            > > --- In kanbandev@yahoogroups.com, Clinton Keith <clintonnkeith@>
                            > > wrote:
                            > > >
                            > > > Hi Eric,
                            > > >
                            > > > Thanks for the response.
                            > > >
                            > > > This team is distributed however, so the "cards in a visible place"
                            > > > approach won't work for them.
                            > > >
                            > > > Are there any tools or experiences in doing this on distributed
                            > > > teams? I know that there are Scrum tools and teams that have done
                            > > > this successfully.
                            > > >
                            > > > Best,
                            > > > Clint
                            > > >
                            > > >
                            > > >
                            > > > On Feb 4, 2009, at 12:01 PM, Landes Eric (CI/AFR2-NA) wrote:
                            > > >
                            > > > >
                            > > > > Clint,
                            > > > > I did not notice any replies to this, so I will tell you my
                            > > > > experiences.
                            > > > > When we first started using a "kanban" approach, the biggest win
                            > > for
                            > > > > us
                            > > > > was to put all the work we had on cards in a visible place. The
                            > > team
                            > > > > then got to see constantly what we were working. Also management
                            > > could
                            > > > > see this every time they came into the teams workspace.
                            > > > >
                            > > > > So you might want to try just putting up a board, putting all
                            > > the work
                            > > > > up there, and what stage the work is at. We used minimal queues at
                            > > > > first (Backlog, WIP, and Transport is what we called them).
                            > > Today, we
                            > > > > have more queues and have evolved to limiting WIP, and to some
                            > > extent
                            > > > > the queues. Highly visible information radiators really help a
                            > > team
                            > > > > and
                            > > > > management start to focus on the workflow, and in my case
                            > > displayed
                            > > > > the
                            > > > > value of a kanban board to management.
                            > > > >
                            > > > > Eric Landes
                            > > > > Microsoft MVP
                            > > > > http://feeds.feedburner.com/aspadvice/lhVO (My Blog)
                            > > > > http://www.linkedin.com/in/ericlandes Linked In Profile
                            > > > > http://twitter.com/ericlandes Twitter
                            > > > >
                            > > > > > -----Original Message-----
                            > > > > > From: kanbandev@yahoogroups.com
                            > > > > > [mailto:kanbandev@yahoogroups.com] On Behalf Of Clinton Keith
                            > > > > > Sent: Monday, February 02, 2009 5:35 PM
                            > > > > > To: kanbandev@yahoogroups.com
                            > > > > > Subject: [kanbandev] Gantt to Kanban transition for distributed
                            > > > > teams?
                            > > > > >
                            > > > > > Hi All,
                            > > > > >
                            > > > > > I'm helping a friend adopt some lean practices at a company
                            > > > > > that works
                            > > > > > in an entirely distributed manner. Right now they use "dot
                            > > > > > project"
                            > > > > > Gantt charts to manage schedules for creating complex art assets
                            > > > > > (levels & such for video games). Any advice for tools to
                            > > > > > help such a
                            > > > > > team transition away from Gantt charts on a distributed team?
                            > > He'll
                            > > > > > face resistance trying to take too great of a leap at first.
                            > > > > >
                            > > > > > Thanks,
                            > > > > > Clint
                            > > > > >
                            > > > > >
                            > > > > >
                            > > > > >
                            > > > > > ------------------------------------
                            > > > > >
                            > > > > > Yahoo! Groups Links
                            > > > > >
                            > > > > >
                            > > > > >
                            > > > > >
                            > > > >
                            > > > >
                            > > >
                            > >
                            > >
                            > >
                            >
                          • Clinton Keith
                            David, ... Great question. I had to ask myself this question since that was an important criteria when I was managing projects. ... This is number one. Part
                            Message 13 of 30 , Feb 6, 2009
                              David,

                              I'm always curious about this insistence on tracking and management
                              tools being free. Why?

                              Great question.  I had to ask myself this question since  that was an important criteria when I was managing projects.

                              Is this because management with the budget for tools simply doesn't
                              get it?

                              This is number one.  Part of it is the licensing conditions that some vendors require (numerous seats up front, service contracts, etc).  Part of it may be a history of tools that are too rigid, don't allow customization for a local environment and failed to gain traction.

                              The evidence is on your side. The single biggest factor in improving
                              the performance of software teams is fixing bad management. You cannot
                              manage without information and you cannot get information without
                              collecting tracking data.

                              So when the ROI is so clear, why do tools need to be free?

                              Is it?  It's pretty big leap between buying a tool and "fixing bad management".  WE know it, but we hang out in places like this with people that talk and think about this stuff all day long.  Many teams that wish to "fix bad management" have a greater challenge than simply creating some transparency.

                              The people in the executive suite certainly don't see the ROI.  These are the people who sit next to the bean counters who pull out the old expense reports from 7 years ago and say "look at how much money we spent on Microsoft Project Server and Project X was still late".  These people don't have any of your books on their shelves.

                              So the key thing is not to convince ourselves.  It's to address the culture that exists within the executive suites.  That culture trumps methodology, and certainly tools budgets, all the time.  Finding ways to communicate ROI to them in terms they understand and believe in is the challenge.

                              Just a subjective view...

                              Clint

                              Clinton Keith, 





                            • David J Anderson
                              I m conscious of Brian Marick s later comments about providing some specific anecdotal reply to the questions Tim raises. I ve been busy traveling and haven t
                              Message 14 of 30 , Feb 6, 2009
                                I'm conscious of Brian Marick's later comments about providing some
                                specific anecdotal reply to the questions Tim raises. I've been busy
                                traveling and haven't had a chance to provide a good quality reply. So
                                here goes...

                                --- In kanbandev@yahoogroups.com, "timuttormark" <timuttormark@...> wrote:
                                >
                                > I'm experienced with Scrum but just learning about Kanban. There is
                                > one aspect of Scrum which I am trying to compare against Kanban, that
                                > is the pressure to produce as experienced by members of the team.
                                >
                                > In Scrum development the team makes a commitment (to the product
                                > owners and themselves) to finish a set of stories during each
                                > iteration. Then each day in the daily standup, team members again
                                > make commitments to their peers about which task(s) they plan to
                                > finish that day.
                                >
                                > These regular commitments in Scrum result in a perceived pressure for
                                > individual team members to produce. This can result from peer
                                > pressure, integrity (keeping one's word), increased ownership (having
                                > made the commitments themselves, as opposed to having them dictated by
                                > management), or simply fear (of appearing not to be pulling one's
                                > weight relative to the rest of the team). These are all aspects of
                                > the maxim "deadlines get things done".
                                >
                                > This sense of pressure is not necessarily positive. While it can
                                > result in increased output by each team member, it can also backfire
                                > and cause some people to cut corners in the short term (declaring
                                > tasks as "done" with poor quality or net positive technical debt), and
                                > to cause others to experience burn-out in the long run.
                                >
                                > How is this reflected in Kanban?

                                My observation of kanban done properly over a long period of time is
                                that it does not suffer the negatives you observe. Kanban does not
                                treat all work items homogeneously from a risk perspective. We use
                                classes of service to delineate risk. While there is an SLA ticking
                                against each item, priority is given to items from a higher class of
                                service.

                                The commitment in kanban is different - to make a high quality release
                                on a regular cadence. There is reporting around velocity/productivity
                                and cycle time and due date performance (against the SLA).

                                However, there just isn't the same "pressure" to perform that methods
                                like Scrum use.

                                > I know that some units of work
                                > (tasks/stories/CRs/whatever) can have individual deadlines. How does
                                > the lack of other artificial deadlines (created and imposed by other
                                > processes such as Scrum) help or hinder in Kanban?

                                There isn't a lack of "other artificial deadlines", as each item has
                                its SLA clock ticking against it. However, it is OK for that SLA to
                                expire. Kanban reports Due Date Performance (%) against the SLA
                                (artificial deadline).

                                The team adopts an organization level operations review (usually
                                monthly) to assess performance and discuss improvement.

                                Whether the customer is satisfied with a particular Due Date
                                Performance is heavily dependent on whether items with a high risk and
                                higher class of service were delivered on-time or not. Due Date
                                Performance can be reported against Class of Service.

                                Kanban would really expect a 100% DDP against Expedite and Fixed
                                Delivery Date classes of service. Anything less is likely to lead to
                                dissatisfaction.

                                Dissatisfaction with lower classes of service will be a product of
                                both the DDP and the cadence. For example if DDP is only 50% for
                                standard class items but cadence is weekly then the late items will
                                mostly be only 1 week late. This may be acceptable from a customer
                                satisfaction perspective.

                                Hence, the rule of thumb is that you trade DDP for frequency of
                                release. If you can improve your ability to release by reducing the
                                transaction costs of a release, by improving configuration management,
                                and orchestration of releases, then you can afford to have a higher
                                release cadence and a poorer DDP.

                                There is a huge and significant lesson in this. Capability (and
                                maturity) in configuration management and release management can be
                                traded for reliability in schedule commitments and capability (and
                                maturity) in estimation.

                                So, as a development team lead / manager, what would you rather get
                                good at - estimation and schedule reliability, or configuration
                                management and release/deployment? I think the latter is more under
                                your control and more predictable/dependable and likely to lead to
                                positive behavioral, psychological and sociological trends leading to
                                a higher trust culture. A focus on "feet to the fire" schedule
                                commitment has a tendency to encourage negative behavioral,
                                psychological and sociological trends leading to a lower trust culture.

                                I think this is key difference with Scrum. Kanban requires an
                                engineering discipline in configuration management and deployment.
                                Perhaps we don't emphasize this enough?!!! hmmmm (stroking chin)

                                Regards,
                                David
                                http://www.agilemanagement.net/
                              • Raoul Duke
                                ... I am obviously not super well-read on Kanban, but I dare say this aspect could stand to be given more air time. Your post has been very helpful and
                                Message 15 of 30 , Feb 6, 2009
                                  > I think this is key difference with Scrum. Kanban requires an
                                  > engineering discipline in configuration management and deployment.
                                  > Perhaps we don't emphasize this enough?!!! hmmmm (stroking chin)

                                  I am obviously not super well-read on Kanban, but I dare say this
                                  aspect could stand to be given more air time. Your post has been very
                                  helpful and educational. Doing something such that people don't have
                                  their feet to the fire sounds like a good thing, and it is scary-sad
                                  that some people (such as myself) find it hard to believe it can
                                  exist?!

                                  sincerely.
                                • Rob Park
                                  The single biggest factor in improving the performance of software teams is fixing bad management. Do others feel this is true? I certainly don t like bad
                                  Message 16 of 30 , Feb 8, 2009
                                    "The single biggest factor in improving the performance of software teams is fixing bad management."
                                    Do others feel this is true?  I certainly don't like bad management, but if your developers aren't say practicing TDD or aren't doing a good job of decoupling or aren't keeping the code base clean by mercilessly refactoring, then I'd contend you're better off fixing that.

                                    And if my pm tool is free, then the ROI case on that is a pretty easy sell. :)  I used a free wiki to manage my distributed kanban for a year.  The nice part about using a wiki was that it was as flexible as a whiteboard and allowed us to easily adapt for process improvements.

                                    That said, I don't feel the pm tool has to be free, but it seems that it should be in the price range of a big, magnetic whiteboard, some index cards, and some magnets.  Although in a distributed environment, you should expect to pay a premium for anything that will truly improve communication.

                                    .rob.

                                    On Fri, Feb 6, 2009 at 11:31 AM, David J Anderson <netherby_uk@...> wrote:

                                    I'm always curious about this insistence on tracking and management
                                    tools being free. Why?

                                    Is this because management with the budget for tools simply doesn't
                                    get it?

                                    The evidence is on your side. The single biggest factor in improving
                                    the performance of software teams is fixing bad management. You cannot
                                    manage without information and you cannot get information without
                                    collecting tracking data.

                                    So when the ROI is so clear, why do tools need to be free? In theory,
                                    I should be willing to pay more for a tracking tool than I'd pay for
                                    an IDE because improving the management gives me a bigger boost than
                                    improving the efficiency of individual developers.

                                    David
                                    http://www.agilemanagement.net/



                                    --- In kanbandev@yahoogroups.com, Clinton Keith <clintonnkeith@...> wrote:
                                    >
                                    > Hi Greg,
                                    >
                                    > Thanks for the information. I'm shocked at the lack of tools to
                                    > address this need. I'd love to see the tool you are developing at the
                                    > conference or earlier.
                                    >
                                    > Clint
                                    >
                                    >
                                    > On Feb 4, 2009, at 6:03 PM, Greg Frazer wrote:
                                    >
                                    > > Hi Clint,
                                    > >
                                    > > While doing what we can to co-locate the teams at a particular
                                    > > geographical site, resource constraints concerning 'off-shored'
                                    > > development teams and deep scientific expertise (large Pharma,
                                    > > regulatory environment) regularly require us to operate with
                                    > > distributed teams. Generally we focus efforts down to teams of ten
                                    > > people or less, but could include varying splits on any combination of
                                    > > UK, Italy, India, and two sites in the US.
                                    > >
                                    > > Many of our teams are mature in Agile/XP, and early last year
                                    > > recognized that our local Agile process optimizations kept aligning
                                    > > with many of the Lean approaches.
                                    > >
                                    > > However, like you, we have been disappointed with the lack of tool
                                    > > support for distributed teams. Previously, we suffered from lack of
                                    > > alignment on communicating hand-offs, priorities, and resource
                                    > > allocations across sites. We also sought automated, electronic
                                    > > tracking to make data-backed policy changes and informed decisions on
                                    > > where to apply more resources.
                                    > >
                                    > > We verified three half-baked solutions with potential, though none
                                    > > were developed specifically as a kanban visual.
                                    > > Our best recommendation for commonly available tools would be to use
                                    > > Mingle (from Thoughtworks). It is not free, but your ability to
                                    > > customize the card types, states, transitions and visual 'board' to
                                    > > your project team/flow was well thought through and implemented.
                                    > > There is also a plug-in to Jira called GreenHopper (by GreenPepper)
                                    > > that is similar to Jira and close to free.
                                    > > For a lighter-weight option, one of our teams just used a wiki and
                                    > > spreadsheet. A number of others mentioned successfully using this
                                    > > format at Agile 08. We have found this option is simple and easy to
                                    > > optimize for the particular project flow. It is not a solution that
                                    > > scales well to large corporate portfolio management with plenty of
                                    > > editors.
                                    > >
                                    > > A few of us are four months into building a Flex3 on Ruby tool that is
                                    > > explicitly for use to maintain a card board and provide statistics on
                                    > > flow timings and SLAs. We just started using it on our first
                                    > > distributed team two weeks ago. I'll demo this at an open space at
                                    > > the Lean conference in May. We would like to make this generally
                                    > > available, after sufficient feedback and verification, to help support
                                    > > the evolution of Lean in software. Let me know if anyone is as
                                    > > desperate as we were and wants to toss ideas together to help it
                                    > > continue to take form.
                                    > >
                                    > > Cheers,
                                    > > Greg Frazer
                                    > >
                                    > > --- In kanbandev@yahoogroups.com, Clinton Keith <clintonnkeith@>
                                    > > wrote:
                                    > > >
                                    > > > Hi Eric,
                                    > > >
                                    > > > Thanks for the response.
                                    > > >
                                    > > > This team is distributed however, so the "cards in a visible place"
                                    > > > approach won't work for them.
                                    > > >
                                    > > > Are there any tools or experiences in doing this on distributed
                                    > > > teams? I know that there are Scrum tools and teams that have done
                                    > > > this successfully.
                                    > > >
                                    > > > Best,
                                    > > > Clint
                                    > > >
                                    > > >
                                    > > >
                                    > > > On Feb 4, 2009, at 12:01 PM, Landes Eric (CI/AFR2-NA) wrote:
                                    > > >
                                    > > > >
                                    > > > > Clint,
                                    > > > > I did not notice any replies to this, so I will tell you my
                                    > > > > experiences.
                                    > > > > When we first started using a "kanban" approach, the biggest win
                                    > > for
                                    > > > > us
                                    > > > > was to put all the work we had on cards in a visible place. The
                                    > > team
                                    > > > > then got to see constantly what we were working. Also management
                                    > > could
                                    > > > > see this every time they came into the teams workspace.
                                    > > > >
                                    > > > > So you might want to try just putting up a board, putting all
                                    > > the work
                                    > > > > up there, and what stage the work is at. We used minimal queues at
                                    > > > > first (Backlog, WIP, and Transport is what we called them).
                                    > > Today, we
                                    > > > > have more queues and have evolved to limiting WIP, and to some
                                    > > extent
                                    > > > > the queues. Highly visible information radiators really help a
                                    > > team
                                    > > > > and
                                    > > > > management start to focus on the workflow, and in my case
                                    > > displayed
                                    > > > > the
                                    > > > > value of a kanban board to management.
                                    > > > >
                                    > > > > Eric Landes
                                    > > > > Microsoft MVP
                                    > > > > http://feeds.feedburner.com/aspadvice/lhVO (My Blog)
                                    > > > > http://www.linkedin.com/in/ericlandes Linked In Profile
                                    > > > > http://twitter.com/ericlandes Twitter
                                    > > > >
                                    > > > > > -----Original Message-----
                                    > > > > > From: kanbandev@yahoogroups.com
                                    > > > > > [mailto:kanbandev@yahoogroups.com] On Behalf Of Clinton Keith
                                    > > > > > Sent: Monday, February 02, 2009 5:35 PM
                                    > > > > > To: kanbandev@yahoogroups.com
                                    > > > > > Subject: [kanbandev] Gantt to Kanban transition for distributed
                                    > > > > teams?
                                    > > > > >
                                    > > > > > Hi All,
                                    > > > > >
                                    > > > > > I'm helping a friend adopt some lean practices at a company
                                    > > > > > that works
                                    > > > > > in an entirely distributed manner. Right now they use "dot
                                    > > > > > project"
                                    > > > > > Gantt charts to manage schedules for creating complex art assets
                                    > > > > > (levels & such for video games). Any advice for tools to
                                    > > > > > help such a
                                    > > > > > team transition away from Gantt charts on a distributed team?
                                    > > He'll
                                    > > > > > face resistance trying to take too great of a leap at first.
                                    > > > > >
                                    > > > > > Thanks,
                                    > > > > > Clint
                                    > > > > >
                                    > > > > >
                                    > > > > >
                                    > > > > >
                                    > > > > > ------------------------------------
                                    > > > > >
                                    > > > > > Yahoo! Groups Links
                                    > > > > >
                                    > > > > >
                                    > > > > >
                                    > > > > >
                                    > > > >
                                    > > > >
                                    > > >
                                    > >
                                    > >
                                    > >
                                    >


                                  • David J Anderson
                                    It s interesting that you list practices as objectives rather than outcomes. David http://www.agilemanagement.net/ ... teams is ... don t like ... aren t ...
                                    Message 17 of 30 , Feb 8, 2009
                                      It's interesting that you list practices as objectives rather than
                                      outcomes.

                                      David
                                      http://www.agilemanagement.net/

                                      --- In kanbandev@yahoogroups.com, Rob Park <robert.d.park@...> wrote:
                                      >
                                      > "The single biggest factor in improving the performance of software
                                      teams is
                                      > fixing bad management."Do others feel this is true? I certainly
                                      don't like
                                      > bad management, but if your developers aren't say practicing TDD or
                                      aren't
                                      > doing a good job of decoupling or aren't keeping the code base clean by
                                      > mercilessly refactoring, then I'd contend you're better off fixing that.
                                      >
                                      > And if my pm tool is free, then the ROI case on that is a pretty
                                      easy sell.
                                      > :) I used a free wiki to manage my distributed kanban for a year.
                                      The nice
                                      > part about using a wiki was that it was as flexible as a whiteboard and
                                      > allowed us to easily adapt for process improvements.
                                      >
                                      > That said, I don't feel the pm tool has to be free, but it seems that it
                                      > should be in the price range of a big, magnetic whiteboard, some index
                                      > cards, and some magnets. Although in a distributed environment, you
                                      should
                                      > expect to pay a premium for anything that will truly improve
                                      communication.
                                      >
                                      > .rob.
                                      >
                                      > On Fri, Feb 6, 2009 at 11:31 AM, David J Anderson
                                      > <netherby_uk@...>wrote:
                                      >
                                      > > I'm always curious about this insistence on tracking and management
                                      > > tools being free. Why?
                                      > >
                                      > > Is this because management with the budget for tools simply doesn't
                                      > > get it?
                                      > >
                                      > > The evidence is on your side. The single biggest factor in improving
                                      > > the performance of software teams is fixing bad management. You cannot
                                      > > manage without information and you cannot get information without
                                      > > collecting tracking data.
                                      > >
                                      > > So when the ROI is so clear, why do tools need to be free? In theory,
                                      > > I should be willing to pay more for a tracking tool than I'd pay for
                                      > > an IDE because improving the management gives me a bigger boost than
                                      > > improving the efficiency of individual developers.
                                      > >
                                      > > David
                                      > > http://www.agilemanagement.net/
                                      > >
                                      > >
                                      > > --- In kanbandev@yahoogroups.com <kanbandev%40yahoogroups.com>,
                                      Clinton
                                      > > Keith <clintonnkeith@> wrote:
                                      > > >
                                      > > > Hi Greg,
                                      > > >
                                      > > > Thanks for the information. I'm shocked at the lack of tools to
                                      > > > address this need. I'd love to see the tool you are developing
                                      at the
                                      > > > conference or earlier.
                                      > > >
                                      > > > Clint
                                      > > >
                                      > > >
                                      > > > On Feb 4, 2009, at 6:03 PM, Greg Frazer wrote:
                                      > > >
                                      > > > > Hi Clint,
                                      > > > >
                                      > > > > While doing what we can to co-locate the teams at a particular
                                      > > > > geographical site, resource constraints concerning 'off-shored'
                                      > > > > development teams and deep scientific expertise (large Pharma,
                                      > > > > regulatory environment) regularly require us to operate with
                                      > > > > distributed teams. Generally we focus efforts down to teams of ten
                                      > > > > people or less, but could include varying splits on any
                                      combination of
                                      > > > > UK, Italy, India, and two sites in the US.
                                      > > > >
                                      > > > > Many of our teams are mature in Agile/XP, and early last year
                                      > > > > recognized that our local Agile process optimizations kept
                                      aligning
                                      > > > > with many of the Lean approaches.
                                      > > > >
                                      > > > > However, like you, we have been disappointed with the lack of tool
                                      > > > > support for distributed teams. Previously, we suffered from
                                      lack of
                                      > > > > alignment on communicating hand-offs, priorities, and resource
                                      > > > > allocations across sites. We also sought automated, electronic
                                      > > > > tracking to make data-backed policy changes and informed
                                      decisions on
                                      > > > > where to apply more resources.
                                      > > > >
                                      > > > > We verified three half-baked solutions with potential, though none
                                      > > > > were developed specifically as a kanban visual.
                                      > > > > Our best recommendation for commonly available tools would be
                                      to use
                                      > > > > Mingle (from Thoughtworks). It is not free, but your ability to
                                      > > > > customize the card types, states, transitions and visual
                                      'board' to
                                      > > > > your project team/flow was well thought through and implemented.
                                      > > > > There is also a plug-in to Jira called GreenHopper (by
                                      GreenPepper)
                                      > > > > that is similar to Jira and close to free.
                                      > > > > For a lighter-weight option, one of our teams just used a wiki and
                                      > > > > spreadsheet. A number of others mentioned successfully using this
                                      > > > > format at Agile 08. We have found this option is simple and
                                      easy to
                                      > > > > optimize for the particular project flow. It is not a solution
                                      that
                                      > > > > scales well to large corporate portfolio management with plenty of
                                      > > > > editors.
                                      > > > >
                                      > > > > A few of us are four months into building a Flex3 on Ruby tool
                                      that is
                                      > > > > explicitly for use to maintain a card board and provide
                                      statistics on
                                      > > > > flow timings and SLAs. We just started using it on our first
                                      > > > > distributed team two weeks ago. I'll demo this at an open space at
                                      > > > > the Lean conference in May. We would like to make this generally
                                      > > > > available, after sufficient feedback and verification, to help
                                      support
                                      > > > > the evolution of Lean in software. Let me know if anyone is as
                                      > > > > desperate as we were and wants to toss ideas together to help it
                                      > > > > continue to take form.
                                      > > > >
                                      > > > > Cheers,
                                      > > > > Greg Frazer
                                      > > > >
                                      > > > > --- In kanbandev@yahoogroups.com <kanbandev%40yahoogroups.com>,
                                      > > Clinton Keith <clintonnkeith@>
                                      > > > > wrote:
                                      > > > > >
                                      > > > > > Hi Eric,
                                      > > > > >
                                      > > > > > Thanks for the response.
                                      > > > > >
                                      > > > > > This team is distributed however, so the "cards in a visible
                                      place"
                                      > > > > > approach won't work for them.
                                      > > > > >
                                      > > > > > Are there any tools or experiences in doing this on distributed
                                      > > > > > teams? I know that there are Scrum tools and teams that have
                                      done
                                      > > > > > this successfully.
                                      > > > > >
                                      > > > > > Best,
                                      > > > > > Clint
                                      > > > > >
                                      > > > > >
                                      > > > > >
                                      > > > > > On Feb 4, 2009, at 12:01 PM, Landes Eric (CI/AFR2-NA) wrote:
                                      > > > > >
                                      > > > > > >
                                      > > > > > > Clint,
                                      > > > > > > I did not notice any replies to this, so I will tell you my
                                      > > > > > > experiences.
                                      > > > > > > When we first started using a "kanban" approach, the
                                      biggest win
                                      > > > > for
                                      > > > > > > us
                                      > > > > > > was to put all the work we had on cards in a visible
                                      place. The
                                      > > > > team
                                      > > > > > > then got to see constantly what we were working. Also
                                      management
                                      > > > > could
                                      > > > > > > see this every time they came into the teams workspace.
                                      > > > > > >
                                      > > > > > > So you might want to try just putting up a board, putting all
                                      > > > > the work
                                      > > > > > > up there, and what stage the work is at. We used minimal
                                      queues at
                                      > > > > > > first (Backlog, WIP, and Transport is what we called them).
                                      > > > > Today, we
                                      > > > > > > have more queues and have evolved to limiting WIP, and to some
                                      > > > > extent
                                      > > > > > > the queues. Highly visible information radiators really help a
                                      > > > > team
                                      > > > > > > and
                                      > > > > > > management start to focus on the workflow, and in my case
                                      > > > > displayed
                                      > > > > > > the
                                      > > > > > > value of a kanban board to management.
                                      > > > > > >
                                      > > > > > > Eric Landes
                                      > > > > > > Microsoft MVP
                                      > > > > > > http://feeds.feedburner.com/aspadvice/lhVO (My Blog)
                                      > > > > > > http://www.linkedin.com/in/ericlandes Linked In Profile
                                      > > > > > > http://twitter.com/ericlandes Twitter
                                      > > > > > >
                                      > > > > > > > -----Original Message-----
                                      > > > > > > > From: kanbandev@yahoogroups.com
                                      <kanbandev%40yahoogroups.com>
                                      > > > > > > > [mailto:kanbandev@yahoogroups.com
                                      <kanbandev%40yahoogroups.com>]
                                      > > On Behalf Of Clinton Keith
                                      > > > > > > > Sent: Monday, February 02, 2009 5:35 PM
                                      > > > > > > > To: kanbandev@yahoogroups.com <kanbandev%40yahoogroups.com>
                                      > > > > > > > Subject: [kanbandev] Gantt to Kanban transition for
                                      distributed
                                      > > > > > > teams?
                                      > > > > > > >
                                      > > > > > > > Hi All,
                                      > > > > > > >
                                      > > > > > > > I'm helping a friend adopt some lean practices at a company
                                      > > > > > > > that works
                                      > > > > > > > in an entirely distributed manner. Right now they use "dot
                                      > > > > > > > project"
                                      > > > > > > > Gantt charts to manage schedules for creating complex
                                      art assets
                                      > > > > > > > (levels & such for video games). Any advice for tools to
                                      > > > > > > > help such a
                                      > > > > > > > team transition away from Gantt charts on a distributed
                                      team?
                                      > > > > He'll
                                      > > > > > > > face resistance trying to take too great of a leap at first.
                                      > > > > > > >
                                      > > > > > > > Thanks,
                                      > > > > > > > Clint
                                      > > > > > > >
                                      > > > > > > >
                                      > > > > > > >
                                      > > > > > > >
                                      > > > > > > > ------------------------------------
                                      > > > > > > >
                                      > > > > > > > Yahoo! Groups Links
                                      > > > > > > >
                                      > > > > > > >
                                      > > > > > > >
                                      > > > > > > >
                                      > > > > > >
                                      > > > > > >
                                      > > > > >
                                      > > > >
                                      > > > >
                                      > > > >
                                      > > >
                                      > >
                                      > >
                                      > >
                                      >
                                    • Landes Eric (CI/AFR2-NA)
                                      Clint, I agree that convincing the folks in the executive suite is key. And those numbers are key also. I have found that when you consistently produce
                                      Message 18 of 30 , Feb 10, 2009
                                        Clint,
                                        I agree that convincing the folks in the executive suite is key.  And those numbers are key also.  I have found that when you consistently produce metrics that executives understand, it is easier to sell them on spending money on a tool.  For instance, if you say, I am producing these metrics and it takes me X amount of time to finish.  With this new tool, by spending a mere X per developer, I can produce deeper metrics more quickly.  IMO that may be a way to sell purchasing the tool to the guy in the executive suit. 
                                         
                                        In my case, our management believes that purchasing tools adds value, so we support that belief by consistantly demonstrating value.  I am lucky in that way I guess.
                                         
                                         


                                        From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On Behalf Of Clinton Keith
                                        Sent: Friday, February 06, 2009 2:38 PM
                                        To: kanbandev@yahoogroups.com
                                        Subject: Re: [kanbandev] Re: Why free tools? (was Gantt to Kanban transition for distributed teams?)

                                        David,

                                        I'm always curious about this insistence on tracking and management
                                        tools being free. Why?

                                        Great question.  I had to ask myself this question since  that was an important criteria when I was managing projects.

                                        Is this because management with the budget for tools simply doesn't
                                        get it?

                                        This is number one.  Part of it is the licensing conditions that some vendors require (numerous seats up front, service contracts, etc).  Part of it may be a ! history of tools that are too rigid, don't allow customization for a local environment and failed to gain traction.

                                        The evidence is on your side. The single biggest factor in improving
                                        the performance of software teams is fixing bad management. You cannot
                                        manage without information and you cannot get information without
                                        collecting tracking data.

                                        So when the ROI is so clear, why do tools need to be free?

                                        Is it?  It's pretty big leap between buying a tool and "fixing bad management".  WE know it, but we hang out in places like this with people that talk and think about this stuff all day long.  Many te a! ms that wish to "fix bad management" have a greater challenge than simply creating some transparency.

                                        The people in the executive suite certainly don't see the ROI.  These are the people who sit next to the bean counters who pull out the old expense reports from 7 years ago and say "look at how much money we spent on Microsoft Project Server and Project X was still late".  These people don't have any of your books on their shelves.

                                        So the key thing is not to convince ourselves.  It's to address the culture that exists within the executive suites.  That culture trumps methodology, and certainly tools budgets, all the time.  Finding ways to communicate ROI to them in terms they understand and believe in is the challenge.

                                        Just a subjective view...

                                        Clint

                                        Clinton Kei t! h, 





                                      • Brandon Carlson
                                        I ll add one more nugget: As soon as the price for a tool becomes too high then the process starts to support the tool rather than the tool supporting the
                                        Message 19 of 30 , Feb 10, 2009
                                          I'll add one more nugget:

                                          As soon as the price for a tool becomes too high then the process
                                          starts to support the tool rather than the tool supporting the
                                          process.

                                          I've witnessed time and time again where a buying a fancy tool that
                                          generates charts becomes the centerpiece of the process, not the flow
                                          of value.

                                          Thanks!
                                          Brandon

                                          On Tue, Feb 10, 2009 at 8:13 AM, Landes Eric (CI/AFR2-NA)
                                          <eric.landes@...> wrote:
                                          > Clint,
                                          > I agree that convincing the folks in the executive suite is key. And those
                                          > numbers are key also. I have found that when you consistently produce
                                          > metrics that executives understand, it is easier to sell them on spending
                                          > money on a tool. For instance, if you say, I am producing these metrics and
                                          > it takes me X amount of time to finish. With this new tool, by spending a
                                          > mere X per developer, I can produce deeper metrics more quickly. IMO that
                                          > may be a way to sell purchasing the tool to the guy in the executive suit.
                                          >
                                          > In my case, our management believes that purchasing tools adds value, so we
                                          > support that belief by consistantly demonstrating value. I am lucky in that
                                          > way I guess.
                                          >
                                          >
                                          > Eric Landes
                                          >
                                          > Microsoft MVP
                                          >
                                          > http://feeds.feedburner.com/aspadvice/lhVO (My Blog)
                                          >
                                          > http://www.linkedin.com/in/ericlandes Linked In Profile
                                          >
                                          > http://twitter.com/ericlandes Twitter
                                          >
                                          >
                                          >
                                          > ________________________________
                                          > From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On Behalf
                                          > Of Clinton Keith
                                          > Sent: Friday, February 06, 2009 2:38 PM
                                          > To: kanbandev@yahoogroups.com
                                          > Subject: Re: [kanbandev] Re: Why free tools? (was Gantt to Kanban transition
                                          > for distributed teams?)
                                          >
                                          > David,
                                          >
                                          > I'm always curious about this insistence on tracking and management
                                          > tools being free. Why?
                                          >
                                          > Great question. I had to ask myself this question since that was an
                                          > important criteria when I was managing projects.
                                          >
                                          > Is this because management with the budget for tools simply doesn't
                                          > get it?
                                          >
                                          > This is number one. Part of it is the licensing conditions that some
                                          > vendors require (numerous seats up front, service contracts, etc). Part of
                                          > it may be a ! history of tools that are too rigid, don't allow customization
                                          > for a local environment and failed to gain traction.
                                          >
                                          > The evidence is on your side. The single biggest factor in improving
                                          > the performance of software teams is fixing bad management. You cannot
                                          > manage without information and you cannot get information without
                                          > collecting tracking data.
                                          >
                                          > So when the ROI is so clear, why do tools need to be free?
                                          >
                                          > Is it? It's pretty big leap between buying a tool and "fixing bad
                                          > management". WE know it, but we hang out in places like this with people
                                          > that talk and think about this stuff all day long. Many te a! ms that wish
                                          > to "fix bad management" have a greater challenge than simply creating
                                          > some transparency.
                                          > The people in the executive suite certainly don't see the ROI. These are
                                          > the people who sit next to the bean counters who pull out the old expense
                                          > reports from 7 years ago and say "look at how much money we spent on
                                          > Microsoft Project Server and Project X was still late". These people don't
                                          > have any of your books on their shelves.
                                          > So the key thing is not to convince ourselves. It's to address the culture
                                          > that exists within the executive suites. That culture trumps methodology,
                                          > and certainly tools budgets, all the time. Finding ways to communicate ROI
                                          > to them in terms they understand and believe in is the challenge.
                                          > Just a subjective view...
                                          > Clint
                                          > Clinton Kei t! h,
                                          > clint@... | www.clintonkeith.com
                                          >
                                          >
                                          >
                                          >
                                          >
                                        • Robin Dymond
                                          Great point Brandon. EVERY instance of Rational Clearxxxx that I have seen has warped internal thinking as you suggest. The tool is very expensive so we must
                                          Message 20 of 30 , Feb 11, 2009
                                            Great point Brandon.

                                            EVERY instance of Rational Clearxxxx that I have seen has warped
                                            internal thinking as you suggest. The tool is very expensive so we
                                            must use it in these labor intensive and wasteful ways. Meanwhile the
                                            tool regularly crashes and slows down the team with obese process.

                                            Robin

                                            On 2/11/09, Brandon Carlson <bcarlso@...> wrote:
                                            > I'll add one more nugget:
                                            >
                                            > As soon as the price for a tool becomes too high then the process
                                            > starts to support the tool rather than the tool supporting the
                                            > process.
                                            >
                                            > I've witnessed time and time again where a buying a fancy tool that
                                            > generates charts becomes the centerpiece of the process, not the flow
                                            > of value.
                                            >
                                            > Thanks!
                                            > Brandon
                                            >
                                            > On Tue, Feb 10, 2009 at 8:13 AM, Landes Eric (CI/AFR2-NA)
                                            > <eric.landes@...> wrote:
                                            >> Clint,
                                            >> I agree that convincing the folks in the executive suite is key. And
                                            >> those
                                            >> numbers are key also. I have found that when you consistently produce
                                            >> metrics that executives understand, it is easier to sell them on spending
                                            >> money on a tool. For instance, if you say, I am producing these metrics
                                            >> and
                                            >> it takes me X amount of time to finish. With this new tool, by spending a
                                            >> mere X per developer, I can produce deeper metrics more quickly. IMO that
                                            >> may be a way to sell purchasing the tool to the guy in the executive suit.
                                            >>
                                            >> In my case, our management believes that purchasing tools adds value, so
                                            >> we
                                            >> support that belief by consistantly demonstrating value. I am lucky in
                                            >> that
                                            >> way I guess.
                                            >>
                                            >>
                                            >> Eric Landes
                                            >>
                                            >> Microsoft MVP
                                            >>
                                            >> http://feeds.feedburner.com/aspadvice/lhVO (My Blog)
                                            >>
                                            >> http://www.linkedin.com/in/ericlandes Linked In Profile
                                            >>
                                            >> http://twitter.com/ericlandes Twitter
                                            >>
                                            >>
                                            >>
                                            >> ________________________________
                                            >> From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On
                                            >> Behalf
                                            >> Of Clinton Keith
                                            >> Sent: Friday, February 06, 2009 2:38 PM
                                            >> To: kanbandev@yahoogroups.com
                                            >> Subject: Re: [kanbandev] Re: Why free tools? (was Gantt to Kanban
                                            >> transition
                                            >> for distributed teams?)
                                            >>
                                            >> David,
                                            >>
                                            >> I'm always curious about this insistence on tracking and management
                                            >> tools being free. Why?
                                            >>
                                            >> Great question. I had to ask myself this question since that was an
                                            >> important criteria when I was managing projects.
                                            >>
                                            >> Is this because management with the budget for tools simply doesn't
                                            >> get it?
                                            >>
                                            >> This is number one. Part of it is the licensing conditions that some
                                            >> vendors require (numerous seats up front, service contracts, etc). Part
                                            >> of
                                            >> it may be a ! history of tools that are too rigid, don't allow
                                            >> customization
                                            >> for a local environment and failed to gain traction.
                                            >>
                                            >> The evidence is on your side. The single biggest factor in improving
                                            >> the performance of software teams is fixing bad management. You cannot
                                            >> manage without information and you cannot get information without
                                            >> collecting tracking data.
                                            >>
                                            >> So when the ROI is so clear, why do tools need to be free?
                                            >>
                                            >> Is it? It's pretty big leap between buying a tool and "fixing bad
                                            >> management". WE know it, but we hang out in places like this with people
                                            >> that talk and think about this stuff all day long. Many te a! ms that
                                            >> wish
                                            >> to "fix bad management" have a greater challenge than simply creating
                                            >> some transparency.
                                            >> The people in the executive suite certainly don't see the ROI. These are
                                            >> the people who sit next to the bean counters who pull out the old expense
                                            >> reports from 7 years ago and say "look at how much money we spent on
                                            >> Microsoft Project Server and Project X was still late". These people
                                            >> don't
                                            >> have any of your books on their shelves.
                                            >> So the key thing is not to convince ourselves. It's to address the
                                            >> culture
                                            >> that exists within the executive suites. That culture trumps methodology,
                                            >> and certainly tools budgets, all the time. Finding ways to communicate
                                            >> ROI
                                            >> to them in terms they understand and believe in is the challenge.
                                            >> Just a subjective view...
                                            >> Clint
                                            >> Clinton Kei t! h,
                                            >> clint@... | www.clintonkeith.com
                                            >>
                                            >>
                                            >>
                                            >>
                                            >>
                                            >


                                            --
                                            Robin Dymond, CST
                                            Managing Partner, Innovel, LLC.
                                            www.innovel.net
                                            www.scrumtraining.com
                                            (804) 239-4329
                                          • Brandon Carlson
                                            Thanks Robin, I d like to clarify one additional thing. The cost that I refer to is the combination of acquisition cost *and* cost of change. Even if you have
                                            Message 21 of 30 , Feb 11, 2009
                                              Thanks Robin,

                                              I'd like to clarify one additional thing. The cost that I refer to is
                                              the combination of acquisition cost *and* cost of change. Even if you
                                              have a free tool but you've invested heavily in
                                              configuration/documentation, the problem remains the same. The process
                                              becomes rigid and resistant to change.

                                              Thanks!
                                              Brandon

                                              On Wed, Feb 11, 2009 at 2:46 AM, Robin Dymond <rdymond@...> wrote:
                                              > Great point Brandon.
                                              >
                                              > EVERY instance of Rational Clearxxxx that I have seen has warped
                                              > internal thinking as you suggest. The tool is very expensive so we
                                              > must use it in these labor intensive and wasteful ways. Meanwhile the
                                              > tool regularly crashes and slows down the team with obese process.
                                              >
                                              > Robin
                                              >
                                              > On 2/11/09, Brandon Carlson <bcarlso@...> wrote:
                                              >> I'll add one more nugget:
                                              >>
                                              >> As soon as the price for a tool becomes too high then the process
                                              >> starts to support the tool rather than the tool supporting the
                                              >> process.
                                              >>
                                              >> I've witnessed time and time again where a buying a fancy tool that
                                              >> generates charts becomes the centerpiece of the process, not the flow
                                              >> of value.
                                              >>
                                              >> Thanks!
                                              >> Brandon
                                              >>
                                              >> On Tue, Feb 10, 2009 at 8:13 AM, Landes Eric (CI/AFR2-NA)
                                              >> <eric.landes@...> wrote:
                                              >>> Clint,
                                              >>> I agree that convincing the folks in the executive suite is key. And
                                              >>> those
                                              >>> numbers are key also. I have found that when you consistently produce
                                              >>> metrics that executives understand, it is easier to sell them on spending
                                              >>> money on a tool. For instance, if you say, I am producing these metrics
                                              >>> and
                                              >>> it takes me X amount of time to finish. With this new tool, by spending a
                                              >>> mere X per developer, I can produce deeper metrics more quickly. IMO that
                                              >>> may be a way to sell purchasing the tool to the guy in the executive
                                              >>> suit.
                                              >>>
                                              >>> In my case, our management believes that purchasing tools adds value, so
                                              >>> we
                                              >>> support that belief by consistantly demonstrating value. I am lucky in
                                              >>> that
                                              >>> way I guess.
                                              >>>
                                              >>>
                                              >>> Eric Landes
                                              >>>
                                              >>> Microsoft MVP
                                              >>>
                                              >>> http://feeds.feedburner.com/aspadvice/lhVO (My Blog)
                                              >>>
                                              >>> http://www.linkedin.com/in/ericlandes Linked In Profile
                                              >>>
                                              >>> http://twitter.com/ericlandes Twitter
                                              >>>
                                              >>>
                                              >>>
                                              >>> ________________________________
                                              >>> From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On
                                              >>> Behalf
                                              >>> Of Clinton Keith
                                              >>> Sent: Friday, February 06, 2009 2:38 PM
                                              >>> To: kanbandev@yahoogroups.com
                                              >>> Subject: Re: [kanbandev] Re: Why free tools? (was Gantt to Kanban
                                              >>> transition
                                              >>> for distributed teams?)
                                              >>>
                                              >>> David,
                                              >>>
                                              >>> I'm always curious about this insistence on tracking and management
                                              >>> tools being free. Why?
                                              >>>
                                              >>> Great question. I had to ask myself this question since that was an
                                              >>> important criteria when I was managing projects.
                                              >>>
                                              >>> Is this because management with the budget for tools simply doesn't
                                              >>> get it?
                                              >>>
                                              >>> This is number one. Part of it is the licensing conditions that some
                                              >>> vendors require (numerous seats up front, service contracts, etc). Part
                                              >>> of
                                              >>> it may be a ! history of tools that are too rigid, don't allow
                                              >>> customization
                                              >>> for a local environment and failed to gain traction.
                                              >>>
                                              >>> The evidence is on your side. The single biggest factor in improving
                                              >>> the performance of software teams is fixing bad management. You cannot
                                              >>> manage without information and you cannot get information without
                                              >>> collecting tracking data.
                                              >>>
                                              >>> So when the ROI is so clear, why do tools need to be free?
                                              >>>
                                              >>> Is it? It's pretty big leap between buying a tool and "fixing bad
                                              >>> management". WE know it, but we hang out in places like this with people
                                              >>> that talk and think about this stuff all day long. Many te a! ms that
                                              >>> wish
                                              >>> to "fix bad management" have a greater challenge than simply creating
                                              >>> some transparency.
                                              >>> The people in the executive suite certainly don't see the ROI. These are
                                              >>> the people who sit next to the bean counters who pull out the old expense
                                              >>> reports from 7 years ago and say "look at how much money we spent on
                                              >>> Microsoft Project Server and Project X was still late". These people
                                              >>> don't
                                              >>> have any of your books on their shelves.
                                              >>> So the key thing is not to convince ourselves. It's to address the
                                              >>> culture
                                              >>> that exists within the executive suites. That culture trumps methodology,
                                              >>> and certainly tools budgets, all the time. Finding ways to communicate
                                              >>> ROI
                                              >>> to them in terms they understand and believe in is the challenge.
                                              >>> Just a subjective view...
                                              >>> Clint
                                              >>> Clinton Kei t! h,
                                              >>> clint@... | www.clintonkeith.com
                                              >>>
                                              >>>
                                              >>>
                                              >>>
                                              >>>
                                              >>
                                              >
                                              > --
                                              > Robin Dymond, CST
                                              > Managing Partner, Innovel, LLC.
                                              > www.innovel.net
                                              > www.scrumtraining.com
                                              > (804) 239-4329
                                              >
                                            • Mattias Skarin
                                              Would be nice to hear real experience from someone experimenting a bit with this.. For example: trying Kanban with monthly demos.. After inserting a
                                              Message 22 of 30 , Mar 23, 2009
                                                Would be nice to hear real experience from someone experimenting a bit
                                                with this..
                                                For example: trying Kanban with monthly demos..

                                                After inserting a demosession in one kanbanteam once it encourages me to
                                                try and learn abit more around the subject. Craftmanship proudness,
                                                emergence of new ideas, alignment around value focus are some positive
                                                sideeffects.
                                              • Janice Linden-Reed
                                                Our teams are on a kanban system but we still use iterations and an iteration planning meeting, iteration demo and retrospective. The iteration planning
                                                Message 23 of 30 , Mar 24, 2009

                                                  Our teams are on a kanban system but we still use iterations and an iteration planning meeting, iteration demo and retrospective.

                                                   

                                                  The iteration planning meeting allows the team to preview the upcoming queue. It gives the team the chance to talk about the planned stories with the product owners, poke holes in the requirements, question the priorities….  Most importantly, it gives the team a chance to take a breath and step back.  They are usually so heads-down in development that it is hard for them to get the big picture, a la how stories relate to the product roadmap.

                                                   

                                                  The batch of stories that comes out of iteration planning is the pool of stories from which the team pulls during the iteration.

                                                   

                                                  This meeting takes 2 hours every 3 weeks.

                                                   

                                                  We don't size the stories or even set acceptance criteria at the planning meeting.  That is done as each story is pulled during the iteration.

                                                   

                                                  Unfortunately, there is still the implied scrum-concept of team commitment to that set of stories for that iteration.  There is also the notion that new stories cannot be introduced during the iteration, which is just ridiculous.  For this reason, I am trying to move away from iterations, but it is taking some time, mainly due to product owner concerns that there won't be any schedule pressure if we abandon iterations.

                                                   

                                                  Janice Linden-Reed
                                                  Sr. Project Manager
                                                  Posit Science

                                                  www.PositScience.com

                                                  Your brain will thank you.™

                                                   


                                                  From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On Behalf Of Mattias Skarin
                                                  Sent: Monday, March 23, 2009 12:59 AM
                                                  To: kanbandev@yahoogroups.com
                                                  Subject: [kanbandev] Re: Is there a lack of perceived schedule pressure in Kanban?

                                                   

                                                  Would be nice to hear real experience from someone experimenting a bit
                                                  with this..
                                                  For example: trying Kanban with monthly demos..

                                                  After inserting a demosession in one kanbanteam once it encourages me to
                                                  try and learn abit more around the subject. Craftmanship proudness,
                                                  emergence of new ideas, alignment around value focus are some positive
                                                  sideeffects.

                                                • chrisjmatts1968
                                                  As the fat controller ( Scrum Master, Kanban Sensei whatever ) on the project, one of the things I struggled with was keeping track of the developer s
                                                  Message 24 of 30 , Mar 25, 2009
                                                    As the fat controller ( Scrum Master, Kanban Sensei whatever ) on the project, one of the things I struggled with was keeping track of the developer's commitments. i.e. when they said they would finish a task.

                                                    It is not a problem that they slip as it normally out of their control, but with a biggish team I need to keep on top of it.

                                                    The approach we adopted, ( which seems to work ) was to expand the "Work in Progress" state to have the days of the week across the top... Mon / Tues / Wed / Thurs / Fri. Each developer states when they think they will finish a task and the card is placed below that day of the week. As all tasks are five days or less ( or else broken down ), the system wraps nicely without having to re-adjust the days.

                                                    At the daily stand-up, each developer says whether...

                                                    1. They are on track.
                                                    2. They have finished ( Deploy the red pen of success to tick the card )
                                                    3. They are slipping ( The slide of shame )
                                                    4. Going to finish early ( LOL )

                                                    I find it is an nice lightweight means of remembering when jobs are meant to be done, and provides a reminder to the developer.

                                                    Is it possible this is a lightweight way of achieving schedule pressure in Kanban without the overhead of release planning?
                                                  • Troy Tuttle
                                                    How much time do team members typically spend on estimating the time for a task? When you notice a number of missed dates, is there effort put into making
                                                    Message 25 of 30 , Mar 26, 2009
                                                      How much time do team members typically spend on estimating the time for a task?  When you notice a number of missed dates, is there effort put into making better estimations or root-cause analysis?

                                                      On Wed, Mar 25, 2009 at 4:21 AM, chrisjmatts1968 <chris.matts@...> wrote:
                                                      As the fat controller ( Scrum Master, Kanban Sensei whatever ) on the project, one of the things I struggled with was keeping track of the developer's commitments. i.e. when they said they would finish a task.

                                                      It is not a problem that they slip as it normally out of their control, but with a biggish team I need to keep on top of it.

                                                      The approach we adopted, ( which seems to work ) was to expand the "Work in Progress" state to have the days of the week across the top... Mon / Tues / Wed / Thurs / Fri. Each developer states when they think they will finish a task and the card is placed below that day of the week. As all tasks are five days or less ( or else broken down ), the system wraps nicely without having to re-adjust the days.

                                                      At the daily stand-up, each developer says whether...

                                                      1. They are on track.
                                                      2. They have finished ( Deploy the red pen of success to tick the card )
                                                      3. They are slipping ( The slide of shame )
                                                      4. Going to finish early ( LOL )

                                                      I find it is an nice lightweight means of remembering when jobs are meant to be done, and provides a reminder to the developer.

                                                      Is it possible this is a lightweight way of achieving schedule pressure in Kanban without the overhead of release planning?


                                                      __._

                                                    • chrisjmatts1968
                                                      Troy ... Seconds rather than minutes. For each MMF, we have a white board session to identify the tasks. We start from the outputs and work back to the inputs,
                                                      Message 26 of 30 , Mar 27, 2009
                                                        Troy

                                                        > How much time do team members typically spend on estimating the time for a task?

                                                        Seconds rather than minutes.

                                                        For each MMF, we have a white board session to identify the tasks. We start from the outputs and work back to the inputs, identifying changes to the system as we go. I stick a card to the board for each change. At the end of the session, the team provide estimates using Karl Scotland's t-shirt sizing (S - 1 day /M - 2 day / L - 5 days). Todd Little showed that actual versus estimate has a lognormal distribution ( http://www.toddlittleweb.com/Papers/Little%20Cone%20of%20Uncertainty.pdf ) so there is no real value in making the estimates any more accurate. I will often nudge the estimates up if I do not think the team have correctly assessed the complexity. I rarely if ever revise an estimate down.

                                                        On my previous project I asked the project manager to estimate 20 cards as S/M/L. He took under 30 seconds.

                                                        > When you notice a number of missed dates, is there effort put into
                                                        > making better estimations or root-cause analysis?

                                                        As a result of the credit crunch, the Bank has announced they are closing the business I support ( Exotic Credit Derivatives ). This means that the team is shrinking, including support, and the development team often have to assist with support issues. "Bad" estimation has a minor effect on dates compared to interruptions. Interruptions cannot be planned for other than to increase team size or slack, two options that are not available.

                                                        To hit the dates for the MMF, we will descope a lot of features that are sometimes considered essential. For example, We only build GUIs that are frequently used. GUIs to maintain static that changes once a month or less are deferred to "Phase 2", and that data is maintained through SQL scripts instead.

                                                        In other words, the main way we achieve deadlines is to avoid unnecessary features.
                                                      • Mattias Skarin
                                                        ... Hmm.. this is a bit off the original thread.. We spend 30-40min per week. Each week 1-2 new projects/stories are introduced.
                                                        Message 27 of 30 , Mar 28, 2009
                                                          >How much time do team members typically spend on estimating the time for a
                                                          >task? When you notice a number of missed dates, is there effort put into
                                                          >making better estimations or root-cause analysis?

                                                          Hmm.. this is a bit off the original thread..
                                                          We spend 30-40min per week. Each week 1-2 new projects/stories are
                                                          introduced.
                                                        • Ted Young
                                                          ... How long do these whiteboard sessions last? And is the whole team (devs, testers, etc.) included in these session or just a few people? ;ted
                                                          Message 28 of 30 , Mar 28, 2009
                                                            On Fri, Mar 27, 2009 at 4:05 AM, chrisjmatts1968 <chris.matts@...> wrote:
                                                            > For each MMF, we have a white board session to identify the tasks.

                                                            How long do these whiteboard sessions last? And is the whole team
                                                            (devs, testers, etc.) included in these session or just a few people?

                                                            ;ted
                                                          • Chris
                                                            About an hour. Everyone is involved Sent from my iPhone
                                                            Message 29 of 30 , Mar 28, 2009
                                                              About an hour. Everyone is involved

                                                              Sent from my iPhone

                                                              On 28 Mar 2009, at 19:26, Ted Young <tedyoung@...> wrote:

                                                              On Fri, Mar 27, 2009 at 4:05 AM, chrisjmatts1968 <chris.matts@ gmail.com> wrote:
                                                              > For each MMF, we have a white board session to identify the tasks.

                                                              How long do these whiteboard sessions last? And is the whole team
                                                              (devs, testers, etc.) included in these session or just a few people?

                                                              ;ted

                                                            • davenicolette
                                                              Hi Tim, My 2 cents: I think Scrum is a great tool for teams/organizations that have certain characteristics, specifically because it forces people to change
                                                              Message 30 of 30 , Mar 31, 2009
                                                                Hi Tim,

                                                                My 2 cents: I think Scrum is a great tool for teams/organizations that have certain characteristics, specifically because it "forces" people to change non value-add behaviors.

                                                                The feeling of "pressure" created by time-boxing is one of the ways Scrum forces the team/organization to take steps toward a culture characterized by a "sense of urgency," as defined (for instance) by John Kotter. As the people cultivate a positive sense of urgency, they will start to be driven by a focus on value rather than by fear of a deadline. I would say "schedule pressure" is a means to an end - helping teams/organizations shift their culture in the right direction. After they've shifted beyond a critical point on the spectrum, they no longer need artificial pressure to force them to continue delivering value.

                                                                Scrum "forces" things in other ways, too; for example, the specific roles "force" people to take personal accountability for results. This is great in an organization whose culture is based on blame-avoidance and "looking busy." By calling for "whole team" and "cross-functional team," and defining certain time-boxed rituals/ceremonies, Scrum "forces" people to communicate and collaborate with each other. Once they learn to do those things routinely, they no longer have to be forced into doing it. Scrum "forces" people to get into a steady rhythm of delivering incremental value. This is useful in organizations where the norm has been to deliver nothing for months or years on end. Once the people get into the habit of regular delivery, the need to force them into it goes away. Scrum "forces" people to review their work and talk about how to improve it by calling for regular retrospectives and by emphasizing values of trust and transparency. That's very useful in organizations where the culture has been to avoid discussing problems. Once the organization adopts continuous improvement as a normal practice, there ceases to be any need to force them to do it.

                                                                The notion of "scrumban" or evolution from Scrum toward kanban is a manifestation of this process of organizational maturation, too. If this view of Scrum makes sense to you, then maybe you can see that "schedule pressure" is (or should be) a temporary measure to deal with specific organizational problems, and not a goal in its own right. If kanban lacks this sort of built-in pressure, it's for positive reasons and not because the "need" for schedule pressure has been overlooked.

                                                                Cheers,
                                                                Dave

                                                                --- In kanbandev@yahoogroups.com, "timuttormark" <timuttormark@...> wrote:
                                                                >
                                                                > I'm experienced with Scrum but just learning about Kanban. There is
                                                                > one aspect of Scrum which I am trying to compare against Kanban, that
                                                                > is the pressure to produce as experienced by members of the team.
                                                                >
                                                                > In Scrum development the team makes a commitment (to the product
                                                                > owners and themselves) to finish a set of stories during each
                                                                > iteration. Then each day in the daily standup, team members again
                                                                > make commitments to their peers about which task(s) they plan to
                                                                > finish that day.
                                                                >
                                                                > These regular commitments in Scrum result in a perceived pressure for
                                                                > individual team members to produce. This can result from peer
                                                                > pressure, integrity (keeping one's word), increased ownership (having
                                                                > made the commitments themselves, as opposed to having them dictated by
                                                                > management), or simply fear (of appearing not to be pulling one's
                                                                > weight relative to the rest of the team). These are all aspects of
                                                                > the maxim "deadlines get things done".
                                                                >
                                                                > This sense of pressure is not necessarily positive. While it can
                                                                > result in increased output by each team member, it can also backfire
                                                                > and cause some people to cut corners in the short term (declaring
                                                                > tasks as "done" with poor quality or net positive technical debt), and
                                                                > to cause others to experience burn-out in the long run.
                                                                >
                                                                > How is this reflected in Kanban? I know that some units of work
                                                                > (tasks/stories/CRs/whatever) can have individual deadlines. How does
                                                                > the lack of other artificial deadlines (created and imposed by other
                                                                > processes such as Scrum) help or hinder in Kanban?
                                                                >
                                                                > Thanks,
                                                                > -- Tim Uttormark
                                                                >
                                                              Your message has been successfully submitted and would be delivered to recipients shortly.