Download as KEY, PPTX
Uploaded byDon Bolen
Agile Project Management for elearning development
The document outlines project management practices tailored for agile eLearning development, emphasizing the adoption of agile methodologies over traditional practices. It highlights key components such as project initiation, planning, execution, monitoring, and closing, while also referencing the Agile Manifesto and its principles focused on customer collaboration and flexibility. Additionally, it discusses tools like Scrum and Kanban for managing workflows and optimizing team collaboration.
More Related Content
Similar to Agile Project Management for elearning development
Agile Project Management for elearning development
- 1. Project Management for Agile elearning development Don Bolen, PMP, CSM
- 2. Why do we manage?
- 3. ? this session shouldanswer
- 4. Project Management ProcessGroups – PMBOK 4th Edition Knowledge Monitoring & Initiation Planning Executing Closing Areas Controlling Integration Develop Project Charter Develop Project Direct & Manage Project Monitor & Control Project Close Project or Phase Management Plan Execution Work Perform Integrated Change Control Scope Collect Requirements Verify Scope Define Scope Control Scope Create WBS Time Define Activities Control Schedule Sequence Activities Estimate Activity Resources Estimate Activity Durations Develop Schedule Cost Estimate Costs Control Costs Determine Budget Quality Plan Quality Perform Quality Assurance Perform Quality COntrol HR Develop HR Plan Acquire Project Team Develop Project Team Manage Project Team Communications Identify Stakeholders Plan Communications Distribute Information Report Performance Manage Stakeholders Expectations Risk Plan Risk Management Manage and Control Risks Identify Risks Perform Qualitative Risk Analysis Perform Quantitative Risk Analysis Plan Risk Responses Procurement Plan Procurement Control Procurements Administer Procurements Close Procurements
- 5. Project Management ProcessGroups – PMBOK 4th Edition Knowledge Monitoring & Initiation Planning Executing Closing Areas Controlling Integration Develop Project Charter Develop Project Direct & Manage Project Monitor & Control Project Close Project or Phase Management Plan Execution Work Perform Integrated Change Control Scope Collect Requirements Verify Scope Define Scope Control Scope Create WBS Time Define Activities Control Schedule Sequence Activities Estimate Activity Resources Estimate Activity Durations Develop Schedule Cost Estimate Costs Control Costs Determine Budget Quality Plan Quality Perform Quality Assurance Perform Quality COntrol HR Develop HR Plan Acquire Project Team Develop Project Team Manage Project Team Communications Identify Stakeholders Plan Communications Distribute Information Report Performance Manage Stakeholders Expectations Risk Plan Risk Management Manage and Control Risks Identify Risks Perform Qualitative Risk Analysis Perform Quantitative Risk Analysis Plan Risk Responses Procurement Plan Procurement Control Procurements Administer Procurements Close Procurements
- 6.
- 7. Is this yourapproach? Analysis Design Develop Implement Evaluate
- 8. Is this yourapproach? Analysis Design Develop Implement Evaluate Is it effective? Efficient?
- 9. The Agile Manifesto “Weare 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 tools - Working software over comprehensive documentation - Customer collaboration over contract That is, while there is value in the items on the right, we value the items on the left more.” http://www.agilemanifesto.org/
- 10. The Agile Manifesto “Weare 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 Individuals and interactions tools Working software - Working software over comprehensive Customer collaboration documentation - Responding to change over contract Customer collaboration That is, while there is value in the items on the right, we value the items on the we value the items on the left more left more.” http://www.agilemanifesto.org/
- 11. The Agile Principlesof useful - Customer satisfaction by rapid delivery software - Welcome changing requirements, even late in development - Working software is delivered frequently (weeks rather than months) - Working software is the principal measure of progress - Sustainable development, able to maintain a constant pace - Close, daily co-operation between business people and developers - Face-to-face conversation is the best form of communication (co-location) - Projects are built around motivated individuals, who should be trusted - Continuous attention to technical excellence and good design - Simplicity - Self-organizing teams http://www.agilemanifesto.org/principles.html - Regular adaptation to changing circumstance
- 12. The Agile Principlesof useful - Customer satisfaction by rapid delivery software - Welcome changing requirements, even late in development - Working software is delivered frequently (weeks rather than months) - Working software is the principal measure of progress - Sustainable development, able to maintain a constant pace - Close, daily co-operation between business people and developers - Face-to-face conversation is the best form of communication (co-location) - Projects are built around motivated individuals, who should be trusted - Continuous attention to technical excellence and good design - Simplicity - Self-organizing teams http://www.agilemanifesto.org/principles.html - Regular adaptation to changing circumstance
- 13. The Iron Triangle Traditional Scope Cost Schedule Highsmith, Agile Project Management, p 21
- 14. The Iron Triangle Traditional Agile Scope Value Cost Schedule Quality Constraints Highsmith, Agile Project Management, p 21
- 15. Traditional vs whatyou Plan Agile expect to happen Enforce the plan Large, in-charge PM Directive, top down Use change control
- 16. Traditional vs Agile Plan what you expect by iteration Control is through adaption/inspection Use Agile proactively to manage change
- 17. Why Agile? >> Less Defects QUALITY productivity, faster time to market $$ Market alignment Quicker identification of loser projects LEAN http://blog.mountaingoatsoftware.com/presentation-on-the-benefits-of-agile
- 19. How will thiswork?
- 20. Agi le use s s t o r ie s t o g at h e r c u s t o me r re q u i re me n t s
- 21. A b ack l o g i s a lis t of p r i o r i t i ze d s t o r ie s
- 22.
- 23. As a .... <Us e r ro le> I wa n t .. . <G o a l> S o t h at .. .<B us i ne s s Va l ue>
- 24. As a learner,I want my elearning courses to have open navigation so that I can freely move through the course As a SME, I want the elearning courses to have linear navigation so that the learners progress in an orderly fashion As a manager, I want my employees to be able to test out of content that they already know so that the training is efficient and they’re back to work as soon as possible
- 25. As a .... <Us e r ro le> I wa n t .. . <G o a l> S o t h at .. .< B us i ne s s Va l ue>
- 26.
- 27.
- 28.
- 29. Image cc Maree Revely(aka Somerslea)
- 32. Scrum Product Development Scrum Master Owner Team Timeboxed SPRINTS Prescribed, limited MEETINGS
- 33. Daily Scrum 24 hours Product Backlog Sprint “Shippable” Backlog Product 2 - 4 weeks
- 34. Sprint Planning Define the sprint goal, summarizes product backlog Team time estimates Selects stories for the sprint Selects time for daily scrum
- 35. Sprint Planning Activity
- 36. Classroom to Online 3.5hrs classroom Test out of lecture content Scenarios with branching Learner must pass test
- 37. 3.5 hrs classroom Test out of lecture content convert PPT Scenarios with branching Learner must pass test to elearning
- 38. 3.5 hrs classroom Test out of lecture content convert PPT Scenarios with branching Learner must pass test to elearning create sb create gfx create audio create ...
- 39. 3.5 hrs classroom Test out of lecture content convert PPT Scenarios with branching Learner must pass test to elearning create sb create gfx size = how much effort create audio create ...
- 40. 3.5 hrs classroom Test out of lecture content convert PPT Scenarios with branching Learner must pass test to elearning storyboard graphics audio create ...
- 41. 3.5 hrs classroom Test out of lecture content convert PPT Scenarios with branching Learner must pass test to elearning storyboard graphics audio create ...
- 42. Daily Scrum Meeting Ask What did you yesterday? What will you do today? What obstacles are there? 15 Minutes Only pigs, no chickens
- 43. Scrum Taskboard in Sprint story to do progress done Goal unplanned next
- 44. Scrum Taskboard in Sprint story to do progress done Goal burndown unplanned next
- 45. Measuring via “Burndown” Start Work Remaining End Date
- 46. Burndown Good Work Remaining or Bad? Date
- 47. Burndown Good Work Remaining or Bad? Date
- 48.
- 49. Daily Scrum 24 hours Product Backlog Sprint “Shippable” Backlog Product 2 - 4 weeks
- 50. Daily Scrum Sprint Review / Retrospective 24 hours Product Backlog Sprint “Shippable” Backlog Product 2 - 4 weeks
- 51. Sprint Review / Retrospective Reviews what and was not completed Presents the “working” “Shippable” Product increment - demo Reflects on what worked, what didn’t Identify improvements
- 53.
- 54. Scrum Defined ROLES/RULES Timeboxed SPRINTS Prescribed,limited MEETINGS
- 56. Kanban Visualize the workflow LimitWork In Progress (WIP) Manage flow Process policies must be explicit Improve collaboratively
- 57.
- 58. backlog doing (3) testing done
- 59. backlog doing (3) testing done FLOW
- 61.
- 62. backlog doing (3) testing done urgent!!
- 63. backlog doing (3) testing done urgent!!
- 64. backlog doing (3) testing done urgent!!
- 65.
- 67. Kanban Kanban board Limit WorkIn Progress (WIP) Explicit process flow Deliver often Make improvements
- 68.
- 69. Success Commit to frequent releases
- 70.
- 71. Success Be transparent -Use Task/Kanban board
- 72. Success scrum stand up pic COLLABORATE leverage team creativity
- 73. Success Do what’ll work in your environme nt
- 74.
- 75.
- 76. References David J Anderson,Kanban 2010 Jim Benson & Tonianne DeMaria Barry, Personal Kanban: Mapping Work | Navigating Life Pete Deemer, et al, The Scrum Primer, ver 1., 2010 http:// www.scrumalliance.org/resources/339 Jim Highsmith, Agile Project Management, 2010 Henrick Kniberg, Scrum And XP from the Trenches, 2007 Henrick Kniberg & Mattias Skarin, Kanban and Scrum, Making the most of both, 2010 Project Management Body of Knowledge, 4th Edition, 2008 Ken Schwaber, Agile Project Management with Scrum Ken Schwaber & Jeff Sutherland, Scrum Guide July 2011 http:// www.scrum.org/ Michele Sliger & Stacia Brokerick, The Software Project Manager’s Bridge to Agility
- 77.
- 78.
- 79. Project Management for Agile elearning development Don Bolen, PMP, CSM don@dbolen.com @dbolen
Editor's Notes
- #2 Welcome to Agile for elearning development\nToday we&#x2019;ll look at Agile and explore some tools/methodologies that hopefully will be useful to you.\n
- #3 Why do we manage? This isn&#x2019;t a rhetorical question. Why do we manage projects? \nANSWER - We need some structure so successes can be repeated versus the just do anything approach. \n
- #4 What Agile is, and isn't (there&#x2019;s not an easy button)\nHow Agile aligns with &#x201C;traditional&#x201D; project management\nAgile approaches of Scrum and Kanban that can be used in elearning development.\nWhat tools are available for planning and tracking development\nThat you can mix/match/hybridize to meet your needs\nAnd you&#x2019;ll probably see some agile practices that you have employed\n\n
- #5 From the Project Management Body of Knowledge (affectionately known as PMBOK) we have these knowledge areas and process groups. \nY&#x2019;all use these, right? Each and every day? CLICK The PMBOK is a guide rather than a methodology and is not intended to be applied uniformly. (it&#x2019;s there on Page 4) \nHowever, if you have a PMO, you probably have some prescribed PM process.\n\n
- #6 So why do we have problems with projects?\nResearch I&#x2019;ve read shows that 1 in 5 IT projects are likely to bring &#x201C;full satisfaction&#x201D; (Failure Rate, retrieved from http://www.it-cortex.com/Stat_Failure_Rate.htm 10/26/2011) and one survey showed that 37% projects are troubled and at risk of failure. \n\nA $5 million project that leads to an almost $200 million loss is a classic &#x201C;black swan.&#x201D; he average overrun was 27%&#x2014;but that figure masks a far more alarming one. Graphing the projects&#x2019; budget overruns reveals a &#x201C;fat tail&#x201D;&#x2014;a large number of gigantic overages. Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%\n
- #7 You recognize this right? ADDIE. The waterfall approach may be the issue; you do Analysis, some approval gate, the start Design, etc. CLICK for build At Delta (and many orgs I&#x2019;ve consulted with), have a gated ISD process. What happens when you get to implement and something happened to change your content? If we have issues, imagine the challenges in software development\n\n
- #8 The Agile manifesto was a response to the waterfall approach to software development in February 2001. \nLet&#x2019;s reflect for a moment. What strikes you about the manifesto? WAIT and then click for reveal.\nAs one wag noted - &#x201C;It's generally not a good idea to mess with people who issue manifestos.&#x201D;\n\n
- #9 Here are the paraphrased principles behind the manifesto. Again let&#x2019;s reflect. What strikes you about these principles? CLICK to reveal next slide\n\n\n
- #10 Enough of these dense wordy slides, let&#x2019;s start to compare traditional project management to agile \n
- #11 The iron triangle, AKA the triple constraints, the trade off triangle. These variables limit our choices in managing our projects - Remember that old chestnut &#x201C;Good, Fast, Cheap; pick any two&#x201D; This is how we measure our project&#x2019;s success &#x2013; did it deliver on time and on budget. But where is quality? \nQuick question, what do we mean by scope? From PMBOK &#x2013; it&#x2019;s the sum of products, services and results to be provided by the project. \nRemember Jim Cameron&#x2019;s Titanic (the movie) - applying time/cost this project was not successful but generated $1.8 B gross revenue\nCLICK for reveal In Agile, our measures are: \nvalue to the customer, quality required to deliver continuous value and constraints (scope, schedule, cost)\n\n
- #12 Let&#x2019;s compare, traditional PM is about the plan and then enforcing to the plan, we don&#x2019;t like it when things don&#x2019;t go according to plan\n
- #13 In Agile, planning is closer to reality with short iterations, hey this plan ain&#x2019;t working, let&#x2019;s change. In the PMBOK, this is called rolling wave planning (progressive elaboration meaning that near term work is planned in detail while future work is planned at a &#x201C;higher&#x201D; level, p 135) Sadly many orgs and PMO don&#x2019;t embrace rolling wave. \n
- #14 from four studies - Agile delivers quality improvement of +63%, 70% decrease in code defects\nSalesforce.com more cumulative value in releases, lower dev costs, faster time to market \n\nBy Lean, it follows lean principles - Eliminate waste, Amplify learning, Decide as late as possible, Deliver as fast as possible, Empower the team, Build integrity in, See the whole\n\n
- #15 Here&#x2019;s a great visualization for Agile S/W development. VersionOne is an ATL company. You can get this poster from their website. Agile is incremental and iterative, using small, dedicated co-located and self organizing teams in close collaboration with a business customer. Agile is value-driven focused on delivering most important features first and in the ways the teams chose to work together TDD = test driven environment Refactoring = cleaning code for maintenance and enhancements\nAgile Project Management mode >> Envision - Speculate- Explore-Adopt-Close (Highsmith, p81)\n
- #16 So how can we make this work? Enough history and background&#x2026;\n\n
- #17 Agile gathers user stories for requirements and product expectations\n\n
- #18 From there we build a backlog, a set of requirements for something.\n
- #19 lets do a planning activity\n
- #20 you&#x2019;ll assume a role (the persona) and you will fill in the blanks\nAs a ______, I want _____ so that _____. \n
- #21 as example\n
- #22 my lovely assistants will distribute the post its and go forth. We&#x2019;ll timebox (more about timeboxing in a few) this and sdebrief\n\n3 minutes - who wants to share? Moving on....\n
- #23 let&#x2019;s talk about agile tools \n
- #24 CLICK to reveal. Better in many cases is determined by need and culture\nSo true in one&#x2019;s org. Lift and shifted practices don&#x2019;t always translate or work well when transplanted\n
- #25 what is this &#x2013; right it&#x2019;s a scrum, a way to restart play in rugby, in this game you advance the ball by passing the ball. Scrum is an agile tool/process/approach/methodology/framework that forces focus on delivering the highest business value in the shortest time. \nScrum has rules. Scrum calls for Sprints, rapid and repeated development and inspection of actual working software (every 2 or 4 weeks).\nThe business sets the priorities. Scrum teams self-organize to determine the best way to deliver the highest priority features. \nWith every Sprint, everyone can see real working software and decide to release it as is or continue to enhance it for another sprint.\n\n
- #26 The Scrum Guide updated in July, is a mere 17 pages. Ken Schwaber and Jeff Sutherland developed scrum. \nMicrosoft, Google, IBM, Siemens, John Deere, Lockheed-Martin, Time-Warner, Turner Broadcaating use Scrum\n\n
- #27 Who has heard about pigs and chickens? Pigs are totally committed to the project and accountable for its outcome, and chickens, who consult on the project and are informed of its progress.\n
- #28 Scrum Teams are self-organizing and cross-functional \nThe Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner is a sole person (NOT A COMMITTEE). The Product Owner clearly communicates vision and goals. For the Product Owner to succeed, the entire organization must respect his/her decisions. \n&#xA0;\nThe Team is responsible for delivering the product. The team is cross functional and typically 5&#x2013;9 members.\n&#xA0;\nScrumMaster facilities the Scrum, main role removing obstacles and &#x201C;enforces&#x201D; the scrum rules. The scrum master is likened to a servant leader. SM finds ways effective product backlog management; coaching self-organizing teams and facilitating scrum adoption in the org. The SM is a protector of the team from distractions\n\n\n\n
- #29 Here&#x2019;s what scrum looks like, we&#x2019;ll talk about Sprint Planning, the Daily Scrum meeting and Review/Retrospective in a moment\n
- #30 Is timeboxed to no more than 8 hours for one-month sprint (2 weeks, 4 hours)\nWhat will be delivered in upcoming sprint? How will the work be achieved? Product owner present the product backlog. The team figures out what can get done and selects the work for the sprint backlog. An important concept is what does &#x201C;DONE&#x201D; mean. The team will use group decision techniques to arrive at consensus - planning poker, fist of fives, other group techniques. \n\n\n
- #31 lets do an activity, organize with your neighbors,\nWe have two week sprints ...\n\n
- #32 I&#x2019;m the product owner and here&#x2019;s our story backlog\nYou&#x2019;ll take these stories and then break out the tasks and &#x201C;size&#x201D; your sprint and define what DONE is\n\nMandatory manager course 3.5 hours in classroom with lecture, case study and debrief with PPT (very bad PPT) Requirements are to allow test out of lecture content and add branching scenarios. If learner tests out, must do the scenarios and then successfully pass test for LMS credit. \n
- #33 CLICK for build. Let&#x2019;s take stories and break them down so we can plan the sprint - what the team will deliver at the end of the iteration. CLICK\n
- #34 CLICK for build. Let&#x2019;s take stories and break them down so we can plan the sprint - what the team will deliver at the end of the iteration. CLICK\n
- #35 CLICK for build. Let&#x2019;s take stories and break them down so we can plan the sprint - what the team will deliver at the end of the iteration. CLICK\n
- #36 CLICK for build. Let&#x2019;s take stories and break them down so we can plan the sprint - what the team will deliver at the end of the iteration. CLICK\n
- #37 CLICK for build. Let&#x2019;s take stories and break them down so we can plan the sprint - what the team will deliver at the end of the iteration. CLICK\n
- #38 Let&#x2019;s take stories and break them down into tasks so we can plan our sprints and have something to &#x201C;ship&#x201D;. What are the tasks to create the storyboard, audio, scenarios, graphics, audio, tests, other stuff that can go into the courseware? CLICK to reveal The team then estimates effort (days, hours, points) and who is responsible. Finally - what is DONE. So pick one aspect to work with your group.\n\nQuick debrief\n
- #39 Daily Scrum - The team should be able to describe how it will work together each and every day. This is a standup meeting. NOTE - not a status meeting. \n
- #40 The Daily Scrum meeting occurs in front of the Taskboard. How is this visible? Transparent?\nQuestions? CLICK to reveal burndown Measures, I need measures, I went to metrics session this morning\nSo how do you measure this Sprint stuff?\n\n\n
- #41 Does everyone know what burndown means? You look at the work remaining over time and you want to see if you&#x2019;re on track. Think of those 60 mile cancer walks, end of day 1 you should have walked 20 miles. \n\n\n\n
- #42 bad\n
- #43 Not so good either, can do way more stories off the sprint backlog\n\n
- #44 here&#x2019;s real &#x2018;tho messy burndown chart.\n
- #45 CLICK TO REVEAL. At the end of the sprint, you will conduct a Sprint Review and a Sprint Retrospective. These are two events\n
- #46 Sprint review is the show and tell. Retrospective is the lessons learned and what can we improve in next sprint\n\n\n
- #47 Think Scrum can only work in the workplace? Here&#x2019;s a family Scrum board\n\n
- #48 And one for organizing weekend chores\n
- #49 Scrum in summary \nWhat are the roles? Product Owner, Team, &#xA0;Scrum Master \nHow long are SPRINTS typically? 2-4 weeks\nMeetings? \nQuestions about SCRUM Can you do something like this in your org?\nSunGard presented in an online forum in Feb 2011 in using Scrum in developing learning paths for EE, they used this across departments using Agile approaches - developed learning game prototypes for testing (some on paper)\nIn the same OLF, Lowes&#x2019; developers presented Applying Agile Game Development Techniques to E-Learning\nWikispeed used lean/agile/scrum software-development process WIKISPEED has designed and built the SGT01&#x2014; a 100 mpg, four-seat commuter car with a mid-engine and rear-wheel drive with goal to mass produce this car price of under $20,000 USD.&#xA0;http://www.wikispeed.com\n\nAnyone have some examples?\n\n
- #50 Kanban from Japanese means signboard, foundational to the Toyota Production System. Kanban can be defined as &#x201C;visual card&#x201D;\n\n
- #51 Visualizing the flow of work and making it visible is core to building an understanding how work works. Limiting work-in-progress implies a pull system across the workflow - yes this is PULL. Flow of work through each state in the workflow should be monitored, measured and reported. Handoff, what&#x2019;s &#x201C;done&#x201D; or ready for testing really mean must be explicit. Agree that you need (and want) to improve. Kanban doesn&#x2019;t timebox per sprints. You&#x2019;re pulling from the backlog.\n\n
- #52 from David Anderson&#x2019;s Kanban Start with what you do now with the roles and processes you have. Agree to pursue incremental, evolutionary change. The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. You start by planning, devising a system for the work. Remember, this grew out of software development with the goal of regular delivery of working product. We can do the same thing. \n\n\n
- #53 CLICK for flow Here&#x2019;s a sample Kanban board. Backlog from planning meetings (some type of process) Note in this case we&#x2019;re limiting the WIP to 3, We have some stories in testing and a bunch DONE. \n\nBacklog from planning meetings (some type of process) - planning poker, fist of five, managers meet and give backlog, etc. \n
- #54 Here&#x2019;s a real world example.\n
- #55 lets do an activity, go back to your groups, take your sprint backlog discuss and arrive at your WIP limit.\n
- #56 CLICK for flow Here&#x2019;s a sample Kanban board with urgent. CLICK Once an item moved into testing, we have capacity. Rather than picking from the backlog, we pull the urgent task. B\n
- #57 CLICK for flow Here&#x2019;s a sample Kanban board with urgent. CLICK Once an item moved into testing, we have capacity. Rather than picking from the backlog, we pull the urgent task. B\n
- #58 Other tools exist many with free trials or limited free access\nhttp://www.versionone.com/; http://agilezen.com/; http://www.rallydev.com/index.php\n\n
- #59 Here&#x2019;s a personal Kanban board from a PMI colleague\n
- #60 Use a Kanban board, build it to suit your org and work flow. Pull systems will expose bottlenecks. Limit WIP, reducing WIP will increase quality. Be explicit in process, don&#x2019;t just throw over the cube wall. Deliver often - delivering small high quality releases will build trust. Make continued, evolutionary improvements.\n
- #61 Reducing WIP shortens lead time (cycle time) Anderson, p 29\n\n\n
- #62 More frequent release of working stuff build trust with customers and the team\n\n
- #63 Pull the work from the backlog, everyone sees the backlog and what &#x2018;s coming next\n\n
- #64 It&#x2019;s on the board, transparent. What are questions are answered at the daily scrum meting?\n
- #65 Use a daily stand up, encourage daily interactions with product owner, the team, stakeholders Use the board!!!!\n\n
- #66 One of the tenets in Agile is adapting to different situations - from the Declaration of Interdependence. Remember your people change skills\n
- #67 Don&#x2019;t be afraid to do a mashup &#x2013; turns out in 1995 at Delta in Video Services we were using Scrum-like, Srum-ish, Scrumban to manage our episodic production &#x2013; who knew? From David Anderson tweet - 10/18 "If there is a way to do Kanban wrong, it's to copy someone's existing process."\n\n
- #68 try it, run a pilot, do it in stealth mode, experiment, be patient and don&#x2019;t be afraid to fail, you may learn something. \n\n
- #69 \n
- #70 \n
- #71 \n
- #72 \n