Introduction to Agile Methods
•Als PPTX, PDF herunterladen•
2 gefällt mir•882 views
Introduction to Agile Methods
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (8)
Ähnlich wie Introduction to Agile Methods
Ähnlich wie Introduction to Agile Methods (20)
Mehr von Richard Cheng
Mehr von Richard Cheng (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Introduction to Agile Methods
- 1. Richard Cheng 2015 Project Management Symposium INTRODUCTION TO AGILE METHODS
- 2. • Agile trainer and coach • Member of PMI, Scrum Alliance, Agile Alliance, Agile Leadership Network • CST, CSM, CSPO, CSP, PMI-ACP, PMP • Founder & executive committee member of Agile Delivery for Agencies, Programs, and Teams (ADAPT) • Experience in Federal and commercial Agile transformations Richard Cheng richard.cheng@excella.com @RichardKCheng
- 3. “Traditional” IT Project Management ◊ Process and tools ◊ Comprehensive documentation ◊ Contract negotiations ◊ Following a plan This is how we control projects….
- 5. IT Industry average success rate? Success rate ~ 33% IT Industry average success rate? Success rate ~ __% Industry Success Rate From 2010 report from The Standish Group
- 6. Problems with Waterfall Requirements Design Develop Test Deploy “I believe in this concept, but the implementation described above is risky and invites failure” – Dr. Winston Royce Managing the Development of Large Software Systems, Winston Royce (1970)
- 7. Agile Manifesto Individuals and interactions over Process and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: That is, while there is value in the items on the right, we value the items on the left more. http://agilemanifesto.org/
- 8. 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. Agile Principles
- 9. Scrum vs. Waterfall ◊ Waterfall is based on Predictability – Feedback is usually not attained until late in the project – Works best when all details are known up front – Change is expensive ◊ Scrum is based on Adaptability – Constant feedback – Allows for discovery throughout the lifecycle – Provides infrastructure to support and implement change
- 10. The Stacey Diagram ◊ Simple projects don’t need Scrum ◊ The Complicated projects benefits from Scrum to increase certainty and agreement ◊ Scrum returns the biggest process gains in the Complex space ◊ In the Anarchy space, there is high risk regardless of method Ralph Stacey, Strategic Management and Organizational Dynamics Technology Requirements
- 11. Agile Methodologies Agile Scrum – Iterative method used by most teams XP – The software engineering practices Kanban – Often used in operations Lean – Concepts used for organizational Agile
- 12. Scrum Overview Product Vision Roadmap Day Sprint… … … Plan Day Day Daily Scrum Review Retro Sprint Plan Review Retro Idea Initiation Release Plan Release Release Plan Plan Time
- 13. Scrum Framework * Diagram from Scrum Primer From the Scrum Primer Product Backlog
- 14. Kanban ◊ Visualize Flow ◊ Limit Work In Progress (WIP) ◊ Measure Workflow ◊ Optimize the Workflow
- 15. Visualize Flow In Queue Development In Progress Done QA Tests In Progress Done Release In Progress Done Item Item Item Item Item Item Item Item Item Item Item Item Item Item Item Item Item Item
- 16. Limit Work In Progress In Queue (5) Development (3) In Progress Done QA Tests (4) In Progress Done Release (5) In Progress Done Item Item Item Item Item Item Item Item Item Item Item Item Item
- 17. Measure Workflow ◊ Average Time In Queue – 3 days ◊ Average Time In Development – 2 days ◊ Average Time Waiting for QA Test – 2 days ◊ Average Time In QA Test – 5 days ◊ Average Time Waiting for Release – 9 days ◊ Average Time in Release – 3 days ◊ Average throughput - 24 days
- 18. Optimize Workflow ◊ Average Time In Queue – 3 days ◊ Average Time In Development – 2 days ◊ Average Time Waiting for QA Test – 2 days ◊ Average Time In QA Test – 5 days ◊ Average Time Waiting for Release – 9 days ◊ Average Time in Release – 3 days ◊ Average throughput - 24 days
- 19. Optimize Workflow In Queue (5) Development (3) In Progress Done QA Tests (4) In Progress Done Release (5) In Progress Done Item Item Item Item Item Item Item Item Item Item Item Item ItemItem
- 20. When to use Kanban ◊ Operational Work – Networking – Help Desk – Pure Operation and Maintenance ◊ When 1 weeks Scrum Sprints are too long ◊ Visualizing and measuring across multiple workflows or teams ◊ If Scrum is not working for you, transitioning to Kanban will usually make things worse (other than the cases above) ◊ Kanban concepts can be applied to Scrum and Waterfall
- 21. Scaled Concepts ◊ Scaled Agile Framework (SAFe) ◊ Large Scaled Scrum (LESS) ◊ Disciplined Agile Delivery (DAD) ◊ Spotify model …
- 22. Scaled Agile Framework™ Big Picture
- 23. LeSS
- 24. Disciplined Agile Delivery (DAD) Disciplined Agile Delivery: The Foundation for Scaling Agile © Disciplined Agile Consortium 24 Scrum LeanKanban XP Agile Modeling And more…SAFeOutside In Dev. Team Size Geographic Distribution Compliance Domain Complexity Technical Complexity Organizational Distribution DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner.
- 26. Excella Consulting Experience and Expertise in Agile Solutions – Coaching – Training – Assessments – Agile Adoption – Agile Development Teams – Agile PMO Training Courses – Certified ScrumMaster (CSM) – Certified Scrum Product Owner (CSPO): The Agile Business Analyst – Advanced Certified Scrum Product Owner (CSPO) – Certified Scrum Developer (CSD) – Agile Testing – Agile Business Intelligence and Data Warehousing – Automated Acceptance Testing – Great for Analysts and Testers!! See http://www.excella.com/training for more information
- 27. Contact Information Richard K Cheng richard.cheng@excella.com 703-967-8620 http://www.excella.com Twitter: @RichardKCheng
Hinweis der Redaktion
- This is what we do today
- Everyone standup >90% sit >80% 50% 30% 20% 10% Stand up on your hands If I’m a baseball player, this is a good stat
- Download paper from wikipedia. Easy ready Iterate through it and get your feedback from customer
- Story of Agile Manifesto:
- Small steps Synchronize Timeboxes Collocation Technical debt Self organize Track stories/feature completion not tasks
- Information radiator – Available info, office with pictures Refrigerator – Open door, dig around
- Information radiator – Available info, office with pictures Refrigerator – Open door, dig around
- Information radiator – Available info, office with pictures Refrigerator – Open door, dig around
- The fundamental observation was that many organizations were struggling with how to scale agile methods, in particular Scrum. We felt that the first step was to identify how to successfully develop a solution from end-to-end. Although mainstream agile methods clearly provided a lot of great strategies, there really wasn’t any sort of glue beyond consultantware (e.g. hire me and I’ll show you how to do it) putting it all together. This is where the DAD framework comes in, but that’s only a start as you also need to tailor your approach to reflect the context in which you find yourself. The DAD framework provides a better foundation for scaling agile: Risk and value driven lifecycle. Scrum has what is called a value driven lifecycle. Work is prioritized by value to the business and is performed in priority order. This is a pretty good approach, but it’s possible to do better. Disciplined agile teams recognize that it’s a pretty good idea to tackle the riskier work early in an endeavor in order to help eliminate some or all of the risk. Some people like to refer to this as an aspect of “failing fast” although we like to put it in terms of succeeding early. A risk-value approach to work prioritization, and better yet explicit risk-based milestones (such as reaching stakeholder agreement early and proving the architecture with working code early), can increase your chance of project success. Self organization with effective governance. There has been much ado made over the strategy of self organizing teams with the agile community and rightfully so as it is an effective strategy. But, agile project teams don’t work in a vacuum but instead work within the scope and constraints of a larger, organizational ecosystem. Instead of optimizing the project part as many agile methods imply that you should do in DAD we recommend that you adopt an effective governance strategy that guides and enables agile teams. Delivery of consumable solutions over construction of working software. There are two issues here, a delivery focus over a construction focus and a solution focus over a software focus. First, disciplined agile teams recognize that there is some up-front project initiation/inception work that occurs early in a project. DAD also recognizes that there is often some deployment/transition effort that occurs towards the end of a project. The end result is that DAD promotes the idea that you need to adopt a full delivery lifecycle, not just a construction-focused lifecycle, if you’re to successfully avoid common mistakes such as a Water-Scrum-Fall approach. Futhermore, because DAD isn’t prescriptive it suggests several versions (agile, lean, continuous delivery) of the lifecycle. Second, agile teams do far more than produce software. We create supporting documentation. The software runs on hardware that may need to be upgraded and/or redeployed. We potentially change the business process around the usage of the system we’re producing. We may even affect changes to the organization structure of the people using the system. In short, it is blatantly obvious that we’re not just producing “potentially shippable software” but instead are producing “potentially shippable solutions”. Moreover, producing something that is just “potentially shippable” isn’t what our stakeholders actually want. What they really desire is something that’s consumable, something that they can easily understand and adopt to help them achieve their goals. The rhetoric “potentially shippable software” plays well to some developers, but it isn’t a sufficient goal. Enterprise awareness over team awareness. We alluded to this in point #2. Disciplined agile teams recognize that they work in a larger organizational ecosystem. This enterprise awareness motivates them to leverage existing assets; enhance existing assets; work closely with enterprise professionals such as enterprise architects, reuse engineers, portfolio managers, and data adminstrators; and produce solutions that reflect the technology and business roadmaps of your organization. Done right this increases a team’s ability to deliver. Context-sensitive and goal driven over prescriptive. One process size does not fit all. A strategy that works for a small co-located team will put a large geographically distributed team at risk. A strategy that works well in a non-regulatory environment may result in people’s deaths in a regulatory one (or more likely fines because hopefully you’ll be caught before you ship). So, if you want to build an effective team you need to be able to select the right strategy for the situation you find yourself in. DAD describes a straightforward, easy to consume strategy that is goal driven