Agile Development with Scrum

April 2011

2

Introduction to Agile Manifesto for Agile Software Development Twelve Principles of Agile Software Why Transition to Agile? Types of Agile Processes Scrum – History Scrum Process Overview Scrum Artifacts Scrum Roles Scrum – Pigs and Chickens

Agenda Scrum - Timeboxes Scrum - Burndown Scrum - Velocity What About Requirements? What About QA? What About Offshore Development? Adopting Agile / Scrum Risks and Concerns In Summary References

3

What is Agile development?– Agile development is a relatively new way of approaching the

software development lifecycle– It is an alternative to documentation-driven, heavyweight software

development processes– Agile stresses iterative development over the linear waterfall

methodology

Introduction to Agile

4

“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 software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over 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)

5

1) Our highest priority is to satisfy the customerthrough 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.

4) Business people and developers must work together daily throughout the project.

Twelve Principles of Agile Software

6

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

7

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.

Twelve Principles of Agile Software

8

Why Transition to Agile?

Accelerate Time to Market – Deliver product features in weeks instead of months or longer.

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

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

Manage Outsourced Agile Projects – Many external vendors have made the move to Agile or are claiming to. Managing them is difficult without competency in Agile.

Agile development is not a “silver bullet” that solves all development problems. If waterfall methodologies work well for an organization, it should consider sticking with them. However, there are many advantages to agile development:

9

Types of Agile Processes

Scrum - An iterative, incremental methodology for project management. Scrum is a process skeleton that contains sets of practices and predefined roles such as Product Owner and Scrum Master.

Extreme Programming (XP) - Advocates frequent "releases" in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. Other elements include programming in pairs or doing extensive code review, unit testing of all code.

10

Scrum - History

The word “Scrum” comes from a Rugby term for a huddle. In Scrum practice, the development team meets in a daily huddle to set priorities and raise issues.

Scrum was invented by Jeff Sutherland and Ken Schwaber in 1995, and has been adopted by leading companies such as Microsoft, Fidelity, and GE.

11

Scrum Process Overview

Product requirements are collected in a backlog. A subset of those requirements is developed into a release called a Sprint that is

shipped every two to four weeks. A daily meeting is used to keep the whole process on track.

12

Scrum Artifacts

Product Backlog - is a prioritized list of everything that might be needed in the product.

Sprint Backlog - is a list of tasks to turn the Product Backlog for one Sprint into an increment of potentially shippable product. A burndown is a measure of remaining backlog over time.

Release Burndown - measures remaining Product Backlog across the time of a release plan.

Sprint Burndown - measures remaining Sprint Backlog items across the time of a Sprint.

13

Scrum Roles

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.

14

Scrum – Pigs and Chickens

Scrum Team members are called “pigs.” The Product Owner is the “pig” of the Product Backlog. The Team is the “pig” of the Sprint work. The Scrum Master is the “pig” of the Scrum process.

Everyone else is a “chicken.” Chickens cannot tell “pigs” how to do their work. Chickens and pigs come from the story:

15

Scrum - Timeboxes

Release Planning Meeting - The purpose of release planning is to establish a plan and goals that the Scrum Teams and the rest of the organizations can understand and communicate. Release planning answers the questions, “How can we turn the vision into a winning product in best possible way?

Sprint - A Sprint is an iteration. Sprints are time-boxed. A timebox is a fixed unit of development capacity. Cost and time are fixed for an iteration. During the Sprint, the Scrum Master ensures that no changes are made that would affect the Sprint Goal.

Sprint Planning Meeting - The Sprint Planning meeting is when the iteration is planned. It is time-boxed to eight hours for a one month Sprint.

16

Scrum - Timeboxes

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.

17

Scrum - Timeboxes 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.

18

Scrum - Burndown

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.

19

Scrum - Velocity 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

20

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?

21

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?

22

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?

23

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?

24

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

25

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

26

In Summary

References

27

http://www.scrum.org/

http://agilemanifesto.org/

http://www.mountaingoatsoftware.com/

http://www.rallydev.com/