Training - Introducing Agile, Lean and Kanban
•Descargar como PPTX, PDF•
9 recomendaciones•8,605 vistas
This is a presentation that I did for a team to introduce them to Agile, Lean and Kanban, It covers these these 3 areas, how they overlap and then gets into greater details about the Kanban Method.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Training - Introducing Agile, Lean and Kanban
Similar a Training - Introducing Agile, Lean and Kanban (20)
Más de Sudipta Lahiri
Más de Sudipta Lahiri (19)
Último
Último (20)
Training - Introducing Agile, Lean and Kanban
- 1. AGILE / LEAN / KANBAN 12/10/2013 Sudipta Lahiri, Digité 1
- 2. Let’s bust some myths first... 2 Agile methods are NOT: You can get temporary speed... but not sustainable Speed needs much more discipline that otherwise! Sloppy Whatever-you-want-to-do No-questions-asked, no-managers or no-dates Compressing schedule Throwing out documentation Coding till the last minute Think Formula One racing! Agile teams need testers... with strong testing skills 12/10/2013
- 3. Many are doing it today… 3 12/10/2013
- 4. 4 Even the Government is doing it… 12/10/2013
- 5. 5 So, what is all this noise about? 12/10/2013
- 6. The evolution of SDLC 6 1970s: Waterfall 1980s: SSAD 1985: CMMI 1990s OOD/RAD 12/10/2013
- 7. Changing Focus 7 Building the product RIGHT Are we building the RIGHT product? 12/10/2013
- 8. Emergence of Agile 8 2001: Agile Manifesto individuals and interactions over processes and tools Colocation/pair programming Working software over comprehensive documentation Sprints: deliverable software Customer collaboration over contract negotiation Responding to change over following a plan Plan/Scope committed to the current Sprint 12/10/2013
- 10. 10 Thinking progressed in 2 tracks... Management Methods XP SCRUM Lean Kanban SCRUMBAN Many others... Engineering Methods TDD + BDD Build Automation => Continuous Integration Continuous Delivery Continuous Deployment 12/10/2013
- 11. Lean applied to Software 11 What is a “Lean” system? A system in which we: Eliminate waste: Focus on hand-offs, source of errors Amplify learning; create knowledge Defer commitment Deliver as fast as possible Respect people; Empower them Build quality in; optimize whole Improvements can happen when you can see what is happening in the system => reduce waste Focus on better economic outcome than better utilization of resources Think of it as a pipeline... Anything, that slows things flowing out of the pipeline is a waste 12/10/2013
- 12. A different balancing act... 12 Cost (resources) Time Scope Agile software development Traditional software development Time Cost (resources) Scope (Target business goals & outcomes) 12/10/2013
- 13. SCRUM 13 12/10/2013 Img Src: Scrum Primer by Pete Deemer
- 14. What is Kanban? 14 David Anderson formulated the method Kanban = kan ("visual") + ban ("card" or "board") Coined by Toyota during the late 1940s and early 1950s and has spread to the manufacturing industry all over the world as a tool of Lean Manufacturing Kanban: signal Used to support noncentralized "pull" production control to gain visibility into the process and execution status, reduce waste (and costs), and help 12/10/2013
- 15. 15 The Kanban Method: Core Practices Visualize the Work Focus is on creating a continuously Limit Work in Process (WIP) improving system; NOT on creating Manage Flow; Establish a Cadence the most optimal Remove bottlenecks and improve the flow system Increase throughput Map your value stream Making invisible work, visible! Make Process Policies Explicit ------------------------------------------------------ Improve Collaboratively, Evolve Experimentally (using models and scientific method) Implement Feedback Loops 12/10/2013
- 16. A Board looks like this... 16 12/10/2013
- 17. Value Stream 17 Through metrics you can evaluate your efficiency. How much time spent on value add vs non value add 12/10/2013
- 18. Why Pull? Why Kanban 18 We don’t want to: Build features that nobody needs right now Write more specs than we can code Write more code than we can test Test more code than we can deploy Work on Tickets/ Transactions that are not priority 12/10/2013
- 19. Limiting Work-In-Progress (WIP) 19 Reduces multi-tasking Prevent context switching Performing tasks one-at-a-time yields results sooner Maximizes throughput Enhances teamwork Working together to make things done Increase cross-functionality 12/10/2013
- 20. Making policies explicit 20 Policies are not evil Defining policies vs QMS A framework for common understanding across all team members For example: Process Flow Input Cadence; Output Cadence WIP Limits Definition of “Done” Entry and Exit Criteria (moving from one stage to another) Handling rework Should the card be send back on the work board OR stay in the same lane till it is reworked? Handling Class of Service How to handle Expedite cards? 12/10/2013
- 21. 21 Here’s what happens… Courtesy: Henrik Kniber 12/10/2013
- 22. 22 12/10/2013
- 23. 23 12/10/2013
- 24. 24 12/10/2013
- 25. 25 12/10/2013
- 26. 26 12/10/2013
- 27. 27 12/10/2013
- 28. How work happens today? 28 Project Managers do scope/work decomposition and assign tasks to people Typically, done in a very deterministic manner We make a MS Project schedule; gives a planned end date Tasks start slipping Team members try to juggle between what is planned (and kept on schedule) + new arrivals! In most cases, people avoid reprioritization (you can’t do it for every incremental piece) As a result: Planned tasks start slipping Multiple reasons: some in control of project team and some not... Quality drops because people multitasking and context switching Unscheduled tasks start coming in Management asks questions but very difficult to justify and show the problem! Teams works in a reactive mode (as opposed to a planned proactive manner) Team feels there is no time to breathe... the pressure seems endless! 12/10/2013 Some anticipated and some unanticipated... Defects: you don’t know how many will come and their flow New RFPs/CRs that need to be estimated that may or may not ever fructify Some visible to the Project manager and some not... These get assigned to people who are
- 29. How a “Project Board” changes this? 29 Shows all work items, their current state of progress and the people who are on it Help collaborate between the project team: If someone needs help, they can “block” without escalation/followup If someone is overloaded, others in the team can respond Work items move forward as they progress! Everyone knows what others are working on Provide for additional social tools to collaborate within project team Brings out many “hidden” things that people are working on Makes it obvious where work is getting piled up to everyone You will see this when we show this in a fast simulation model Colors help you visualize the pattern of work For e.g., are you doing more value enhancement work or more rework? Chat/Threaded Discussions “What-if” simulation models Project Board is touch screen enabled and available on mobile 12/10/2013 platforms
- 30. 30 How a “Project Board” changes this? Putting a limit on the work in process determines what really needs to be done Creates a scorecard with just having a simple Kanban board The board keeps us accountable You know how many get done! The person who owns the card has to move it forward Encourage teamwork as the tasks that are not being completed will focussed and 12/10/2013 worked on, together
- 31. 31 Kanban – an evolutionary approach Kanban is an adaptive capability for evolutionary change Not a process definition or a framework to be tailored 12/10/2013
- 33. 33 The Daily Standup Meeting 12/10/2013
- 34. 34 The Challenges of Status Calls… People report to leader… Leader summarizes the status update … and sometimes “massage” the status update Often, there is chaos, no agenda, too many people Louder personalities (few) dominate Many sit quiet in tacit acceptance 12/10/2013
- 35. 35 Rationale behind the Standup call Regularly communicating, working together and helping each other is the best team practice Gaining a shared understanding of what work is done and what remains to be done 12/10/2013
- 36. 36 Standup Call is the Team Huddle! We have all seen the “HUDDLE”… in action Why not in your teams? 12/10/2013
- 37. This is what happens… 37 Team Meeting to provide a Daily Status Update in 15 min Gather issues during the Standup Process issues after the Standup: take discussions offline Each person tells their peers (not their manager) What they did yesterday and what they plan on doing today Where are they stuck or need help? Think ahead your elevator pitch Use the Board; have a facilitator Same place; same time Do not wait; do not repeat Ideally, start the day with a Standup 12/10/2013
- 38. GIFTS (goals) of a Standup Call 38 G – Good Start to the day Give energy; instil a sense of purpose/urgency Clear understanding what needs to be done to achieve it BUT… if you cannot START the day, schedule it at the end of the day so that it is not linked to starting work in the day Expose problems to allow us to improve Share better techniques and ideas Focus on moving work through the system to achieve our objectives T – Reinforce the sense of Team Strongly tied with team members helping each other with shared obstacles Effective teams are built by regularly communicating, working, and helping each other I – Support Improvement F – Reinforce Focus on the Right Things No "false urgency“: where people are geared up for activity but are without shared direction Effective teams are autonomous (selforganizing) S – Communicate Status How is the work progressing? Is there anything else interesting that 12/10/2013
- 39. Some more guidelines 39 Who Attends? “All Hands” People are giving update on behalf of the stories Reject any meeting that risks that timeline Including your manager’s or your customers They will appreciate your commitment to the “Huddle” Set your reminder 5 min ahead of start time Speaking order: Round-robin… OR… Replace some meetings/reports with Standup “Stories” are the participants The last person who arrives speaks first Speak loudly; don’t whisper… You have to energize! End the meeting with a high note Break eye contact with the manager For larger teams May not be possible in 15 min Focus on Blocked Cards, Expedite Cards 12/10/2013 Leave time for something that
- 40. Standup Call - Mistakes 40 Be cautious of few issues dominating the call Take them offline Not Standing: Take out the chairs! Some people get into “story telling” Team members not showing up on time Get support from line managers Pick a time that everyone is OK with Provide buffer between meetings Allowing distractions Location, No mobiles/laptops Meeting etiquette Not having a dedicated team room Not using Standup for distributed teams 12/10/2013
- 42. The Retrospective Template: For mid-size projects 42 Appreciations Let everyone write their own points on a post-it and stick it on the white board What do they mean: Puzzles Risks Wishes Risks: Future pitfalls that can endanger the project, represented by a bomb. Actions Puzzles: Questions for which you have no answer, represented by a question mark. Appreciations: What you liked during the previous iteration, represented by a smiley face. Wishes: Not improvements, but ideas of your ideal project, represented by a star. 12/10/2013
- 43. Scope 43 What did we plan to do? What actually happened? Why? What would we do next time? What do we want to do more of, what do we want to change or stop? (5 mins max) 12/10/2013
- 44. The method 44 Nominate a facilitator Consider an outside facilitator to eliminate inter-personal issues Consider removing chairs => No more endless debates Avoid the product owner (unless you have a great one!) Tend to hijack the discussion with “all problem with dev” Collect data for 15 min Define ground rules. Consider: Be respectful interrupt Put away laptops and phones Park long discussions in the designated lot What is said here stays here Look at Cumulative Flow, Cycle Time and Lead Time – what issues do we see, what actions can we take? (5 mins max) 12/10/2013 Collate your blockers Recap what you hear to ensure understanding Go round the group – what have we done for the improvement actions we committed to last week? (23min per person) ; Do not
- 46. getKanban Game 46 Each team has a playing board representing a Kanban task board, and a collection of story cards representing work to be done. Each card has a value associated to it and an estimated effort for each stage Team earns as cards complete the Value Stream Teams compete to maximise net profit by optimizing the flow of work All resources can do everything except when the system specifically mentions a constraint System generates events and you have to keep re-planning based on the same Lookout for Expedite or FixedDay cards; there is price for missing deadlines When you pull cards, from the Backlog, new cards will appear; notice for the value of the cards 12/10/2013
- 47. 47 12/10/2013
Notas del editor
- 1945 to 1965: The Origins – late 1950/early 1960s - the use of “engineering” to software1965 to 1985: The Software Crisis – Cost and Budget overruns (The Mythical Man Month; OS/360 project of over 1000 people)/Fatal incidents in medical science(Therac25)/property theft1985 to 1989: Tools, discipline, formal methods, process, and professionalism were touted as silver bullets; No (single) Silver Bullet. SSAD/OOAD/Documentation/Standards1990 to 1999: Prominence of the Internet (spread of networks/web/virus/SEOs/natural lanuage translators) – growth of the user base2000 to Present: Lightweight MethodologiesTools, discipline, formal methods, process, and professionalism were touted as silver bullets
- In the olden days, our focus was to write detailed specs with the hope that this was the “perfect” requirement and then put a whole bunch of process rigor to make sure that we build it right! Then, this model faltered... So, we then started focussed on a process of continuous validation with the end user to see if we are building the right product? This automatically meant that some of the best practices of software engineering to make the product right is already built in! You cannot build a huge technical debt and hope that this will come be refactored later.
- Map the Value Stream. A Kanban approach looks at the whole stream of work, from where it enters the scope of the team, to where it leaves. Thus typically, a Kanban system will explicitly include the transformation of work from the problem or idea, through to its release. i.e. Concept to Cash (or Consumption), or Incubate to Liquidate.Visualise the Work. A Kanban approach will make all the work as visible as possible, across the whole Value Stream. In particular, this includes the visualisation of expanding/contracting, or zooming in and out, of work items to make their value/solution, or other hierarchical relationships visible.SUDI>>> The points mentioned are particular to an electronic board. However, the visualization aspect remains important even for the manual board (as per Slide 10)Limit Work in Progress. A Kanban approach will explicitly limit work in progress. This is distinct from managing work in progress through the use if time-boxes as described by David Anderson. This absolute limiting of work in progress is what makes Kanban a pull system, rather than a very small batch push system.SUDI>>> Not clear I get it… why should limiting WIP make it a pull system?Establish a Cadence. A Kanban approach will create a natural rhythm by setting up a cadence which will help the team deliver. This will typically de-couple the input (planning and prioritization) from the output (release), allowing more freedom than the time-box, but still providing a framework to release regularly, measure performance and continuously improve. Simply put, establishing a Cadence means, establishing a regular frequency for doing things that need to be done repetitively. These could be Customer Reviews, Production Releases, Daily Team Meetings, etc.SUDI>>> I think this aspect has been significantly simplified. The whole premise that you can release regularly just because you a cadence/rhythm is not right. One needs to grouping line items in a logical way that will make a release (SCRUM like planning). a significant assumption that not just testing but test automation is happening at the same pace. Not just TDD but actual functional test case automation to make a final release.
- Value Stream analysis and mapping provides a visual of where waste may be occurring. Waste is any step where no value is being added to the production or the service delivery process.
- SUDI>>> Also, work on items that risk being obselete by the time we actually take it for development…
- Pause for a moment and explain how having a “Done” lane enables Pull.Also, that typically one should have a “Done” lane when work flows from one person to another (not within stages of the same person’s execution)!
- Understand the significance of “Get Coffee”! You are telling them not to keep developing things because I am not ready to absorb them!
- In SWIFT-Kanban Dev team:Stand up is of 20-30min Followed by an issue based discussion involving concerned peopleThis approach works well for us because one team is in US; so, need for other callsin the middle of the day is reduced
- Refer: http://www.batimes.com/articles/seven-common-mistakes-with-the-daily-stand-up-meeting.html