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

Kanban for a network operations team

Expand Messages
  • w4trgate
    I am the lead for a 6 person network operations team. The company for which I work has gotten Scrum fever and my manager wants to use it to handle our group s
    Message 1 of 6 , Nov 4, 2011
    View Source
    • 0 Attachment
      I am the lead for a 6 person network operations team. The company for which I work has gotten Scrum fever and my manager wants to use it to handle our group's work. I've been through the company-provided ScrumMaster training and I've read David Anderson's Kanban book. I personally feel Kanban is a better fit to start off with.

      Our workload comes in two flavors: planned and interrupt-driven. Projects and other scrum team tasks fit into the planned category and the interrupt-driven tasks are the usual trouble tickets, last-minute drive-bys, break/fix work, and other requests for our time that tend to come out of the blue. My first goal is to get a Kanban system established to start getting visibility and metrics together. Eventually I can see a hybrid Scrum/Kanban system where tasks from projects/scrums are simply part of the backlog and flow through our system. How would I set this up on a board? I thought about horizontal swimlanes splitting planned and interrupt work into separate lanes but as a Kanban noob I am interested in how group members are (if at all) handling interrupt work vs. planned work.

      Chuck Nixon
    • Joe Miller
      I had a similar issue and I chose to add a 3rd horizontal swim lane to our board. We already had an Expedite and main lane so we broke the main lane into
      Message 2 of 6 , Nov 4, 2011
      View Source
      • 0 Attachment
        I had a similar issue and I chose to add a 3rd horizontal swim lane to our board.  We already had an "Expedite" and main lane so we broke the main lane into "tangible" and "intangible" which we took from the Spotify Ops team's presentation here:  http://www.infoq.com/articles/kanban-operations-spotify

        We debated calling the new lanes "external work" and "internal work" instead, but in the end decided on tangible/intangible with similar rules as the Spotify team.

        In your case, you could consider calling one lane the 'planned/scrum lane' and 'interrupt driven' lane.   

        You might want to set some rules for minimum sizes with the interrupt work.  We don't put interrupt-driven work on the board that is less than 1 hour of time.  I've heard others use 15 or 30 mins.  We did this so that we don't skew our metrics.  The cumulative flow diagram is very sensitive to the relative sizing of tasks.  We implemented sizing to help with this, but we still set a limit that anything less than an hour won't get a ticket (in most cases.)   BTW, track your metrics early on in the process. I didn't stat tracking metrics in a CFD until much later and I regret it now =)

        I think Kanban is very compatbile with Scrum.  Kanban adds that visualization element that scrum lacks.  I've seen plenty of scrum teams walk around in total chaos because no one has any idea what each other is working on.  Kanban can help here.

        On Fri, Nov 4, 2011 at 1:16 PM, w4trgate <watrgate@...> wrote:
         

        I am the lead for a 6 person network operations team. The company for which I work has gotten Scrum fever and my manager wants to use it to handle our group's work. I've been through the company-provided ScrumMaster training and I've read David Anderson's Kanban book. I personally feel Kanban is a better fit to start off with.

        Our workload comes in two flavors: planned and interrupt-driven. Projects and other scrum team tasks fit into the planned category and the interrupt-driven tasks are the usual trouble tickets, last-minute drive-bys, break/fix work, and other requests for our time that tend to come out of the blue. My first goal is to get a Kanban system established to start getting visibility and metrics together. Eventually I can see a hybrid Scrum/Kanban system where tasks from projects/scrums are simply part of the backlog and flow through our system. How would I set this up on a board? I thought about horizontal swimlanes splitting planned and interrupt work into separate lanes but as a Kanban noob I am interested in how group members are (if at all) handling interrupt work vs. planned work.

        Chuck Nixon


      • David Anderson
        Can you say something more about the value metrics and particularly CFDs are giving you? Often people question the value of CFDs after they are limiting WIP
        Message 3 of 6 , Nov 4, 2011
        View Source
        • 0 Attachment
          Can you say something more about the value metrics and particularly CFDs are giving you? Often people question the value of CFDs after they are limiting WIP with a kanban system. I'm interested in your story.

          David

          --- In kanbanops@yahoogroups.com, Joe Miller <joeym@...> wrote:
          >
          > I had a similar issue and I chose to add a 3rd horizontal swim lane to our
          > board. We already had an "Expedite" and main lane so we broke the main
          > lane into "tangible" and "intangible" which we took from the Spotify Ops
          > team's presentation here:
          > http://www.infoq.com/articles/kanban-operations-spotify
          >
          > We debated calling the new lanes "external work" and "internal work"
          > instead, but in the end decided on tangible/intangible with similar rules
          > as the Spotify team.
          >
          > In your case, you could consider calling one lane the 'planned/scrum lane'
          > and 'interrupt driven' lane.
          >
          > You might want to set some rules for minimum sizes with the interrupt work.
          > We don't put interrupt-driven work on the board that is less than 1 hour
          > of time. I've heard others use 15 or 30 mins. We did this so that we
          > don't skew our metrics. The cumulative flow diagram is very sensitive to
          > the relative sizing of tasks. We implemented sizing to help with this, but
          > we still set a limit that anything less than an hour won't get a ticket (in
          > most cases.) BTW, track your metrics early on in the process. I didn't
          > stat tracking metrics in a CFD until much later and I regret it now =)
          >
          > I think Kanban is very compatbile with Scrum. Kanban adds that
          > visualization element that scrum lacks. I've seen plenty of scrum teams
          > walk around in total chaos because no one has any idea what each other is
          > working on. Kanban can help here.
          >
          > On Fri, Nov 4, 2011 at 1:16 PM, w4trgate <watrgate@...> wrote:
          >
          > > **
          > >
          > >
          > > I am the lead for a 6 person network operations team. The company for
          > > which I work has gotten Scrum fever and my manager wants to use it to
          > > handle our group's work. I've been through the company-provided ScrumMaster
          > > training and I've read David Anderson's Kanban book. I personally feel
          > > Kanban is a better fit to start off with.
          > >
          > > Our workload comes in two flavors: planned and interrupt-driven. Projects
          > > and other scrum team tasks fit into the planned category and the
          > > interrupt-driven tasks are the usual trouble tickets, last-minute
          > > drive-bys, break/fix work, and other requests for our time that tend to
          > > come out of the blue. My first goal is to get a Kanban system established
          > > to start getting visibility and metrics together. Eventually I can see a
          > > hybrid Scrum/Kanban system where tasks from projects/scrums are simply part
          > > of the backlog and flow through our system. How would I set this up on a
          > > board? I thought about horizontal swimlanes splitting planned and interrupt
          > > work into separate lanes but as a Kanban noob I am interested in how group
          > > members are (if at all) handling interrupt work vs. planned work.
          > >
          > > Chuck Nixon
          > >
          > >
          > >
          >
        • Joe Miller
          It s just that - it s actually placing an emphasis on why we should be working harder to limit WIP. I would say we weren t doing kanban right . We were not
          Message 4 of 6 , Nov 5, 2011
          View Source
          • 0 Attachment
            It's just that - it's actually placing an emphasis on why we should be working harder to limit WIP.  I would say we weren't doing kanban 'right'. We were not focusing on single-item flow, limited WIP, etc. We would routinely overflow the WIP and context-switch rapidly between tasks. CFD has helped put an emphasis on why we should be diligent on limiting WIP by visualizing what the consequences were of not limiting WIP - we weren't getting as much done, although we were very busy.  Now that we are passed that hurdle, it is entirely possible the CFD will lose value for us.

            I should mention that we only have about 3 months of data in the CFD now, and only 1 month since I realized that the diverse sizes of our stories was making the data almost useless.  At that point, we reset the CFD over and assigned S/M/L(1/2/3) sizes to our tasks.

            A possible but not yet validated benefit from the CFD is in communicating impact to the business. We track our 'expedite' swim lane on the CFD as well.  I suspect that may come in handy as a tool to engage in better prioritization conversations in the future.  Eg: if the business is bypassing the normal process and stuffing the Expedite channel, I would like to be able to show the impact that is having on the rest of the team's responsibilities. I think the CFD may be helpful here.

            For our metrics, we use the google spreadsheet bekk.no which has other charts besides CFD.  Some of these may be helpful in the future too, as we build up more data.  http://open.bekk.no/cumulative-flow-diagrams-with-google-spreadsheets/ 

            We are also metrics junkies.  Not quite on the level of the Etsy folks, but we try to track a lot of data from our apps and infrastructure in Graphite.  So, the metrics from our kanban board scratchs our metrics itch.

            On Fri, Nov 4, 2011 at 10:30 PM, David Anderson <dja@...> wrote:
             

            Can you say something more about the value metrics and particularly CFDs are giving you? Often people question the value of CFDs after they are limiting WIP with a kanban system. I'm interested in your story.

            David



            --- In kanbanops@yahoogroups.com, Joe Miller <joeym@...> wrote:
            >
            > I had a similar issue and I chose to add a 3rd horizontal swim lane to our
            > board. We already had an "Expedite" and main lane so we broke the main
            > lane into "tangible" and "intangible" which we took from the Spotify Ops
            > team's presentation here:
            > http://www.infoq.com/articles/kanban-operations-spotify
            >
            > We debated calling the new lanes "external work" and "internal work"
            > instead, but in the end decided on tangible/intangible with similar rules
            > as the Spotify team.
            >
            > In your case, you could consider calling one lane the 'planned/scrum lane'
            > and 'interrupt driven' lane.
            >
            > You might want to set some rules for minimum sizes with the interrupt work.
            > We don't put interrupt-driven work on the board that is less than 1 hour
            > of time. I've heard others use 15 or 30 mins. We did this so that we
            > don't skew our metrics. The cumulative flow diagram is very sensitive to
            > the relative sizing of tasks. We implemented sizing to help with this, but
            > we still set a limit that anything less than an hour won't get a ticket (in
            > most cases.) BTW, track your metrics early on in the process. I didn't
            > stat tracking metrics in a CFD until much later and I regret it now =)
            >
            > I think Kanban is very compatbile with Scrum. Kanban adds that
            > visualization element that scrum lacks. I've seen plenty of scrum teams
            > walk around in total chaos because no one has any idea what each other is
            > working on. Kanban can help here.
            >
            > On Fri, Nov 4, 2011 at 1:16 PM, w4trgate <watrgate@...> wrote:
            >
            > > **

            > >
            > >
            > > I am the lead for a 6 person network operations team. The company for
            > > which I work has gotten Scrum fever and my manager wants to use it to
            > > handle our group's work. I've been through the company-provided ScrumMaster
            > > training and I've read David Anderson's Kanban book. I personally feel
            > > Kanban is a better fit to start off with.
            > >
            > > Our workload comes in two flavors: planned and interrupt-driven. Projects
            > > and other scrum team tasks fit into the planned category and the
            > > interrupt-driven tasks are the usual trouble tickets, last-minute
            > > drive-bys, break/fix work, and other requests for our time that tend to
            > > come out of the blue. My first goal is to get a Kanban system established
            > > to start getting visibility and metrics together. Eventually I can see a
            > > hybrid Scrum/Kanban system where tasks from projects/scrums are simply part
            > > of the backlog and flow through our system. How would I set this up on a
            > > board? I thought about horizontal swimlanes splitting planned and interrupt
            > > work into separate lanes but as a Kanban noob I am interested in how group
            > > members are (if at all) handling interrupt work vs. planned work.
            > >
            > > Chuck Nixon
            > >
            > >
            > >
            >


          • Lowe Schmidt
            I also took inspiration from the Spotify presentation (and they re really intelligent and nice guys:), One thing you can add is having what they call a goalie
            Message 5 of 6 , Nov 5, 2011
            View Source
            • 0 Attachment
              I also took inspiration from the Spotify presentation (and they're really intelligent and nice guys:),

              One thing you can add is having what they call a goalie (we call it daily third line). One person each week is responsible for taking all the interrupt driven tasks, whether they over IM, phone or someone strolling in and talking to us, either do them or size them and put them on the board. This frees up the others to do planned work without being interrupted, we will visualise this by having a flag or something similar on the goalies desk. The only thing that is "all hands on deck" is production incidents. 

              On 4 November 2011 21:16, w4trgate <watrgate@...> wrote:
               

              I am the lead for a 6 person network operations team. The company for which I work has gotten Scrum fever and my manager wants to use it to handle our group's work. I've been through the company-provided ScrumMaster training and I've read David Anderson's Kanban book. I personally feel Kanban is a better fit to start off with.

              Our workload comes in two flavors: planned and interrupt-driven. Projects and other scrum team tasks fit into the planned category and the interrupt-driven tasks are the usual trouble tickets, last-minute drive-bys, break/fix work, and other requests for our time that tend to come out of the blue. My first goal is to get a Kanban system established to start getting visibility and metrics together. Eventually I can see a hybrid Scrum/Kanban system where tasks from projects/scrums are simply part of the backlog and flow through our system. How would I set this up on a board? I thought about horizontal swimlanes splitting planned and interrupt work into separate lanes but as a Kanban noob I am interested in how group members are (if at all) handling interrupt work vs. planned work.

              Chuck Nixon




              --
              Lowe Schmidt
              +46763382827

            • w4trgate
              Each week we have an on-call person who could act as the goalie. This person takes tickets and responds to service outages so it wouldn t be much of a change.
              Message 6 of 6 , Nov 10, 2011
              View Source
              • 0 Attachment
                Each week we have an on-call person who could act as the goalie. This person takes tickets and responds to service outages so it wouldn't be much of a change.

                Thanks for the Spotify lead. I will go read up on that.

                --- In kanbanops@yahoogroups.com, Lowe Schmidt <lowe.schmidt@...> wrote:
                >
                > I also took inspiration from the Spotify presentation (and they're really
                > intelligent and nice guys:),
                >
                > One thing you can add is having what they call a goalie (we call it daily
                > third line). One person each week is responsible for taking all the
                > interrupt driven tasks, whether they over IM, phone or someone strolling in
                > and talking to us, either do them or size them and put them on the board.
                > This frees up the others to do planned work without being interrupted, we
                > will visualise this by having a flag or something similar on the goalies
                > desk. The only thing that is "all hands on deck" is production incidents.
                >
                > On 4 November 2011 21:16, w4trgate <watrgate@...> wrote:
                >
                > > **
                > >
                > >
                > > I am the lead for a 6 person network operations team. The company for
                > > which I work has gotten Scrum fever and my manager wants to use it to
                > > handle our group's work. I've been through the company-provided ScrumMaster
                > > training and I've read David Anderson's Kanban book. I personally feel
                > > Kanban is a better fit to start off with.
                > >
                > > Our workload comes in two flavors: planned and interrupt-driven. Projects
                > > and other scrum team tasks fit into the planned category and the
                > > interrupt-driven tasks are the usual trouble tickets, last-minute
                > > drive-bys, break/fix work, and other requests for our time that tend to
                > > come out of the blue. My first goal is to get a Kanban system established
                > > to start getting visibility and metrics together. Eventually I can see a
                > > hybrid Scrum/Kanban system where tasks from projects/scrums are simply part
                > > of the backlog and flow through our system. How would I set this up on a
                > > board? I thought about horizontal swimlanes splitting planned and interrupt
                > > work into separate lanes but as a Kanban noob I am interested in how group
                > > members are (if at all) handling interrupt work vs. planned work.
                > >
                > > Chuck Nixon
                > >
                > >
                > >
                >
                >
                >
                > --
                > Lowe Schmidt
                > +46763382827
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.