1. © 2010 Bennett, McRobb and Farmer1 Agile Methodologies—DSDM, XP and Scrum Based on Chapter 21 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (4th Edition), McGraw Hill, 2010.

2. 2© 2010 Bennett, McRobb and Farmer In This Lecture You Will Learn:  The characteristics of Agile software development  The key features of three leading Agile Methodologies:  DSDM  Scrum  eXtreme Programming (XP)

3. 3© 2010 Bennett, McRobb and Farmer Agile Software Development Agile approaches to development are linked by the Agile Manifesto, which emphasises: –People over process –Software over documentation –Collaboration over contracts –Change over plans (paraphrased from agilemanifesto.org)

4. 4© 2010 Bennett, McRobb and Farmer Characteristics of Agile Methodologies All agile approaches share a few characteristics: –Iterative development –Flexible, empowered teams –A “lightweight” approach - i.e. a preference for producing working code rather than analysis or design models –E.g. proponents of XP claim that “the code is the model”

5. 5© 2010 Bennett, McRobb and Farmer Dynamic Systems Development Method DSDM predates the Agile Manifesto It is a management and control framework for Rapid Application Development RAD aims to build a working system rapidly Prototyping aims to build elements of a system (a partial system) quickly Similar development environments can be used for both A prototype may incrementally become a working system

6. 6© 2010 Bennett, McRobb and Farmer Why RAD? Traditional waterfall approach has various deficiencies Also problems controlling iterative development

7. 7© 2010 Bennett, McRobb and Farmer Origins of DSDM RAD became popular in early 1990s, due to various deficiencies of waterfall lifecycle DSDM created in 1994, to define the structure and controls for a RAD project Does not specify the development methodology Has been used with SSADM (a structured methodology) and OO

8. 8© 2010 Bennett, McRobb and Farmer DSDM Project Management DSDM takes a radical perspective on project control Historically, requirements were fixed, while resources were allowed to vary DSDM fixes resources for the project (time available and budget), then delivers only what can be achieved within these limits

9. 9© 2010 Bennett, McRobb and Farmer DSDM Principles The latest version, DSDM Atern is based on 8 principles. 1.Focus on business need. Fitness for purpose is the essential test for all products. 2.Deliver on time. Deadlines are never sacrificed for lower priority requirements (relates to timeboxing and MoSCoW rules). 3.Collaborate. In DSDM all stakeholders are important, including end-users and resource managers.

10. 10© 2010 Bennett, McRobb and Farmer DSDM Principles 4.Never compromise quality. For this reason, testing is integrated throughout the life cycle. 5.Develop iteratively. Allows the project to converge on an accurate business solution. 6.Build incrementally from firm foundations. Partial solutions are acceptable if they satisfy an immediate need, and this encourages feedback from users. 7.Communicate continuously and clearly. 8.Demonstrate control.

11. 11© 2010 Bennett, McRobb and Farmer DSDM Life Cycle The DSDM life cycle has 7 phases: –Pre-Project –Feasibility –Foundations –Exploration –Engineering –Deployment –Post-Project

12. 12© 2010 Bennett, McRobb and Farmer Simplified DSDM life cycle Forward paths through process Backward paths to evolve the system Exploration Engineering Feasibility Foundations post- project pre- project Deployment

13. 13© 2010 Bennett, McRobb and Farmer DSDM Life Cycle Feasibility –Determines whether the project is suitable for a DSDM approach –Typically lasts only weeks –Should also address the following questions Is the computerized information system technically possible? Will the benefit of the system be outweighed by its costs? Will the information system operate acceptably within the organization?

14. 14© 2010 Bennett, McRobb and Farmer DSDM Life Cycle Foundations –Identifies overall scope of the project –Results in agreed high level functional and non- functional requirements –Maintainability objectives set at this stage determine the quality goals for the remainder of the project: maintainable from initial operation not necessarily maintainable when first installed but this can be addressed later short life-span system that will not be subject to maintenance

15. 15© 2010 Bennett, McRobb and Farmer DSDM Life Cycle Exploration –Development of prototypes to elicit detailed requirements –These may ultimately be delivered as operational systems—for operational use and non-functional requirements –Includes analysis models as well as prototypes

16. 16© 2010 Bennett, McRobb and Farmer DSDM Life Cycle Engineering –Prototypes developed to the point where they can be used operationally –Distinction between exploration and engineering is not clear-cut –Project may move back and forth between these phases for several iterations

17. 17© 2010 Bennett, McRobb and Farmer DSDM Life Cycle Deployment –Install latest increment and train users –Review how well requirements have been met –May return to earlier phases: To Engineering to complete non-functional requirements To Exploration to complete functional requirements To Foundations if a new functional area has been identified

18. 18© 2010 Bennett, McRobb and Farmer Timeboxing Fixes resource allocation for a project or a part of a project Limits time available for refinement of requirements, design, construction and implementation as appropriate Each timebox has a set of prioritised objectives

19. 19© 2010 Bennett, McRobb and Farmer Timeboxing Each timebox produces one or more deliverables Within a timebox, there are 3 main concerns –Investigate what needs to be done (determines the direction of work) –Develop and refine the specified deliverables –Consolidate the work prior to the final deadline

20. 20© 2010 Bennett, McRobb and Farmer Timeboxes A timebox has three phases, each with a different focus of attention Activity within each phase is iterated as necessary Investigate / set objectives Produce Deliverables Consolidate Work Done A timebox occurs in an overall sequence of other timeboxes The end of a timebox is an absolutely inflexible deadline Investigate / set objectives Produce Deliverables Consolidate Work Done Investigate / set objectives Produce Deliverables Consolidate Work Done

21. 21© 2010 Bennett, McRobb and Farmer MoSCoW Rules Heuristic to help prioritise requirements – (Must, Should, Could, Want) –Must have requirements are crucial –Should have requirements are important –Could have requirements are less important –Want to have but not this time around requirements can reasonably be left for development in a later increment

22. 22© 2010 Bennett, McRobb and Farmer Scrum: a framework for developing complex products Unusually, “Scrum” is not an acronym - it derives from rugby In Scrum, people are either pigs or chickens –Pigs are full team members, chickens are everyone else –Some chickens can specify a product, but no chicken can tell a pig how to do their work

23. 23© 2010 Bennett, McRobb and Farmer Scrum Framework This mainly consists of: –Roles of the people –Timeboxes (borrowed from DSDM) –Artefacts produced or used by the team –Rules about who can do what Scrum has no defined lifecycle, although it does insist on an iterative approach

24. 24© 2010 Bennett, McRobb and Farmer Scrum Roles Team members do the development work in whatever way they think best ScrumMaster coaches and motivates the team and ensures that Scrum rules are followed Product Owner has the power to decide when an increment is “done” These roles are the only pigs, all others are chickens

25. 25© 2010 Bennett, McRobb and Farmer Scrum Timeboxes As in DSDM, all work iterations and meetings are timeboxed Required meetings include: –Sprint Planning Meeting –Daily Scrum –Sprint Review Meeting Known as Scrum’s ceremonies, these meetings punctuate each sprint (a 2 to 4 week work iteration)

26. 26© 2010 Bennett, McRobb and Farmer Scrum Artefacts Four key artefacts are continuously updated as the project proceeds: –Product Backlog: a prioritised list of requirements, maintained by Product Owner. –Release Burndown: a graphic estimate of the total work needed to complete the project. –Sprint Backlog and Sprint Burndown are similar, but apply to the current Sprint, not the project as a whole

27. 27© 2010 Bennett, McRobb and Farmer Scrum Rules The process of Scrum is defined by its rules, which include: –Scrum teams are self-organizing, and no formal leader is imposed –Only pigs can talk during a Daily Scrum –Chickens cannot tell pigs how to do their work –Only the Product Owner can define what it means to say that an increment is “done”

28. 28© 2010 Bennett, McRobb and Farmer Extreme Programming XP is a novel combination of elements of best practice in systems development First publicized by Kent Beck (Beck, 2000) Known for its use of pair programming but has other important aspects

29. 29© 2010 Bennett, McRobb and Farmer Underlying Principles of XP Communication. XP highlights the importance of good communication among developers and between developers and users Simplicity. XP focuses on the simplest solution for the immediate known requirements

30. 30© 2010 Bennett, McRobb and Farmer Underlying Principles of XP Feedback. Feedback in XP is geared to giving the developers frequent and timely feedback from users and also in terms of test results. Work estimates are based on the work actually completed in the previous iteration Courage. Urges the developer to throw away code that is not quite correct and start again. Essentially the developer has to leave unproductive lines of development despite personal investment in the ideas

31. 31© 2010 Bennett, McRobb and Farmer Extreme Programming XP also emphasises –embracing change is important and key to systems development –development staff are motivated by producing quality work

32. 32© 2010 Bennett, McRobb and Farmer Requirements Capture in XP Based on user stories that describe the requirements –written by the user –basis of project planning and the development of test harnesses Very similar to use cases though some proponents of XP suggest that there are key differences in granularity –typical user story is about three sentences with no technology indicated –Developers get detailed descriptions from the customer when they start developing

33. 33© 2010 Bennett, McRobb and Farmer XP Activities The planning game involves quickly defining the scope of the next release from user priorities and technical estimates. The plan is updated regularly as the iteration progresses The information system should be delivered in small releases that incrementally build up functionality through rapid iteration A unifying metaphor or high level shared story focuses the development

34. 34© 2010 Bennett, McRobb and Farmer XP Activities The system should be based on a simple design Programmers prepare unit tests in advance of software construction and customers define acceptance tests The programme code should be restructured to remove duplication, simplify the code and improve flexibility—this is known as refactoring, and is discussed in Fowler (1999) in detail

35. 35© 2010 Bennett, McRobb and Farmer XP Activities Pair programming means that code is written by two programmers using one workstation The code is owned collectively and anyone can change any code The system is integrated and built frequently each day. This gives the opportunity for regular testing and feedback

36. 36© 2010 Bennett, McRobb and Farmer XP Activities Normally staff should work no more than forty hours a week A user should be a full-time member of the team All programmers should write code according to agreed standards that emphasise good communication through the code

37. 37© 2010 Bennett, McRobb and Farmer Using XP Best suited to projects with a relatively small number of programmers—say no more than ten Critical to maintain clear communicative code and to have rapid feedback –If these are not possible then XP would be problematic XP not sympathetic to using UML for analysis & design

38. 38© 2010 Bennett, McRobb and Farmer Summary In this lecture you have learned about  Some characteristics of Agile software development  The key features of three leading Agile Methodologies:  DSDM  SCRUM  eXtreme Programming (XP)

39. 39© 2010 Bennett, McRobb and Farmer References DSDM Consortium (2007) Schwaber (2009) Beck (2004) (For full bibliographic details, see Bennett, McRobb and Farmer)