Agile Software

Development

1

Who I am…

2

Rui Barreira

Senior Delivery Manager/Agile Coach

@ VORTAL

Agile Enthusiast since 2008

Experienced Software Architect and

Product Manager

pt.linkedin.com/in/ruimbarreira/

rui.barreira@vortal.biz

What is NOT!

3

4

Agile is NOT! – Reduced Team Capacity

5

Agile is NOT! – One Big Story

6

Agile is NOT! – No Process

7

Agile is NOT!

“letting the programming team do whatever they need to with

no project management, and no architecture, allowing a

solution to emerge, the programmers will do all the testing

necessary with Unit Tests…”

Business Value

8

9

What is Business Value?

• Value: is any desirable result for a stakeholder in a context;

• Stakeholder: are groups or individuals with a relationship to the

change or the solution;

• Needs: are problems, opportunities or constraints with potential of

value to a stakeholder;

• Changes: are any controlled transformations of an organization;

• Solutions: are specific ways to satisfy needs in a context;

• Contexts: are the part of the environment that encompasses a

change;

10

What is Business Value?

“Price is what you pay, Value is What you get!”

Warren Buffet

11

Types of Business Value?

12

Delivering Business Value is difficult!

• Of the work executed: “Many (possibly most) organisations lose as much as 45% of their total revenues due to costs associated with low quality”

• On Failing: Some 75 percent of most large-scale J2EE projects fail by missing both time and budget projections …”

• On Value: “64% of features actually delivered are either rarely or never used”

13

How to create Business Value!

WATERFALL (Royce)

Requirements, design

implementation,

verification &

maintenance

1960 85 9119801970

V-MODEL (Anon)

Aligns testing to

Waterfall development

SPIRAL MODEL

(Barry Boehm)

Iterative

RAD

(James Martin)

Prototyping, iterative,

time-boxed, user driven

RUP (Rational)

Object oriented,

iterative, time-boxed,

user driven

AGILE e.g. XP

(Kent Beck)

Incremental, user

driven, low process

98 99

Waterfall V-Model

Spiral Model

RAD

RUP

Agile Philosophy

14

15

The Philosophy

� Agile methods are considered

� Lightweight

� People-based rather than Plan-based

� Several agile methods

� No single agile method

� XP most popular

� No single definition

� Agile Manifesto closest to a definition

� Set of principles

� Developed by Agile Alliance

16

The Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

17

The Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

18

The 12 principles of Agile

19

On Image Agile

Agile Methodologies

20

21

All of them are Agile

� Agile methods:

� Scrum

� Extreme Programming

� Adaptive Software Development (ASD)

� Dynamic System Development Method (DSDM)

� Lean IT

� …

� Agile Alliance (www.agilealliance.org)

� A non-profit organization promotes agile development

22

Lets Talk About SCRUM

23

Sequencing vs Overlapping

Requirements Design Code Test

24

Scrum in 100 Words

� Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.

� It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).

� The business sets the priorities. Our teams self-manage to determine the best way to deliver the highest priority features.

� Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance for another iteration.

25

Scrum Characteristics

• Self-organizing teams

• Product progresses in a series of month-long “sprints”

• Requirements are captured as items in a list of “product backlog”

• No specific engineering practices prescribed

• Uses generative rules to create an agile environment for delivering projects

• One of the “agile processes”

26

Scrum Framework

•Product owner

•ScrumMaster

•Team

Roles

•Sprint planning

•Sprint review

•Sprint retrospective

•Daily scrum meeting

Ceremonies

•Product backlog

•Sprint backlog

•Burndown charts

Artifacts

27

Scrum Roles – Product Owner

• Define the features of the product

• Decide on release date and content

• Be responsible for the profitability of the product (ROI)

• Prioritize features according to market value

• Adjust features and priority every iteration, as needed

• Accept or reject work results

28

Scrum Roles – Scrum Master

• Represents management to the project

• Responsible for enacting Scrum values and practices

• Removes impediments

• Ensure that the team is fully functional and productive

• Enable close cooperation across all roles and functions

• Shield the team from external interferences

29

Scrum Roles – The Team

• Typically 5-9 people

• Cross-functional:

• Programmers, testers, user experience designers, etc.

• Members should be full-time

• May be exceptions (e.g., database administrator)

• Teams are self-organizing

• Ideally, no titles but rarely a possibility

• Membership should change only between sprints

30

Scrum Ceremonies - Planning Meeting

Sprint Planning

Meeting

Product Backlog

Team Capabilities

Business Conditions

Technology

Current Product

Sprint Backlog

Sprint Goal

Product Backlog

31

Scrum Ceremonies - Planning Meeting

• Team selects items from the product backlog they can commit to completing

• Sprint backlog is created

• Tasks are identified and each is estimated (1-16 hours)

• Collaboratively, not done alone by the ScrumMaster

• High-level design is considered

Sprint

goal

Sprint

goal

Sprint

backlog

Sprint

backlog

32

Scrum Ceremonies – The Daily Scrum

• Parameters

• Daily

• 15-minutes

• Stand-up

• Not for problem solving

• Whole world is invited

• Only team members, ScrumMaster, product owner, can talk

• Helps avoid other unnecessary meetings

33

Scrum Ceremonies – The Daily Scrum

What did you do yesterday?What did you do yesterday?11

What will you do today?What will you do today?22

Is anything in your way?Is anything in your way?33

34

Scrum Ceremonies – The Sprint Review

• Team presents what it accomplished during the sprint

• Typically takes the form of a demo of new features or underlying architecture

• Informal

• 2-hour prep time rule

• No slides

• Whole team participates

• Invite the world

35

Scrum Ceremonies – The Sprint Retrospective

• Periodically take a look at what is and is not working

• Typically 15–30 minutes

• Done after every sprint

• Whole team participates

• ScrumMaster

• Product owner

• Team

• Possibly customers and others

36

Scrum Artifacts – The Product Backlog

• The requirements

• A list of all desired work on the project

• Ideally expressed such that each item has value to the users or customers of the product

• Prioritized by the product owner

• Reprioritized at the start of each sprint

37

Scrum Artifacts – The Sprint Backlog

• A subset of Product Backlog Items, which define the work for a Sprint

• Is created ONLY by Team members

• Each Item has it’s own status

• Should be updated every day

• Individuals sign up for work of their own choosing

• Work is never assigned

• Estimated work remaining is updated daily

38

Scrum Artifacts – The Sprint Backlog

39

Scrum Artifacts – All Backlogs

Strategic Roadmap

All the features ofproduct roadmap

Products’s Backlog

All the features of a particular product

Sprint Backlog

Stories for thesprint

40

Scrum Artifacts – The Sprint Burndown Chart

• Depicts the total Sprint Backlog hours remaining per day

• Shows the estimated amount of time to release

• Ideally should burn down to zero to the end of the Sprint

• Actually is not a straight line

• Can bump UP

41

Scrum Artifacts – The Sprint Burndown Chart

42

Definition of Done

Code Commented

and Committed to

Line

Developmen

t Finished

Report

Unit Tests

Functional

Requirement

Document

Technical Requirement Document

Agile Practices

43

44

For Though Tasks – Pair Programming

45

For Though Tasks – Pair Programming

We help each other succeed. This practice comes

from XP.

46

For Though Tasks – Pair Programming

Pair-Pressure– Keep each other on task and focused

– Don’t want to let partner down

– “Embarrassed” to not follow the prescribed process

– Parkinson’s law “work expands to fill all available time.”

Pair-Think– Distributed cognition: “searching through larger spaces of alternatives”

» Have shared goals and plans

» Bring different prior experiences to the task

» Different access to task relevant information

» Must negotiate a common shared of action

Pair-Relaying– Each, in turn, contributes to the best of their knowledge and ability

– Then, sit back and think while their partner fights on

47

For Though Tasks – Pair Programming

Pair-Reviews– Continuous design and code reviews

– Ultimate in defect removal efficiency

– Removes programmers distaste for reviews

» 80% of all (solo) programmers don’t do them regularly or at all

Debug by describing– Tell it to the Furby

Pair-Learning– Continuous reviews � learn from partners techniques, knowledge of

language, domain, etc.

– “Between the two of us, we knew it or could figure it out”

– Apprenticeship

– Defect prevention always more efficient than defect removal

48

Roles – Pair Programming

The DriverThe person with "control" of the computer

Does the bulk of the typing

The NavigatorActively follows along with the driver with comments

Can take over at any time

49

For Quality – Continuous Integration

“ Continuous Integration is a software development practice

where members of a team integrate their work frequently, usually

each person integrates at least daily - leading to multiple

integrations per day. Each integration is verified by an automated

build (including test) to detect integration errors as quickly as

possible.“

http://martinfowler.com/articles/continuousIntegration.html

50

For Quality – Continuous Integration

• The ultimate goal of continuous integration is to be able to deploy all code.

• Although you won’t release in the middle of a sprint, the point is to be technologically ready, even if you are not functionally.

• With Continuous integration, you are integrating in short cycle and thus have smaller changes to deal with as you integrate.

• Continuous integration does not make sense unless it’s automated, has a short turn around time (fast builds), and everyone owns the concept of Green Builds.

• You need tests to fail or pass a build. Tests are the backbone that give you a green or a red light to take a snapshot of your build.

51

Challenges – Continuous Integration

• Don’t force this. It requires everyone to buy-in.

• CI also requires some setup, if you don’t have one.

• Keeping build times short. This might require some serious effort and might show you the deficiency of your builds.

• And you need a good version control system – VC systems like subversion that allows atomic check-in.

52

Start with the wheels – Interactive Design

53

It’s Simulation Time!

Agile Values

54

55

COMMITMENT

56

COLLECTIVE

OWNERSHIP

57

COMMUNICATION &

COLLABORATION

58

PEOPLE

Thank

You!

59