This presentation is an introduction Agile / Scrum development.

1. Agile Development with Scrum April 2011

3. Scrum - Burndown

4. Scrum - Velocity

5. What About Requirements?

6. What About QA?

7. What About Offshore Development?

8. Adopting Agile / Scrum

9. Risks and Concerns

10. In Summary

12. “We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value: Individuals and interactions over processes and toolsWorking softwareover comprehensive documentationCustomer collaborationover contract negotiationResponding to changeover following a plan That is, while there is value in the items onthe right, we value the items on the left more.” Manifesto for Agile Software Development (2001) 4

13. 1) Our highest priority is to satisfy the customerthrough early and continuous deliveryof 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. 4) Business people and developers must work together daily throughout the project. Twelve Principles of Agile Software 5

14. 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. 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. Twelve Principles of Agile Software 6

15. Twelve Principles of Agile Software 9) Continuous attention to technical excellence and good design enhances agility. 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. 7

17. Enhance Ability to Manage Changing Priorities – Business owners set priorities for each release.

18. Increase Productivity – Collaboration is improved between business owners and developers through frequent communication.

22. A subset of those requirements is developed into a release called a Sprint that is shipped every two to four weeks.

24. Scrum Roles 13 Product Owner – A representative from the business who owns the requirements for the product and sets priorities for the development team. The product owner dictates the contents of each sprint and represents the interests of business stakeholders. Scrum Master – Replacing the traditional role of the project manager, the Scrum Master is the coach of the development team. Primary responsibility is to manage the scrum process and remove impediments to success. Team - Teams of developers turn Product Backlog into increments of potentially shippable functionality every Sprint. Teams are also self-organizing. The optimal size for a Team is seven people, plus or minus two. The team should include QA, BA, and even architects.

27. Scrum - Timeboxes 16 Sprint Review - At the end of the Sprint, a Sprint Review meeting is held. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was just done. Sprint Retrospective - After the Sprint Review and prior to the next Sprint Planning meeting, the Scrum Team has a Sprint Retrospective meeting. At this meeting, the Scrum Master encourages the Scrum Team to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint.

28. Scrum - Timeboxes 17 Daily Scrum - Each Team meets daily for a 15-minute inspect and adapt meeting called the Daily Scrum. The Daily Scrum is at the same time and same place throughout the Sprints. During the meeting, each Team member explains: 1. What he or she has accomplished since the last meeting; 2. What he or she is going to do before the next meeting; and 3. What obstacles are in his or her way.

29. Scrum - Burndown 18 A burndown is a measure of remaining backlog over time. Burndown charts can be used to project development activity into the future and estimate delivery dates.

30. Scrum - Velocity 19 Velocity is a measure of productivity for a development team. It is the sum of the estimates of delivered features per iteration. The initial velocity of a new team is unknown. Team velocity will typically stabilize between 3 and 6 iterations

31. Traditional functional requirements documents are replaced by user stories in most Agile development practices. A user story is one or more sentences in the business language of the end user that captures what the user wants to achieve. Typical format: "As a <role>, I want <goal/desire> so that <benefit>" Ex: As a mobile application tester, I want to test my test cases and report results to my management so that I can look good. What About Requirements? 20

32. User stories are small enough to fit on a post-it note, which are typically used for requirements management in sprint planning meetings. What About Requirements? 21

33. Acceptance test criteria are written along with the user stories. This brings test cases into the picture early in the development process. QA plays an active role with the development team. They are integrated with the Scrum to ensure that quality is built in from the start. Due to the frequent Agile releases, testing should be automated as much as possible to reduce the workload on QA. What About QA? 22

34. Agile development stresses face-to-face communication and close collaboration among developers. The offshore development model is not a natural fit for Agile development, but it can be achieved with effort. Distributed scrums require the coordination of two or more Scrum Masters for daily meetings. What About Offshore Development? 23

35. Agile can be adopted across the board in a “big bang” manner or selectively across projects. Implementing Agile / Scrum in a pilot project isolates the risk associated with doing something new. Transitioning from a traditional waterfall structure to agile does not happen overnight. The total transformation can take over a year. To be successful, investments need to be made in tools, best practices, and training. Adopting Agile / Scrum 24

36. It is easy to misunderstand Agile methods. Many organizations implement short waterfall cycles and think they are agile. Agile / Scrum requires heavy interaction from the product owner. If the business isn’t committed, it won’t work. Agile also makes the development process more transparent to the business. This can pose a risk if the business isn’t committed to the inevitable learning curve. Agile challenges the notion that a project end date can be determined when it starts. Teams need to establish velocity before target dates can be committed. You don’t know what your team is capable of until you are at least a few releases in. Then delivery dates can start to be estimated. Risks and Concerns 25

37. In Summary 26

39. http://agilemanifesto.org/

40. http://www.mountaingoatsoftware.com/

41. http://www.rallydev.com/