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

how to handle kanban on a large, distributed team?

Expand Messages
  • Aaron Sanders
    Let s say you work on a system comprised of 50 teams working on 25 products from 5 locations, east coast, west coast, Japan, India and the UK (so the sun never
    Message 1 of 6 , Dec 1, 2007
    View Source
    • 0 Attachment
      Let's say you work on a system comprised of 50 teams working on 25
      products from 5 locations, east coast, west coast, Japan, India and
      the UK (so the sun never sets on development). To make it simpler,
      program and product management are distributed with the teams, as
      opposed to centralized. The leadership team, however, is centralized
      in one place and includes the architects and core leadership team of
      VPs for each group.

      One team works on more than one release, and one release can span
      multiple teams. There are also internal projects with no customer
      facing value, plus ongoing support of production releases.

      Teams mostly work on horizontal slices of the system, with teams also
      dedicated to: site ops, prod ops, QA, DBA, and perf, as well as dev.

      Current release throughput is 6 per quarter, with a lead time of 4
      weeks per release.

      How would WIP capacity best be determined, and how should releases be
      pulled through, given such variance in releases per team, and teams
      per release?
    • David J Anderson
      Aaron, Given the description in the final paragraph that lead time is 4 weeks and you have a release every 2 weeks, then the minimum WIP is 2 projects
      Message 2 of 6 , Dec 2, 2007
      View Source
      • 0 Attachment
        Aaron,

        Given the description in the final paragraph that lead time is 4 weeks
        and you have a release every 2 weeks, then the minimum WIP is 2
        projects overlapping and staggered by 2 weeks. Given that there might
        be some variation then perhaps a WIP limit of 3 is appropriate.

        With a WIP limit of 3, I'd have a queue of at most 2 and probably only
        1 but the decision on this would depend on the lead time of any
        preparatory work that happens while things are queuing.

        So help me understand the rest of your described situation to
        understand why a WIP limit of 3 projects/releases might not be the
        right answer?

        David


        --- In kanbandev@yahoogroups.com, "Aaron Sanders" <aremsan@...> wrote:
        >
        > Let's say you work on a system comprised of 50 teams working on 25
        > products from 5 locations, east coast, west coast, Japan, India and
        > the UK (so the sun never sets on development). To make it simpler,
        > program and product management are distributed with the teams, as
        > opposed to centralized. The leadership team, however, is centralized
        > in one place and includes the architects and core leadership team of
        > VPs for each group.
        >
        > One team works on more than one release, and one release can span
        > multiple teams. There are also internal projects with no customer
        > facing value, plus ongoing support of production releases.
        >
        > Teams mostly work on horizontal slices of the system, with teams also
        > dedicated to: site ops, prod ops, QA, DBA, and perf, as well as dev.
        >
        > Current release throughput is 6 per quarter, with a lead time of 4
        > weeks per release.
        >
        > How would WIP capacity best be determined, and how should releases be
        > pulled through, given such variance in releases per team, and teams
        > per release?
        >
      • Chris Matts
        Aaron I do not have a solution so much as a restatement of the problem. The solution will probably require some form of software. The constraint moves and
        Message 3 of 6 , Dec 2, 2007
        View Source
        • 0 Attachment
          Aaron

          I do not have a solution so much as a restatement of the problem. The
          solution will probably require some form of software.

          The constraint moves and changes in size depending on the release and
          each release's requirement from each lower level constraint.

          When determining the release, each team ( constraint ) needs to have a
          Kanban board and associated number of slots. As you pull the business
          value and features are injected into the system, features and hence
          team level kanban cards will be generated and injected into the
          system. The only way to increase the flow is add capacity to the
          constraint.

          Chris




          On Dec 2, 2007 12:52 AM, Aaron Sanders <aremsan@...> wrote:
          >
          >
          >
          >
          > Let's say you work on a system comprised of 50 teams working on 25
          > products from 5 locations, east coast, west coast, Japan, India and
          > the UK (so the sun never sets on development). To make it simpler,
          > program and product management are distributed with the teams, as
          > opposed to centralized. The leadership team, however, is centralized
          > in one place and includes the architects and core leadership team of
          > VPs for each group.
          >
          > One team works on more than one release, and one release can span
          > multiple teams. There are also internal projects with no customer
          > facing value, plus ongoing support of production releases.
          >
          > Teams mostly work on horizontal slices of the system, with teams also
          > dedicated to: site ops, prod ops, QA, DBA, and perf, as well as dev.
          >
          > Current release throughput is 6 per quarter, with a lead time of 4
          > weeks per release.
          >
          > How would WIP capacity best be determined, and how should releases be
          > pulled through, given such variance in releases per team, and teams
          > per release?
          >
          >



          --
          Regards

          Chris Matts
        • David J Anderson
          Some clarifying questions? How many of the 50 teams are dev teams? How many dev teams does it take to make a coherent whole i.e. UI layer, business logic, db
          Message 4 of 6 , Dec 2, 2007
          View Source
          • 0 Attachment
            Some clarifying questions?

            How many of the 50 teams are dev teams? How many dev teams does it
            take to make a coherent whole i.e. UI layer, business logic, db dev /
            persistence, and so forth?

            Is it desired to keep up releases of every one of the 25 products
            every 2 weeks or so? If not what is the required cadence of delivery
            for each product? Is it similar i.e. once per month, or does it vary
            by product?

            David

            --- In kanbandev@yahoogroups.com, "Aaron Sanders" <aremsan@...> wrote:
            >
            > Let's say you work on a system comprised of 50 teams working on 25
            > products from 5 locations, east coast, west coast, Japan, India and
            > the UK (so the sun never sets on development). To make it simpler,
            > program and product management are distributed with the teams, as
            > opposed to centralized. The leadership team, however, is centralized
            > in one place and includes the architects and core leadership team of
            > VPs for each group.
            >
            > One team works on more than one release, and one release can span
            > multiple teams. There are also internal projects with no customer
            > facing value, plus ongoing support of production releases.
            >
            > Teams mostly work on horizontal slices of the system, with teams also
            > dedicated to: site ops, prod ops, QA, DBA, and perf, as well as dev.
            >
            > Current release throughput is 6 per quarter, with a lead time of 4
            > weeks per release.
            >
            > How would WIP capacity best be determined, and how should releases be
            > pulled through, given such variance in releases per team, and teams
            > per release?
            >
          • David J Anderson
            Aaron, Another clarifying question?... Are you trying to reduce this problem to a single virtual-kanban system - a single pipe with a single release train? If
            Message 5 of 6 , Dec 3, 2007
            View Source
            • 0 Attachment
              Aaron,

              Another clarifying question?...

              Are you trying to reduce this problem to a single virtual-kanban
              system - a single pipe with a single release train?

              If so then I can see why the resourcing versus WIP (kanban) limit is a
              tricky problem?

              Perhaps we can arrange to discuss it off line and then post our
              conclusions to the group?

              David


              --- In kanbandev@yahoogroups.com, "David J Anderson" <netherby_uk@...>
              wrote:
              >
              > Some clarifying questions?
              >
              > How many of the 50 teams are dev teams? How many dev teams does it
              > take to make a coherent whole i.e. UI layer, business logic, db dev /
              > persistence, and so forth?
              >
              > Is it desired to keep up releases of every one of the 25 products
              > every 2 weeks or so? If not what is the required cadence of delivery
              > for each product? Is it similar i.e. once per month, or does it vary
              > by product?
              >
              > David
              >
              > --- In kanbandev@yahoogroups.com, "Aaron Sanders" <aremsan@> wrote:
              > >
              > > Let's say you work on a system comprised of 50 teams working on 25
              > > products from 5 locations, east coast, west coast, Japan, India and
              > > the UK (so the sun never sets on development). To make it simpler,
              > > program and product management are distributed with the teams, as
              > > opposed to centralized. The leadership team, however, is centralized
              > > in one place and includes the architects and core leadership team of
              > > VPs for each group.
              > >
              > > One team works on more than one release, and one release can span
              > > multiple teams. There are also internal projects with no customer
              > > facing value, plus ongoing support of production releases.
              > >
              > > Teams mostly work on horizontal slices of the system, with teams also
              > > dedicated to: site ops, prod ops, QA, DBA, and perf, as well as dev.
              > >
              > > Current release throughput is 6 per quarter, with a lead time of 4
              > > weeks per release.
              > >
              > > How would WIP capacity best be determined, and how should releases be
              > > pulled through, given such variance in releases per team, and teams
              > > per release?
              > >
              >
            • Aaron Sanders
              Yeah, I d like to come up with a single, recursive, virtual KSSE which deals with the different rolling waves of interrelated products, supported by more than
              Message 6 of 6 , Dec 3, 2007
              View Source
              • 0 Attachment
                Yeah, I'd like to come up with a single, recursive, virtual KSSE which
                deals with the different rolling waves of interrelated products,
                supported by more than one platform, consisting of many releases.

                I have started at the team level to come up with correct limits on WIP
                for each team and feeding features for releases in at that level.
                Coming up a level for injecting releases is daunting. Coming up
                another level to product dependencies and the platforms being
                developed in parallel becomes quite a challenge.

                Trying to explain it all and walking around delicate NDA issues isn't
                fun. I figured if I put a scenario somewhat different from the 'real'
                one out there and walk through a virtual situation may help me.
                Usually for simulations you cut down the problem, but I am trying to
                blow it up a little bit.

                I can have some data which is a little closer to reality, which
                shouldn't divulge too much, and come back with that to talk through.

                In the mean time, your answers (and even questions!) have provided me
                with some insight in to the problem. So, thanks. I'll reshape the
                issue as soon as I can.



                --- In kanbandev@yahoogroups.com, "David J Anderson" <netherby_uk@...>
                wrote:
                >
                > Aaron,
                >
                > Another clarifying question?...
                >
                > Are you trying to reduce this problem to a single virtual-kanban
                > system - a single pipe with a single release train?
                >
                > If so then I can see why the resourcing versus WIP (kanban) limit is a
                > tricky problem?
                >
                > Perhaps we can arrange to discuss it off line and then post our
                > conclusions to the group?
                >
                > David
                >
                >
                > --- In kanbandev@yahoogroups.com, "David J Anderson" <netherby_uk@>
                > wrote:
                > >
                > > Some clarifying questions?
                > >
                > > How many of the 50 teams are dev teams? How many dev teams does it
                > > take to make a coherent whole i.e. UI layer, business logic, db dev /
                > > persistence, and so forth?
                > >
                > > Is it desired to keep up releases of every one of the 25 products
                > > every 2 weeks or so? If not what is the required cadence of delivery
                > > for each product? Is it similar i.e. once per month, or does it vary
                > > by product?
                > >
                > > David
                > >
                > > --- In kanbandev@yahoogroups.com, "Aaron Sanders" <aremsan@> wrote:
                > > >
                > > > Let's say you work on a system comprised of 50 teams working on 25
                > > > products from 5 locations, east coast, west coast, Japan, India and
                > > > the UK (so the sun never sets on development). To make it simpler,
                > > > program and product management are distributed with the teams, as
                > > > opposed to centralized. The leadership team, however, is centralized
                > > > in one place and includes the architects and core leadership team of
                > > > VPs for each group.
                > > >
                > > > One team works on more than one release, and one release can span
                > > > multiple teams. There are also internal projects with no customer
                > > > facing value, plus ongoing support of production releases.
                > > >
                > > > Teams mostly work on horizontal slices of the system, with teams
                also
                > > > dedicated to: site ops, prod ops, QA, DBA, and perf, as well as dev.
                > > >
                > > > Current release throughput is 6 per quarter, with a lead time of 4
                > > > weeks per release.
                > > >
                > > > How would WIP capacity best be determined, and how should
                releases be
                > > > pulled through, given such variance in releases per team, and teams
                > > > per release?
                > > >
                > >
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.