Agile 101
•Download as PPTX, PDF•
30 likes•29,486 views
Learn the basics of the agile way-of-life that has helped many companies realize their potential in the market. The agile secret sauce was once a thing that was only enjoyed by software organizations on the East and West coasts, but is now invading Indianapolis -- increasing productivity, making teams empowered (and happier!), and helping managers focus less on the taskmaster role and more on the important stuff.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Agile 101
Similar to Agile 101 (20)
Recently uploaded
Recently uploaded (20)
Agile 101
- 1. © 2015 beLithe, Inc.
- 2. We are driven by helping teams and individuals be the best they can be. We do this through introducing and living agile, people focused practices.
- 3. Chris Daily Experiences across multiple industries focused in Agile Transformations and Software Development. Led teams in start- ups to Fortune 500 companies. Tana Linback Background focused on the people and organizational culture that are the foundation of business and Agility. Unique combination of work in software development and human resources leadership.
- 4. Agile 101
- 5. © 2015 beLithe, Inc. Agenda AGILE INTRO LEARNING OBJECTIVES • Pre-agile waterfall methodology basics • What agile is and is not • Benefits of employing agile practices • Next steps to continue exploring the agile way Waterfall Basics Agile Overview Agile Manifesto & Values 01 02 Agile Principles Common Misconceptions Characteristics of Agile Practices Three Agile Components03 Agile Journey04
- 6. Waterfall A traditional approach to project management.
- 7. © 2015 beLithe, Inc. Project Management 101 Project Planned program of work that requires a definitive amount of time, effort and planning to complete. Processes used to complete a project. Individual who plans and directs the work required to complete a project. Individuals that do the work to deliver on project deliverables. Project Manager Project Management Project Team
- 8. © 2015 beLithe, Inc. History of Waterfall Project Management Project management processes were developed based on step-by-step manufacturing models the United States military used during World War II. Waterfall process developed from highly structured physical environments where after- the-fact changes are prohibitively costly, if not impossible. PhotoCourtesyofflintgm100.com PhotoCourtesyofthwapschoolyard.com
- 9. © 2015 beLithe, Inc. Requirements: Gathering the list of product features desired from a project. Requirements Design Development Testing Deployment In the waterfall method to managing projects, you complete work in stages. You do not move to another stage until you have completed the work in the previous stage. STAGES DEFINED Development: The stage where product features are created. Design: The stage where an outline or plan is made for creating individual product features. Testing: The stage where the developed product features are ensured to work. Deployment: The final stage of a project where completed product features are moved to a state where they can be used.
- 10. © 2015 beLithe, Inc. Waterfall Project Stats Successful Challenged Failed 14% 57% 29% The Standish Group defines project success as on time, on budget, and with all planned features. They do not report how many projects are in their database but say that the results are from projects conducted from 2002 through 2010. - Mike Cohn, Mountain Goat Software on the CHAOS Manifesto 2012 Report
- 11. © 2015 beLithe, Inc. Impaired Project Issues Standish Group, 2012 Chaos Report 13% 12% 10% 9% 9% 8% 8% 7% Incomplete Requirements 20% 15% 10% 0% 5% Lack of User Involvement Lack of Resources Unrealistic Expectations Lack of Executive Support Challenging Requirements & Specs Didn’t Need It Any Longer Lack of Planning
- 12. © 2015 beLithe, Inc. Start to Finish Issues with Waterfall • Must have all requirements up front • Estimation is complex • Must understand capabilities of all involved Start Must resist change or document change requests (which extends schedule and budget) Team must create and maintain volumes of documentation Customers or stakeholders may not be available for questions Finish • Final testing • Must wait for full and complete user feedback • Value not achieved until end
- 13. Insanity: doing the same thing over and over and expecting different results. - Albert Einstein
- 14. © 2015 beLithe, Inc. Agile Manifesto
- 15. © 2015 beLithe, Inc. Agile Manifesto: Statement of Values Individuals and Interactions OVER PROCESS AND TOOLS Working Software OVER COMPREHENSIVE DOCUMENTATION Customer Collaboration OVER CONTRACT NEGOTIATION Responding to Change OVER FOLLOWING A PLAN
- 16. © 2015 beLithe, Inc. 12 Guiding Agile Principles Customer Satisfactio n Quality Team- work Project Mgmt Customer satisfaction by rapid delivery of useful software P P Welcome changing requirements, even late in development P P Working software is delivered frequently (weeks rather than months) P P Working software is the primary measure of progress P Sustainable development, able to maintain a constant pace P P P Close, daily co-operation between business people and developers P P P Face-to-face conversation is the best form of communication P P Projects are built around motivated individuals, who should be trusted P Continuous attention to technical excellence and good design P Simplicity – the art of maximizing the amount of work not done P Self-organizing teams P Team regularly reflects on how to become more effective, then adjusts P P
- 17. © 2015 beLithe, Inc.
- 18. © 2015 beLithe, Inc. Agile = entity that possesses agility Agility or nimbleness is the ability to change the body’s position efficiently. Requires the integration of isolation skills using... Textbook Definition Speed Strength EnduranceBalance Coordination Reflexes
- 19. © 2015 beLithe, Inc. Agile is a mindset. What is Agile, Really?
- 20. © 2015 beLithe, Inc. Common Misconceptions No more planning No more QA Change req’s whenever Agile isn’t disciplined Agile = Scrum No more design No more docu- mentation Agile doesn’t scale Allows you to go faster
- 21. © 2015 beLithe, Inc. Agile scrum Crystal XP Kanban RUP FDD and a few more… CI
- 22. © 2015 beLithe, Inc. More Prescriptive more rules to follow More Adaptive fewer rules to follow RUP XP scrum Kanban Do whatever! 120 13 9 3 0 The Sweet Spot Prescriptive vs. Adaptive
- 23. © 2015 beLithe, Inc. Agile Fail early, fail often Emergent feature discovery Deliver working software Value driven development Fixed- length iterations Self- organized teams Multi-level planning (release/epic /story) Amplify learning Deciding as late as possible Building integrity in Eliminate waste Delivering as fast as possible Empowering the team See the whole AGIL ELEAN Agile vs. Lean
- 24. © 2015 beLithe, Inc. Sequential vs. Overlapping Work Requirements Design Code Test 4 weeks 4 weeks 4 weeks 4 weeks Time
- 25. © 2015 beLithe, Inc. Iterative Work Potential Change Potential Change Potential Change Potential Change Potential Change Potential Change Potential Change 2 Years – No Change 2 Week Increments
- 26. © 2015 beLithe, Inc. DOACT CHECK PLAN PDCA William Edwards Deming“Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place”
- 27. Team regularly reflects on how to become more effective, then adjusts.
- 28. Agile Components
- 29. © 2015 beLithe, Inc. • Adaptive software development (ASD) • Agile modeling • Agile Unified Process (AUP) • Business analyst designer method (BADM) • Crystal Clear Methods • Disciplined agile delivery • Dynamic systems development method (DSDM) • Extreme programming (XP) • Feature-driven development (FDD) • Lean software development • Kanban (development) • Scrum • Scrumban • Spiral • Iterative Agile Component: Framework Definition of Framework A framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful.
- 30. © 2015 beLithe, Inc. Framework Example: Scrum Framework
- 31. © 2015 beLithe, Inc. • XP • User Story • CI/CD • User Story Mapping • FDD • ATDD • TDD • Agile Modeling • Emergent Design • RUP • Agile modeling • Backlogs (Product and Sprint) • Behavior-driven development (BDD) • Cross-functional team • Continuous integration (CI) • Domain-driven design (DDD) • Information radiators (scrum board, task board, visual management board, burndown chart) Agile Component: Practice Definition of Practice A practice is a repeated exercise in or performance of an activity or skill so as to acquire or maintain proficiency in it. • Iterative and incremental development (IID) • Pair programming • Planning poker • Refactoring • Scrum events (sprint planning, daily scrum, sprint review • and retrospective) • Test-driven development (TDD) • Agile testing • Timeboxing • Use case • User story • Story-driven modeling • Retrospective • Velocity tracking • User Story Mapping
- 32. © 2015 beLithe, Inc. Practice Example: User Stories 32
- 33. © 2015 beLithe, Inc. • Scaled agile framework (SAFe) • Disciplined Agile Delivery (DAD) • Large-Scale Scrum (LeSS) • Nexus (scaled professional Scrum) • Scrum at Scale • Enterprise Scrum • Setchu (Scrum-based lightweight framework) Agile Component: @Scale Definition of @Scale Scaling agile to the enterprise level, typically with five or more interconnected teams.
- 34. © 2015 beLithe, Inc. Common Agile Misconceptions Revisited Constantly planning Test as work is ready Prioritized Req’s Disciplined approach to practices Many agile approaches (hybrid) No more planning No more QA Change req’s whenever Agile isn’t disciplined Agile = Scrum No more design No more docu- mentation Agile doesn’t scale Allows you to go faster Emergent design Bare minimum Divide and conquer Sooner, not faster
- 35. © 2015 beLithe, Inc. Agile Journey 1 2 3 4 Create backlogs, roadmaps, and agile teams Technical practices, release planning, and metrics Refactoring, CI, and DevOps Lean Startup 05 Steps Practicing what we preach 5 Team projects, ad. gov., software cap. Source: http://www.leadingagile.com/the-journey/
- 36. www.beLithe.com
Editor's Notes
- **Review Statement
- **Review Statement
- The Statement of Values from the Agile Manifesto is often misunderstood. I’ve highlighted the word
- Five Myths of Agile Development Source: http://blogs.versionone.com/agile_management/ Myth #1: Agile Development is Undisciplined Interestingly, most of the practices associated with agile development have been around for decades. It is only more recently that the practices have been packaged together as collections of interdependent practices. These practices, whether incorporated within Extreme Programming, Scrum, Feature-Driven Development, or any other agile methodology, really help define the innovation which has taken place. Myth #2 – Agile Teams Do Not Plan This misconception generally relates to a lack of understanding of an agile, or incremental, planning approach. Most agile teams spend as much, if not more, time planning their projects. Myth #3 – Agile is Not Predictable Agile development replaces detailed, speculative plans with high-level, feature-driven plans that acknowledge the inherent complexity and uncertainty of software development projects. Ongoing reconciliation of actual effort to original plans is replaced with incremental planning and re-planning at a more granular level throughout the development process. Myth #4 – Agile Does Not Scale Over the last decade, enough agile projects involving hundreds of people have been performed by multiple teams, in multiple locations, across multiple time zones to have a high degree of confidence in the ability of agile development to scale.
- The Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints. The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress. And because a team’s work cycle is limited to two to four weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world.
- In essence, it could be said that the agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace. In the end, a development agile methodology that preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released, is an attractive option for stakeholders and developers alike.
- ***ALLOWS YOU TO GO FASTER?
- William Edwards Deming (October 14, 1900 – December 20, 1993) was an American statistician, professor, author, lecturer and consultant. He is perhaps best known for his work in Japan. There, from 1950 onward, he taught top management how to improve design (and thus service), product quality, testing and sales (the last through global markets)[1] through various methods, including the application of statistical methods. Deming is probably most famous for the Deming Cycle, which has lives on in most business sites in America in some form. Kind of looks like Scrum, right? So how does this apply to Continuous Delivery.
- http://whatis.techtarget.com/definition/framework
- graphic
- https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=definition%20of%20practice
- https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=definition%20of%20practice
- In essence, it could be said that the agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace. In the end, a development agile methodology that preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released, is an attractive option for stakeholders and developers alike.