Agile project management

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)


Learn Agile Software development in one hour by Bhawani Nandan Prasad

Transcript of Agile project management

  • 1. Agile Software Development Bhawani Nandan Prasad

2. Objectives Agile Development Basics Traditional methods Iterative development Benefits of iterative development Different flavors of Agile Managing Agile projects Self-organization and self-management Tracking Agile projects (without micro-managing) PMBOK and Agile Q&A 3. Problems Companies Face Excessively long time to market for products Customer orientation is lacking Over-engineered products (~60% features on a product are never used!) Cost of delivering software is too high Poor productivity of teams Too much wasted work to fix defects and rework designs Software quality is poor Ability to responding to change is low Employee morale is low (and attrition rates are high!) Project failure rate is too high (~70% or more) RoI delivered falls short of expectations 4. Traditional Software Development Design Coding Testing DeployAdvantage: Logically sound Disadvantage: Assumes predictability! Analysis 5. The answer Iterative development, done in small incremental chunks, validating requirements at each step Agile development evolved in mid-90s the word Agile was adopted in 2001 Various flavors of Agile development include Scrum (the most popular) Extreme Programming (or XP) Crystal Clear Adaptive software development Feature driven software development Dynamic Systems Development Method (DSDM); etc. Has significant parallels with Lean movement in the manufacturing world, though they are not necessarily analogous 6. Providing early value Value Realized Time Incremental delivery All-at-once Delivery 7. Agile Manifesto Feb 2001 We are 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 negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas 8. 12 Principles of Agile 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. 9. 12 Principles of Agile (continued) 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. 10. 12 Principles of Agile (continued) 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. 11. 12 Principles of Agile (continued) 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. Characteristics of Agile Process 1. Modularity 2. Iterative 3. Time-Bound 4. Parsimony - minimal number of activities necessary to mitigate risks and achieve their goals 5. Adaptive 6. Incremental 7. Convergent - actively attacking all of the risks 8. People-Oriented 9. Collaborative 13. Scrum Basics 14. Product Owner Responsible for managing Project RoI and risk Responsible for consolidating all inputs into what the team should produce and turn it into a prioritized backlog Participate actively in the sprint planning and sprint review meetings and is available to the team throughout the sprint Determines release plan and communicates to everybody 15. The Team 16. The team! Ideally 7 people + or 2 Has worked with as high as 15 and as small as 3 Team can be change between Sprints (better not to) Can be distributed (better results when co-located) Cross-functional Posses all the skills necessary to produce an increment of potentially shippable product Self Managing Empowered to do whatever is necessary to produce the potentially shippable product, within the constraints of the organizations standards. 17. Scrum Master! 18. Scrum Master! Scrum Master helps the team achieve success using Scrum by Serving the team Facilitate the teams group interaction to help the team achieve its full potential Helps to remove blocks that are surfaced by the team Protecting the team Protects team from outside interference or disruption Supporting the teams use of Scrum Organizes and facilitates Scrum related practices Reminds the team Scrum standards 19. Product backlog 20. Product backlog List of everything that could ever be of value to the business for the team to produce. Ranked in order of priority Priority is a function of business value and risk Product owner can make any changes they want before start of a Sprint / Sprint Planning meeting It can be addition of new items, changing or removing or existing items or re-ordering them Ideally for 2 sprints items should be well defined 21. Example of product backlog 22. Sprint planning meeting 23. Sprint planning meeting Goal: For the team to make good commitment around what it will deliver by the end of the Sprint Whats a Good Commitment? Clearly understood by all Shared among team Achievable without sacrificing quality Achievable without sacrificing sustainable pace Attended by Team, Product owner, Scrum Master Usually take 1-2 Hrs for each week of Sprint duration 24. Sprint calendar 2 week iterations 25. Sprint backlog 26. No changes during a sprint! Once team has committed no changes No changes to deliverables Details will emerge during Sprint, but no new work or substantially changed work Product Owner can terminate the Sprint if necessary No Changes to Sprint Duration Sprint ends on planned date whether has completed its commitment or not However Product Owner can make the changes to the remaining Product backlog before the start of the next Sprint 27. Daily standup meeting 28. Daily standup meetings Every weekday Whole team attends (including QA) Everyone stands 15 minutes or less Everyone reports three things What was able to accomplish since last meeting What will try to accomplish since by next meeting What is blocking me No discussion, conversation until end of meeting Update of artifacts after standup 29. Closing a sprint 30. Sprint review Purpose of Sprint Review Demo (not power point presentation) what the team has built Generate feedback which Product Owner can incorporate in the product backlog Attended by Product Owner, Managers, Scrum Master and Team Usually lasts 2 Hrs Followed by Sprint Retrospectives 31. Sprint retrospective What it is? 1-2 Hr meeting followed by each Sprint Review/Demo Attended by Product Owner, Scrum Master, Team Whats working and what could work better Why does Retrospective matter Accelerate visibility Accelerate actions to improve Its a key mechanism of continuous improvements (Inspect & Adopt) 32. Advantages of Agile Development Customer is able to see value much faster Near releasable product every 2 weeks! Reduces waste by continuously validating the output Forces orderly management of changes during the life-cycle 33. Disadvantages of Agile development Scrum doesnt fix anything, team has to do it May feel like things are worse at the beginning due to Scrum makes all dysfunction visible Bad product will be delivered sooner Some team or Organization are not ready for it Team willingness is important Managements active support is important Inevitably some people will get fed up and leave Partial adoption is worse than none 34. Agile or Waterfall? If Waterfall is working for you, dont use Scrum! Ken Schwaber See link: http://leadinganswe rs.typepad. com/leading_ answers/files/ agile_suitabilit y_filters. pdf 35. Engineering best-practices Teams need to be prepared to work with minimal specifications Test-driven development Continuous integration: Automated builds and tests Highly functional, motivated teams are needed Ability to work in cross-functional teams is critical 36. Managing Agile projects Note that Scrum does NOT talk about a role for Manager or Project Manager. So what do Managers do on Scrum projects? A project manager or coordinator operating in a matrix environment can be trained to morph into a Scrum Master Line managers (who have reporting authority) should Be the Functional and/or Technical expert Help the team understand the larger context of the project Protect the team during prioritization battles Foster the right culture in the team Act as a mentor or a coach to the team Represent the team at external forums Be risk managers for the projects 37. Release Planning Though Sprint contents can change, there often needs to be a long- term roadmap for software projects evolved during release planning sessions What should happen during a release planning? Prepare of a release roadmap with epics defined at high level High-level guesstimate of what and how much can be accomplished in a release Identify project dependencies on external factors or