Agile pm and scrum
•Download as PPTX, PDF•
0 likes•560 views
A quick comparison between Agile Project Management based on DSDM Atern and Scrum
Recommended
More Related Content
What's hot
What's hot (10)
Similar to Agile pm and scrum
Similar to Agile pm and scrum (20)
Recently uploaded
Recently uploaded (20)
Agile pm and scrum
- 2. Why do projects fail?
- 4. Waterfall
- 5. Waterfall dilutes the objectives www.bordewijk-training.nl
- 6. Agile is more successful than traditional approaches Source: CHAOS Manifesto 2011, The Standish Group www.bordewijk-training.nl
- 7. B-DUF
- 10. Cowboy Coding
- 12. N-DUF
- 14. Agile
- 15. E-DUF
- 17. Project Variables Process Driven Value Driven www.bordewijk-training.nl
- 18. Agile Drawbacks • Can get out of control (if you break the rules) • Can be difficult to scale • Requires users to fully engage and be disciplined • Requires a ‘no blame’ culture • Can be difficult to estimate costs • Requires faith
- 19. Agile Benefits • Delivers real business benefits not unnecessary fluff • Deeply involves users in the development process • Users feel involved and empowered • Gives visibility of working prototypes early • Receive user feedback early • Reduces software testing and defects • Reduces unnecessary processes and documentation • Lessens management overhead •Delivers on time!
- 20. Our use of Agile
- 21. History of DSDM • Started early 1990s • Reaction to Rapid Application Development (RAD) • Unstructured processes across organisations • DSDM Consortium founded 1994 • Initiated by blue chip organisations including: • British Airways • American Express • Oracle • Logica • Data Sciences • Allied Domecq • First version published February 1995
- 22. History of SCRUM • Described in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka • Called the ‘Holistic’ or ‘Rugby’ approach • Whole process performed by one multi-functional team • By 1991 became known as SCRUM • In 1995 first formal presentations and workshops formalising methodology
- 23. Our use of Agile • 8 Principles • Project Roles • Project Lifecycle • Prioritised List of Requirements • MoSCoW Prioritisation • Timeboxing • Backlogs • Burn Down Charts • Daily Stand-ups • Sprints • User Stories • Story Points (Estimating)
- 24. 8 Principles 1. Focus on the business need 2. Deliver on time 3. Collaborate 4. Never compromise quality 5. Build incrementally from firm foundations 6. Develop iteratively 7. Communicate continuously and clearly 8. Demonstrate control
- 25. • 8 Principles • Project Roles • Project Lifecycle • Prioritised List of Requirements • MoSCoW Prioritisation • Timeboxing • Backlogs • Burn Down Charts • Daily Stand-ups • Sprints • User Stories • Story Points (Estimating)
- 26. Project Roles
- 27. • 8 Principles • Project Roles • Project Lifecycle • Prioritised List of Requirements • MoSCoW Prioritisation • Timeboxing • Backlogs • Burn Down Charts • Daily Stand-ups • Sprints • User Stories • Story Points (Estimating)
- 29. Project Lifecycle Example 1 Example 2
- 30. • 8 Principles • Project Roles • Project Lifecycle • Prioritised List of Requirements • MoSCoW Prioritisation • Timeboxing • Backlogs • Burn Down Charts • Daily Stand-ups • Sprints • User Stories • Story Points (Estimating)
- 31. Requirements
- 32. User Stories As a <type of user> I want <some goal> so that <some reason>.
- 33. Estimating • Point Scale (Story Points) • Linear (1,2,3,4,5) • Power of 2 (1,2,4,8) • Alphabet (A,B,C,D) • Clothes sizes (XS,S,M,L,XL) • Avoid assigning actual time (hours or days) • Helps to determine project velocity • Costs can be estimated based on points and velocity
- 34. Prioritised List of Requirements 2 Control Documents: 1. List of Requirements 2.Detailed Specification Document (The Spec.) See sample documents
- 35. • 8 Principles • Project Roles • Project Lifecycle • Prioritised List of Requirements • MoSCoW Prioritisation • Timeboxing • Backlogs • Burn Down Charts • Daily Stand-ups • Sprints • User Stories • Story Points (Estimating)
- 36. MoSCoW Prioritisation M - MUST have this time S - SHOULD have this if at all possible C - COULD have this if it does not affect anything else W - WON'T have this time but WOULD like in the future
- 37. When is it a MUST?
- 38. • 8 Principles • Project Roles • Project Lifecycle • Prioritised List of Requirements • MoSCoW Prioritisation • Timeboxing • Backlogs • Burn Down Charts • Daily Stand-ups • Sprints • User Stories • Story Points (Estimating)
- 39. Timeboxing
- 40. Example: Timeboxing Set an objective for a 10 day Timebox Load the 10 day Timebox with 10 days work Then do 10 days work! If you are falling behind, drop something out.
- 41. • 8 Principles • Project Roles • Project Lifecycle • Prioritised List of Requirements • MoSCoW Prioritisation • Timeboxing • Backlogs • Burn Down Charts • Daily Stand-ups • Sprints • User Stories • Story Points (Estimating)
- 42. Daily Stand-ups
- 43. Daily Stand-ups 1. What did you do yesterday? 2. What are you going to do today? 3. What’s stopping you from achieving this?
- 44. • 8 Principles • Project Roles • Project Lifecycle • Prioritised List of Requirements • MoSCoW Prioritisation • Timeboxing • Backlogs • Burn Down Charts • Daily Stand-ups • Sprints • User Stories • Story Points (Estimating)
Editor's Notes
- The Waterfall Model is traditionally used to plan and deliver software development projects. It is a sequential design process in which progress is seen as flowing steadily downwards. The waterfall development model originates in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, although Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed, non-working model. This, in fact, is how the term is generally used in writing about software development—to describe a critical view of a commonly used software development practice. Royce went on to describe corrections to this “waterfall approach”. Some of these can be described as (very early) attempts to make development more… agile! Customer involvement and bringing testing forward are among these suggested improvements. Research has shown that agile projects deliver higher success rates as opposed to projects delivered in the traditional waterfall approach. The Standish Group publishes a yearly report called the CHAOS Manifesto. This manifesto finds that “In 2002, agile projects made up less than 2% of overall projects and less than 5% of new application development projects . Today, agile projects account for almost 9% of all projects and 29% of new application development projects [...] The increase in project success rates can directly tie back to projects resolved through the agile process.” One of the Founding Fathers of Scrum, Jeff Sutherland, said about this: Software Development is inherently unpredictable and is therefore almost impossible to plan using waterfall Users do not know what they want until they see working software The (quality/ineffective/inefficient) structure of an organization will be embedded in the code Maximize value creation across the entire process Agile can double of triple productivity, this may be an issue for the rest of the organization Jeff continues with stating that generally speaking there is a... lack of agility in Operations and Infrastructure lack of agility in management, sales, marketing, and product management A waterfall approach doesn’t solve those issues. We need to activate all stakeholders to achieve quality in software development.
- [continued from previous slide] If we want to change the situation and deliver quality software products Jeff Sutherland suggests: We should demand technical excellence We should organize knowledge and improve education We should promote individual change and lead organizational change. Also, think of John Kotter’s 8 steps for leading change (see slide on this in Day 2) CHAOS states that Agile projects are successful more often than non-agile projects: “The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns.” The difficulty in being able to adapt to change is ultimately the primary reason why waterfall projects continue to fail.