Agile Software Developmentcodemanship.co.uk/files/agile.pdf · • The History of Agile Software...

© Codemanship Ltd 2015

Agile Software Development


About Me

Blah blah blah blah blah etc

[email protected]


What To Expect Today

• Introduction to Agile

• The History of Agile Software Development

• The Agile Manifesto

• The 4 Agile Values

• Core principles of Agile

• Continuous Delivery

• Extreme Programming

• Planning

• Managing

• Designing

• Coding

• Testing


What To Expect Tomorrow

• Scrum

• Roles

• Scrum Master

• Product Owner

• Development Team

• Events

• Sprints

• Daily Scrum

• Sprint Review (Retrospectives)

• Artefacts

• Product Backlog

• Sprint Backlog

• Product Increment

• Sprint Burn-down Chart

• Product Burn-down Chart

• Agile Pitfalls

• Agile, the CodemanshipWay

• Goals, not features

• Reality-driven Development

• How to build great Agile teams

• Scaling Agile - the reality

INTRODUCTION TO AGILE


HISTORY OF AGILE SOFTWARE DEVELOPMENT


Waterfall Model (1970)


Managing The Development of Large Software Systems (1970)

Winston W. Royce

http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

"I believe in this concept, but the implementation described above is risky

and invites failure"

Agile Is Older Than You Think #1


"We were doing incremental development as early as

1957, in Los Angeles, under the direction of Bernie

Dimsdale at IBM's Service Bureau Corporation. He was

a colleague of John von Neumann, so perhaps he

learned it there, or assumed it as totally natural. I do

remember Herb Jacobs (primarily, though we all

participated) developing a large simulation for Motorola,

where the technique used was, as far as I can tell ... All

of us, as far as I can remember, thought waterfalling of a

huge project was rather stupid, or at least ignorant of the

realities. I think what the waterfall description did for us

was make us realize that we were doing something else,

something unnamed except for 'software development.'"

Gerald Weinberg

"Iterative and Incremental

Development: A Brief History".

IEEE Computer, June 2003



Started writing about evolutionary

project management in 1970,

leading to Evo method described

in Principles of Software

Engineering Management (1988)

Tom Gilb



"A Process for the Development of Software for

Nontechnical Users as an Adaptive System".

Edmonds, E. A.

General Systems, 1974

(According to Edmonds, this was first submitted to

Computer Aided Design magazine in 1970, and was

rejected with the criticism:

“If you don't know what you are going to do before

you start you shouldn't start"

Earnest Edmonds



Rapid Application Development (RAD) developed and

deployed by the New York Telephone Company's

Systems Development Center under the direction of Dan

Gielan in 1974

Gielan went on to lecture extensively about their

approach

Dan Gielan

Spiral Model (1986)


A Spiral Model of Software Development and Enhancement (1986)

Barry Boehm

http://csse.usc.edu/csse/TECHRPTS/1988/usccse88-500/usccse88-500.pdf

When Dinosaurs Ruled The Earth (1980’s)


The Lightweight Backlash (1990’s)


Snowbird, Utah, 2001


THE AGILE MANIFESTO



We are uncovering better ways of developing software by

doing it and helping others do it. Through this work we have

come to value:

• 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.

Agile Principles


1. Customer satisfaction by early and continuous delivery of useful software

2. Welcome changing requirements, even late in development

3. Working software is delivered frequently (weeks rather than months)

4. Close, daily cooperation between business people and developers

5. Projects are built around motivated individuals, who should be trusted

6. Face-to-face conversation is the best form of communication (co-location)

7. Working software is the principal measure of progress

8. Sustainable development, able to maintain a constant pace

9. Continuous attention to technical excellence and good design

10.Simplicity—the art of maximizing the amount of work not done—is essential

11.Self-organizing teams

12.Regular adaptation to changing circumstances

CONTINUOUS DELIVERY


What Is Continuous Delivery?

Continuous delivery is the process of having a shippableproduct/ piece of software after each check in to source control.

Business Implications Of Continuous Delivery

• Deployment becomes entirely a business decision

• Deployment can happen as frequently as the business requires

• Deployment can happen as soon as features & changes are ready

• At any given time, the amount of work in progress is minimised

• Cycle times from conception to delivery can be massively reduced

• Features/changes per release can be minimised

• Business feedback cycles can be minimised

• Businesses can learn faster

Technical Implications of Continuous Delivery

• The software must always be fit for purpose

• Test assurance needs to be high

• Programmers must be able to build and properly test the software quickly and cost-effectively

• Deploying software must be fast, reliable and cost-effective

• Building, testing & deploying software must be fully automated

• Whatever you deliver, it must be easy to change so it can continue to evolve

EXTREME PROGRAMMING


History of XP

• 1993 - Chrysler C3 payroll project initiated

• 1994 - Kent Beck brought in to performance-tune Smalltalk code

• Beck’s role widens to look at development process

• 1996 – Beck becomes C3 project leader

• Implements ideas from collaborations with Ward Cunningham

• Ron Jeffries brought in to develop ideas, acts as coach on C3 project

• 1995 - Principles & practices of XP shared with wider world via original c2.com Wiki (invented by Cunningham)

• 1999 – Beck’s Extreme Programming Explained published


Nothing New (Examples)


1957 – NASA Project Mercury software

teams drive development by agreeing

failing tests up-front and specifically

writing code to pass those tests (Test-

driven Development)

1984 – Thinking Forth by Leo Brodie first

in-print use of term “refactoring” to

describe practice of simplifying code to

make it more readable

Why “Extreme”?


If it’s a good idea to test early

and often, it must be a great idea

to test continuously

If nobody ever reads the

architecture document, let’s not

waste time writing one

Principles of XP


Minimise delay between

action and feedback

speeds learning

Assume solution to

every problem is

extremely simple

(Y.A.G.N.I. – you ain’t

gonna’ need it)

Embrace changes to

requirements, no matter

how late. Embrace

learning.

XP Values


The XP Process


XP PRACTICES - PLANNING


User Stories


Borrow a DVD

As a video library member, I want to borrow a copy of a DVD so that I can watch it without buying my own copy

Release Planning


Donate a DVD

As a video library member, I want to donate a DVD to the library so that other members can borrow it and I can earn points for priority services

Borrow a DVD


Return a DVD

As a video library member, I want to return a copy of a DVD I’ve borrowed so that I can other members can borrow and earn priority points when I return it on time

Send Weekly Newsletter

As the video library administrator, I want a newsletter emailed to all members once a week listing all the new titles added since the last newsletter so that members can see what new titles are available

Join the Library

As a movie lover, I want to join the video library so that I can get access to its collection of titles

Reserve a DVD

As a video library member, I want to reserve titles for which all rental copies are currently on loan so I can borrow it when copies are returned. If there’s a queue for a title, I want to be able to use my priority points to fast-track myself up the queue.

1. 2. 3.

4. 5. 6.

5 days 2 days 3 days


Small Releases


? ? ? ?

Iteration Planning


Donate a DVD

As a video library member, I want to donate a DVD to the library so that other members can borrow it and I can earn points for priority services

Borrow a DVD


Return a DVD

As a video library member, I want to return a copy of a DVD I’ve borrowed so that I can other members can borrow and earn priority points when I return it on time



Join the Library

As a movie lover, I want to join the video library so that I can get access to its collection of titles

Reserve a DVD

As a video library member, I want to reserve titles for which all rental copies are currently on loan so I can borrow it when copies are returned. If there’s a queue for a title, I want to be able to use my priority points to fast-track myself up the queue.

1. 2. 3.

4. 5. 6.



Next Iteration

Project Velocity = 7 days/iteration

Estimating & Signing Up


• Various units used for

estimation – it’s actually

academic, because time

taken = story points /

velocity in any unit

• Any developer can estimate

a story

• Estimating means you are

bidding to do that work

• The lowest bid wins

XP PRACTICES - MANAGING


Open Workspace


Sustainable Pace


Daily Stand-up Meeting


Project Velocity


0

5

10

15

20

25

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6

Project Velocity

Story Points Completed 3 Iteration Average Story Points Remaining

Today’s

weather is

likely to be

like

yesterday’s

weather“burn-down”

Move People Around


Retrospectives


Kristian Sørensen, 2014

XP PRACTICES - DESIGNING


Simple Design


System Metaphor


Modeling with CRC Cards


Library

• Knows about titles• Knows about new

titles• Adds donated titles• Adds new titles

• Title• Member

Title

• Knows its name, director & year of release

• Knows about rental copies

• Registers rental copy

• Email Alert

Email Alert

• Sends email to members who specified matching title

?

Member

• Knows about priority points

• Awards priority points

class

responsibilities collaborations

Solutions Spike




?

Can’t estimate because not sure what

technical solution might take

…knock up quick

prototype to learn what’s

involved, then…

Estimate time required to…

…feed back lessons to

estimate story

You Ain’t Gonna Need It (YAGNI)


Refactoring


Refactoring - Overview


Agility & The Cost of Change


Refactoring – Obstacles To Change


Lack of Test Assurance Poor Readability High Complexity

Duplication Dependencies

Refactoring Discipline


1. Identify problem

(complexity - method

does too much) 2. Apply appropriate

refactoring (Extract

Method)

3. Run tests!!!

XP PRACTICES - CODING


On-Team Customer


Coding Standards


Test-driven Development


TDD process


Write a test

that fails

Write simplest

code to pass

the test

Refactor to

keep code

maintainable

Test #2 –

Boiled eggs

with toast

TDD Example – Designing a Kitchen


Test #1 –

Boiling

eggs Refactor to

remove

duplication

Simplest

solution

Simplest

solution

Pair Programming


DriverNavigator

Continuous Integration


Repository

Continuous Integration


Frequent automated…

• Compilation of

source code

• Packaging of

executables &

supporting files

• Testing

Team Heartbeat


Check-In Dance


1. Grab build token

2. Merge

3. Run tests

4. Commit

5. Wait for

successful build

6. Release build

token

Collective Code Ownership


server-side

code

web front

end

SQL

reporting

Collective Code Ownership


The Code

XP PRACTICES - TESTING


Writing Tests For Bugs


Bug: Invoice total not calculated correctly

Invoice totals should include sales tax

Acceptance Test-driven Development


Acceptance Test-driven Development


Borrow a DVD


Test: Borrow a DVD that has one copy for loan

Given that title ‘The Abyss’ has one copy available for loan,

When member jasongormanborrows that copy

Then the count of available copiesis reduced by one, leaving zerocopies for loan, so other memberscannot borrow The Abyss

Executable Specification

Effect of action

Definition of “Done”


Borrow a DVD


Test: Borrow a DVD that has one copy for loan

Given that title ‘The Abyss’ has one copy available for loan,


Then the count of available copiesis reduced by one, leaving zerocopies for loan, so other memberscannot borrow The Abyss

Test: Borrow a DVD that has more than one copy for loan

Given that title ‘The Abyss’ has two copies available for loan,


Then the count of available copiesis reduced by one, leaving one copyfor loan, so other members can still borrow The Abyss

Measuring completeness by

acceptance tests passed gives

an objective and honest account

of real progress

SCRUM


Origins of Scrum

• “A flexible, holistic product development strategy where a development team works as a unit to reach a common goal“

• Hirotaka Takeuchi & Ikujiro Nonaka, New Product Development Game (1986)

• New approach to commercial product development to increase speed & flexibility

• Based on case studies from manufacturing firms in automotive, photocopier & printer industries

• Team "tries to go the distance as a unit, passing the ball back and forth“, like in rugby

• Jeff Sutherland & Ken Schwaber presented paper describing the scrum methodology at OOPSLA '95

• Sutherland & Schwaber attend Agile summit at Snowbird, Utah in 2001


Scrum Process


Daily Scrum

e.g. 14 days

SCRUM ROLES


Product Owner


The Product Owner…

• Represents stakeholders & is “voice of the customer”

• Represents development team to stakeholders

• Writes user stories

• Manages product backlog

• Does NOT interfere in technical decisions


Development Team


The Development Team is…

• Responsible for delivering potentially shippable increments (PSIs) of product at end of each sprint

• Made up of 3–9 individuals who do the actual work (analyse, design, develop, test, technical communication, document, etc.)

• Cross-functional; having all skills necessary to complete product increment

• Self-organising


Scrum Master


The Scrum Master…

• Facilitates Scrum on the team

• Helps to remove obstacles to progress

• Buffers team from distractions

• Coaches team, product owner & stakeholders on Scrum principles & practices

• Promotes self-organisation within team

• Is NOT a project manager or team leader


SCRUM EVENTS


Sprint


• Time-boxed iteration

• Duration of 1-4 weeks (average

2 weeks)

• Emphasis on work product at

end that is really done

Sprint Planning


• Identify user stories to form sprint backlog

• Estimate effort required to complete sprint backlog

• Team votes to commit to sprint goal

• Sets a 4-hour window to complete planning per 2-week

sprint (pro rata)

• 1st half: team agree on backlog items to include

in sprint

• 2nd half: team decompose items and to

estimate effort required)

Planning Poker


Technique to eliminate

“anchoring” in estimates and

achieve consensus

• Product Manager explains

requirement

• Team members place

estimate card face down

• Cards turned over at once

• Outliers explain their

reasoning

• If necessary, play another

round

• TimeboxedEstimate numbers are far apart to

avoid “I say it’s a 9” “I say it’s a 10”

quibbling.

e.g., Fibonacci series

Daily Scrum


Development Teams meets for

max 15 minutes daily, each

answering:

• What did I do yesterday?

• What will I do today?

• What is blocking me from

achieving sprint goals?

Teams ensure:

• Everyone comes prepared

• Starts on time

• Same time/place every day

(typically early in the day in

the team area)

Sprint Review


• Review completed work

• Present product increment to

stakeholders (“show & tell”)

Sprint Retrospective


• Reflect on previous Sprint

• What went well, what not-so-well?

• Agree plans to improve processes

SCRUM ARTIFACTS


Product Backlog


Type Requirement Effort Value

Feature Review a movie 5 21

Feature Rate review usefulness 1 5

Bug All movies should have poster

images

3 8

Non-Func App should install in < 30

seconds

13 13

Feature Follow a movie network user’s

reviews

2 5

Feature Add movie trivia 5 3

Bug Movies users aren’t old

enough to rent shouldn’t be

displayed

8 5

Priority

• Your product’s “TO DO”

list

• Managed by Product

Owner

• An ordered list of

requirements that

includes new features,

bug fixes, non-

functional requirements

• Prioritised by business

value, risk,

dependencies and date

needed

• Includes estimates of

business value by

stakeholders, and

development effort by

team

Sprint Backlog


To Do In Progress Done

Sprint: #8 w/c 15/7/13 Due Date: 27/7/13 • Sprint’s “TO DO” list

• Managed by

Development Team

• Team takes highest

priority items from

product backlog they

believe they can

commit to for this sprint

• Once committed, no

more backlog items

can be added

• At sprint completion,

product backlog is

revisited and updated

as necessary

Product Increment


• Sum of all product backlog

items completed during

current sprint & previous

sprints

• Must be complete

according to agreed

Definition of Done

• Must be shippable, even if

product owner decides not

to release

Sprint Burn-down Chart


• Charts work

remaining against

estimated total

effort in a sprint

• Managed by

development team

Release Burn-down Chart


• Provides visibility

of overall progress

on the product

• Shows how scope

changes over

multiple sprints

• Helps identify

trends in

productivity and

scope

• Managed by

Scrum Master

AGILE PITFALLS


Incremental Waterfall (“WAgile”)


Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5

Incrementally executing a

detailed plan that’s not

supposed to change cuts

out opportunities to learn

Absentee Customer


Lack of customer engagement is

consistently cited as the primary

cause of software project failure

frAgile – Lack of Technical Discipline


If the code is difficult to

maintain, teams cannot

respond to change

Piecemeal Architecture


When team members

pursue different

architectural styles

because they’re not

communicating about it

enough

Lack of Training & Support


Task Focus vs Goal Focus


Teams who focus on tasks tend to

struggle to lose sight of the end goals,

and struggle to achieve objectivity in

measuring progress

Build Blindness #1


When teams know

their build is broken,

and they ignore it

Build Blindness #2


When teams assume

that because tests are

all passing, software

is working

Scrum Master as Project Manager


The Scrum Master is NOT in charge

Product Owner as Customer


The Product Owner is NOT the customer

Estimates vs. Commitments


Going Agile Overnight


Adopt and improve Agile practices iteratively

AGILE THE CODEMANSHIP WAY


Goals, Not Features


• Establish testable,

realistic goals for

software and

systems

• Iterate towards

those goals, rather

than following a plan

or working through a

list of features

• BALANCED:

Consider multiple

stakeholder

perspectives (not

just financial goals)

Features From Goals


Recruitment Process

Recruitment Management System

edit job ad approve job ad publish job ad Send link to online skills test

<< goal >>

Reduce hiring time from 8 to 6 weeks

Reality-driven Development


• Analyse requirements and

test designs and working

software in as close an

approximation to the real

world as possible

• Try software out in realistic

situations on real end users

• Simulated business

environments are sometimes

referred to as Model Offices

• Business scenarios can be

explored and repeated,

allowing testing in edge

cases and operational

extremes

Business Stories


Recruit a developer

As development manager, I want to recruit software developers who have the necessary skills and experience to work on our in-house business systems, so that we can take on new work and maintain systems in production

Business Test Scripts


The CRM team require a full-stack web developer to replace a team

member who is leaving in 2 months.

They create a job spec that reads:

“WANTED: Full-stack Web Developer

Seeking full-stack web developer with Java/JEE, JavaScript, HTML and

SQL skills to enhance CRM system.”

The HR dept approve the job spec and publish it on the company

website. It is also syndicated automatically to Jobserve.com and Stack

Overflow.

After 20 mins, Jill Smith applies with her CV via email.

After 60 mins, Ken Chan applies with his CV through the website.

After 90 mins, Amanda Johnson calls the advertised number to enquire.

… etc etc

Designing A Model Office


Recruitment

Management

server

Dev manager’s

laptop (web

browser)

HR manager’s

laptop (web

browser)

Company web

server

Candidate’s tablet

computer

Switchboard/Call

Management

System

Candidate’s phone

Fake jobserve.com

Fake stackoverflowpublish

syndicate

create job spec

approve

job spec

apply via

enquire via

connect via

application

application

http://www.google.co.uk/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRxqFQoTCMqMrZXt-McCFUN_GgodBzEBAg&url=http://itintelligenceindia.com/training/i-t-engineer-wing/server&psig=AFQjCNH3pIkqVYZj3jPwPR3Xx0wJVQecgg&ust=1442400039380401

http://www.google.co.uk/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRxqFQoTCMqMrZXt-McCFUN_GgodBzEBAg&url=http://itintelligenceindia.com/training/i-t-engineer-wing/server&psig=AFQjCNH3pIkqVYZj3jPwPR3Xx0wJVQecgg&ust=1442400039380401

Building Great Agile Teams


• Self-organising teams build themselves

• Favour small teams (4-6 people)

• Favour experienced developers

• Be flexible about technologies

• Recruit proactively

• Always be recruiting

• Build a strong dev culture & a good

reputation

• If you can’t find good enough people,

seriously consider:

• Paying more

• Offering greater autonomy

• Abandon prejudices and

preconceptions

Scaling Agile – The Reality


• There’s no compelling evidence that any software

organisation has ever achieved economy of scale

• Favour small, independent, autonomous self-

organising teams doing what’s best for them and their

customer

• Promote continuous opportunities for teams to interact

and learn from each other

• Favour loose project dependencies and interop

protocols over “enterprise architecture”

• Be continually aware of project and product

dependencies

• Favour clear goals and simple standards over

prescribed processes

• Look to nature – swarm intelligence

• Dev culture can scale - massively

www.codemanship.com


Agile Software Developmentcodemanship.co.uk/files/agile.pdf · • The History of Agile Software...

Documents

Transcript of Agile Software Developmentcodemanship.co.uk/files/agile.pdf · • The History of Agile Software...