Poor Man's Kanban


Published on

Description and video for this presentation here:

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Causes:Long lead timeHard to plan
  • There’s always a reason.Example: emptying water from a boat. Do something about the reason!
  • In Scrum and Kanban you are supposed to add stuff.In RUP, you are supposed to remove stuff.Scrum + XPKanban + daily standupScrum team using use cases or limiting WIPDon’t call it Scrum if it isn’t.
  • Poor Man's Kanban

    1. 1. An introduction to a lean-styledsoftware development methodology
    2. 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. 3.  Henrik Kniberg (slides used under Creative Commons License) David Anderson Corey Ladas Ron Jeffries Jesper Boeg Many others
    4. 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. 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. 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. 7.  http://www.nouveautech.co.uk/waterfallprocess.html
    8. 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. 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. 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. 11.  Estimation paradox The amount of time spent in estimation produces a problem it was designed to manage
    12. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. http://blog.crisp.se/henrikkniberg/tags/kanban/ Henrik Kniberg 35
    32. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 54. Top 10 Customer requirements Top 3 project impediments Top 5 Internal improvementsHenrik Kniberg 63
    55. 55. Definition of ”ready fordevelopment” Definition of ”ready for system test” 64
    56. 56. Team 1 Team 2 Team 3 Henrik Kniberg 65 65
    57. 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