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

Re: [kanbandev] Re: Kanban system design problems

Expand Messages
  • Mike Burrows
    Collaboration between silos is indeed vital, but simple cures aren t sufficient when (to take real examples): 1. The work items going across silo boundaries
    Message 1 of 14 , Apr 9 1:47 AM
    View Source
    • 0 Attachment
      Collaboration between silos is indeed vital, but simple cures aren't sufficient when (to take real examples):
      1. The work items going across silo boundaries are large
      2. There are stage gates between silos (reinforcing #1 and building in a delay)
      3. The silos aren't in the same building/country (a big and obvious target but not necessarily the one causing the most pain)
      Problems like these get solved thanks to commitment from both sides and from those who set the rules if they sit outside/above the teams involved.  Naturally this is much easier if Kanban is regarded by the "bigger system" as the means to get tough issues surfaced and fixed.  Implemented as a change management system, in other words.

      Mike

      --
      Mike Burrows
      Positive Incline Limited
      mjb@...
      http://positiveincline.com
      http://twitter.com/asplake


      On 9 April 2011 09:04, alexishui <alexis.hui@...> wrote:
       

      Dadi, the great thing about Kanban is you have the tools to incrementally change your system of work. A simple way to get started is find two parts of your process that is currently siloed, and make those parts share a common WIP. This will put a controlled amount of pain on the team to force collaboration and members from the faster silo to help the bottleneck as they won't be able to start new work. Once these two groups start collaborating successfully, you can now look at the next part of the system and repeat.

      --- In kanbandev@yahoogroups.com, "comspy66" <blubberplinth@...> wrote:
      >
      >
      > --- In kanbandev@yahoogroups.com, "Alexis Hui" <alexis.hui@> wrote:
      > >
      > > Been through a similar situation before, would start with the following:
      > >
      > > 1) Way too much WIP is in the system, set a global WIP by work type, a good number might be 3 new website/big enhancements and 2 small enhancements (be strict on WIP limits, lower the better)
      > >
      > > 2) Analyze the demand by work type, frequency of new websites/big enhancements vs small enhancements and also figure out average cycle time per work type
      > >
      > > 3) Establish a regular queue replenishment and get the PM + sales + designers to play product owners, this will depend on the teams cycle times per work item
      > >
      > > Once you have these 3 key pieces set-up, you should have some good data and a working system to improve upon
      > >
      > > -Alexis Hui
      > > http://www.agileconsulting.blogspot.com
      > > Sent on the TELUS Mobility network with BlackBerry
      > >
      >
      > Hi Alexis,
      >
      > Thanks for these recommendations. We are actually starting to work on 2) this week.
      >
      > We've had a really hard time with establishing low global WIP in the system, because there is so much WIP in there already ;-) Vicious cycle, really. My feeling is that because there is very little explicit collaboration between team members the tendency is to have at least 2 or more items per person in flight. So, setting a low global WIP limit would be very "revolutionary", if you catch my meaning". What's your experience with doing this? How did you go about it?
      >
      > 3) is also something that we have discussed, but not done anything about as yet. Will recommend this in next session.
      >
      > Thanks a lot for you help!
      >
      > Cheers,
      > Dadi.
      >


    • comspy66
      Alexis, I think this is a good idea in my context. The client is actually going to combine two steps that used to require a handoff with the expensive
      Message 2 of 14 , Apr 12 3:56 AM
      View Source
      • 0 Attachment
        Alexis, I think this is a good idea in my context. The client is actually going to combine two steps that used to require a handoff with the expensive miscommunication and confusion that entailed. However, the points you gave, Mike, are very relevant for other parts of the Kanban system. Especially, points 1 and 2, and since there is a whole-company view of Kanban as a change management system I think commitment to these kinds of changes are very possible.

        Thanks,
        Dadi.

        --- In kanbandev@yahoogroups.com, Mike Burrows <mjb@...> wrote:
        >
        > Collaboration between silos is indeed vital, but simple cures aren't
        > sufficient when (to take real examples):
        >
        > 1. The work items going across silo boundaries are large
        > 2. There are stage gates between silos (reinforcing #1 and building in a
        > delay)
        > 3. The silos aren't in the same building/country (a big and obvious
        > target but not necessarily the one causing the most pain)
        >
        > Problems like these get solved thanks to commitment from both sides and from
        > those who set the rules if they sit outside/above the teams involved.
        > Naturally this is much easier if Kanban is regarded by the "bigger system"
        > as the means to get tough issues surfaced and fixed. Implemented as a
        > change management system, in other words.
        >
        > Mike
        >
        > --
        > Mike Burrows
        > Positive Incline Limited
        > mjb@...
        > http://positiveincline.com
        > http://twitter.com/asplake
        >
        >
        > On 9 April 2011 09:04, alexishui <alexis.hui@...> wrote:
        >
        > >
        > >
        > > Dadi, the great thing about Kanban is you have the tools to incrementally
        > > change your system of work. A simple way to get started is find two parts of
        > > your process that is currently siloed, and make those parts share a common
        > > WIP. This will put a controlled amount of pain on the team to force
        > > collaboration and members from the faster silo to help the bottleneck as
        > > they won't be able to start new work. Once these two groups start
        > > collaborating successfully, you can now look at the next part of the system
        > > and repeat.
        > >
        > >
        > > -Alexis Hui
        > > http://www.agileconsulting.blogspot.com
        > >
        > > --- In kanbandev@yahoogroups.com, "comspy66" <blubberplinth@> wrote:
        > > >
        > > >
        > > > --- In kanbandev@yahoogroups.com, "Alexis Hui" <alexis.hui@> wrote:
        > > > >
        > > > > Been through a similar situation before, would start with the
        > > following:
        > > > >
        > > > > 1) Way too much WIP is in the system, set a global WIP by work type, a
        > > good number might be 3 new website/big enhancements and 2 small enhancements
        > > (be strict on WIP limits, lower the better)
        > > > >
        > > > > 2) Analyze the demand by work type, frequency of new websites/big
        > > enhancements vs small enhancements and also figure out average cycle time
        > > per work type
        > > > >
        > > > > 3) Establish a regular queue replenishment and get the PM + sales +
        > > designers to play product owners, this will depend on the teams cycle times
        > > per work item
        > > > >
        > > > > Once you have these 3 key pieces set-up, you should have some good data
        > > and a working system to improve upon
        > > > >
        > > > > -Alexis Hui
        > > > > http://www.agileconsulting.blogspot.com
        > > > > Sent on the TELUS Mobility network with BlackBerry
        > > > >
        > > >
        > > > Hi Alexis,
        > > >
        > > > Thanks for these recommendations. We are actually starting to work on 2)
        > > this week.
        > > >
        > > > We've had a really hard time with establishing low global WIP in the
        > > system, because there is so much WIP in there already ;-) Vicious cycle,
        > > really. My feeling is that because there is very little explicit
        > > collaboration between team members the tendency is to have at least 2 or
        > > more items per person in flight. So, setting a low global WIP limit would be
        > > very "revolutionary", if you catch my meaning". What's your experience with
        > > doing this? How did you go about it?
        > > >
        > > > 3) is also something that we have discussed, but not done anything about
        > > as yet. Will recommend this in next session.
        > > >
        > > > Thanks a lot for you help!
        > > >
        > > > Cheers,
        > > > Dadi.
        > > >
        > >
        > >
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.