Deep Kanban - a biased and opinionated participant in the path towards synergy
•Als KEY, PDF herunterladen•
2 gefällt mir•2,148 views
This was my talk at the Lean Kanban Netherlands 2012
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Deep Kanban - a biased and opinionated participant in the path towards synergy
Ähnlich wie Deep Kanban - a biased and opinionated participant in the path towards synergy (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Deep Kanban - a biased and opinionated participant in the path towards synergy
- 1. Deep Kanban OpenCage.info a biased and opinionated participant in the path towards synergy
- 2. About me Kurt Häusler From New Zealand Lives and works in Germany Not currently a consultant
- 4. Outline Central themes Definitions The story Conclusion Ask questions at any time
- 5. Central Themes Kanban appears differently to trainers and practitioners
- 6. Central Themes A high-trust culture might not necessarily emerge, especially if anyone that cares about things like that feels obliged to express neutrality
- 7. Central Themes How to reconcile Kanban with its place in a larger context of change, or reconciliation in general
- 8. Definitions Deep Kanban - a biased and opinionated participant in the path towards synergy
- 10. The Marshall Model Gives us a vocabulary Useful for Kanban buy-in Useful as model in the application of the 6th core practice
- 11. Rightshifting “Improving the effectiveness of knowledge-work businesses.” Implies culture change via thinking differently There is a tendency to left-drift
- 12. Analytic vs Synergistic Bad old thing Good new thing Low trust culture High trust culture Theory X Theory Y Extrinsic motivation Intrinsic motivation Focus on cost Focus on value Management Fellowship Single loop learning Double loop learning
- 13. Rightshifting A modern healthy culture for product development and knowledge work doesn’t appear by magic You need internal change agents or culture hackers, biased towards freeing knowledge workers to delight customers Path towards synergy: rightshifting from analytic to synergistic
- 14. Definitions Deep Kanban - a biased and opinionated participant in the path towards synergy
- 15. Deep Kanban 1. Visualise 2. Limit WIP 3. Manage flow 4. Make Policies Explicit 5. Implement Feedback Loops 6. Improve Collaboratively, Evolve Experimentally (using models and the scientific method)
- 16. Kiviat Charts
- 17. Definitions Deep Kanban - a biased and opinionated participant in the path towards synergy
- 18. Participants Managers Workers Internal Culture Hackers External Consultants Kanban Itself
- 19. Managers Likely to posses an analytic set of thinking tools Biased to left-drift May prefer driving change rather then being changed Hold purse-strings Have momentum behind decision making
- 20. Workers Unaccustomed to owning process May have internal bias to left-drift, neutrality or right-shift. Bias likely not realized externally
- 21. Internal Culture Hackers Biased to right-shift May be managers or workers Likely in the minority May be responsible for advocating or “coaching” Kanban
- 22. External Consultants Possibly an internal bias to right-shift Depend on management for funding
- 23. The Kanban System Exhibits characteristics that qualify it as a participant Imposes pull Via WIP limits, imposes things like kaizen, slack and/or swarming
- 24. Definitions Deep Kanban - a biased and opinionated participant in the path towards synergy
- 25. Biased and Opinionated Analytic Synergistic Low-Trust High-Trust
- 27. Culture Traditional Hacker Management
- 28. Kanban Coach Traditional Management Kanban Itself
- 29. Kanban Coach Traditional Management Kanban Itself
- 30. Kanban Coach Traditional Management Kanban Itself
- 31. Kanban Coach Traditional Management Kanban Itself
- 32. It Is Complicated Kanban (pull and WIP limits) will result in situations that compel change These changes could be analytic/low-trust or they could be synergistic/high-trust Analytic changes tend to conflict with pull and WIP limits, (and may threaten the sustainability of Kanban itself).
- 33. Kanban Coach Traditional Management Kanban Itself
- 34. Kanban Coach Traditional Management Kanban Itself
- 35. There is so much momentum behind the prevailing analytic mindset that neutrality seems like a losing strategy.
- 36. But David Said... WHAT KANBAN COACHES DO, AND DON’T DO: Stop Advocating! Stop Evangelizing! Observe Instead There Is No Judgment in Kanban Kanban consultants respect the current situation and do not pass judgment upon it.
- 37. He also said: Leadership is the magic ingredient
- 38. The idea seems to be: Start where you start Just add the Kanban magic sauce If you were advocating change before Kanban, then after Kanban you should stop it Watch Kanban do its magic
- 39. My issues with that are... It assumes we are introducing Kanban for its own sake, and not as a tool to support a wider initiative Managers accustomed to analytic thinking are not going read David’s blog, and do what they always did Progressive culture hackers with high-trust ideals are going read David’s blog and sit back and observe This is not speculation, I have seen it occur
- 40. The Story Introduction of Kanban at a medium sized German software company Also subject of my MSc dissertation Does NOT describe a company that actually reached “synergy” with deep Kanban
- 41. “well we only have Theory X people around here” “does that mean Agile is not suitable?”
- 42. The Product 10 year old client-server product ~1,000,000 LOC C++, SQL, C#
- 43. The Customers A handful of larger “project customers” A large number of smaller customers
- 44. The Nature of Demand New development projects Change requests Bugs
- 47. 2009 I joined Suggested Kanban at a release retrospective Gave a presentation on Agile, Lean, Scrum and Kanban
- 48. 2010 My focus on improving Scrum, mainly by pushing for cross functional teams and backlog grooming Started my dissertation with little enthusiasm from the PMs Then the boss read an article about Kanban...
- 49. The Workshop Held in February 2011 With external consultants Learn about Kanban and decide if we want to do it
- 50. Goals of Most Participants Better quality Better maintainability
- 51. My Goals Better cultural and psychological environment Better motivation Better communication and collaboration between project and development department
- 52. The Consultants Suggested Shorter time to market Increased throughput
- 53. What We Settled On Increasing Throughput
- 54. Further Details Focus on mechanics of Kanban Scrum “Kaizen”
- 55. The Kickoff Meeting Held 2 weeks after the workshop on Feb 28th Plan to start with Kanban the following day!
- 56. Preparation Project department VSM Development department concerned with estimation and bug-fixing
- 57. The Kickoff Meeting Balancing new development and maintenance Swimlanes? Identified 11 process steps and suggested WIP limits significantly below current WIP
- 58. WIP Current WIP was 315 We decided on a limit of 108
- 59. One of the Initial Designs Column WIP Limit Understand and Assess 10 Analyze 10 Offer 50 Product backlog Prepare for Sprint Planing 8 Development including acceptance tests 8 Internal acceptance 8 Review, test, improve and integrate 4 Wait for Freeze Prepare for client release including documentation 20 Deployment 20 In production
- 60. First Few Weeks Split into 2 systems, New Development and Maintenance Each “feature” is a project of around 20-30 stories Total WIP limit is equivalent to 5000 stories, or 100 per person
- 61. Other Calculations Excluding buffers like Offer and Product Backlog: 40 stories per person Working backwards from sensible 2 stories per person implies total WIP limit of 100 stories, or 4 features.
- 63. Types of Changes Optimizations to Kanban itself Addressing the symptoms but not changing the underlying system Actual system improvements
- 65. Observations Project and Development departments working together ok, but less “agile”. Project culture dominates. The board is a hybrid of portfolio and team level. Most activities left and right of development are independent of feature “size”.
- 66. The First Retrospective Batch Size Still no measurable lead time for either New Development or Maintenance Global WIP
- 67. The First Retrospective Management reported that “development” must be a problem because cards move quicker through the other columns, and linger in development
- 68. My Suggestion
- 69. Maintenance Statistics WIP Lead Time Throughput Estimate/Target 100 20 5 Actual 85 40 2
- 70. New Development Statistics WIP Lead Time Throughput Estimate/Target 180 275 0.65 Actual 105 350 0.3
- 71. 3-Day Workshop with David Initial focus on culture I somehow got diverted towards the “metrics” David’s workshop got me back on culture
- 72. 2nd Retrospective Developers lament: “It just feels like a continuous stream of work. We miss projects” Managers lament: “We need more detailed planing documentation.” Suggest a planning phase where we plan projects upfront Managers also need: More control. Suggest more formal sign-off between “phases”
- 73. I Suggested More Agility I called it “reintegrating Scrum” Cross-functional teams, delivering small enough stories that they can be delivered in 30 days or less.
- 74. The ScrumMaster Suggested Cross functional teams specializing on sub-domains
- 75. What We Committed To A more formal approach to projects and planning A more formal “quality gate” approach Teams specializing on sub-domains (but maybe not cross-functional)
- 76. What Management Decided to Implement A more formal approach to projects and planning A more formal “quality gate” approach Teams specializing on function
- 77. Other Observations Push rather than pull Conflict and stress over WIP limits and deadlines No tolerance or acceptance of slack or swarming Increasing time pressure from management
- 78. The Realization Management continue to work and think they way they always did. Since before, and during Scrum, and now with Kanban Culture dominated by fear and mistrust
- 79. Example A glimmer of hope extinguished
- 80. Conclusion Reconciling neutrality T much focus on the easy bits oo Kanban as a tool for disruptive culture hacking
- 81. Reconciling Neutrality External Consultants vs Internal Culture Hackers Strategy vs Tactics Mechanics / easy-bits vs larger mission
- 82. Shift Focus Towards the Hard Bits Current focus on principles and practices good for training and initial system design Description on the tin, less relevant for on- going change efforts at the coal face Even trainers should probably spend 5% on Kanban itself and 95% on “propaganda”
- 83. One of Our Current Best Hopes for the Future of the Workplace We have a chance here to really change the world There is a lot of momentum behind 19th century management, and neutrality wont beat it Kanban should play the central role in everything that the rightshifters and Stoosians are trying to do
Hinweis der Redaktion
- Things have teeth and look scary when you go deep.\nGreet Audience - Hello everyone, nice to be here.\nI am new at this, to me you all look as scary as this fish. But as Deming said, drive out fear.\n
- Not being a consultant means I am slightly more trustworthy. Less likely to exhibit a bias towards positive experiences.\nThe photo is me as a victim of traditional management thinking. My experience as a software developer taught me that the world of management needs to radically change.\n
- For those that like letters of the alphabet, I can probably say how each are significant. Especially the MSc and KCP\nAlso a quick note about what I am doing now, what interests me (Rightshifting, Stoos), and what I intend on getting into in 2013 (Games and Storytelling).\n\n
- It is a 50 minute talk.\n0-5 This intro\n5-15 Central themes\n15-25 Definitions\n25-40 The story - Mostly based on my experiences at Bewotec\n40-45 Conclusion\n45-50 Questions\n
- Trainers and consultants that help with initial system more concerned with the description of Kanban. A lot of the principles and practices, and a lot of the discussion around kanban are mostly relevant for that initial introduction. Workers, managers and change agents on the ground are concerned with very different things 6 months later.\nMention how in discussions online, I might say something based on my experiences, and a trainer or consultant will reply saying I am wrong and use the description of Kanban as proof.\n
- A lot of the principles and practices imply a neutrality that might be more appropriate for trainers and external consultants than workers, managers and change agents on the ground.\n
- Kanban doesn’t stand alone. It is just one tool that a company may decide on to support a wider system of change. Depending on the goals of Kanban, and the way it is introduced it might be hard to reconcile the way a Kanban coach is expected to work, with the way a scrum master, manager, developer or culture hacker might otherwise work.\n\nDavid actually said at the 3-day workshop that he tries to talk people out of “kanban initiatives” because the focus should be on the culture not the tool. But I don’t know how to reconcile that with neutrality. \n
- \n
- Don’t forget to mention the productivity, waste and ROI in change bits.\nAnd why I like the model.\n
- \n
- The second point is perhaps a reaction to the idea that we can only change culture via changing the management system.\n\n
- Low trust to high trust culture was discussed at DAs masterclass. (He implied high trust results from Kanban. My experience suggests that doesn’t automatically happen).\nI personally tend to be biased towards the things on the right to the extent that I think things on the left can be actively bad.\n\n\n
- 1. Or with Kanban alone.\n2. That second bit was what I learned as a consultant, without that don’t even try.\n
- \n
- Explain shallow and deep, but mention the intention to have at least wip limiting should be there before calling it Kanban.\n\nNow the actual change happens in step 6, assuming Kanban is actually being used as a tool to support change.\nJudging by the discussion around Kanban, people seem to be using it mostly as a workflow management tool.\n\nAlthough as an aside, I don’t know how it is possible to have a sustainable Kanban system with WIP limits and pull, but without an effort to improve and evolve. I suspect it works in small teams ok, but I don’t think it is sustainable with a wide Kanban system.\n
- Thank Bernadette Daria and the limited WIP society for the diagram.\nPeople have stopped talking about shallow or deep and are looking more at these detailed Kiviat charts, but its a little too fine grained for me. I like deep and shallow, because there is a fundamental qualitative difference between kanban systems that focus on managing the flow of work, and those that primarily support change.\n
- \n
- Managers and Workers separate, because even though this split is unsavory, it exists, and considering that managers have the resources to bring in consultants etc. By managers and workers, I exclude the few who are internal culture hackers\n\nCulture hackers is what I call change agents\n
- \n
- They have probably learned to delegate their decision making upwards\n
- People that know about change models, the true use of Kanban, and may be conflicted about how to reconcile their calling as a culture hacker with the neutrality associated with Kanban coaching.\n\nThey might not be as refined as how they express their bias.\n
- \n
- Similar to a manager making decisions, it can be overridden, it may depend on acceptance.. It is really not that much different to a manager “making suggestions” or asking people to do things.\n\nI think in a deep, wide kanban system, pull, and WIP limits are much more shocking and radical things to impose on an organization than anything an organization has to do to set up a scrum team.\n
- \n
- If Analytic and Synergistic are too controversial, or too abstract, lets call it low-trust and high-trust, as David Anderson uses that in his workshops.\n
- We can assume the average organization is either moving towards, or sitting stably at 1.\nPerhaps as a smaller company it started off as Ad Hoc or even Synergistic, and as they grew they had scaling issues they needed to solve and they solved it with traditional management.\n
- Forces towards right-shifting usually come from culture hackers.\nIf right-shifting doesn’t occur, then traditional management must be pushing back.\nSometimes culture hackers might succeed.\n
- Now if we introduce Kanban, the culture hacker is now a Kanban coach, who read that a good Kanban coach should be neutral.\nLets also assume Kanban itself is neutral.\nManagers that have always acted according to the analytic mindset don’t feel compelled or obligated to either neutrality, or to start thinking differently.\nThey may have agreed to change, and Kanban might set things up for change, but the changes they make will result in left-drift.\n
- To see rightshifting occur, or a high-trust culture to emerge, we need to see either Kanban coaches exhibiting a force to rightshift....\n
- or management suddenly start thinking differently...\nI think some people believe this might happen when a manager looks at the card wall or the CFD, maybe it does in some cases...\n
- or Kanban itself acts as a force to rightshift... or as a force causing a high-trust culture to emerge.\nMany people imply that this is absolutely not the case, and are adamant that Kanban merely “shows us things”, and doesn’t force anything, and it is up to people to act on what they see. \nDavid Anderson, I think, implies Kanban itself will help result in a high trust culture to emerge...\n
- I wont yet claim that Kanban is a force to right-shift, or bring about a high-trust culture, but lets say it compels change of either kind, but is biased against changes inspired by the analytic mindset, and towards changes inspired by the synergistic mindset.\n
- Maybe I don’t understand the point of neutrality, but my ideal would be if all three of these components, plus any other participants are biased towards rightshifting and developing a high-trust culture.\n
- People don’t voluntarily change, even if they look at a task board or a CFD. I think Kanban is biased, and I think Kanban coaches should be.\n
- \n
- \n
- This was the subtitle of my dissertation.\n
- This seems to imagine that analytic managers, after years of commanding and controlling, are going to suddenly look at a Kanban board or a CFD and start thinking differently, and presumably providing the required leadership with the Kanban coach in an assisting role.\n\nIt also conflicts with what a lot of other people say, that Kanban just shows you things, and it is up to people to actually make the improvements. But with all the Kanban experts sitting back and observing, it leaves a power vacuum that will only be filled with the same old analytic decision making that built the current system.\n
- 1. Presumably, if other aspects of the wider initiative involve pro-active pursuit of certain goals, then it may be hard to work out what to keep doing and what to stop doing. i.e. which actions are “part of Kanban” and which actions are part of the wider initiative.\n\n2. The type of people who explicitly choose theory x management, because it suits how they see the workforce.\n\n3. The people who probably suggested Kanban in the first place, understand it the best, and end up taking on the coaching role. They are going to observe the analytic thinking managers hijack Kanban and use it to accelerate the left-drift\n
- 1. Mention the size of the company and the departments\n3. In fact they seemed determined to reject it. \n
- I think anyone can become a “theory y employee” once management adopt a theory y management approach, i.e. treat people with respect\n
- \n
- \n
- \n
- \n
- One interesting point is that we got 2 consultants in. One focused on cultural and management aspects, and the other one on technical. The former didn’t last as long.\n\nI can’t call it Scrum-but, but it was the type of Scrum where they do the task breakdown first and estimate it in hours. Instead of measuring velocity they add up everyones hours and multiply it by 0.85 to represent 85% productive time and 15% meetings.\n
- One other interesting experience was seeing a presentation from the project department about how we work, and seeing a classical waterfall style diagram. I was shocked as I thought we were a Scrum organisation. It was pointed out that Scrum happens inside this little “development” box in the middle\n
- \n
- \n
- \n
- Everyone looked at me like I was crazy. “How will replacing Scrum with Kanban achieve that?”\n
- 1. But our customers only want to upgrade once or twice a year anyway...\n
- Basically doing more work in the same amount of time, and making more money. I don’t actually think that is the sweet spot of Kanban. Kanban can reduce lead times given a throughput. But increasing throughput is usually best left to things outside Kanban. Better technical practices etc.\n
- 1. We spent too much time on the easy bits in my opinion. From Scrum we already new about moving cards around etc. there was too little discussion about the actual changes and how they would be handled. I asked but that was apparently outside the scope of Kanban itself.\n2. Kanban would track larger MMFs, and a development column in the middle would be where Scrum happens at the story level.\n3. Confusion...\n
- 2. As a new release starts.\n
- 1. No single process\n
- \n
- \n
- Total WIP here is 138, plus unlimited columns.\n
- 1. Was not a change to underlying system, but to the Kanban system itself\n
- 2. 4 features.. which is exactly how many new development teams we have, 1 feature per team seems sensible.\nFor me it was clear we should have tracked things at the story level, or set up a very small portfolio system to track features.\n
- Note the 2 main changes. We noticed there was a lot of inventory in the Manual Integration test stage in the first month. Then in June we noticed there was a lot of inventory in Preparing Customer release and customer acceptance. No change to system, just a focus on addressing the symptom.\n\nThis is also typical of portfolio systems, not much flow.\n\nOh and at the beginning of june someone took the first board away for some reason.\n
- \n
- Maintenance looks a lot better. Notice we only started counting the backlog in May.\n
- 1, There were more managers used to making decisions in the project departments. The Scrum walled garden at least allowed developers to have a voice and make decisions at a certain level.\n
- This was a month later\n1. I wanted to address this\n2. In one month no card had yet traveled across the board.\n3. In allocating WIP across maintenance and new development, we forgot to account for the fact that new development features are 20 to 30 times larger than maintenance tasks.\n
- \n
- Made sense to split the Kanban system into a portfolio system and a normal system. One tracking features and one tracking stories. This was rejected.\n\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Management had a secret meeting (not all of them were at the retro)\n
- \n
- 2. Management actively favors those that work how they like, and “punish” those who speak up at retrospectives.\n
- A developer had a good idea, and was excited to help\nAnother coach suggested he prepare an A3\nDrama over where to book the 2 hours time\nA new project would have to be set up for it in the time tracking system - but that needs to be “escalated” to senior management\nHe backs off of course, and there were comments floating around about people not being committed to critical projects so they might be better suited for less interesting projects.\nYou cant be neutral about things like that\n
- \n
- \n
- \n
- \n
- \n