Demystify Agile

807 views

Published on

Demystify Agile, is a presentation about agile... it gives bird eye view of agile

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
807
On SlideShare
0
From Embeds
0
Number of Embeds
45
Actions
Shares
0
Downloads
106
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Demystify Agile

  1. 1. Saket Bansal PMP, PMI-ACP , CSM , ITIL V3 Fwww.izenbridge.com 1
  2. 2.  Essence of Agile Overview of Agile Methods (XP, Scrum) Agile and Traditional Development Methodology APM (Agile Project Management Framework) Myths about Agile Agile Planning User Stories Agile Estimation Timeboxing Burn Down / Burn up Charts Kanban Board 2
  3. 3. In the struggle for survival, the fittest win out at the expense of their rivals because they succeed in adapting themselves best to their environment. —Charles Darwin www.izenbridge.com 3
  4. 4.  The United States Department of Defense (DoD) and NASA have used iterative and incremental development (IID) since the 1950s In the 1960s, Evolutionary project management(Evo) was conceptualized by Thomas Gilb. Evo recommends one- to two-week iterations, delivery of product each iteration In 1986, “The New New Product Development Game,” a whitepaper published by Takeuchi and Nonaka Takeuchi and Nonaka discuss the “rugby approach” of dedicated, self-organizing teams www.izenbridge.com 4
  5. 5. “The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.” The New New Product Development Game www.izenbridge.com 5
  6. 6. Source: Wikipedia-Photo taken by Maree Reveley (aka Somerslea) www.izenbridge.com 6
  7. 7.  The 1990s saw a flurry of agile approaches Scrum at Easel Corporation Extreme Programming Clear Crystal IBM’s Rational Unified Process Dynamic Systems Development Method (DSDM) www.izenbridge.com 7
  8. 8. Agile software development is a group of softwaredevelopment methods based on iterative and incrementaldevelopment, where requirements and solutions evolvethrough collaboration between self-organizing, cross-functional teams. It promotes adaptive planning,evolutionary development and delivery, a time-boxed iterativeapproach, and encourages rapid and flexible response tochange. It is a conceptual framework that promotes foreseeninteractions throughout the development cycle www.izenbridge.com 8
  9. 9.  In 2001, a group of 17 “lightweight” methodologists met Including Representative of  eXtreme Programming (XP)  Scrum  DSDM Adaptive Software DevelopmentPhoto taken by Scott Catron  The Salt Lake Valley, The Agile Manifesto was Snowbird, Utah written www.izenbridge.com 9
  10. 10. We are uncovering better ways of developing software by doingit and helping others do it. Through this work we have come tovalue:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more. www.izenbridge.com 10
  11. 11.  Focus on empowered, self-managing teams; Autonomous teams do not need the day-to-day intervention of management Management protects team from outside interference Agile teams are composed of a mix of skills Agile team members are able to step in for each other as necessary www.izenbridge.com 11
  12. 12.  Traditionally we measure progress by the percent complete of the functional milestones  Agile teams provide actual working product as a status report, “product review” Design changes as the system is built, results in outdated documentation Agile teams prefer face-to-face communication over documentation because it is simpler, faster, and more reliable. www.izenbridge.com 12
  13. 13.  Contract negotiation, Identify and define everything and spells out the payment and date specifications Customers become a part of the development process Writing specs down and throwing them over the fence is simply not effective www.izenbridge.com 13
  14. 14.  It’s much easier to respond to change when the organization and the customer share a clear understanding of the project’s status In plan-driven environments, all requirements are specified up front, broken down to the task level and estimated  Agile plans follow more of a rolling wave approach using top- down planning www.izenbridge.com 14
  15. 15. The empirical model of process control provides and exercisescontrol through frequent inspection and adaptation forprocesses that are imperfectly defined andgenerate unpredictable and unrepeatable outputs.  www.izenbridge.com 15
  16. 16. www.izenbridge.com 16
  17. 17.  Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Three pillars uphold every implementation of empirical process control: • Transparency • Inspection • Adaptation www.izenbridge.com 17
  18. 18. Agile Methods www.izenbridge.com 18
  19. 19.  Scrum Team Events • Sprints • Sprint Planning Meeting • Sprint Review Meeting • Daily Scrum • Sprint Review Meeting • Sprint Retrospectives Artifacts • Product Backlog • Sprint Backlog www.izenbridge.com 19
  20. 20. www.izenbridge.com 20
  21. 21.  Simplicity Communication Feedback Courage Respect  www.izenbridge.com 21
  22. 22. www.izenbridge.com 22
  23. 23. Agile Vs. Traditional www.izenbridge.com 23
  24. 24. A project is still a project: • Vision • Life cycle • Requirements • Schedule • Team • Communication mechanisms www.izenbridge.com 24
  25. 25. Agile : Iterative Traditional: Waterfall www.izenbridge.com 25
  26. 26. Waterfall Model Agile Project Life Cycle www.izenbridge.com 26
  27. 27. www.izenbridge.com 27
  28. 28.  Plan as you go  Plan all in advance Feature-breakdown  Work-breakdown structure structure  Functional specs User stories  Gantt chart  Status reports Release plan  Deliver at the end Story boards  Learn at the end Deliver as you go  Follow the plan Learn every iteration  Manage tasks Adapt everything Manage team Agile : Iterative Traditional www.izenbridge.com 28
  29. 29. Agile Project Management Framework www.izenbridge.com 29
  30. 30. Based On Adaptive Software Development (Highsmith 2000). 30 www.izenbridge.com
  31. 31.  Envision: Determine the product vision and project objectives and constraints, the project community, and how the team will work together Speculate: Develop a capability and/or feature-based release plan to deliver on the vision Explore: Plan and deliver running tested stories in a short iteration, constantly seeking to reduce the risk and uncertainty of the project Adapt: Review the delivered results, the current situation, and the team’s performance, and adapt as necessary Close: Conclude the project, pass along key learning, and celebrate. www.izenbridge.com 31
  32. 32.  What is the customer’s product vision? What are the key capabilities required in the product? What are the project’s business objectives? What are the project’s quality objectives? What are the project constraints (scope, schedule, cost)? Who are the right participants to include in the project community? How will the team deliver the product (approach)? www.izenbridge.com 32
  33. 33.  Speculating establishes a target and a direction. Speculating isn’t wild risk-taking but “conjecturing something based on incomplete facts or information.” The Speculate phase spotlights product and project. Produce a refined list of scope items Develop a Release Develop detailed Iteration Plans for the next Iteration www.izenbridge.com 33
  34. 34.  Iteration Planning and Monitoring Technical Practices Project Community www.izenbridge.com 34
  35. 35.  A traditional project manager focuses on following the plan, whereas an agile leader focuses on adapting successfully to inevitable changes Team has to answer critical questions • Is value, in the form of a releasable product, being delivered? • Is the quality goal of building a reliable, adaptable product being met? • Is the project progressing satisfactorily within acceptable constraints? • Is the team adapting effectively to changes imposed by management, customers, or technology? www.izenbridge.com 35
  36. 36. Conduct the Project Closure , Pass along key learning andcelebrate. www.izenbridge.com 36
  37. 37. Myths… www.izenbridge.com 37
  38. 38.  Agile Development is Undisciplined Agile Team do not plan Agile Development is not Predictable Agile Development does not scale Agile means teams cannot be controlled by management  Agile means I can change my mind whenever I want to Agile means you never have to write documentation www.izenbridge.com 38
  39. 39. Agile Planning www.izenbridge.com 39
  40. 40. “Planning is everything. Plans are nothing.” -Field Marshal Helmuth Graf von Moltke www.izenbridge.com 40
  41. 41. If estimating and planning are difficult, and if it’s impossible toget an accurate estimate until so late in a project, why do it atall? www.izenbridge.com 41
  42. 42.  Reducing risk Reducing uncertainty Supporting better decision making Establishing trust Conveying information www.izenbridge.com 42
  43. 43.  Is focused more on the planning than on the plan Encourages change Results in plans that are easily changed Is spread throughout the project www.izenbridge.com 43
  44. 44. “No plan survives contact with the enemy.” -Field Marshal Helmuth Graf von Moltke www.izenbridge.com 44
  45. 45.  Nearly two-thirds of projects significantly overrun their cost estimates (Lederer and Prasad 1992) Sixty-four percent of the features included in products are rarely or never used (Johnson 2002) The average project exceeds its schedule by 100% (Standish 2001) www.izenbridge.com 45
  46. 46.  Planning is by activity rather than feature Features not prioritized We ignore uncertainty Estimates become commitments www.izenbridge.com 46
  47. 47. “A good plan violently executed now is better than a perfect planexecuted next week.” -General George S. Patton www.izenbridge.com 47
  48. 48.  Work as one team Work in short iterations Deliver something each iteration Focus on business priorities Inspect and adapt www.izenbridge.com 48
  49. 49. Most Agile teams are concernedonly with the three innermostlevels Release Planning Iteration Planning Day Planning www.izenbridge.com 49
  50. 50. User Stories www.izenbridge.com 50
  51. 51. A user story describes functionality that will be valuable toeither a user or purchaser of a system or software. www.izenbridge.com 51
  52. 52. Card: Stories are traditionally written on note cards. Card may be annotated with Notes , Estimates etc,Conversation: Details behind the story come out during conversations with product owner.Confirmation: Acceptance tests confirms a story was coded correctly www.izenbridge.com 52
  53. 53. Epic , Is a large User StoryTheme : A Collection of RelatedUser Stories www.izenbridge.com 53
  54. 54.  Independent Negotiable Valuable to users or customers Estimatable Small Testable www.izenbridge.com 54
  55. 55.  Start with a Goal story Monster.com Users Goal Is : Find a Job • Search for jobs based on skill ,location , salary , Company • Display resume to the Recruiters so that Recruiters can search • Easily apply for job www.izenbridge.com 55
  56. 56.  “A Job Seeker can post a resume” Technical Division • A Job Seeker can fill out a resume form. • Information on a resume form is written to the database. Slice the Cake • A Job Seeker can submit a resume that includes only basic information such as name, address, education history. • A Job Seeker can submit a resume that includes all information an employer may want to see. www.izenbridge.com 56
  57. 57.  “A recruiter can manage the ads she has placed.” A recruiter can review resumes from applicants to one of her ads. A recruiter can change the expiration date of an ad. A recruiter can delete an application that is not a good match for a job. www.izenbridge.com 57
  58. 58. Agile Estimation www.izenbridge.com 58
  59. 59.  Commonly used estimation units among agile team Based on size and complexity of work Unit-less but numerically relevant estimate www.izenbridge.com 59
  60. 60.  Apple Orange Pears Melon Banana Grapes Strawberry www.izenbridge.com 60
  61. 61.  Forces the use of Relative estimating It’s a Size estimation Puts estimation in Unit which we can add together www.izenbridge.com 61
  62. 62.  Velocity is a measure of a team’s rate of progress. Calculated by summing up all story points assigned to user story that the team completed during iteration www.izenbridge.com 62
  63. 63.  The story being estimated is the only thing you’ll work on. Everything you need will be on hand when you start. There will be no interruptions. www.izenbridge.com 63
  64. 64.  Supporting the current release Sick time Meetings Demonstrations Personnel issues Phone calls Special projects Training Email Reviews and walk-throughs Interviewing candidates Task switching www.izenbridge.com 64
  65. 65.  1, 2, 3, 5, and 8 1, 2, 4, and 8 Epic / theme • 13, 20, 40, and 100 www.izenbridge.com 65
  66. 66.  Expert opinion Analogy Disaggregation www.izenbridge.com 66
  67. 67.  Each estimator is given a deck of cards, each card has a valid estimate written on it Customer/Product owner reads a story and it’s discussed briefly Each estimator selects a card that’s his or her estimate Cards are turned over so all can see them Discuss differences (especially outliers) Re-estimate until estimates converge www.izenbridge.com 67
  68. 68. Timeboxing www.izenbridge.com 68
  69. 69.  Timeboxing is setting a fixed time limit to overall development effort and let other characteristics such as scope vary. Timeboxing Examples • Iterations • Daily Standups www.izenbridge.com 69
  70. 70.  Focus Increased Productivity Realization of Time Spent Time Available www.izenbridge.com 70
  71. 71. Burndown /Burnup Charts www.izenbridge.com 71
  72. 72.  Release burndown chart  The vertical axis shows the number of story points remaining in the project. Iterations are shown across the horizontal axis. A release burndown chart shows the amount of work remaining at the start of each iteration. www.izenbridge.com 72
  73. 73. www.izenbridge.com 73
  74. 74. www.izenbridge.com 74
  75. 75.  It’s a concept related to Lean and Just In Time (JIT) production Kanban Boards shows current status of all the tasks need to be done in current iteration, the tasks are represented by cards, and the stauses are presented by area on the baord separated and labeled. Kanban boards helps the team in knowing how they are doing and what to do next. www.izenbridge.com 75
  76. 76. www.izenbridge.com 76
  77. 77. Saket BansalSaket.Bansal@iZenBridge.comM: 9910802561Web: www.iZenBridge.comLinkedIn: www.linkedin.com/in/saketbansal www.izenbridge.com 77

×