basic agile for being agile

About Agile So,ware Development

Ruben Gonzalez Blanco @_rubengb

[email protected]

Dealing with So,ware

How we Understand So,ware Development

A radiography of the So,ware development process

So,ware Development Cliché

Dealing with So,ware -‐ EvoluHon

So,ware Crisis

So#ware Engineering

No Silver Bullet

Agile Manifesto

Cra#smanship Manifesto

Cra,ing Incremental

1960 1970 1980 1950 1990 2000 2010

Waterfall IteraHve Rapid Prototyping

CMM

Cra,ing

PredicHve Processes

IteraHve Processes

Agile Methods Scrum, XP, FDD, DSDM, OpenUP…

Spiral, RAD, Objectory, RUP

Waterfall, CMM, ISO9000

EvoluHonary

Dealing with So,ware is about Dealing with Complexity and Uncertainty

Inherent complexity and uncertainty

•  Machines are complex

•  Machines are faster and can process more data than human brain (consciously)

•  Although Machines are predictable (based on math and logic), the level of parallelism, speed and volume of data and instrucHons processed per second makes dealing with machines a complex and uncertain task

•  Modern mathemaHcal/logical formulas = so,ware programs needs TesHng to make sure we have instructed the machine properly. Can not be predicted upfront

•  Uncertain and Changing Requirements, FuncHonal, non FuncHonal

created by Machines and the Problem to solve

Accidental complexity and uncertainty created by Humans

So,ware Development depends on humans creaHvity, knowledge, passion, talent desires … but also in their collaboraHons and interacHons So,ware is “so,” or flexible, it is possible to express almost any kind of abstracHon Managing de Development Process is complex

Since the outcome is uncertain we need a ConHnuous CreaHve ISRF Cycle

IntenHon RealizaHon

Feedback

Synthesis

That is based on human creaHvity, talent and knowledge that is acquired

along the synthesis process

knowledge

Time Inten%on' Realiza%on'

Feedback'

Synthesis'

Inten%on' Realiza%on'

Feedback'

Synthesis'


Feedback'

Synthesis'

Learning by doing Deliberate pracHce

Difficulty: understand the Problem (What) and figure out possible SoluHon (How)

Problem SoluHon

At the same Hme

at mulHple levels of detail…

What

How

What

How

What

How

User System

Component

What

How

What

How

What

How

Domain

…concurrently , in mulHple brains and within different Hme frames


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'

Till the Desired Working So#ware Emerges


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'

Compile Failed

Run Failed

Test Failed

Test Passed

Enhance Idea/Design

Test Failed


Feedback'

Synthesis'

Test Passed

Emergence is the key characterisHc of complex systems.

WORKING SOFTWARE

IntenHonal

Emergent

… in both the So,ware SpecificaHon and the So,ware RealizaHon

Both SpecificaHons and Architecture Emerge and Grow along the process

System “Specs” Architecture So#ware System

Idea Need Problem

IntenHonal

Emergent


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'


Feedback'

Synthesis'

All depends on Talented Individuals

inspired creaHve

passionate

team player

Knowledge Mastery Talent

MoLvaLon CreaLvity InspiraLon Passion Genius

Requires MulHple Disciplines in a Team CollaboraHng together

Domain Experts

Ux Designers

Business Analysts

Product Managers

So#ware Developers Testers

System Engineers

Deployment Engineers

So,ware Architects

Human Factors

Users

Project Managers

Dealing with So,ware “a la” Agile

Agile So,ware Development is just a set of Principles, Values, and PracHces for dealing with so,ware complexity

and uncertainty

The purpose : Effec3ve So6ware Development

Agile Manifesto We are uncovering bemer ways of developing so,ware by doing it and helping others do it.

Through this work we have come to value:

Individuals and interacLons over processes and tools

Working so#ware over comprehensive documentaHon

Customer collaboraLon over contract negoHaHon

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 le, more

hmp://agilemanifesto.org/

Our highest priority is to saLsfy the customer through early and conLnuous delivery of valuable so#ware.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s compeHHve advantage.

Deliver working so#ware frequently, from a couple of weeks to a couple of months, with a preference to the shorter Hmescale.

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

Build projects around moLvated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effecHve method of conveying informaHon to and within a development team is face-‐to-‐face conversaLon.

1

2

3

4

5

6

7

8

9

10

11

12

Working so#ware is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

ConHnuous amenHon to technical excellence and good design enhances agility.

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

The best architectures, requirements, and designs emerge from self-‐organizing teams.

At regular intervals, the team reflects on how to become more effecHve, then tunes and adjusts its behaviour accordingly.

12 Agile Principles

Agile Manifesto cloud

Copyright 2007 Dean Leffingwell

What Paradigms Is Agile Breaking?

Culture

Measure of Success

Waterfall Development IteraLve Development

IteraLve and Incremental Development

Parallel Development

Acceptance Test Driven Development

Command-‐and-‐Control Leadership /CollaboraLve

Conformance to Plan Response to Change

Design

QA

Process

Big Design Up Front ConLnuous/Emergent

Big Test on Backend ConLnuous

Agile Development

Tool Support Highly specific Fully Integrated

Agile Grounds

Value Driven

Culture

AdapHve Management

Understanding IteraHve Development

IteraHve vs Waterfall Development

So,-‐NOT-‐aware

So,ware

Waterfall Requirements

Analysis&Design

ImplementaHon

TesHng

Deployment SpecificsHons Architecture

So,ware So,ware

Paperware

Itera3on1 Itera3on2 Itera3on3 Release1 Working So,ware

Release2 Release3

Focus In Executable Software

You can't know everything at the beginning

You learn as you work

Why IteraHve •  It accommodates changing requirements •  IntegraHon is not one "big bang" at the end of a project •  Risks are usually discovered or addressed during early integraHons •  Reuse is facilitated •  Management has a means of making tacHcal changes to the product •  Defects can be found and corrected over several iteraHons, •  It is a bemer use of project personnel. •  Team members learn along the way. •  The development process itself is improved and refined along the way

IteraHon general pamern PLAN

NING

REVIEW

ITERATION N

PLAN

NING

REVIEW

ITERATION N+1

Product Backlog •  User Stories •  Features •  Architecture Stories •  Issues/Bugs

new reqs

Working So,ware

PLAN

NING

REVIEW

ITERATION N+2

IteraHon a la mini-‐waterfall

Requirements

Analysis&Design

ImplementaHon

TesHng

Deployment

PLAN

NING

REVIEW

ITERATION N

Product Backlog

Working So,ware

Requirements

Analysis&Design

ImplementaHon

TesHng

Deployment

IteraHon a la agile

PLAN

NING

REVIEW

ITERATION N

Product Backlog

Working So,ware

Concurrent & Blended around people collaboraHon

2-‐4 weeks

IteraHon a la agile example : D/B/T teams

User Story1 UserStory2 UserStory3 Feature1 Feature2

… define

build

test

define

build

test

define

build

test

ITERATION <n>

DBT user story 1 DBT component 2

DBT Feature1

Backlog n

UserStory2 UserStory3

NewUserStory4 Feature2

NewFeature3 …

Backlog n+1 PLAN

NING

REVIEW

Working So,ware

D/B/T : •  User story •  Feature •  Technical/Architecture •  Bug

IteraHons a la ¿agile? Example interleaved “waterfalls”

PLAN

NING

REVIEW

ITERATION N-‐1

PLAN

NING

REVIEW

ITERATION N

Product Backlog •  User Stories •  Features •  Architecture Stories •  Issues/Bugs

PLAN

NING

REVIEW

ITERATION N+1

Requirements N

Analysis&Design N

ImplementaHon N

TesHng N PLAN

NING

REVIEW

ITERATION N+2

Deployment N

Acceptance N Acceptance N-‐3

Requirements N+1 Requirements N+2

Deployment N-‐1

Acceptance N-‐1

Deployment N-‐2

Acceptance N-‐2

Requirements N+3

TesHng N-‐1 TesHng N-‐2

Analysis&Design N-‐1

ImplementaHon N-‐1

Analysis&Design N+1

ImplementaHon N+1

Analysis&Design N+2

ImplementaHon N+2

TesHng N+1

Deployment N-‐3

IteraHons IteraLng and IncremenLng

“iteraHng” builds a rough version, validates it, then slowly builds up quality

1 2 3

IteraHng allows you to move from vague idea to realizaHon

From Jeff Pamon : hmp://www.agileproductdesign.com/blog/dont_know_what_i_want.html

“incremenHng” builds a bit at a Hme

1 2 3

But, incremenHng calls for a fully formed idea

© 2006-‐2009 Jeff Pamon: hmp://www.agileproductdesign.com/blog/dont_know_what_i_want.html

In so,ware, iteraHons combine iteraHve and incremental development

•  To find out “what” and “how” •  To improve the System

•  To release funcHonality incrementally •  To gradually add parts to the System when “what” and “how” are known

ITERATIVE

INCREMENTAL

© 2006-‐2009 Jeff Pamon: hmp://www.agileproductdesign.com/blog/dont_know_what_i_want.html

IteraHve Development is a form of AdapHve Management

Agile is about dealing with so,ware uncertainty through AdapLve Management

Agile Grounds

Value Driven

Culture

AdapHve Management

Value Driven

SOURCE : DSDM Based on Dean Leffingwell scaling agile blog

Fixed Scope

Time Resources

Time

Scope

Plan Driven

Value Driven

The Plan creates cost/schedule es1mates

feature intent & commitment to deliver the max value

Resources

Fixed

EsLmated IntenLonal & Max Possible

The happy IteraHve project

•  User Stories •  Features •  Architecture Stories •  Issues/Bugs

ITERATION1 ITERATION2 ITERATION3 ITERATION4

Final RELEASE

Backlog

Fixed Time

The unhappy IteraHve project

•  User Stories •  Features •  Architecture Stories •  Issues/Bugs

ITERATION1 ITERATION2 ITERATION3 ITERATION4

Final RELEASE

Backlog

New Req

“Embracing the Change”

Fixed Time

Value Driven Strategies

•  PrioriLze and reduce goals to hit the release date –  Less goals => less So,ware

•  Do not commit to early: – Decide what to deliver by experimenHng in the iteraHons.

–  Remember that both Specs and Architecture emerge •  Avoid Big UpFront Designs and Specs (BUFDS)

•  Grow Features quality iteraHon by iteraHon –  Start with simplest, minimal feature soluHon and add more quality iteraHon by iteraHon

Based on Jeff Pamon: hmp://www.agileproductdesign.com Embrace Uncertainty presentaHon

Agile Grounds

Value Driven

Culture

AdapHve Management

Schneider Culture Model

Agile Culture

Agile Methods

RUP Process Framework

Overview of Processes/Methods

Low Ceremony Limle documentaHon Light process

High Ceremony Well documented Traceability CCB

CMM-‐I

CMM

IteraHve Risk Driven ConHnuous integraHon and tesHng

Waterfall SequenHal, Few risks Late IntegraHon and tesHng

Open UP DSDM XP SCRUM

Agile

Source: Per Kroll/ Philippe Krutchen

The Agile Methods

•  Each IteraLon delivers working so#ware: Ready to be demonstrated to Business Customer and deployed in producHon environment

•  All development disciplines (requirements, analysis and design, implementaHon, test…) are nearly concurrent : FiDng all ac3vi3es in a short 3me itera3on

•  Teams are self managing : Bomom-‐up vs Top-‐down management •  Use of specific pracLces that keep the code base fresh and flexible: Pair

programming, code refactoring, test driven development, conHnuous integraHon

•  Lean principles and techniques eliminate waste whenever possible

Agile Methods

DSDM

FDD Crystal

PragmaHc Programming

AdapHve So,ware Development

The most extended methods under the Agile umbrella are Scrum and XP

Embrace Change

Embrace Uncertainty

Be Value Driven

Use AdapLve Management

Agile AdopHon

In any case Remember that in so,ware

development there is not silver bullet Fred Brooks

….and you must Adapt Methods to the Team, not the opposite

DSDM

FDD Crystal

PragmaHc Programming

AdapHve So,ware Development

THE END!

Books: Scaling Software Agility: Best Practices for Large Enterprises, Dean Leffingwell

Agile Estimating and Planning, Mike Cohn

Agile Project Management with Scrum, Ken Schwaber

The Enterprise and Scrum, Ken Schwaber

Scrum And XP from the trenches, Henrik Kniberg

Succeeding with Agile. Software Development using Scrum. Mike Cohn

Specification by Example. Gojko Adzic

Agile References (II)

Presentations: Building Better Products Using User Story Mapping – Jeff Patton

Embrace Uncertainty – Jeff Pattong http://www.agileproductdesign.com/presentations/index.html

Websites: Agile Community: https://agile.telefonica.com Agile Alliance http://www.agilealliance.org Scrum Alliance http://www.scrumalliance.org Mountain Goat Software http://www.mountaingoatsoftware.com/scrum http://www.scrumalliance.org/articles/46 http://www.leadingagile.com/2009/08/scrum-of-scrums.html (how to handle dependencies) http://geekoff.blogspot.com/2008/12/big-org-small-bandwidth.html

Agile References (III)

Kanban (Lean)

Kanban (Lean Development)

Kanban in a nusthell •  Visualize the workflow

–  Split the work into pieces, write each item on a card and put on the wall

–  Use named columns to illustrate where each item is in the workflow.

•  Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state.

•  Measure the lead Hme (average Hme to complete one item, someHmes called “cycle”), opHmize the process to make lead Lme as small and predictable as possible.

Cra,smanship

raising the bar

Cra,smanship Manifesto As aspiring So,ware Cra,smen we are raising the bar of professional so,ware development by pracHcing it and helping others learn the cra,. Through this work we have come to value:

That is, in pursuit of the items on the le, we have found the items on the right to be indispensable.

Not only working so,ware, but also well-‐cra#ed so#ware

Not only responding to change,

but also steadily adding value

Not only individuals and interacHons, but also a community of professionals

Not only customer collaboraHon,

but also producLve partnerships

hmp://manifesto.so,warecra,smanship.org/