Downloaded 108 times
![21
Team Members
Developer [2-4]
Tester [1-2]
Agile BA for larger teams and Scaled Agile
Tech Lead especially for more developers
Technical Writer [Optional]
Specialist roles main join, FE Dev, DBA etc.
Different Sized
Teams will benefit
from different
practices and Agile
Flavors
• Small 1-4
• Medium 5-8
• Large > 10](https://image.slidesharecdn.com/agileintroductionforicf-130809151243-phpapp01/85/Agile-Introduction-21-320.jpg)
Uploaded byGuy Winterbotham CSM,PMP
Agile Introduction
This document provides an introduction to Agile methodology. It discusses how Agile addresses problems in software development like lack of predictability, transparency, and responsiveness to change. It then defines what Agile is from a mindset, values, and principles perspective. It also outlines some popular Agile flavors like Scrum, Kanban, SAFe, and XP. Finally, it walks through what a day or sprint looks like for a Scrum team, including roles, artifacts, meetings, and how stories are planned and tracked on a Scrum board. The overall document serves to introduce the core concepts and promise of Agile software development.
More Related Content
Similar to Agile Introduction
![5G Explained! A High Level Overview [Introduction]](https://cdn.slidesharecdn.com/ss_thumbnails/5gexplainedahighleveloverview-260119165306-cc137a3e-thumbnail.jpg?width=640&height=640&fit=bounds)
Agile Introduction
- 1. 1ironworks.com Introduction to Agile ICFPM Group Presentation 4/2/2013
- 2. 2 Pomodoro 1: ThePromise of Agile • What problems in software development does Agile address? • Where does Agile fit in the Universe of Methodologies • What is Agile – from Squishy to Solid? • What is the Promise of Agile? • What flavors does Agile come in? • The Current State of Agile Pomodoro 2: A day/week/month in the life of … • A Scrum Team • A Kanban Team • A Scaled Team Lean Coffee Retrospective: Agile Dunk Tank Agenda
- 3. 3 Businesses are lookingfor an approach to software development approach that offers: • Predictability and Transparency • Right-sized, just- enough, and just-in- time • Responsive to rapid market change • Incremental, and iterative delivery to delivery value, early and often • Quality built in along the way Agile Addresses: Software Development is Complex
- 4. 4 Predictability: What hasrecent history told us ? The Standish Group’s CHAOS report results from a 40,000 projects Top reasons for success 1. User involvement 2. Executive support 3. Clear objectives 4. Optimizing scope 5. Agile process1994 16% Succeeded ≈170% overrun 2004 32% Succeeded ≈70% overrun “Doing projects with iterative processes as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.” Jim Johnson, Chairman of Standish Group
- 5. 5 Sometimes, 16% Rarely, 19% Never,45% Always, 7% Often, 13% Feature Usage in Software Projects Has Product Development produced Just enough, Just in time? Always or often used 20% Never or rarely used 64% Standish Group Study Reported at XP2002 by Jim Johnson, Chairman
- 6. 6 Agile Accelerates ValueDelivery: Incremental and Iterative 4 444 : Documents Documents Unverified Code Software
- 7. 7 Transparency: Do AgilePractitioners listen to the Business? VersionOne: 7th Annual State of Agile Development 2013 0% 20% 40% 60% 80% 100% Manage distribute teams Increase engineering discipline Simplify dev process Improve team morale Reduce risk Enhance maintainability Reduce cost Project visibility Enhance software quality Better Align IT/business Manage changing priorities Accelerate time to market 4 7 10 7 11 8 10 15 17 3 29 30 24 35 42 38 45 39 34 45 50 41 49 43 33 42 37 40 36 39 39 20 26 25 19 22 38 16 11 15 8 14 17 10 7 11 3 5 Highest Very Somewhat Not
- 8. 8 What is Agile?– Squishy to Solid
- 9. 9 Mindset Agile is amindset Learn through Discovery Collaboration Failing Early Seeking Feedback for learning Strive for Continuous Delivery Focus on Value A mindset is the established set of attitudes held by someone
- 10. 10 Values Mindset Agile is amindset defined by values: Agile Manifesto A Value is an established ideal that the members of a given society regard as desirable Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
- 11. 11 Principles Values Mindset Agile is amindset defined by values guided by principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- 12. 12 Practices Principles Values Mindset … and manifestedthrough many different practices “We surveyed the Agile Community and came up with Over 70 Different Practices” Ahmed Sidky, Santeon Group Practices
- 13. 13 Practices Principles Values Mindset The various Agileflavors are combinations of practices Practices
- 14. 14 The Universes ofMethodologies and Standards
- 15. 15 We’re used toAgile Expects Time Lines Define Done, Build Quality in Top Down Control/ Hierarchical Servant Leadership/Self managing teams. Fixed Budgets Fixed Burn Rate Predictable, all at once deliverables Incremental deliverables driven by value Multiple matrixed departments, part time commitment of resources Co-location – one team. Communication by Document Just enough documentation to start conversation Customer is “managed” Customer is part of team. Certain Knowledge Uncertainty solved by “IKIWISI” Estimates and Actuals Empirical Results, Cone of Uncertainty The Paradigm Shift from Waterfall
- 16. 16 There are ManyPopular Flavors …… Agile Principles Scrum SAFe XP DSDM Crystal Kanban (Lean) Flavor Characteristics Scrum “Reference Implementation” of Agile. Release, iteration and daily planning; prioritized backlog, demos, retrospectives, generalizing specialists. Time boxed Kanban Focus of understanding how work flows, visualizing the work. Limit WIP. Often outside of SW. SAFe: Agile @ Scale Handles integrating multiples teams with program and portfolio layers Extreme Programming (XP) Technical focus on development practices. Prescribes practices that are commonly needed to make Scrum deliver high quality. Time Boxed.
- 17. 17 …. In theend it’s about the People …..
- 18. 18 • New(ish) roleintroduced by Agile. • NOT the same as or a replacement of the Project Manager. • Focus on relationships, listening, fac ilitating. • The Agile SME • Team facing not product facing! About the Agile Coach
- 19. 19 An agile coach… Coordinatingindividual contributions Coaching for collaboration Being a subject matter expert Being a facilitator for the team Being invested in specific outcomes Being invested in overall performance Knowing the answer Asking the team for the answer Directing Letting the team find their own way Driving Guiding
- 20.
- 21. 21 Team Members Developer [2-4] Tester[1-2] Agile BA for larger teams and Scaled Agile Tech Lead especially for more developers Technical Writer [Optional] Specialist roles main join, FE Dev, DBA etc. Different Sized Teams will benefit from different practices and Agile Flavors • Small 1-4 • Medium 5-8 • Large > 10
- 22. 22 Agile @ Scale:Beyond Team Delivery Models Agile Enterprise Scaled Delivery Teams Agile Delivery Teams Scaling Considerations Enterprise: • Team size • Geographic distribution • Regulatory compliance • Domain complexity • Organization distribution • Technical complexity • Organizational complexity • Enterprise discipline Scaled Teams: • Handoffs/Integration • Incoming and Outgoing process contracts • Consistency Team delivery: • Maturity • Construction of working software; various delivery models Software Project Management practices focused on delivering working, tested code every 2 – 4 weeks; Highly incremental delivery practices designed to improve code quality; Program-level alignment to a common, larger mission. Synchronizing planning, development, int egration, delivery and customer feedback A set of Lean leadership principles, that include respect for people, continuous improvement, product development flow and executive sponsorship for a Lean Agile operating mode
- 23. 23 Pomodoro 1 isover! 5 mins at the end of the first time box Questions? Get and move to another seat!
- 24. 24 Pomodoro 2: ADay/Week/Month in the life of an Agile Team What is the most important part of this go cart? – The brakes, they let you go faster Scrum uses time-boxed “breaks” Kanban uses Work in Progress “breaks” Agile @ Scale: A peak at the bigger picture
- 25. 25 Scrum prescribes roles,artifacts and meetings
- 26. 26 Scrums aims tohave a repeatable cadence to delivery
- 27. 27 Scrum Cadence Every Release:The process begins with the product owner collecting and prioritizing requirements in a product backlog. Every Sprint Beginning: Sprint Planning - The team and product owner work together to select the highest priority requirements/ stories that can be accomplished within a time boxed sprint. Every Day: The ScrumMaster and the team have a daily scrum meeting. Every Sprint End: The team demonstrates the completed features to the product owner. • These features are a potential shippable product. • The feedback gathered from the demonstration is fed back into the product backlog. • The team then has a retrospective to determine what worked well, and what improvements need to be made to the process for the next sprint.
- 28. 28 What is aStory Combination of • Requirements that combined provide a standalone shippable feature • Visuals to support the knowledge transfer • Acceptance criteria: Definition of done to drive developer and guide testers • Small enough to fit in a sprint and be estimable using tasks
- 29. 29 Sprint Planning wherestories become tasks Planning Units Ideal hours or days There are other units, but these two are the most common Purpose of Estimates Not for tracking time Scrum is results oriented, not effort driven Sprint Rules No changes during No change to sprint duration Team takes work until they’re full Velocity How much work the team actually accomplishes in a sprint
- 30. 30 Scrum board =Information Radiator for the Team • The board Informs • Highlights impediments • Burndown shows progress • Focus of daily meeting • Swimlanes per story • Done means shippable!
- 31. 31 Scrum: The daystarts with a daily meeting 15 minutes or less Same time, same place – the board Starts on time regardless with no role calls 3 questions What I did since the last standup What I will do before the next standup What’s in my way Yes, that’s it. That’s all. No more, no less. It’s a commitment meeting, not a status meeting.
- 32. 32 Sprint: Demo andRetrospect on the events of the Sprint Preparation • As little as possible • Low tech, high impact • No PowerPoint – this is not about slide ware, this is about showing real stuff
- 33. 33 Scrums can belinked for larger releases Release 1 Sprint 1 Sprint Planning Daily Standup Retro and Demo Sprint n Sprint Planning Daily Standup Retro and Demo Ideas Product Backlog Release Planning Release Backlog Sprint Backlog Fixed Time and Resource Not Done Sprint Backlog Not Done
- 34. 34 Lean and Kanban:First in factories, now front offices Toyota Production System TQM TOC Just-In-Time Six Sigma Lean Healthcare Lean Manufacturing Lean Marketing Lean Construction 60’s-80’s 80’s 90’s 2000’s Today Focus is on the system: rapid flow and feedback, versus planning and “efficiency” Enterprise Kanban
- 35. 35 Kanban in factoriesallowed decentralized decision making Set priorities, not schedules Enterprise Kanban Kanban is Japanese for visual card
- 36. 36 The Kanban Methodfor Software 1. Visualize the workflow 2. Limit Work-in-Progress 3. Manage Flow 4. Make Process Policies Explicit 5. Improve Collaboratively using models and the scientific method
- 37. 37 Kanban does notprescribe roles, artifacts and meetings Start with current process and focus on improvement Focus on reducing cycle time in the system Improvements are done “real-time” rather than waiting for retrospectives Metrics are different reflective continuous flow
- 38. 38 For knowledge workers,Kanban = Post-ItTM Notes Visualizing work provides immediate insight into flow (or not) bottlenecks
- 39. 39 Kanban works welloutside of IT But sticky notes don’t scale, work for distributed teams, or track metrics
- 40. 40 Electronic systems supportbroader view Enterprise Kanban
- 41. 41 Cumulative flow diagramsreplace burndowns Not based on estimates or percent complete – just card moves Enterprise Kanban
- 42. 42 Electronic Kanban boardsfor distributed visualization Enterprise Kanban
- 43. 43 Project A ProjectB Project C Project Z Infrastructure QADevelopment Multi-level Kanban Supports Scaling Enterprise Portfolio Cards: Vertical Lanes: Swimlanes: For: Key Projects Quarters Lines of Business CIO & Peers Project Breakdown Cards: Vertical Lanes: Swimlanes: For: Deliverables Months Functions Project Leads Departments Operations or User Stories Process Team Members Cards: Swimlanes: For: Road Map Source Control Change Mgmt Test Planning API Integration Link to multiple systems Enterprise Kanban
- 44. 44 SAFe Roots Lean Thinking Product DevelopmentFlow Agile Development Field experience at enterprise scale Iterative and Incremental Development Core Values: 1. Alignment 2. Code Quality 3. Program Execution 4. Transparency
- 45. 45 SAFe : Multiplelayers need to interoperate
- 46. 46 Agile Teams actas foundations of productivity • Empowered, self-organizing, self-managing teams with developers, testers, content authority • Teams deliver valuable, fully-tested software increments every two weeks • Teams apply Scrum and Kanban project management practices and XP technical practices • Teams operate under program vision, system, architecture and User experience guidance
- 47. 47 Focus: Strategic Alignment.Code Quality. Collective Ownership Test-First: TDD ATDD Emergent Design Scalability Required Agile Analysis Continuous Integration XP Inspired User Stories SAFe Scrum XP Inspired Technical Practices Strategic Alignment Sprint and PSI/Program objectives Aligned sprints and velocities Program architecture and UX Guidance, governance Lean prioritization Code Quality Test First: TDD and ATDD Continuous integration: component and system Test automation Fortnightly system demonstration
- 48. 48 Focus: Program Execution.Transparency. Program Execution Economic prioritization Frequent, evaluable, quality deliveries Fast customer feedback Fixed, reliable cadence Fast tracking to actual needs Transparency All backlogs and progress visible to all stakeholders Objective reporting based on working code Everyone understands capacity, velocity, WIP
- 49. 49 Scale to theProgram Level A self-organizing, self-managing team-of-agile-teams committed to continuous value delivery Organized around enterprise value streams Aligned to a common mission Delivers fully tested, system-level solutions every 8-12 weeks Common sprint lengths and normalized velocity Face-to-face planning cadence provides development collaboration, alignment, synchronization, evaluation
- 50. 50 Develop on Cadence.Deliver on Demand. Deliver on Demand Develop on Cadence Customer Upgrade Customer preview Docs and certs QA-Release to Market- Governance Firewall Major Release Docs and certs Feature Release Major Release PSI PSI PSI PSI PSIPSI
- 51. 51 Scale to thePortfolio • Lean principles emphasize sustainably fastest value delivery • Portfolio vision guides investments and the enterprise architecture needed to support customer and business needs • Business epic kanban system provides visibility and work-in-process limits to support continuous product development flow • Enterprise architecture is a first class citizen; architectural epics are developed and maintained in a kanban system • Objective metrics support governance and kaizen
- 52. 52 This session willrun more like a Kanban team and can be used as a retrospective technique: 1. Creates 5 ideas for questions using 5 mins of the Crawford Slip Method 2. Get with a Business Unit and figure out the groups favorite 5 questions 3. Post to the backlog 4. Vote with Green dots 5. We will flow questions based on highest priority 6. We will answer each question given it 5 mins 7. If it needs > 5 mins we will ask the team “Enough or another 5” 8. Time Left? Yes - goto 5 9. No – You are released! Lean Coffee Session
- 53. 53 Certification Opportunities (beyondinitial training) • Supports both client engagements and internal resources/teams • Certified Scrum Professional • Certified Agile Coach • Certified Agile Trainer ICF Agile/Lean Community • Connect internal pockets of Agile/Lean enthusiasts across ICF and Ironworks • Create avenues for idea sharing • Promote Agile/Lean practices and training • Coaching internal key Agile roles Local Agile/Lean Communities • Engage and support local communities (Agile Richmond, Capital Kanban, LeanStartUP…) Community Evolvement
Editor's Notes
- #4 When you look at the history of the adoption of innovation the length of time available for planning and execution was a lot longer then software
- #7 Question: After the second sprint, what does the business have under waterfall? Under Agile? After Sprint four? Sprint six?
- #11 We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:[Left over right]That is, while there is value in the items onthe right, we value the items on the left more.
- #13 We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:[Left over right]That is, while there is value in the items onthe right, we value the items on the left more.
- #14 We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:[Left over right]That is, while there is value in the items onthe right, we value the items on the left more.
- #17 Over the years, many delivery models have been created that in line with core Agile Principles.Each model has its strengths and should be selected in context of the project or product needs, technical domain, enterprise objectives
- #23 Critical to take Agile delivery models in context to other teams and enterprise goals/processes.
- #34 Waterfall planning determines scope first then plans a schedule to fit.Lean / Agile planning develops a regular delivery cadence, breaks work down into the smallest-possible deliverable increments and then makes continuous priority decisions about what makes sense to do next. The non-critical work will somehow never rise to the top.The primary difference between Scrum and Kanban in an iterative sense, is that kanban decouples the planning cycle from the technical release cycle. Stand-ups will still be done daily. Backlog reviews, customer demo’s and retrospectives may still be done bi-weekly or monthly. But product releases will be done as often as engineering practices and customer capacity to accept change will allow.
- #36 In a manufacturing or logistics setting, kanban is used to tell people at a given work station when to do work of certain type based on visual signals sent by other workers in downstream steps of the overall process. For example, a worker on an production line might have a bin of parts that he uses as inputs to his step in the process. Once his parts bin gets to a predetermined level, he will come to a kanban card telling him to order more. He will hang that card up in a visible location. That tells the person who makes those parts to start making more. New parts are made just-in-time because in-process inventory is waste. It takes up space. It consumes processing time unnecessarily. It becomes obsolete.We want to have just enough inventory in the system to buffer against variations in demand
- #37 This is just common sense, seriously:Seeing helps understanding, especially among members of a groupFocusing on fewer things gets more work done in the long run and helps us do a better job on each oneAs managers, we should focus our efforts on ensuring that high quality work flows smoothly through our system – not on micromanaging the individual tasksStoring “the rules” about how work should be done in a process library is a great to be sure they are ignored. Building them into your board so that people are encouraged to do things the right way because the correct steps are mapped as lanes or written next to lanes is much more effective. As rules change, the board should, too.Kanban is a technique for continuous process improvement. You should never stop at your first version. The team should continually review their results and use that learning to update their process/board. And ideally, they should do so with reference to Lean principles and other good management ideas. Every team has context specific needs but there are a lot of great ideas out there.
- #39 On a kanban board, the steps in a team’s process are mapped out as (typically) left-to-right lanes on a whiteboard, wall or window. Marker lines (usually replaced later by tape) separate the lanes. Sticky notes or 3x5 cards represent work items moving through the process flow. Smaller sticky notes (the sort you use to mark where to sign a document) are used to draw attention to specific cards, indicating who’s assigned, specific due dates when truly necessary, priority, blockages, etc.Despite my screenshots, a well designed kanban board uses color to draw attention to cards that matter. For example, you might use green to indicate good cards (those that add value), red to indicate bad cards (work that fixes problems but doesn’t add new value), and yellow to indicate work done to mitigate risks. That’s just an example. The key is draw the eye to the cards that deserve attention by other team members and by management.You don’t have to be able to read the cards on a kanban board to recognize what’s happening. A column that’s jammed full of cards is obviously a bottleneck. Rather than continuing to work on their normal tasks, teams should be trained to “swarm” on the bottleneck – providing whatever help they can to that person or team. At the very least, they should stop piling up work in front of the bottleneck. There’s no value in generating more partially complete work when the system is jammed.
- #40 So far, this could also describe the sort of card wall that many Scrum teams use to manage work during an iteration. A few key things distinguish a kanban board.Scrum card walls are typically limited to To Do, Doing, Done. Kanban boards map out all of the main steps that a team normally takes in doing their work. Unless individual workers do all the work on a story without hand-offs, then even a Scrum sprint is really a mini-waterfall of sequential steps. The kanban board represents this reality.For any given main step in the process (Requirements, Design, Develop, etc.), a kanban board should have at least 2 sub-lanes: one for work that is truly in process and the other as a holding queue. Workers in one step of a process cannot put work into the in process lane for the next step down the line. All they can do is put it in a waiting queue indicating that they are done and that next team can “pull the work” when they are ready.To turn a card wall into a true kanban system like in manufacturing, you have to implement Work-In-Process limits Little’s Law and queuing theory show that any system will slow down dramatically at roughly 60-70% of resource utilization. Trying to maximize resource utilization actually results in drastically less output.Putting explicit limits on WIP (Work in Process) is designed to prevent over-utilization. Limiting WIP tends to measurably increase output and decrease variability.
- #42 Cumulative flow diagram shows where bottlenecks are forming in a process. Think of it as the board turned on its side. Each color represents a lane. The height of the colors represents how many cards were in the lane at a point in time. If one lane is getting taller and the others aren’t, you have a bottleneck.Burn-up analysis allows you to use a team’s work history data to predict whether they can get current workload done a desired end date. The redline is your required productivity trend to hit a target. The yellow line is your actual trend. The green line is what must be done to hit the target. The steeper the green line, the less likely it is that you can recover. The great thing about kanban analytics is that they are based simply on people moving sticky notes. That’s easy for them to do quickly so they actually do it. You get a picture of what’s actually happening rather than an estimate.