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

Kanban for Network Services team

Expand Messages
  • jgmack
    All- I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution. Is anyone using kanban in
    Message 1 of 16 , Sep 29, 2011
    View Source
    • 0 Attachment
      All-
      I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.

      Is anyone using kanban in this scenario? Any advice for me?

      Here's what we have done so far:
      The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.

      Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.

      I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.

      Looking forward to hearing your ideas! TIA!
      Jim Mack
    • Robert Swanbum
      Get them to run the meeting(s) as soon as you can so they have ownership of the work.  We (managers) stepped into the audience during meetings and just
      Message 2 of 16 , Sep 29, 2011
      View Source
      • 0 Attachment
        Get 'them' to run the meeting(s) as soon as you can so they have ownership of the work.  We (managers) stepped into the audience during meetings and just advised when things were either going awry with Kanban rules or in decisions to change the process.

        From: jgmack <jgmack@...>
        To: kanbanops@yahoogroups.com
        Sent: Thursday, September 29, 2011 10:48 AM
        Subject: [kanbanops] Kanban for Network Services team

         
        All-
        I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.

        Is anyone using kanban in this scenario? Any advice for me?

        Here's what we have done so far:
        The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.

        Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.

        I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.

        Looking forward to hearing your ideas! TIA!
        Jim Mack



      • mj.wivell
        Jim, We ve worked with several operations teams to set up a Kanban System. I ve found that the most important part is two-fold: 1) Setting up the input queue
        Message 3 of 16 , Sep 30, 2011
        View Source
        • 0 Attachment
          Jim,

          We've worked with several operations teams to set up a Kanban System.

          I've found that the most important part is two-fold:
          1) Setting up the input queue meeting
          2) Facilitating the input queue meeting with discipline

          It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."

          In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.

          Getting that meeting right helped set up success in many other areas.

          MJ Wivell
          www.bti360.com

          --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@...> wrote:
          >
          > All-
          > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
          >
          > Is anyone using kanban in this scenario? Any advice for me?
          >
          > Here's what we have done so far:
          > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
          >
          > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
          >
          > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
          >
          > Looking forward to hearing your ideas! TIA!
          > Jim Mack
          >
        • Ian Carroll
          Hi Jim, Here s an overview of our Networks team Kanban system, please see photo below: Demand column: Used to visualise the various stakeholders and to get
          Message 4 of 16 , Sep 30, 2011
          View Source
          • 0 Attachment

            Hi Jim,

            Here's an overview of our Networks team Kanban system, please see photo below:

            Demand column:

            Used to visualise the various stakeholders and to get them thinking about priorities. This is sub-divided into the various projects or sources of demand with the highest priority items being to the right and the lowest to the left. The cards hanging off the board to the left are the rest of the backlog. 

            Input column:

            This is possibly the most important column on the board. This column drives out the prioritisation conversation with stakeholders and provides protection for the delivery team. It forces conversations that used to be avoided and often pushed onto the delivery team to prioritise.

            WIP column:

            Team members pull work from the Input column only when they are ready to do so. If they get blocked on a piece of work, they first focus on unblocking the issue or assist other team members with their tasks.

            Schedule column:

            Once a piece of work has been done it often has to wait for a scheduled maintenance window (often out of hours) before it can be deployed and put live. This column is kind of a waiting for release column and used to plan maintenance windows.

            Long term blockers:

            The section directly above the board with lots of cards with magenta post-its on it is the long term blockers area. This team deals with many 3rd parties and regularly get blocked whilst waiting for the 3rd party to complete something. Unfortunately, the contracts with these 3rd parties do not provide enough leverage to get them to respond quicker so the team could only make them visible. Making them visible enables senior management to see exactly who was blocking them and chase suppliers on a daily basis, applying pressure where possible.

            Waste Envelope:

            Any waste incurred by the team is captured, quantified, and stored in the waste envelope for discussion during retrospectives.

            Blockers Envelope:

            All magenta post-it notes (blockers) are kept once the blockage has been removed. These blockers are then analysed during retrospectives to look for trends, common blockages, or any other intel to assist in improving the process.

            Metrics:

            The team have stuck a paper based metrics form to the right of the board to simplify the generation of a Cumulative Flow Diagram (CFD). They find it easier to write the card count for each column on the form and then update the electronic chart periodically – say at the end of each week.

            “The Infra Card”:

            Each day a new card is inserted directly into the WIP column (a slot is reserved so as not to blow wip limit). Each day between 13:30 and 15:00 the team hit the Infra queues (Infra is the departmental electronic ticketing/job system) for their team and complete what they can within the time box. The number of completed jobs/tickets in Infra is added to the card and its then placed in the done column. The number of jobs/tickets completed is added to the CFD done value.


            Cheers,

            Ian.


            On 30 Sep 2011, at 13:12, mj.wivell wrote:

             

            Jim,

            We've worked with several operations teams to set up a Kanban System.

            I've found that the most important part is two-fold:
            1) Setting up the input queue meeting
            2) Facilitating the input queue meeting with discipline

            It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."

            In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.

            Getting that meeting right helped set up success in many other areas.

            MJ Wivell
            www.bti360.com

            --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@...> wrote:
            >
            > All-
            > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
            >
            > Is anyone using kanban in this scenario? Any advice for me?
            >
            > Here's what we have done so far:
            > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
            >
            > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
            >
            > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
            >
            > Looking forward to hearing your ideas! TIA!
            > Jim Mack
            >


          • Robert Swanbum
            +1   From: mj.wivell To: kanbanops@yahoogroups.com Sent: Friday, September 30, 2011 7:12 AM Subject: [kanbanops] Re: Kanban for Network
            Message 5 of 16 , Sep 30, 2011
            View Source
            • 0 Attachment

              +1
               
              From: mj.wivell <mjwivell@...>
              To: kanbanops@yahoogroups.com
              Sent: Friday, September 30, 2011 7:12 AM
              Subject: [kanbanops] Re: Kanban for Network Services team

               
              Jim,

              We've worked with several operations teams to set up a Kanban System.

              I've found that the most important part is two-fold:
              1) Setting up the input queue meeting
              2) Facilitating the input queue meeting with discipline

              It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."

              In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.

              Getting that meeting right helped set up success in many other areas.

              MJ Wivell
              www.bti360.com

              --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@...> wrote:
              >
              > All-
              > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
              >
              > Is anyone using kanban in this scenario? Any advice for me?
              >
              > Here's what we have done so far:
              > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
              >
              > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
              >
              > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
              >
              > Looking
              forward to hearing your ideas! TIA!
              > Jim Mack
              >



            • Joe Miller
              Ian, that was a great writeup. Something we have been wrestling with on our ops teams kanban board lately now that we are tracking metrics in a CFD is how to
              Message 6 of 16 , Sep 30, 2011
              View Source
              • 0 Attachment
                Ian, that was a great writeup. 

                Something we have been wrestling with on our ops teams' kanban board lately now that we are tracking metrics in a CFD is how to handle story "sizes".  The information communicated by the CFD isn't very good if the sizes of each story vary widely. Our stories can vary widely in size, since we handle small requests that can take 30-60 minutes, and large requests that take multiple days.

                The most common approach I've heard is to try to make all tasks as similarly sized as possible using various techniques (goldilocks estimation, etc).  I'm hesitant to go this route because it seems like it would add more overheard than necessary and could even clutter the board significantly with a huge backlog of small tasks that lose a larger context.  I've also though about giving tickets a simple 1,2,3 sizing, eg: size of 1 = <1 hour.  size of 2 is up to 1 day.  and a size of 3 is anything that is a multiple day effort.

                I'm curious what others have done, especially with kanban in ops teams, to deal with story sizing and getting good metrics.

                On Fri, Sep 30, 2011 at 5:40 AM, Ian Carroll <cazano7@...> wrote:

                Hi Jim,

                Here's an overview of our Networks team Kanban system, please see photo below:

                Demand column:

                Used to visualise the various stakeholders and to get them thinking about priorities. This is sub-divided into the various projects or sources of demand with the highest priority items being to the right and the lowest to the left. The cards hanging off the board to the left are the rest of the backlog. 

                Input column:

                This is possibly the most important column on the board. This column drives out the prioritisation conversation with stakeholders and provides protection for the delivery team. It forces conversations that used to be avoided and often pushed onto the delivery team to prioritise.

                WIP column:

                Team members pull work from the Input column only when they are ready to do so. If they get blocked on a piece of work, they first focus on unblocking the issue or assist other team members with their tasks.

                Schedule column:

                Once a piece of work has been done it often has to wait for a scheduled maintenance window (often out of hours) before it can be deployed and put live. This column is kind of a waiting for release column and used to plan maintenance windows.

                Long term blockers:

                The section directly above the board with lots of cards with magenta post-its on it is the long term blockers area. This team deals with many 3rd parties and regularly get blocked whilst waiting for the 3rd party to complete something. Unfortunately, the contracts with these 3rd parties do not provide enough leverage to get them to respond quicker so the team could only make them visible. Making them visible enables senior management to see exactly who was blocking them and chase suppliers on a daily basis, applying pressure where possible.

                Waste Envelope:

                Any waste incurred by the team is captured, quantified, and stored in the waste envelope for discussion during retrospectives.

                Blockers Envelope:

                All magenta post-it notes (blockers) are kept once the blockage has been removed. These blockers are then analysed during retrospectives to look for trends, common blockages, or any other intel to assist in improving the process.

                Metrics:

                The team have stuck a paper based metrics form to the right of the board to simplify the generation of a Cumulative Flow Diagram (CFD). They find it easier to write the card count for each column on the form and then update the electronic chart periodically – say at the end of each week.

                “The Infra Card”:

                Each day a new card is inserted directly into the WIP column (a slot is reserved so as not to blow wip limit). Each day between 13:30 and 15:00 the team hit the Infra queues (Infra is the departmental electronic ticketing/job system) for their team and complete what they can within the time box. The number of completed jobs/tickets in Infra is added to the card and its then placed in the done column. The number of jobs/tickets completed is added to the CFD done value.


                Cheers,

                Ian.


                On 30 Sep 2011, at 13:12, mj.wivell wrote:

                 

                Jim,

                We've worked with several operations teams to set up a Kanban System.

                I've found that the most important part is two-fold:
                1) Setting up the input queue meeting
                2) Facilitating the input queue meeting with discipline

                It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."

                In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.

                Getting that meeting right helped set up success in many other areas.

                MJ Wivell
                www.bti360.com

                --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@...> wrote:
                >
                > All-
                > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
                >
                > Is anyone using kanban in this scenario? Any advice for me?
                >
                > Here's what we have done so far:
                > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
                >
                > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
                >
                > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
                >
                > Looking forward to hearing your ideas! TIA!
                > Jim Mack
                >



              • Ian Carroll
                Hi Joe, As you ve already mentioned we also try to break things down as far is practicable - but we re still left with large pieces of work. We use a relative
                Message 7 of 16 , Oct 3, 2011
                View Source
                • 0 Attachment
                  Hi Joe,

                  As you've already mentioned we also try to break things down as far is practicable - but we're still left with large pieces of work. We use a relative t-shirt sizing approach. I've included a photo of one of the cards to show how we capture the data. The teams use sizing mainly for "internal" use:

                  1) To assist with prioritisation, i.e. is there more value playing 3 smalls rather than 1 large?
                  2) Looking for anomalies in SPCs e.g. estimate was small but outcome was X-Large. Example in chart below where an estimate of small turned out to be large. The teams explore the anomaly to see if they can identify any improvements to the system. In the example below the team found a source of work that was being planned / defined way way too early in the lifecycle. They also found some opportunities for improving how the prioritisation is done and created classes of service as a result.

                  Another important point is the teams spend very little time estimating and most sizings are off-the-cuff based on gut feel for complexity & effort. All teams have moved to this method but, a small for one team is not the same as a small for another team. Sizing is relative only to the team and shouldn't be used to measure productivity across teams. I mention this because as soon as we established this sizing scheme a couple of managers suggested coming up with a standard sizing method for all teams...

                  Cheers,

                  Ian.



                  On 1 Oct 2011, at 00:14, Joe Miller wrote:

                   

                  Ian, that was a great writeup. 


                  Something we have been wrestling with on our ops teams' kanban board lately now that we are tracking metrics in a CFD is how to handle story "sizes".  The information communicated by the CFD isn't very good if the sizes of each story vary widely. Our stories can vary widely in size, since we handle small requests that can take 30-60 minutes, and large requests that take multiple days.

                  The most common approach I've heard is to try to make all tasks as similarly sized as possible using various techniques (goldilocks estimation, etc).  I'm hesitant to go this route because it seems like it would add more overheard than necessary and could even clutter the board significantly with a huge backlog of small tasks that lose a larger context.  I've also though about giving tickets a simple 1,2,3 sizing, eg: size of 1 = <1 hour.  size of 2 is up to 1 day.  and a size of 3 is anything that is a multiple day effort.

                  I'm curious what others have done, especially with kanban in ops teams, to deal with story sizing and getting good metrics.

                  On Fri, Sep 30, 2011 at 5:40 AM, Ian Carroll <cazano7@...> wrote:

                  Hi Jim,

                  Here's an overview of our Networks team Kanban system, please see photo below:

                  Demand column:

                  Used to visualise the various stakeholders and to get them thinking about priorities. This is sub-divided into the various projects or sources of demand with the highest priority items being to the right and the lowest to the left. The cards hanging off the board to the left are the rest of the backlog. 

                  Input column:

                  This is possibly the most important column on the board. This column drives out the prioritisation conversation with stakeholders and provides protection for the delivery team. It forces conversations that used to be avoided and often pushed onto the delivery team to prioritise.

                  WIP column:

                  Team members pull work from the Input column only when they are ready to do so. If they get blocked on a piece of work, they first focus on unblocking the issue or assist other team members with their tasks.

                  Schedule column:

                  Once a piece of work has been done it often has to wait for a scheduled maintenance window (often out of hours) before it can be deployed and put live. This column is kind of a waiting for release column and used to plan maintenance windows.

                  Long term blockers:

                  The section directly above the board with lots of cards with magenta post-its on it is the long term blockers area. This team deals with many 3rd parties and regularly get blocked whilst waiting for the 3rd party to complete something. Unfortunately, the contracts with these 3rd parties do not provide enough leverage to get them to respond quicker so the team could only make them visible. Making them visible enables senior management to see exactly who was blocking them and chase suppliers on a daily basis, applying pressure where possible.

                  Waste Envelope:

                  Any waste incurred by the team is captured, quantified, and stored in the waste envelope for discussion during retrospectives.

                  Blockers Envelope:

                  All magenta post-it notes (blockers) are kept once the blockage has been removed. These blockers are then analysed during retrospectives to look for trends, common blockages, or any other intel to assist in improving the process.

                  Metrics:

                  The team have stuck a paper based metrics form to the right of the board to simplify the generation of a Cumulative Flow Diagram (CFD). They find it easier to write the card count for each column on the form and then update the electronic chart periodically – say at the end of each week.

                  “The Infra Card”:

                  Each day a new card is inserted directly into the WIP column (a slot is reserved so as not to blow wip limit). Each day between 13:30 and 15:00 the team hit the Infra queues (Infra is the departmental electronic ticketing/job system) for their team and complete what they can within the time box. The number of completed jobs/tickets in Infra is added to the card and its then placed in the done column. The number of jobs/tickets completed is added to the CFD done value.

                  <IMG_1091.jpg>

                  Cheers,

                  Ian.


                  On 30 Sep 2011, at 13:12, mj.wivell wrote:

                   

                  Jim,

                  We've worked with several operations teams to set up a Kanban System.

                  I've found that the most important part is two-fold:
                  1) Setting up the input queue meeting
                  2) Facilitating the input queue meeting with discipline

                  It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."

                  In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.

                  Getting that meeting right helped set up success in many other areas.

                  MJ Wivell
                  www.bti360.com

                  --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@...> wrote:
                  >
                  > All-
                  > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
                  >
                  > Is anyone using kanban in this scenario? Any advice for me?
                  >
                  > Here's what we have done so far:
                  > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
                  >
                  > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
                  >
                  > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
                  >
                  > Looking forward to hearing your ideas! TIA!
                  > Jim Mack
                  >





                • Robert Swanbum
                  We stayed away from sizing because we made a concentrated effort not to inject development time into the board s selection processing.  We forced them to
                  Message 8 of 16 , Oct 3, 2011
                  View Source
                  • 0 Attachment

                    We stayed away from sizing because we made a concentrated effort not to inject development time into the board's selection processing.  We forced them to select based primarily on business priority...what is the most important thing to the business based on customer and or user impact. (We are an Op-Dev support team).  Occasionally the conversation would lend to offering that information if there were multiple items with similiar impact though; we may work two quick ones before tackling a lenghty dev item of equal value.
                     
                    From: Ian Carroll <cazano7@...>
                    To: kanbanops@yahoogroups.com
                    Sent: Monday, October 3, 2011 8:47 AM
                    Subject: Re: [kanbanops] Re: Kanban for Network Services team

                    Hi Joe,

                    As you've already mentioned we also try to break things down as far is practicable - but we're still left with large pieces of work. We use a relative t-shirt sizing approach. I've included a photo of one of the cards to show how we capture the data. The teams use sizing mainly for "internal" use:

                    1) To assist with prioritisation, i.e. is there more value playing 3 smalls rather than 1 large?
                    2) Looking for anomalies in SPCs e.g. estimate was small but outcome was X-Large. Example in chart below where an estimate of small turned out to be large. The teams explore the anomaly to see if they can identify any improvements to the system. In the example below the team found a source of work that was being planned / defined way way too early in the lifecycle. They also found some opportunities for improving how the prioritisation is done and created classes of service as a result.

                    Another important point is the teams spend very little time estimating and most sizings are off-the-cuff based on gut feel for complexity & effort. All teams have moved to this method but, a small for one team is not the same as a small for another team. Sizing is relative only to the team and shouldn't be used to measure productivity across teams. I mention this because as soon as we established this sizing scheme a couple of managers suggested coming up with a standard sizing method for all teams...

                    Cheers,

                    Ian.



                    On 1 Oct 2011, at 00:14, Joe Miller wrote:

                     
                    Ian, that was a great writeup. 

                    Something we have been wrestling with on our ops teams' kanban board lately now that we are tracking metrics in a CFD is how to handle story "sizes".  The information communicated by the CFD isn't very good if the sizes of each story vary widely. Our stories can vary widely in size, since we handle small requests that can take 30-60 minutes, and large requests that take multiple days.

                    The most common approach I've heard is to try to make all tasks as similarly sized as possible using various techniques (goldilocks estimation, etc).  I'm hesitant to go this route because it seems like it would add more overheard than necessary and could even clutter the board significantly with a huge backlog of small tasks that lose a larger context.  I've also though about giving tickets a simple 1,2,3 sizing, eg: size of 1 = <1 hour.  size of 2 is up to 1 day.  and a size of 3 is anything that is a multiple day effort.

                    I'm curious what others have done, especially with kanban in ops teams, to deal with story sizing and getting good metrics.

                    On Fri, Sep 30, 2011 at 5:40 AM, Ian Carroll <cazano7@...> wrote:
                    Hi Jim,
                    Here's an overview of our Networks team Kanban system, please see photo below:

                    Demand column:
                    Used to visualise the various stakeholders and to get them thinking about priorities. This is sub-divided into the various projects or sources of demand with the highest priority items being to the right and the lowest to the left. The cards hanging off the board to the left are the rest of the backlog. 
                    Input column:
                    This is possibly the most important column on the board. This column drives out the prioritisation conversation with stakeholders and provides protection for the delivery team. It forces conversations that used to be avoided and often pushed onto the delivery team to prioritise.
                    WIP column:
                    Team members pull work from the Input column only when they are ready to do so. If they get blocked on a piece of work, they first focus on unblocking the issue or assist other team members with their tasks.
                    Schedule column:
                    Once a piece of work has been done it often has to wait for a scheduled maintenance window (often out of hours) before it can be deployed and put live. This column is kind of a waiting for release column and used to plan maintenance windows.
                    Long term blockers:
                    The section directly above the board with lots of cards with magenta post-its on it is the long term blockers area. This team deals with many 3rd parties and regularly get blocked whilst waiting for the 3rd party to complete something. Unfortunately, the contracts with these 3rd parties do not provide enough leverage to get them to respond quicker so the team could only make them visible. Making them visible enables senior management to see exactly who was blocking them and chase suppliers on a daily basis, applying pressure where possible.
                    Waste Envelope:
                    Any waste incurred by the team is captured, quantified, and stored in the waste envelope for discussion during retrospectives.
                    Blockers Envelope:
                    All magenta post-it notes (blockers) are kept once the blockage has been removed. These blockers are then analysed during retrospectives to look for trends, common blockages, or any other intel to assist in improving the process.
                    Metrics:
                    The team have stuck a paper based metrics form to the right of the board to simplify the generation of a Cumulative Flow Diagram (CFD). They find it easier to write the card count for each column on the form and then update the electronic chart periodically – say at the end of each week.
                    “The Infra Card”:
                    Each day a new card is inserted directly into the WIP column (a slot is reserved so as not to blow wip limit). Each day between 13:30 and 15:00 the team hit the Infra queues (Infra is the departmental electronic ticketing/job system) for their team and complete what they can within the time box. The number of completed jobs/tickets in Infra is added to the card and its then placed in the done column. The number of jobs/tickets completed is added to the CFD done value.
                    <IMG_1091.jpg>

                    Cheers,

                    Ian.


                    On 30 Sep 2011, at 13:12, mj.wivell wrote:

                     
                    Jim,

                    We've worked with several operations teams to set up a Kanban System.

                    I've found that the most important part is two-fold:
                    1) Setting up the input queue meeting
                    2) Facilitating the input queue meeting with discipline

                    It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."

                    In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.

                    Getting that meeting right helped set up success in many other areas.

                    MJ Wivell
                    www.bti360.com

                    --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@...> wrote:
                    >
                    > All-
                    > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
                    >
                    > Is anyone using kanban in this scenario? Any advice for me?
                    >
                    > Here's what we have done so far:
                    > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
                    >
                    > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
                    >
                    > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
                    >
                    > Looking forward to hearing your ideas! TIA!
                    > Jim Mack
                    >







                  • Joe Miller
                    Robert, do you find that there is large variation in task sizes, and if so how do you account for that in your CFD (or other metrics/visualization processes) ?
                    Message 9 of 16 , Oct 3, 2011
                    View Source
                    • 0 Attachment
                      Robert, do you find that there is large variation in task sizes, and if so how do you account for that in your CFD (or other metrics/visualization processes) ?

                      On Mon, Oct 3, 2011 at 7:59 AM, Robert Swanbum <rswany79@...> wrote:

                      We stayed away from sizing because we made a concentrated effort not to inject development time into the board's selection processing.  We forced them to select based primarily on business priority...what is the most important thing to the business based on customer and or user impact. (We are an Op-Dev support team).  Occasionally the conversation would lend to offering that information if there were multiple items with similiar impact though; we may work two quick ones before tackling a lenghty dev item of equal value.
                       
                      From: Ian Carroll <cazano7@...>
                      To: kanbanops@yahoogroups.com
                      Sent: Monday, October 3, 2011 8:47 AM
                      Subject: Re: [kanbanops] Re: Kanban for Network Services team

                      Hi Joe,

                      As you've already mentioned we also try to break things down as far is practicable - but we're still left with large pieces of work. We use a relative t-shirt sizing approach. I've included a photo of one of the cards to show how we capture the data. The teams use sizing mainly for "internal" use:

                      1) To assist with prioritisation, i.e. is there more value playing 3 smalls rather than 1 large?
                      2) Looking for anomalies in SPCs e.g. estimate was small but outcome was X-Large. Example in chart below where an estimate of small turned out to be large. The teams explore the anomaly to see if they can identify any improvements to the system. In the example below the team found a source of work that was being planned / defined way way too early in the lifecycle. They also found some opportunities for improving how the prioritisation is done and created classes of service as a result.

                      Another important point is the teams spend very little time estimating and most sizings are off-the-cuff based on gut feel for complexity & effort. All teams have moved to this method but, a small for one team is not the same as a small for another team. Sizing is relative only to the team and shouldn't be used to measure productivity across teams. I mention this because as soon as we established this sizing scheme a couple of managers suggested coming up with a standard sizing method for all teams...

                      Cheers,

                      Ian.



                      On 1 Oct 2011, at 00:14, Joe Miller wrote:

                       
                      Ian, that was a great writeup. 

                      Something we have been wrestling with on our ops teams' kanban board lately now that we are tracking metrics in a CFD is how to handle story "sizes".  The information communicated by the CFD isn't very good if the sizes of each story vary widely. Our stories can vary widely in size, since we handle small requests that can take 30-60 minutes, and large requests that take multiple days.

                      The most common approach I've heard is to try to make all tasks as similarly sized as possible using various techniques (goldilocks estimation, etc).  I'm hesitant to go this route because it seems like it would add more overheard than necessary and could even clutter the board significantly with a huge backlog of small tasks that lose a larger context.  I've also though about giving tickets a simple 1,2,3 sizing, eg: size of 1 = <1 hour.  size of 2 is up to 1 day.  and a size of 3 is anything that is a multiple day effort.

                      I'm curious what others have done, especially with kanban in ops teams, to deal with story sizing and getting good metrics.

                      On Fri, Sep 30, 2011 at 5:40 AM, Ian Carroll <cazano7@...> wrote:
                      Hi Jim,
                      Here's an overview of our Networks team Kanban system, please see photo below:

                      Demand column:
                      Used to visualise the various stakeholders and to get them thinking about priorities. This is sub-divided into the various projects or sources of demand with the highest priority items being to the right and the lowest to the left. The cards hanging off the board to the left are the rest of the backlog. 
                      Input column:
                      This is possibly the most important column on the board. This column drives out the prioritisation conversation with stakeholders and provides protection for the delivery team. It forces conversations that used to be avoided and often pushed onto the delivery team to prioritise.
                      WIP column:
                      Team members pull work from the Input column only when they are ready to do so. If they get blocked on a piece of work, they first focus on unblocking the issue or assist other team members with their tasks.
                      Schedule column:
                      Once a piece of work has been done it often has to wait for a scheduled maintenance window (often out of hours) before it can be deployed and put live. This column is kind of a waiting for release column and used to plan maintenance windows.
                      Long term blockers:
                      The section directly above the board with lots of cards with magenta post-its on it is the long term blockers area. This team deals with many 3rd parties and regularly get blocked whilst waiting for the 3rd party to complete something. Unfortunately, the contracts with these 3rd parties do not provide enough leverage to get them to respond quicker so the team could only make them visible. Making them visible enables senior management to see exactly who was blocking them and chase suppliers on a daily basis, applying pressure where possible.
                      Waste Envelope:
                      Any waste incurred by the team is captured, quantified, and stored in the waste envelope for discussion during retrospectives.
                      Blockers Envelope:
                      All magenta post-it notes (blockers) are kept once the blockage has been removed. These blockers are then analysed during retrospectives to look for trends, common blockages, or any other intel to assist in improving the process.
                      Metrics:
                      The team have stuck a paper based metrics form to the right of the board to simplify the generation of a Cumulative Flow Diagram (CFD). They find it easier to write the card count for each column on the form and then update the electronic chart periodically – say at the end of each week.
                      “The Infra Card”:
                      Each day a new card is inserted directly into the WIP column (a slot is reserved so as not to blow wip limit). Each day between 13:30 and 15:00 the team hit the Infra queues (Infra is the departmental electronic ticketing/job system) for their team and complete what they can within the time box. The number of completed jobs/tickets in Infra is added to the card and its then placed in the done column. The number of jobs/tickets completed is added to the CFD done value.
                      <IMG_1091.jpg>

                      Cheers,

                      Ian.


                      On 30 Sep 2011, at 13:12, mj.wivell wrote:

                       
                      Jim,

                      We've worked with several operations teams to set up a Kanban System.

                      I've found that the most important part is two-fold:
                      1) Setting up the input queue meeting
                      2) Facilitating the input queue meeting with discipline

                      It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."

                      In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.

                      Getting that meeting right helped set up success in many other areas.

                      MJ Wivell
                      www.bti360.com

                      --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@...> wrote:
                      >
                      > All-
                      > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
                      >
                      > Is anyone using kanban in this scenario? Any advice for me?
                      >
                      > Here's what we have done so far:
                      > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
                      >
                      > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
                      >
                      > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
                      >
                      > Looking forward to hearing your ideas! TIA!
                      > Jim Mack
                      >








                    • Joe Miller
                      Thanks for the response Ian. On this topic, I also found the following from the operations team @ Spotify this weekend:
                      Message 10 of 16 , Oct 3, 2011
                      View Source
                      • 0 Attachment
                        Thanks for the response Ian.  On this topic, I also found the following from the operations team @ Spotify this weekend:  http://www.infoq.com/articles/kanban-operations-spotify

                        Based on your feedback and the info from the Spotify presentation, we are going to try the 't-shirt' sizing approach.  Our main goal with the sizing is to get better data out of the CFD chart and that's it right now.  But Robert makes a good point about size estimation infecting the business-value selection process.  We'll have to watch out for this, and perhaps even 'hide' or try hard to keep sizes out of the discussion with the other business groups as much as possible.

                        Additionally, I like the Spotify teams' approach of having an 'intangible' and 'tangible' split in the horizontal swim lanes.  This fits well with my team's nature of work (ie: many small/medium external requests balanced against projects we create to improve the long term sustainability of the infrastructure). At a previous job this was a significant challenge, and led to quite a bit of rot in the product line (upgrades/patching not done, etc). Hope to avoid that this time around.


                        On Mon, Oct 3, 2011 at 6:47 AM, Ian Carroll <cazano7@...> wrote:
                        Hi Joe,

                        As you've already mentioned we also try to break things down as far is practicable - but we're still left with large pieces of work. We use a relative t-shirt sizing approach. I've included a photo of one of the cards to show how we capture the data. The teams use sizing mainly for "internal" use:

                        1) To assist with prioritisation, i.e. is there more value playing 3 smalls rather than 1 large?
                        2) Looking for anomalies in SPCs e.g. estimate was small but outcome was X-Large. Example in chart below where an estimate of small turned out to be large. The teams explore the anomaly to see if they can identify any improvements to the system. In the example below the team found a source of work that was being planned / defined way way too early in the lifecycle. They also found some opportunities for improving how the prioritisation is done and created classes of service as a result.

                        Another important point is the teams spend very little time estimating and most sizings are off-the-cuff based on gut feel for complexity & effort. All teams have moved to this method but, a small for one team is not the same as a small for another team. Sizing is relative only to the team and shouldn't be used to measure productivity across teams. I mention this because as soon as we established this sizing scheme a couple of managers suggested coming up with a standard sizing method for all teams...

                        Cheers,

                        Ian.



                        On 1 Oct 2011, at 00:14, Joe Miller wrote:

                         

                        Ian, that was a great writeup. 


                        Something we have been wrestling with on our ops teams' kanban board lately now that we are tracking metrics in a CFD is how to handle story "sizes".  The information communicated by the CFD isn't very good if the sizes of each story vary widely. Our stories can vary widely in size, since we handle small requests that can take 30-60 minutes, and large requests that take multiple days.

                        The most common approach I've heard is to try to make all tasks as similarly sized as possible using various techniques (goldilocks estimation, etc).  I'm hesitant to go this route because it seems like it would add more overheard than necessary and could even clutter the board significantly with a huge backlog of small tasks that lose a larger context.  I've also though about giving tickets a simple 1,2,3 sizing, eg: size of 1 = <1 hour.  size of 2 is up to 1 day.  and a size of 3 is anything that is a multiple day effort.

                        I'm curious what others have done, especially with kanban in ops teams, to deal with story sizing and getting good metrics.

                        On Fri, Sep 30, 2011 at 5:40 AM, Ian Carroll <cazano7@...> wrote:

                        Hi Jim,

                        Here's an overview of our Networks team Kanban system, please see photo below:

                        Demand column:

                        Used to visualise the various stakeholders and to get them thinking about priorities. This is sub-divided into the various projects or sources of demand with the highest priority items being to the right and the lowest to the left. The cards hanging off the board to the left are the rest of the backlog. 

                        Input column:

                        This is possibly the most important column on the board. This column drives out the prioritisation conversation with stakeholders and provides protection for the delivery team. It forces conversations that used to be avoided and often pushed onto the delivery team to prioritise.

                        WIP column:

                        Team members pull work from the Input column only when they are ready to do so. If they get blocked on a piece of work, they first focus on unblocking the issue or assist other team members with their tasks.

                        Schedule column:

                        Once a piece of work has been done it often has to wait for a scheduled maintenance window (often out of hours) before it can be deployed and put live. This column is kind of a waiting for release column and used to plan maintenance windows.

                        Long term blockers:

                        The section directly above the board with lots of cards with magenta post-its on it is the long term blockers area. This team deals with many 3rd parties and regularly get blocked whilst waiting for the 3rd party to complete something. Unfortunately, the contracts with these 3rd parties do not provide enough leverage to get them to respond quicker so the team could only make them visible. Making them visible enables senior management to see exactly who was blocking them and chase suppliers on a daily basis, applying pressure where possible.

                        Waste Envelope:

                        Any waste incurred by the team is captured, quantified, and stored in the waste envelope for discussion during retrospectives.

                        Blockers Envelope:

                        All magenta post-it notes (blockers) are kept once the blockage has been removed. These blockers are then analysed during retrospectives to look for trends, common blockages, or any other intel to assist in improving the process.

                        Metrics:

                        The team have stuck a paper based metrics form to the right of the board to simplify the generation of a Cumulative Flow Diagram (CFD). They find it easier to write the card count for each column on the form and then update the electronic chart periodically – say at the end of each week.

                        “The Infra Card”:

                        Each day a new card is inserted directly into the WIP column (a slot is reserved so as not to blow wip limit). Each day between 13:30 and 15:00 the team hit the Infra queues (Infra is the departmental electronic ticketing/job system) for their team and complete what they can within the time box. The number of completed jobs/tickets in Infra is added to the card and its then placed in the done column. The number of jobs/tickets completed is added to the CFD done value.

                        <IMG_1091.jpg>

                        Cheers,

                        Ian.


                        On 30 Sep 2011, at 13:12, mj.wivell wrote:

                         

                        Jim,

                        We've worked with several operations teams to set up a Kanban System.

                        I've found that the most important part is two-fold:
                        1) Setting up the input queue meeting
                        2) Facilitating the input queue meeting with discipline

                        It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."

                        In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.

                        Getting that meeting right helped set up success in many other areas.

                        MJ Wivell
                        www.bti360.com

                        --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@...> wrote:
                        >
                        > All-
                        > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
                        >
                        > Is anyone using kanban in this scenario? Any advice for me?
                        >
                        > Here's what we have done so far:
                        > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
                        >
                        > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
                        >
                        > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
                        >
                        > Looking forward to hearing your ideas! TIA!
                        > Jim Mack
                        >






                      • Robert Swanbum
                        We do have different categories for the requests we get into the group.  This helps in that regard.  But other than that, the task size is not parsed out in
                        Message 11 of 16 , Oct 3, 2011
                        View Source
                        • 0 Attachment
                          We do have different categories for the requests we get into the group.  This helps in that regard.  But other than that, the task size is not parsed out in any metrics.  What really helps is that our board consists of leaders or representatives from every department so they know what is going on and we're never really held to any set target dates.  It gets done when it gets done and they are informed where each item is along the way.

                          From: Joe Miller <joeym@...>
                          To: kanbanops@yahoogroups.com
                          Sent: Monday, October 3, 2011 2:20 PM
                          Subject: Re: [kanbanops] Re: Kanban for Network Services team

                           
                          Robert, do you find that there is large variation in task sizes, and if so how do you account for that in your CFD (or other metrics/visualization processes) ?

                          On Mon, Oct 3, 2011 at 7:59 AM, Robert Swanbum <rswany79@...> wrote:

                          We stayed away from sizing because we made a concentrated effort not to inject development time into the board's selection processing.  We forced them to select based primarily on business priority...what is the most important thing to the business based on customer and or user impact. (We are an Op-Dev support team).  Occasionally the conversation would lend to offering that information if there were multiple items with similiar impact though; we may work two quick ones before tackling a lenghty dev item of equal value.
                           
                          From: Ian Carroll <cazano7@...>
                          To: kanbanops@yahoogroups.com
                          Sent: Monday, October 3, 2011 8:47 AM
                          Subject: Re: [kanbanops] Re: Kanban for Network Services team

                          Hi Joe,

                          As you've already mentioned we also try to break things down as far is practicable - but we're still left with large pieces of work. We use a relative t-shirt sizing approach. I've included a photo of one of the cards to show how we capture the data. The teams use sizing mainly for "internal" use:

                          1) To assist with prioritisation, i.e. is there more value playing 3 smalls rather than 1 large?
                          2) Looking for anomalies in SPCs e.g. estimate was small but outcome was X-Large. Example in chart below where an estimate of small turned out to be large. The teams explore the anomaly to see if they can identify any improvements to the system. In the example below the team found a source of work that was being planned / defined way way too early in the lifecycle. They also found some opportunities for improving how the prioritisation is done and created classes of service as a result.

                          Another important point is the teams spend very little time estimating and most sizings are off-the-cuff based on gut feel for complexity & effort. All teams have moved to this method but, a small for one team is not the same as a small for another team. Sizing is relative only to the team and shouldn't be used to measure productivity across teams. I mention this because as soon as we established this sizing scheme a couple of managers suggested coming up with a standard sizing method for all teams...

                          Cheers,

                          Ian.


                        • Jay Haldors
                          A little commentary... Mattias Jansson is very approachable...he and I have spoke off and on for the last year about Kanban because of this article. Great guy!
                          Message 12 of 16 , Oct 3, 2011
                          View Source
                          • 0 Attachment
                            A little commentary...

                            Mattias Jansson is very approachable...he and I have spoke off and on for the last year about Kanban because of this article. Great guy! Very good experience as well.

                            I love seeing/reading the other comments on the application and methods being used. 

                            I initiated the same Kanban approach as the article with our operations team last year....

                            I have not had total success since we do not have the management buy in to push hard on WIP and review and manage the back log as needed (IMHO). If you have the management  and team working totally bought in I really think this is an extremely powerful approach.

                            What I can say is our Kanabn has provided a lot of value for making the work/tasks explicit and a way to communicate to the organization what is taking place. 

                            As a team we do measure and review move from To Do to  In Progress tasks and have kept that within our defined limits very well since we started. I would like our team to take it to the next level but it will require more buy in and consistent application moving forward.

                            The good news is that other teams in the organization are picking this up as well and are producing very good results. So I look forward to hear about your success.



                            On Mon, Oct 3, 2011 at 12:28 PM, Joe Miller <joeym@...> wrote:
                             

                            Thanks for the response Ian.  On this topic, I also found the following from the operations team @ Spotify this weekend:  http://www.infoq.com/articles/kanban-operations-spotify


                            Based on your feedback and the info from the Spotify presentation, we are going to try the 't-shirt' sizing approach.  Our main goal with the sizing is to get better data out of the CFD chart and that's it right now.  But Robert makes a good point about size estimation infecting the business-value selection process.  We'll have to watch out for this, and perhaps even 'hide' or try hard to keep sizes out of the discussion with the other business groups as much as possible.

                            Additionally, I like the Spotify teams' approach of having an 'intangible' and 'tangible' split in the horizontal swim lanes.  This fits well with my team's nature of work (ie: many small/medium external requests balanced against projects we create to improve the long term sustainability of the infrastructure). At a previous job this was a significant challenge, and led to quite a bit of rot in the product line (upgrades/patching not done, etc). Hope to avoid that this time around.


                            On Mon, Oct 3, 2011 at 6:47 AM, Ian Carroll <cazano7@...> wrote:
                            Hi Joe,

                            As you've already mentioned we also try to break things down as far is practicable - but we're still left with large pieces of work. We use a relative t-shirt sizing approach. I've included a photo of one of the cards to show how we capture the data. The teams use sizing mainly for "internal" use:

                            1) To assist with prioritisation, i.e. is there more value playing 3 smalls rather than 1 large?
                            2) Looking for anomalies in SPCs e.g. estimate was small but outcome was X-Large. Example in chart below where an estimate of small turned out to be large. The teams explore the anomaly to see if they can identify any improvements to the system. In the example below the team found a source of work that was being planned / defined way way too early in the lifecycle. They also found some opportunities for improving how the prioritisation is done and created classes of service as a result.

                            Another important point is the teams spend very little time estimating and most sizings are off-the-cuff based on gut feel for complexity & effort. All teams have moved to this method but, a small for one team is not the same as a small for another team. Sizing is relative only to the team and shouldn't be used to measure productivity across teams. I mention this because as soon as we established this sizing scheme a couple of managers suggested coming up with a standard sizing method for all teams...

                            Cheers,

                            Ian.



                            On 1 Oct 2011, at 00:14, Joe Miller wrote:

                             

                            Ian, that was a great writeup. 


                            Something we have been wrestling with on our ops teams' kanban board lately now that we are tracking metrics in a CFD is how to handle story "sizes".  The information communicated by the CFD isn't very good if the sizes of each story vary widely. Our stories can vary widely in size, since we handle small requests that can take 30-60 minutes, and large requests that take multiple days.

                            The most common approach I've heard is to try to make all tasks as similarly sized as possible using various techniques (goldilocks estimation, etc).  I'm hesitant to go this route because it seems like it would add more overheard than necessary and could even clutter the board significantly with a huge backlog of small tasks that lose a larger context.  I've also though about giving tickets a simple 1,2,3 sizing, eg: size of 1 = <1 hour.  size of 2 is up to 1 day.  and a size of 3 is anything that is a multiple day effort.

                            I'm curious what others have done, especially with kanban in ops teams, to deal with story sizing and getting good metrics.

                            On Fri, Sep 30, 2011 at 5:40 AM, Ian Carroll <cazano7@...> wrote:

                            Hi Jim,

                            Here's an overview of our Networks team Kanban system, please see photo below:

                            Demand column:

                            Used to visualise the various stakeholders and to get them thinking about priorities. This is sub-divided into the various projects or sources of demand with the highest priority items being to the right and the lowest to the left. The cards hanging off the board to the left are the rest of the backlog. 

                            Input column:

                            This is possibly the most important column on the board. This column drives out the prioritisation conversation with stakeholders and provides protection for the delivery team. It forces conversations that used to be avoided and often pushed onto the delivery team to prioritise.

                            WIP column:

                            Team members pull work from the Input column only when they are ready to do so. If they get blocked on a piece of work, they first focus on unblocking the issue or assist other team members with their tasks.

                            Schedule column:

                            Once a piece of work has been done it often has to wait for a scheduled maintenance window (often out of hours) before it can be deployed and put live. This column is kind of a waiting for release column and used to plan maintenance windows.

                            Long term blockers:

                            The section directly above the board with lots of cards with magenta post-its on it is the long term blockers area. This team deals with many 3rd parties and regularly get blocked whilst waiting for the 3rd party to complete something. Unfortunately, the contracts with these 3rd parties do not provide enough leverage to get them to respond quicker so the team could only make them visible. Making them visible enables senior management to see exactly who was blocking them and chase suppliers on a daily basis, applying pressure where possible.

                            Waste Envelope:

                            Any waste incurred by the team is captured, quantified, and stored in the waste envelope for discussion during retrospectives.

                            Blockers Envelope:

                            All magenta post-it notes (blockers) are kept once the blockage has been removed. These blockers are then analysed during retrospectives to look for trends, common blockages, or any other intel to assist in improving the process.

                            Metrics:

                            The team have stuck a paper based metrics form to the right of the board to simplify the generation of a Cumulative Flow Diagram (CFD). They find it easier to write the card count for each column on the form and then update the electronic chart periodically – say at the end of each week.

                            “The Infra Card”:

                            Each day a new card is inserted directly into the WIP column (a slot is reserved so as not to blow wip limit). Each day between 13:30 and 15:00 the team hit the Infra queues (Infra is the departmental electronic ticketing/job system) for their team and complete what they can within the time box. The number of completed jobs/tickets in Infra is added to the card and its then placed in the done column. The number of jobs/tickets completed is added to the CFD done value.

                            <IMG_1091.jpg>

                            Cheers,

                            Ian.


                            On 30 Sep 2011, at 13:12, mj.wivell wrote:

                             

                            Jim,

                            We've worked with several operations teams to set up a Kanban System.

                            I've found that the most important part is two-fold:
                            1) Setting up the input queue meeting
                            2) Facilitating the input queue meeting with discipline

                            It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."

                            In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.

                            Getting that meeting right helped set up success in many other areas.

                            MJ Wivell
                            www.bti360.com

                            --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@...> wrote:
                            >
                            > All-
                            > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
                            >
                            > Is anyone using kanban in this scenario? Any advice for me?
                            >
                            > Here's what we have done so far:
                            > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
                            >
                            > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
                            >
                            > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
                            >
                            > Looking forward to hearing your ideas! TIA!
                            > Jim Mack
                            >







                          • Dominica DeGrandis
                            Hi Joe, Your focus on better data for better decision making is spot on. It s easier to make better decisions based off of relevant CFDs. Measuring cycle
                            Message 13 of 16 , Oct 3, 2011
                            View Source
                            • 0 Attachment
                              Hi Joe,
                              Your focus on better data for better decision making is spot on.  It's easier to make better decisions based off of relevant CFDs.  Measuring cycle time across a set of  tasks doesn't tell us much when they are of widely varying sizes. Combining cycle times for these will skew results, making it difficult to put any predictability into the process.  Swim lanes can provide some help in this area - as you've already discovered via Spotify,  (btw, Mattias is speaking next week at devopsdays Gothenborg ).

                              Another solution is to use separate swim lanes for the S,M,L work items (mentioned by Ian) on the board.  That way, metrics collected for CFDs would prove more meaningful.

                              Have you looked into SPC charts?   They could be created for work items of variable size.  Breaking out the SPC chart by work item and size — so that, for example, large items all appear on the same chart — also helps avoid convoluted metrics. Exceptionally long cycle times for large items would then stand out as special cause variation and would act as talking points for retrospectives and ops reviews. 
                              If you're interested, there's more details on CFDs and SPCs at http://www.limitedwipsociety.org/ 
                              Cheers,
                              Dominica

                              --- In kanbanops@yahoogroups.com, Joe Miller <joeym@...> wrote:
                              >
                              > Thanks for the response Ian. On this topic, I also found the following from
                              > the operations team @ Spotify this weekend:
                              > http://www.infoq.com/articles/kanban-operations-spotify
                              >
                              > Based on your feedback and the info from the Spotify presentation, we are
                              > going to try the 't-shirt' sizing approach. Our main goal with the sizing
                              > is to get better data out of the CFD chart and that's it right now. But
                              > Robert makes a good point about size estimation infecting the business-value
                              > selection process. We'll have to watch out for this, and perhaps even
                              > 'hide' or try hard to keep sizes out of the discussion with the other
                              > business groups as much as possible.
                              >
                              > Additionally, I like the Spotify teams' approach of having an 'intangible'
                              > and 'tangible' split in the horizontal swim lanes. This fits well with my
                              > team's nature of work (ie: many small/medium external requests balanced
                              > against projects we create to improve the long term sustainability of the
                              > infrastructure). At a previous job this was a significant challenge, and led
                              > to quite a bit of rot in the product line (upgrades/patching not done, etc).
                              > Hope to avoid that this time around.
                              >
                              >
                              > On Mon, Oct 3, 2011 at 6:47 AM, Ian Carroll cazano7@... wrote:
                              >
                              > > Hi Joe,
                              > >
                              > > As you've already mentioned we also try to break things down as far is
                              > > practicable - but we're still left with large pieces of work. We use a
                              > > relative t-shirt sizing approach. I've included a photo of one of the cards
                              > > to show how we capture the data. The teams use sizing mainly for "internal"
                              > > use:
                              > >
                              > > 1) To assist with prioritisation, i.e. is there more value playing 3 smalls
                              > > rather than 1 large?
                              > > 2) Looking for anomalies in SPCs e.g. estimate was small but outcome was
                              > > X-Large. Example in chart below where an estimate of small turned out to be
                              > > large. The teams explore the anomaly to see if they can identify any
                              > > improvements to the system. In the example below the team found a source of
                              > > work that was being planned / defined way way too early in the lifecycle.
                              > > They also found some opportunities for improving how the prioritisation is
                              > > done and created classes of service as a result.
                              > >
                              > > Another important point is the teams spend very little time estimating and
                              > > most sizings are off-the-cuff based on gut feel for complexity & effort. All
                              > > teams have moved to this method but, a small for one team is not the same as
                              > > a small for another team. Sizing is relative only to the team and shouldn't
                              > > be used to measure productivity across teams. I mention this because as soon
                              > > as we established this sizing scheme a couple of managers suggested coming
                              > > up with a standard sizing method for all teams...
                              > >
                              > > Cheers,
                              > >
                              > > Ian.
                              > >
                              > >
                              > >
                              > > On 1 Oct 2011, at 00:14, Joe Miller wrote:
                              > >
                              > >
                              > >
                              > > Ian, that was a great writeup.
                              > >
                              > > Something we have been wrestling with on our ops teams' kanban board lately
                              > > now that we are tracking metrics in a CFD is how to handle story "sizes".
                              > > The information communicated by the CFD isn't very good if the sizes of
                              > > each story vary widely. Our stories can vary widely in size, since we handle
                              > > small requests that can take 30-60 minutes, and large requests that take
                              > > multiple days.
                              > >
                              > > The most common approach I've heard is to try to make all tasks as
                              > > similarly sized as possible using various techniques (goldilocks estimation,
                              > > etc). I'm hesitant to go this route because it seems like it would add more
                              > > overheard than necessary and could even clutter the board significantly with
                              > > a huge backlog of small tasks that lose a larger context. I've also though
                              > > about giving tickets a simple 1,2,3 sizing, eg: size of 1 = <1 hour. size
                              > > of 2 is up to 1 day. and a size of 3 is anything that is a multiple day
                              > > effort.
                              > >
                              > > I'm curious what others have done, especially with kanban in ops teams, to
                              > > deal with story sizing and getting good metrics.
                              > >
                              > > On Fri, Sep 30, 2011 at 5:40 AM, Ian Carroll cazano7@...wrote:
                              > >
                              > >> Hi Jim,
                              > >> Here's an overview of our Networks team Kanban system, please see photo
                              > >> below:
                              > >>
                              > >> *Demand column:*
                              > >>
                              > >> Used to visualise the various stakeholders and to get them thinking about
                              > >> priorities. This is sub-divided into the various projects or sources of
                              > >> demand with the highest priority items being to the right and the lowest to
                              > >> the left. The cards hanging off the board to the left are the rest of the
                              > >> backlog.
                              > >>
                              > >> *Input column:*
                              > >>
                              > >> This is possibly the most important column on the board. This column
                              > >> drives out the prioritisation conversation with stakeholders and provides
                              > >> protection for the delivery team. It forces conversations that used to be
                              > >> avoided and often pushed onto the delivery team to prioritise.
                              > >>
                              > >> *WIP column:*
                              > >>
                              > >> Team members pull work from the Input column *only when they are ready to
                              > >> do so*. If they get blocked on a piece of work, they first focus on
                              > >> unblocking the issue or assist other team members with their tasks.
                              > >>
                              > >> *Schedule column:*
                              > >>
                              > >> Once a piece of work has been done it often has to wait for a scheduled
                              > >> maintenance window (often out of hours) before it can be deployed and put
                              > >> live. This column is kind of a waiting for release column and used to plan
                              > >> maintenance windows.
                              > >>
                              > >> *Long term blockers:*
                              > >>
                              > >> The section directly above the board with lots of cards with magenta
                              > >> post-its on it is the long term blockers area. This team deals with many 3rd
                              > >> parties and regularly get blocked whilst waiting for the 3rd party to
                              > >> complete something. Unfortunately, the contracts with these 3rd parties do
                              > >> not provide enough leverage to get them to respond quicker so the team could
                              > >> only make them visible. Making them visible enables senior management to see
                              > >> exactly who was blocking them and chase suppliers on a daily basis, applying
                              > >> pressure where possible.
                              > >>
                              > >> *Waste Envelope:*
                              > >>
                              > >> Any waste incurred by the team is captured, quantified, and stored in the
                              > >> waste envelope for discussion during retrospectives.
                              > >>
                              > >> *Blockers Envelope:*
                              > >>
                              > >> All magenta post-it notes (blockers) are kept once the blockage has been
                              > >> removed. These blockers are then analysed during retrospectives to look for
                              > >> trends, common blockages, or any other intel to assist in improving the
                              > >> process.
                              > >>
                              > >> *Metrics:*
                              > >>
                              > >> The team have stuck a paper based metrics form to the right of the board
                              > >> to simplify the generation of a Cumulative Flow Diagram (CFD). They find it
                              > >> easier to write the card count for each column on the form and then update
                              > >> the electronic chart periodically – say at the end of each week.
                              > >>
                              > >> *"The Infra Card":*
                              > >>
                              > >> Each day a new card is inserted directly into the WIP column (a slot is
                              > >> reserved so as not to blow wip limit). Each day between 13:30 and 15:00 the
                              > >> team hit the Infra queues (Infra is the departmental electronic
                              > >> ticketing/job system) for their team and complete what they can within the
                              > >> time box. The number of completed jobs/tickets in Infra is added to the card
                              > >> and its then placed in the done column. The number of jobs/tickets completed
                              > >> is added to the CFD done value.
                              > >> <IMG_1091.jpg>
                              > >>
                              > >> Cheers,
                              > >>
                              > >> Ian.
                              > >>
                              > >>
                              > >> On 30 Sep 2011, at 13:12, mj.wivell wrote:
                              > >>
                              > >>
                              > >>
                              > >> Jim,
                              > >>
                              > >> We've worked with several operations teams to set up a Kanban System.
                              > >>
                              > >> I've found that the most important part is two-fold:
                              > >> 1) Setting up the input queue meeting
                              > >> 2) Facilitating the input queue meeting with discipline
                              > >>
                              > >> It's important for that meeting to be focused around asking the question
                              > >> "What are the two (what ever the "On Deck" WIP Limit permits) things you
                              > >> would like me to work on next."
                              > >>
                              > >> In our experience we've had true ad hoc work to where we had the input
                              > >> queue meeting each morning. We've also done it weekly. It's typically a very
                              > >> quick meeting.
                              > >>
                              > >> Getting that meeting right helped set up success in many other areas.
                              > >>
                              > >> MJ Wivell
                              > >> www.bti360.com
                              > >>
                              > >> --- In kanbanops@yahoogroups.com, "jgmack" jgmack@ wrote:
                              > >> >
                              > >> > All-
                              > >> > I am working with our Network Services team to get a handle on their
                              > >> workload and have proposed kanban as a possible solution.
                              > >> >
                              > >> > Is anyone using kanban in this scenario? Any advice for me?
                              > >> >
                              > >> > Here's what we have done so far:
                              > >> > The manager and I have put together a mockup board and showed it to the
                              > >> team, explaining the principles of visualizing work, limiting WIP, modifying
                              > >> policies when things aren't working, etc.
                              > >> >
                              > >> > Next steps are to populate the backlog and then run a simulation with
                              > >> the team next week to surface issues, develop policies with the team's input
                              > >> and to try to discover what may work and what might not.
                              > >> >
                              > >> > I would love to hear some success stories from others doing the same
                              > >> thing, especially about how you handle the variability of the tasks, the
                              > >> ad-hoc nature of work requests and the manager's role in this situation.
                              > >> >
                              > >> > Looking forward to hearing your ideas! TIA!
                              > >> > Jim Mack
                              > >> >
                              > >>
                              > >>
                              > >>
                              > >
                              > >
                              > >
                              >
                            • jgmack
                              Wow! Thanks to everyone for sharing your experiences. I m sure I ll have lots of other questions as we begin using Kanban with the Network Services team. I
                              Message 14 of 16 , Oct 4, 2011
                              View Source
                              • 0 Attachment
                                Wow! Thanks to everyone for sharing your experiences. I'm sure I'll have lots of other questions as we begin using Kanban with the Network Services team.

                                I really appreciate the time each of you has taken to respond!
                                Jim

                                --- In kanbanops@yahoogroups.com, Robert Swanbum <rswany79@...> wrote:
                                >
                                >
                                >
                                > +1
                                >  
                                > From: mj.wivell <mjwivell@...>
                                > To: kanbanops@yahoogroups.com
                                > Sent: Friday, September 30, 2011 7:12 AM
                                > Subject: [kanbanops] Re: Kanban for Network Services team
                                >
                                >
                                >  
                                > Jim,
                                >
                                > We've worked with several operations teams to set up a Kanban System.
                                >
                                > I've found that the most important part is two-fold:
                                > 1) Setting up the input queue meeting
                                > 2) Facilitating the input queue meeting with discipline
                                >
                                > It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."
                                >
                                > In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.
                                >
                                > Getting that meeting right helped set up success in many other areas.
                                >
                                > MJ Wivell
                                > www.bti360.com
                                >
                                > --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@> wrote:
                                > >
                                > > All-
                                > > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
                                > >
                                > > Is anyone using kanban in this scenario? Any advice for me?
                                > >
                                > > Here's what we have done so far:
                                > > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
                                > >
                                > > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
                                > >
                                > > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
                                > >
                                > > Looking forward to hearing your ideas! TIA!
                                > > Jim Mack
                                > >
                                >
                              • jgmack
                                Thanks, Ian. Lots of great ideas!
                                Message 15 of 16 , Oct 4, 2011
                                View Source
                                • 0 Attachment
                                  Thanks, Ian. Lots of great ideas!

                                  --- In kanbanops@yahoogroups.com, Ian Carroll <cazano7@...> wrote:
                                  >
                                  > Hi Jim,
                                  >
                                  > Here's an overview of our Networks team Kanban system, please see photo below:
                                  >
                                  > Demand column:
                                  >
                                  > Used to visualise the various stakeholders and to get them thinking about priorities. This is sub-divided into the various projects or sources of demand with the highest priority items being to the right and the lowest to the left. The cards hanging off the board to the left are the rest of the backlog.
                                  >
                                  > Input column:
                                  >
                                  > This is possibly the most important column on the board. This column drives out the prioritisation conversation with stakeholders and provides protection for the delivery team. It forces conversations that used to be avoided and often pushed onto the delivery team to prioritise.
                                  >
                                  > WIP column:
                                  >
                                  > Team members pull work from the Input column only when they are ready to do so. If they get blocked on a piece of work, they first focus on unblocking the issue or assist other team members with their tasks.
                                  >
                                  > Schedule column:
                                  >
                                  > Once a piece of work has been done it often has to wait for a scheduled maintenance window (often out of hours) before it can be deployed and put live. This column is kind of a waiting for release column and used to plan maintenance windows.
                                  >
                                  > Long term blockers:
                                  >
                                  > The section directly above the board with lots of cards with magenta post-its on it is the long term blockers area. This team deals with many 3rd parties and regularly get blocked whilst waiting for the 3rd party to complete something. Unfortunately, the contracts with these 3rd parties do not provide enough leverage to get them to respond quicker so the team could only make them visible. Making them visible enables senior management to see exactly who was blocking them and chase suppliers on a daily basis, applying pressure where possible.
                                  >
                                  > Waste Envelope:
                                  >
                                  > Any waste incurred by the team is captured, quantified, and stored in the waste envelope for discussion during retrospectives.
                                  >
                                  > Blockers Envelope:
                                  >
                                  > All magenta post-it notes (blockers) are kept once the blockage has been removed. These blockers are then analysed during retrospectives to look for trends, common blockages, or any other intel to assist in improving the process.
                                  >
                                  > Metrics:
                                  >
                                  > The team have stuck a paper based metrics form to the right of the board to simplify the generation of a Cumulative Flow Diagram (CFD). They find it easier to write the card count for each column on the form and then update the electronic chart periodically – say at the end of each week.
                                  >
                                  > "The Infra Card":
                                  >
                                  > Each day a new card is inserted directly into the WIP column (a slot is reserved so as not to blow wip limit). Each day between 13:30 and 15:00 the team hit the Infra queues (Infra is the departmental electronic ticketing/job system) for their team and complete what they can within the time box. The number of completed jobs/tickets in Infra is added to the card and its then placed in the done column. The number of jobs/tickets completed is added to the CFD done value.
                                  >
                                  >
                                  >
                                  > Cheers,
                                  >
                                  > Ian.
                                  >
                                  >
                                  > On 30 Sep 2011, at 13:12, mj.wivell wrote:
                                  >
                                  > > Jim,
                                  > >
                                  > > We've worked with several operations teams to set up a Kanban System.
                                  > >
                                  > > I've found that the most important part is two-fold:
                                  > > 1) Setting up the input queue meeting
                                  > > 2) Facilitating the input queue meeting with discipline
                                  > >
                                  > > It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."
                                  > >
                                  > > In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.
                                  > >
                                  > > Getting that meeting right helped set up success in many other areas.
                                  > >
                                  > > MJ Wivell
                                  > > www.bti360.com
                                  > >
                                  > > --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@> wrote:
                                  > > >
                                  > > > All-
                                  > > > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
                                  > > >
                                  > > > Is anyone using kanban in this scenario? Any advice for me?
                                  > > >
                                  > > > Here's what we have done so far:
                                  > > > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
                                  > > >
                                  > > > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
                                  > > >
                                  > > > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
                                  > > >
                                  > > > Looking forward to hearing your ideas! TIA!
                                  > > > Jim Mack
                                  > > >
                                  > >
                                  > >
                                  >
                                • jgmack
                                  We are starting this group out with a daily standup to talk about the day s priorities, because they can change quickly in the Network world. I am targeting a
                                  Message 16 of 16 , Oct 4, 2011
                                  View Source
                                  • 0 Attachment
                                    We are starting this group out with a daily standup to talk about the day's priorities, because they can change quickly in the Network world. I am targeting a 5 to 10 minute meeting that will be facilitated by the functional manager to discuss the work on the board, blockers, and to prioritize what goes into the "Ready" column.

                                    I'm not sure whether we'll do a more formal retrospective or just encourage the team to talk about what's working and what's not working during the daily standups.

                                    Thanks for sharing!
                                    Jim

                                    --- In kanbanops@yahoogroups.com, "mj.wivell" <mjwivell@...> wrote:
                                    >
                                    > Jim,
                                    >
                                    > We've worked with several operations teams to set up a Kanban System.
                                    >
                                    > I've found that the most important part is two-fold:
                                    > 1) Setting up the input queue meeting
                                    > 2) Facilitating the input queue meeting with discipline
                                    >
                                    > It's important for that meeting to be focused around asking the question "What are the two (what ever the "On Deck" WIP Limit permits) things you would like me to work on next."
                                    >
                                    > In our experience we've had true ad hoc work to where we had the input queue meeting each morning. We've also done it weekly. It's typically a very quick meeting.
                                    >
                                    > Getting that meeting right helped set up success in many other areas.
                                    >
                                    > MJ Wivell
                                    > www.bti360.com
                                    >
                                    > --- In kanbanops@yahoogroups.com, "jgmack" <jgmack@> wrote:
                                    > >
                                    > > All-
                                    > > I am working with our Network Services team to get a handle on their workload and have proposed kanban as a possible solution.
                                    > >
                                    > > Is anyone using kanban in this scenario? Any advice for me?
                                    > >
                                    > > Here's what we have done so far:
                                    > > The manager and I have put together a mockup board and showed it to the team, explaining the principles of visualizing work, limiting WIP, modifying policies when things aren't working, etc.
                                    > >
                                    > > Next steps are to populate the backlog and then run a simulation with the team next week to surface issues, develop policies with the team's input and to try to discover what may work and what might not.
                                    > >
                                    > > I would love to hear some success stories from others doing the same thing, especially about how you handle the variability of the tasks, the ad-hoc nature of work requests and the manager's role in this situation.
                                    > >
                                    > > Looking forward to hearing your ideas! TIA!
                                    > > Jim Mack
                                    > >
                                    >
                                  Your message has been successfully submitted and would be delivered to recipients shortly.