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

Re: [kanbandev] Re: one piece flow - not a lean software or Kanban thing

Expand Messages
  • Andrew Pham
    Hello Hakan, ... Yes, you are right that change is hard and this is the hardest. But to be honest, Scrum and Kanban are not hard, especially if you have the
    Message 1 of 1 , Dec 3, 2011
    • 0 Attachment
      Hello Hakan,

      On Fri, Nov 25, 2011 at 6:33 AM, Håkan Forss <hakan_forss@...> wrote:
       

      Kurt, I don’t have all your context so this may be totally wrong for you so bear with me here.

       

      Starting with what you got in the case you describe would be to have a separate process for every combination of PM and customer. When you have visualized this and verified that this is how work is really done you can start improving the processes and maybe even make a more common way of working if that is beneficial for the overall system.

       

      Yes, Kanban is hard, Scrum is hard, all change is hard but in my experience Kanban is the least hard of the approaches I have tried.


      Yes, you are right that change is hard and this is the hardest. But to be honest, Scrum and Kanban are not hard, especially if you have the right undersatnding and support from management and the buying from the teams.

      I have coached Agile (Scrum) and/or Lean (Kanban) teams everywhere and when we have these two conditions united, we have always successfully delivered software everywhere with Agile (Scrum) and/or Kanban (Lean).

      Cheers,

      Andrew

      Author of
      Scrum in Action, Agile Project Management and Development in the Real-World
      http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1-1

      and of "Business-Driven IT-Wide Agile (Scrum) and/or Kanban (Lean) Implementation" (reviewed and upcoming)

       

       

      I usually try to introduce changes in the form of experiments based on a hypothesis. I emphasize that the experiment will run for a limited amount of time and will then be evaluated. If the experiment was successful we keep the change otherwise we try something else based on what we learned or revert back to how we did before. This tends to lower the resistance to change very much.

      From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On Behalf Of Kurt Häusler
      Sent: den 25 november 2011 12:55


      To: kanbandev@yahoogroups.com
      Subject: Re: [kanbandev] Re: one piece flow - not a lean software or Kanban thing

       

       

       

      On Fri, Nov 25, 2011 at 12:18 PM, Mike Burrows <mjb@...> wrote:

       

      I don't know enough about your organisation to know what underlies your issues.  Was such a reorganisation ever possible, likely, planned even?  If it was, what would been its chances of success?  Any higher than Kanban's? Perhaps we will never know, but I do get the strong impression from your posts that things have been difficult for deep-rooted reasons.

       

      I think the type of reorganization that our organization needs is indeed possible. And I think it would have been successful too. Oh and I don't really think of these changes being alternatives to Kanban, but part of Kanban.

       

      And you are right, if there is one thing we have consensus on here is that Kanban has been difficult. And the reasons are indeed deep-rooted, and mostly cultural.

       

      Things would be a lot easier if we just did what needs to be done, but you know how it is, everyone has their values and even agendas and egos, and one person might say oh there's a problem here because we put too much pressure on developers and there is too much bureaucratic overhead for this part of the process that made sense before Kanban but it just doesn't work in a WIP limited, pull context so we need to ditch it. Another 5 people might say the developers need more pressure and we need more bureaucracy, so how do we do that with Kanban, and 5 people beat 1 person. 

       



      > "a whole bunch of stuff needs to change just to get something that doesn't clash with what Kanban imposes"

      I do talk to people who have teams don't want (say) to respect limits, but "clash" and "impose" are strong words when Kanban starts with "respecting", "agree" and "evolutionary" (these are from the principles, before even the practices).  It would seem that something went wong somewhere, and it would be really good for us all to understand this.  Can you elaborate?

       

      OK, lets say the original process has a different sequence of steps for every combination of PM and customer, sometimes it is done one way, sometimes another way. Just the visualization, which requires identifying columns, means all combinations of PM and customer have to follow the same sequence of steps. Even if you choose a sequence of steps that is as close as possible to typical, it will be a radical up-front change for some people.

       

      I find it hard to elaborate without airing too much dirty laundry, but I do intend to speak at conferences next year on the "Kanban is hard" theme based on my experiences at my current org, so the following are more derived from my experience rather than actually what happened.

       

      Lets assume the process consists of say up front planning and promising customers that they will receive complete projects on a date 6 months to a year from now. These promises are based mainly on current financial needs,  and the relationship that sales people have with the customer, rather than any measurements (and of course at the beginning there are no measurements anyway). The main mechanism for achieving these goals is for managers to apply pressure to teams, telling them to not write automatic acceptance tests in some cases, to save time, and getting people to work on weekends.

       

      Now the WIP limits and concept of pull are going to correctly identify this as a situation that needs to change, and change radically in the first week, or things will fall apart. This is what I mean by impose and clash. Until these changes, whatever they might need to be are made, things will work worse than before. I have the feeling that a lot of Kanban users are the early adopter type that have fairly sensible processes to begin with, and Kanban is a more natural fit.

       

      In the future we are going to be seeing more and more companies like ours trying Kanban, and if their starting process quite un-lean is, then there will be a lot of people faced with situations where the introduction of Kanban causes a lot of stress until a certain (large) number of small incremental changes are made. Hopefully this process will be quick enough so that things start to improve before people lose faith in Kanban, otherwise I think for this type of company is really could be important to see some sort of guidance that certain changes are perhaps made before or at the same time as the introduction of Kanban.

       

      So anyway, I don't think things are going "wrong" as such. Kanban is correctly identifying problems, 1 or 2 of use come up with solutions from the agile world that would improve things, 5-10 people come up with solutions from the traditional world that might hide the problem, and everyone else will just say "oh well that is what we have to work with, that can't be changed" and suggest that Kanban is incompatible with the way we work so why are we doing it?


    Your message has been successfully submitted and would be delivered to recipients shortly.