Your SlideShare is downloading. ×
  • Like
Deep Kanban - a biased and opinionated participant in the path towards synergy
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Deep Kanban - a biased and opinionated participant in the path towards synergy

  • 2,253 views
Published

This was my talk at the Lean Kanban Netherlands 2012

This was my talk at the Lean Kanban Netherlands 2012

Published in Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,253
On SlideShare
0
From Embeds
0
Number of Embeds
8

Actions

Shares
Downloads
26
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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

Transcript

  • 1. Deep Kanban OpenCage.infoa biased and opinionated participant in the path towards synergy
  • 2. About meKurt HäuslerFrom New ZealandLives and works inGermanyNot currently aconsultant
  • 3. About meBScCSMCSPMScPSM IKCP
  • 4. Outline Central themes Definitions The story Conclusion Ask questions at any time
  • 5. Central ThemesKanban appears differently to trainersand practitioners
  • 6. Central ThemesA high-trust culture might notnecessarily emerge, especially if anyonethat cares about things like that feelsobliged to express neutrality
  • 7. Central ThemesHow to reconcile Kanban with its placein a larger context of change, orreconciliation in general
  • 8. DefinitionsDeep Kanban - a biased and opinionatedparticipant in the path towards synergy
  • 9. The Marshall Model
  • 10. The Marshall ModelGives us a vocabularyUseful for Kanban buy-inUseful as model in the application of the6th core practice
  • 11. Rightshifting“Improving the effectiveness ofknowledge-work businesses.”Implies culture change via thinkingdifferentlyThere 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 YExtrinsic motivation Intrinsic motivation Focus on cost Focus on value Management FellowshipSingle loop learning Double loop learning
  • 13. RightshiftingA modern healthy culture for product developmentand knowledge work doesn’t appear by magicYou need internal change agents or culturehackers, biased towards freeing knowledgeworkers to delight customersPath towards synergy: rightshifting from analyticto synergistic
  • 14. DefinitionsDeep Kanban - a biased and opinionatedparticipant in the path towards synergy
  • 15. Deep Kanban1. Visualise2. Limit WIP3. Manage flow4. Make Policies Explicit5. Implement Feedback Loops6. Improve Collaboratively, Evolve Experimentally (using models and the scientific method)
  • 16. Kiviat Charts
  • 17. DefinitionsDeep Kanban - a biased and opinionatedparticipant in the path towards synergy
  • 18. ParticipantsManagersWorkersInternal Culture HackersExternal ConsultantsKanban Itself
  • 19. ManagersLikely to posses an analytic set of thinking toolsBiased to left-driftMay prefer driving change rather then beingchangedHold purse-stringsHave momentum behind decision making
  • 20. WorkersUnaccustomed to owning processMay have internal bias to left-drift,neutrality or right-shift.Bias likely not realized externally
  • 21. Internal Culture HackersBiased to right-shiftMay be managers or workersLikely in the minorityMay be responsible for advocating or“coaching” Kanban
  • 22. External ConsultantsPossibly an internal bias to right-shiftDepend on management for funding
  • 23. The Kanban SystemExhibits characteristics that qualify it as aparticipantImposes pullVia WIP limits, imposes things like kaizen,slack and/or swarming
  • 24. DefinitionsDeep Kanban - a biased and opinionatedparticipant in the path towards synergy
  • 25. Biased and OpinionatedAnalytic SynergisticLow-Trust High-Trust
  • 26. Culture TraditionalHacker Management
  • 27. KanbanCoach Traditional ManagementKanban Itself
  • 28. KanbanCoach Traditional ManagementKanban Itself
  • 29. KanbanCoach Traditional ManagementKanban Itself
  • 30. KanbanCoach Traditional ManagementKanban Itself
  • 31. It Is ComplicatedKanban (pull and WIP limits) will result insituations that compel changeThese changes could be analytic/low-trust orthey could be synergistic/high-trustAnalytic changes tend to conflict with pull andWIP limits, (and may threaten the sustainabilityof Kanban itself).
  • 32. KanbanCoach Traditional ManagementKanban Itself
  • 33. KanbanCoach Traditional ManagementKanban Itself
  • 34. There is so much momentumbehind the prevailing analyticmindset that neutrality seems like a losing strategy.
  • 35. But David Said...WHAT KANBAN COACHESDO, 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.
  • 36. He also said:Leadership is the magic ingredient
  • 37. The idea seems to be:Start where you startJust add the Kanban magic sauceIf you were advocating change beforeKanban, then after Kanban you should stopitWatch Kanban do its magic
  • 38. My issues with that are...It assumes we are introducing Kanban for its ownsake, and not as a tool to support a wider initiativeManagers accustomed to analytic thinking are notgoing read David’s blog, and do what they always didProgressive culture hackers with high-trust ideals aregoing read David’s blog and sit back and observeThis is not speculation, I have seen it occur
  • 39. The StoryIntroduction of Kanban at a medium sizedGerman software companyAlso subject of my MSc dissertationDoes NOT describe a company thatactually reached “synergy” with deepKanban
  • 40. “well we only have Theory X people around here” “does that mean Agile is not suitable?”
  • 41. The Product10 year old client-server product~1,000,000 LOCC++, SQL, C#
  • 42. The CustomersA handful of larger “project customers”A large number of smaller customers
  • 43. The Nature of DemandNew development projectsChange requestsBugs
  • 44. The DepartmentsProject, SalesDevelopment
  • 45. Pre-HistoryCowboy-codingXP-butAutomated TestsScrum
  • 46. 2009I joinedSuggested Kanban at a releaseretrospectiveGave a presentation on Agile, Lean,Scrum and Kanban
  • 47. 2010My focus on improving Scrum, mainly bypushing for cross functional teams andbacklog groomingStarted my dissertation with little enthusiasmfrom the PMsThen the boss read an article about Kanban...
  • 48. The WorkshopHeld in February 2011With external consultantsLearn about Kanban and decide if wewant to do it
  • 49. Goals of Most Participants Better quality Better maintainability
  • 50. My GoalsBetter cultural and psychologicalenvironmentBetter motivationBetter communication and collaborationbetween project and developmentdepartment
  • 51. The Consultants Suggested Shorter time to market Increased throughput
  • 52. What We Settled OnIncreasing Throughput
  • 53. Further DetailsFocus on mechanics of KanbanScrum“Kaizen”
  • 54. The Kickoff MeetingHeld 2 weeks after the workshop on Feb28thPlan to start with Kanban the followingday!
  • 55. PreparationProject department VSMDevelopment department concerned withestimation and bug-fixing
  • 56. The Kickoff MeetingBalancing new development andmaintenanceSwimlanes?Identified 11 process steps and suggestedWIP limits significantly below current WIP
  • 57. WIPCurrent WIP was 315We decided on a limit of 108
  • 58. 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
  • 59. First Few WeeksSplit into 2 systems, New Developmentand MaintenanceEach “feature” is a project of around20-30 storiesTotal WIP limit is equivalent to 5000stories, or 100 per person
  • 60. Other CalculationsExcluding buffers like Offer and ProductBacklog: 40 stories per personWorking backwards from sensible 2stories per person implies total WIP limitof 100 stories, or 4 features.
  • 61. CFD New Development
  • 62. Types of ChangesOptimizations to Kanban itselfAddressing the symptoms but notchanging the underlying systemActual system improvements
  • 63. CFD for Maintenance
  • 64. ObservationsProject and Development departmentsworking together ok, but less “agile”. Projectculture dominates.The board is a hybrid of portfolio and teamlevel. Most activities left and right ofdevelopment are independent of feature“size”.
  • 65. The First RetrospectiveBatch SizeStill no measurable lead time for eitherNew Development or MaintenanceGlobal WIP
  • 66. The First RetrospectiveManagement reported that“development” must be a problembecause cards move quicker through theother columns, and linger in development
  • 67. My Suggestion
  • 68. Maintenance Statistics WIP Lead Time ThroughputEstimate/Target 100 20 5 Actual 85 40 2
  • 69. New Development Statistics WIP Lead Time ThroughputEstimate/Target 180 275 0.65 Actual 105 350 0.3
  • 70. 3-Day Workshop with David Initial focus on culture I somehow got diverted towards the “metrics” David’s workshop got me back on culture
  • 71. 2nd RetrospectiveDevelopers lament: “It just feels like acontinuous stream of work. We miss projects”Managers lament: “We need more detailedplaning documentation.” Suggest a planningphase where we plan projects upfrontManagers also need: More control. Suggestmore formal sign-off between “phases”
  • 72. I SuggestedMore AgilityI called it “reintegrating Scrum”Cross-functional teams, delivering smallenough stories that they can be deliveredin 30 days or less.
  • 73. The ScrumMaster Suggested Cross functional teams specializing on sub-domains
  • 74. What We Committed ToA more formal approach to projects andplanningA more formal “quality gate” approachTeams specializing on sub-domains (butmaybe not cross-functional)
  • 75. What Management Decided to ImplementA more formal approach to projects andplanningA more formal “quality gate” approachTeams specializing on function
  • 76. Other ObservationsPush rather than pullConflict and stress over WIP limits anddeadlinesNo tolerance or acceptance of slack orswarmingIncreasing time pressure from management
  • 77. The RealizationManagement continue to work and thinkthey way they always did. Since before,and during Scrum, and now with KanbanCulture dominated by fear and mistrust
  • 78. ExampleA glimmer of hope extinguished
  • 79. ConclusionReconciling neutralityT much focus on the easy bits ooKanban as a tool for disruptive culturehacking
  • 80. Reconciling NeutralityExternal Consultants vs Internal CultureHackersStrategy vs TacticsMechanics / easy-bits vs larger mission
  • 81. 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”
  • 82. One of Our Current Best Hopesfor the Future of the WorkplaceWe have a chance here to really change theworldThere is a lot of momentum behind 19th centurymanagement, and neutrality wont beat itKanban should play the central role ineverything that the rightshifters and Stoosiansare trying to do
  • 83. More Infohttp://kurthaeusler.wordpress.com@Kurt_Haeuslerhttp://flowchainsensei.wordpress.com/rightshifting/http://www.stoosnetwork.org