An introduction to a lean-styledsoftware development methodology
 John Nuechterlein aka jdn „Professional‟ IT experience since 1996 Ph.D. in Philosophy, University of Miami Ex...
 Henrik Kniberg (slides used under Creative Commons License) David Anderson Corey Ladas Ron Jeffries Jesper...
 A very condensed and somewhat inaccurate description of common software development practices Not designed to...
 A phrase introduced by Chris Matts on the yahoo message group to differentiate the very basics of kanban from th...
 Relationship between lean and kanban is murky  Lean tends to focus on „waste‟ while kanban generally a...
 http://www.nouveautech.co.uk/waterfallprocess.html
 A regimented process that attempts to follow a logical process in order to bring a software development project ...
 Test  Execute the designed test scenarios to prove that the code fulfills the original business requireme...
 Seems to mirror other physical development, such as building projects, but they are radically different  Chan...
 Estimation paradox The amount of time spent in estimation produces a problem it was designed to manage
 Estimation paradox, cont.  All significant projects require estimation (especially capital intensive ones...
 Unrealistic specificity  On 9/24/2011, at 2:30 PM, jdn will implement the function that adds a workflow s...
 Fails the „fail fast‟ principle  The first real point at which a requirement can be found to be lacking i...
 Government contracts  “Let‟s iteratively develop as we go along” isn‟t going to cut it Significant Inf...
www.agilemanifesto.org We are uncovering better ways of developing software by doing it and helping others...
 Individuals and interactions over processes and tools  “This isn‟t working” -> “this is the process that has been ...
Principles behind the Agile ManifestoOur highest priority is to satisfy the Working software is the primarycustomer...
 A set of development practices  Pair programming  Two developers program a feature together  Red...
 Develop in iterations  Industry coalescing around 2 week period  Once the tasks for an iteration are defin...
 Clearly defined scrum master  Maintains the overall process  Removes impediments to the team Daily stan...
 Product Backlog  High-level list of potential features  Ordered by business value  Owned by Product ...
 Cross-functional team  No „specialists‟, instead a group consisting of members who can tackle the wide ra...
 Continual Delivery  Small team spending a little time building a small thing, instead of a large group sp...
 Very short feedback cycles  Does the software work  Scrum is best when combined with XP  Quick f...
 Scrum prescribes organizational change up front as you need:  Product owner  Scrum master  Cross-functi...
 It is difficult to have truly cross-functional teams  when the dev team doesn‟t control the implementa...
 Splitting a long project into multiple sprints has its own overhead cost  Some tasks will take longer than what...
 Scrum gives you a description of the sweet spot for software development.  If you or your organization can‟t ...
 A long history, but short version:  Developed by David Anderson while working as a consultant at Microsoft ci...
http://blog.crisp.se/henrikkniberg/tags/kanban/ Henrik Kniberg 35
Dev Backlog Next 3 In production :o) 2 ...
Dev Backlog Next 3 In production :o) 2 ...
Dev Backlog Next 3 In production :o) 2 ...
Dev Backlog Next 3 In production :o) 2 ...
Dev Backlog Next 3 In production :o) 2 ...
Dev Backlog Next 3 In production :o) 2 ...
Dev Backlog Next 3 In production :o) 2...
Dev Backlog Next 3 In production :o) 2 PO ...
Dev Backlog Next 3 In production :o) 2 PO ...
Dev Backlog Next 3 In production :o) 2 PO ...
Dev Backlog Nexet 3 In production :o) 2 PO ...
Dev Backlog Next 3 In production :o) 2 PO ...
Dev Backlog Next 3 In production :o) 2 PO ...
Dev Backlog Next 3 In production :o) 2 PO ...
 Start with what you do now  No immediate changes to any of your current processes Agree to pursue incremental...
 Visualize the workflow  Create a visual representation of your current process, the steps from A to Z in ...
 Make process policies explicit  Highlight the steps where work moves from one stage to another (visual repres...
 Predictable service delivery  Once the flow is defined, established and measured over time, you can get a...
 Making promises you can keep  Once you can define a predictable service delivery, you can accurately prom...
Causes of unnecessary multitasking Focusing on starting stuff rather than finishing Not limiting WIP Focusing ...
Probably a bit of both. Physical Digital • Cheap • Remote • Easy to evolve access • Big...
More prescriptive ...
Top 10 Customer requirements Top 3 project impediments ...
Definition of ”ready fordevelopment” Definition of ”ready for system test” ...
Team 1 Team 2 Team 3 Henrik Kniberg 65 65
 The best thing about Kanban is that it doesn‟t require you to change your current processes. The worst thing abo...
Poor Man's Kanban
Poor Man's Kanban
Poor Man's Kanban
Poor Man's Kanban
Poor Man's Kanban
Poor Man's Kanban
Poor Man's Kanban
Poor Man's Kanban
Poor Man's Kanban
of 66

Poor Man's Kanban

Description and video for this presentation here: http://chicagoalt.net/event/november-2011-meeting-poor-man-s-kanban
Published on: Mar 4, 2016
Published in: Technology      Business      
Source: www.slideshare.net


Transcripts - Poor Man's Kanban

  • 1. An introduction to a lean-styledsoftware development methodology
  • 2.  John Nuechterlein aka jdn „Professional‟ IT experience since 1996 Ph.D. in Philosophy, University of Miami Experience in Operations – SQL Development - .NET Development Industry experience in retail eCommerce, Finance, Manufacturing
  • 3.  Henrik Kniberg (slides used under Creative Commons License) David Anderson Corey Ladas Ron Jeffries Jesper Boeg Many others
  • 4.  A very condensed and somewhat inaccurate description of common software development practices Not designed to „prove‟ kanban is always right (because it isn‟t) Highlight common flaws in traditional waterfall software development and how the industry has sought to resolve them
  • 5.  A phrase introduced by Chris Matts on the yahoo message group to differentiate the very basics of kanban from the very sophisticated versions that existed at the time and exist currently David Anderson seemed to regard it as an acceptable phrase What I am presenting today is the very basics and should not be thought to be comprehensive  What do you expect? I have an hour.
  • 6.  Relationship between lean and kanban is murky  Lean tends to focus on „waste‟ while kanban generally avoids talking about it  Lean software development is more likely to „match up‟ with lean manufacturing, while kanban generally rejects the linkage  In the end, it‟s somewhat irrelevant
  • 7.  http://www.nouveautech.co.uk/waterfallprocess.html
  • 8.  A regimented process that attempts to follow a logical process in order to bring a software development project to fruition Requirements  Determine the requirements that meet business needs Design  Determine the design/architecture that will fulfill those requirements Coding  Produce the code that will implement the design
  • 9.  Test  Execute the designed test scenarios to prove that the code fulfills the original business requirements Implementation  Implement the software according to the accepted practices of the business Support  Support the software according to the accepted practices of the business
  • 10.  Seems to mirror other physical development, such as building projects, but they are radically different  Change requests  An „end user‟ can‟t ask you to change the design of the 2nd floor of a 40 floor building after it is built, but end users of software can and often do request the equivalent  Technology choice  Building materials are largely constrained, but there are few constraints on how you implement software  Should it be a web app or windows app, should it be java or c#, should it use infragistics or wpf, etc.  You can‟t build a building using tapioca  But you can build software using vbscript, foxpro, etc.  Even though you shouldn‟t
  • 11.  Estimation paradox The amount of time spent in estimation produces a problem it was designed to manage
  • 12.  Estimation paradox, cont.  All significant projects require estimation (especially capital intensive ones) but, paradoxically, the more detailed the estimation:  The longer it takes to produce  The more it requires negotiation to cover each item  The longer it takes to get approved when it is „all or nothing‟  Thus, increasingly delaying the project itself and offering more opportunities for the project to fail
  • 13.  Unrealistic specificity  On 9/24/2011, at 2:30 PM, jdn will implement the function that adds a workflow step to fulfill business requirement X X-factor ignorance  The ancillary events that impact product schedule, e.g. the external XYZ database in UAT goes down for a week  It is rare that „x-factors‟ are built into the plan, even though they always occur
  • 14.  Fails the „fail fast‟ principle  The first real point at which a requirement can be found to be lacking is during QA  Way too late, wasteful, quicker feedback is required Too many tasks/projects in flight at once  Start early != finish early  E.g. we are gathering requirements on 12 items, but have yet to deliver any of them
  • 15.  Government contracts  “Let‟s iteratively develop as we go along” isn‟t going to cut it Significant Infrastructure Projects  E.g, moving from Sybase to Oracle  “Let‟s iteratively determine requirements” isn‟t going to cut it Real engineering  Software developed for things like:  Nuclear power plants  Space probes  Red-green-refactor isn‟t going to cut it
  • 16. www.agilemanifesto.org We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
  • 17.  Individuals and interactions over processes and tools  “This isn‟t working” -> “this is the process that has been defined”  Broken processes prevent individuals from making improvements, especially when they are „take it or leave it‟ Working software over comprehensive documentation  “We met the business requirement with feedback from the user” -> “This isn‟t the exact requirement in the document we signed off on”  Functioning software is stymied because it doesn‟t exactly match a document Customer collaboration over contract negotiation  “Here is how we implemented the requirements” -> “This isn‟t how we agreed to implement what is on page 12, section 3.4”  Lack of trust turns software development into a haggle over negotiating terms Responding to change over following a plan  “Circumstances have arisen that required a change in plan” -> “This isn‟t the plan, we all agreed on the plan”  Inability to be truly agile in response to changing circumstances, and circumstances always change
  • 18. Principles behind the Agile ManifestoOur highest priority is to satisfy the Working software is the primarycustomer through early and continuous measure of progress.delivery of valuable software. Agile processes promote sustainableWelcome changing requirements, even late development. The sponsors, developers,in development. Agile processes harness and users should be able to maintain achange for the customers competitive constant pace indefinitely.advantage. Continuous attention to technicalDeliver working software frequently, from excellence and good design enhancesa couple of weeks to a couple of months, agility.with a preference to the shorter timescale. Simplicity--the art of maximizing theBusiness people and developers must work amount of work not done--is essential.together daily throughout the project. The best architectures, requirements,Build projects around motivated and designs emerge from self-organizingindividuals. Give them the environment and teams.support they need, and trust them to get At regular intervals, the team reflects onthe job done. how to become more effective, thenThe most efficient and effective method of tunes and adjusts its behaviorconveying information to and within a accordingly.development team is face-to-faceconversation. 18
  • 19.  A set of development practices  Pair programming  Two developers program a feature together  Reduction in bugs, increased knowledge across team members  Continuous process  Continuous integration gives quick feedback on breaking code changes  Frequent releases that provide concrete value  Collective code ownership  Any team member should be allowed to change any code  Increased knowledge across team members  Sustainable pace  Eliminate death march projects that require continual overtime which burns out team members
  • 20.  Develop in iterations  Industry coalescing around 2 week period  Once the tasks for an iteration are defined, they do not change Clearly defined product owner  PO defines priorities  PO interfaces with both the dev team and stakeholders  PO speaks with one voice
  • 21.  Clearly defined scrum master  Maintains the overall process  Removes impediments to the team Daily standup  What I did yesterday  What I am going to do today  What is getting in my way
  • 22.  Product Backlog  High-level list of potential features  Ordered by business value  Owned by Product Owner Sprint Backlog  List of work to be done in the next sprint  Tasks „assigned‟ by the team, not assigned by anyone else  Business can‟t change tasks inside of a sprint
  • 23.  Cross-functional team  No „specialists‟, instead a group consisting of members who can tackle the wide range of needs across the software platform Demo each iteration  Working, tested software demonstrated  Immediate feedback from stakeholders Retrospective  After each sprint, discuss what worked well, what didn‟t, what needs to change for the next sprint
  • 24.  Continual Delivery  Small team spending a little time building a small thing, instead of a large group spending a long time building a huge thing, but releasing often No scope creep  Tight requirements defined upfront and designed in short increments Reasonable expectations  Because each sprint is timeboxed, the number of tasks is limited and targeted
  • 25.  Very short feedback cycles  Does the software work  Scrum is best when combined with XP  Quick feedback that the code works  Does the created software do what the customer wanted it to do  It is inevitable that the customer will say that they want X, but when you give them X, they will realize they really wanted Y  This is inevitable. So, finding this out at the end of a 2 week sprint is much better than finding this out 5 months into a 6 month project schedule
  • 26.  Scrum prescribes organizational change up front as you need:  Product owner  Scrum master  Cross-functional team  Keymaster, GateKeeper, Oracle  Exaggerating, but you get the point Prescribed organizational change is scary, e.g., “I‟m about to lose my job or have it redefined without my approval”
  • 27.  It is difficult to have truly cross-functional teams  when the dev team doesn‟t control the implementation  Separate dedicated external teams that control  DB  Networking  Migration  Sometimes, specialization is necessary  E.g., knowledge of networking is not easy to come by  Deep knowledge of particular areas of technology necessarily means more shallow knowledge in other areas
  • 28.  Splitting a long project into multiple sprints has its own overhead cost  Some tasks will take longer than whatever sprint length you set  Some projects are hard to split into discrete tasks  Especially when it involves external parties, whether inside the business or 3rd party vendors I took a week-long (or less) course and am now certified  Sure you are
  • 29.  Scrum gives you a description of the sweet spot for software development.  If you or your organization can‟t implement it, that‟s a problem with you or your organization, not with Scrum If your organization could properly develop software, it wouldn‟t need to change. If it can‟t, it needs to change.  Life is hard.  If roles need to change to fix things, they need to change
  • 30.  A long history, but short version:  Developed by David Anderson while working as a consultant at Microsoft circa 2004  A distillation of common emerging practices  Vaguely related to Lean Manufacturing as developed by Toyota  Improved over time as many other practitioners started with the principles and then saw what worked  A work in progress, based on real-world implementations
  • 31. http://blog.crisp.se/henrikkniberg/tags/kanban/ Henrik Kniberg 35
  • 32. Dev Backlog Next 3 In production :o) 2 Ongoing Done A B G C F DH IJ L EM K Henrik Kniberg 36
  • 33. Dev Backlog Next 3 In production :o) 2 Ongoing Done A G B C F DH IJ L EM K Henrik Kniberg 37
  • 34. Dev Backlog Next 3 In production :o) 2 Ongoing Done A G B C F DH IJ L EM K Henrik Kniberg 38
  • 35. Dev Backlog Next 3 In production :o) 2 Ongoing Done C A G D B FH IJ L EM K Henrik Kniberg 39
  • 36. Dev Backlog Next 3 In production :o) 2 Ongoing Done C A G D B FH IJ L EM K Henrik Kniberg 40
  • 37. Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A B G C F DH IJ L EM K Henrik Kniberg 41
  • 38. Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A G B C F DH IJ L EM K Henrik Kniberg 42
  • 39. Dev Backlog Next 3 In production :o) 2 PO Ongoing Done C A G D B FH IJ L EM K Henrik Kniberg 43
  • 40. Dev Backlog Next 3 In production :o) 2 PO Ongoing Done C A G D B FH IJ L EM K Henrik Kniberg 44
  • 41. Dev Backlog Next 3 In production :o) 2 PO Ongoing Done C A G D !? B FH IJ L EM K Henrik Kniberg 45
  • 42. Dev Backlog Nexet 3 In production :o) 2 PO Ongoing Done G !? A D B F E CH IJ LM K Henrik Kniberg 46
  • 43. Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A G D B F E CH IJ LM K Henrik Kniberg 47
  • 44. Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A G D B F E CH IJ LM K Henrik Kniberg 48
  • 45. Dev Backlog Next 3 In production :o) 2 PO Ongoing Done D A G B E F CH IJ LM K Henrik Kniberg 49
  • 46.  Start with what you do now  No immediate changes to any of your current processes Agree to pursue incremental, evolutionary change  Agree across the business that you want to improve what you do now based on evidence (e.g. metrics)  We will get evidence on what most immediately needs improvement, agree on a course of action on how to improve it, take those actions, and then see if it works Respect the current process, roles, responsibilities & job titles  No one loses their job or has their job arbitrarily re- defined  Individuals get to be part of the process of improving the processes
  • 47.  Visualize the workflow  Create a visual representation of your current process, the steps from A to Z in delivering a software development project  Where are the bottlenecks? Visualization „surfaces‟ them Limit WIP  Limit what any individual is working on by numerical limits  Pull in next work items  Explicitly prevent too many tasks from being assigned at one time Manage flow  Find where your blocking points are and prioritize working on those  Agree on a change to improve flow  If it works, move on to the next point  If it doesn‟t, try something else
  • 48.  Make process policies explicit  Highlight the steps where work moves from one stage to another (visual representation), and define the process  When everyone can see the flow, there is a common understanding of the problems with the process Improve collaboratively  Improve in small continuous increments  Make some changes and see what works  Changes are agreed upon across the business  When small changes are made, it is easier to measure the impact  This process never ends. “Lather, rinse, repeat.”
  • 49.  Predictable service delivery  Once the flow is defined, established and measured over time, you can get a realistic picture of how long it will take for a work item to go from start to finish  Everyone can see the impact of bottlenecks in particular areas of the flow  X-factors will always occur, but when you have a visual representation of where they occur, you can implement improvements (or at least account for them) and get a realistic (i.e., measured) estimate of how it impacts schedule
  • 50.  Making promises you can keep  Once you can define a predictable service delivery, you can accurately promise how long a work item will take  The business always knows what is in the pipeline and where it is in the pipeline, and also knows that if they want to prioritize something else they have to de-prioritize something in progress  Visibility into the software development process is available to anyone
  • 51. Causes of unnecessary multitasking Focusing on starting stuff rather than finishing Not limiting WIP Focusing on keep people busy (fear of slack) Accepting the “reason” & solving the symptom instead of the problem Henrik Kniberg 59
  • 52. Probably a bit of both. Physical Digital • Cheap • Remote • Easy to evolve access • Big • History/back • See all at once up • Same view • Metrics • Tangible / Direct manipulation • Brings people together Henrik Kniberg 61
  • 53. More prescriptive More adaptive RUP XP Scrum Kanban Do Whatever (120+) (13) (9) (3) (0) • Architecture Reviewer • Business use case realization • Business Designer • Business use-case model • Whole team • Scrum Master • Visualize the workflow • Business-Model Reviewer • Business vision • Coding standard • Product Owner • Limit WIP • Business-Process Analyst • Change request • TDD • Team • Measure and optimize lead time • Capsule Designer • Configuration audit findings • Collective ownership • Sprint planning • Change Control Manager • Configuration management • Customer tests meeting • Code Reviewer plan • Pair programming • Daily Scrum • Configuration Manager • Data model • Refactoring • Sprint review • Course Developer • Deployment model • Planning game • Product backlogt • Database Designer • Deployment plan • Continuous integration • Sprint backlog • Deployment Manager • Design guidelines • Simple design • BUrndown chart • Design Reviewer • Design model • Sustainable pace • Designer • Development case • Metaphor • Graphic Artist • Development-organization • Small releases • Implementer assessment • Integrator • End-user support material • Process Engineer • Glossary • Project Manager • Implementation model • Project Reviewer • Installation artifacts • Requirements Reviewer • Integration build plan • Requirements Specifier • Issues list • Software Architect • Iteration assessment • Stakeholder • Iteration plan • System Administrator • Manual styleguide • System Analyst • Programming guidelines • Technical Writer • Quality assurance plan • Test Analyst • Reference architecture • Test Designer • Release notes • Test Manager • Requirements attributes • Tester • Requirements • Tool Specialist management plan • User-Interface Designer • Review record • Architectural analysis • Risk list • Assess Viability of architectural • Risk management plan proof-of-concept • Software architecture • Capsule design document • Class design • Software development • Construct architectural proof- plan of-concept • Software requirements • Database design specification • Describe distribution • Stakeholder requests • Describe the run-time • Status assessment architecture • Supplementary business • Design test packages and specification classes • Supplementary specification • Develop design guidelines • Target organization assessment • Develop programming • Test automation architecture guidelines • Test cases • Identify design elements • Test environment configuration • Identify design mechanisms • Test evaluation summary • Incorporate design elements • Test guidelines • Prioritize use cases • Test ideas list • Review the architecture • Test interface specification • Review the design • Test plan • Structure the implementation • Test suite model • Tool guidelines • Subsystem design • Training materials • Use-case analysis • Use case model • Use-case design • Use case package • Analysis model • Use-case modeling guidelines • Architectural proof-of-concept • Use-case realization • Bill of materials • Use-case storyboard • Business architecture document • User-interface guidelines • Business case • User-interface prototype • Business glossary • Vision • Business modeling guidelines • Work order Henrik Kniberg 62 • Business object model • Workload analysis model • Business rules • Business use case
  • 54. Top 10 Customer requirements Top 3 project impediments Top 5 Internal improvementsHenrik Kniberg 63
  • 55. Definition of ”ready fordevelopment” Definition of ”ready for system test” 64
  • 56. Team 1 Team 2 Team 3 Henrik Kniberg 65 65
  • 57.  The best thing about Kanban is that it doesn‟t require you to change your current processes. The worst thing about Kanban is that it doesn‟t require you to change your current processes Since Kanban is by its nature largely non- prescriptive compared to other methodologies, it doesn‟t necessarily tell you how to proceed

Related Documents