Agile ConceptsIntroduction To Agile Practices

Joaquim Ferreira

About Me

Joaquim Ferreira.NET Engineer @ Truphone

Email: joaquimf@truphone.com

Profile:http://

www.linkedin.com/in/joaquimluisdaluzferreir

a

Certified Scrum MasterLicense 000138872

June 2011 to June 2015

Agenda

1 2 3 4 5

6

Agile ManifestoFeatures

When

Principles Benefits

Differences

7

How

8Practices

9

Scrum

10

Kanban

Agile ManifestIndividuals and

interactions over processes and

tools

Working software over

comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over

following a plan

http://www.agilemanifesto.org/Kent Beck

Mike BeedleArie van Bennekum

Alistair CockburnWard Cunningham

Martin Fowle

James GrenningJim HighsmithAndrew HuntRon Jeffries

Jon KernBrian Marick

Robert C. MartinSteve Mellor

Ken SchwaberJeff SutherlandDave Thomas

12 Principles

Our highest priority is to satisfy the customer through early and continuous delivery

of valuable software

Welcome changing requirements, even late

in development. Agile processes harness

change for the customer's

competitive advantage

Deliver working software frequently, from a

couple of weeks to a couple of months, with a preference to the shorter

timescale

Business people and developers must work

together daily throughout the project

Build projects around motivated individuals.

Give them the environment and support

they need, and trust them to get the

job done

The most efficient and effective method of

conveying information to and within a development

team is face-to-face conversation

12 Principles

Working software 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

Continuous attention to technical excellence

and good design enhances agility

Simplicity--the art of maximizing the amount

of work not done--is essential

The best architectures, requirements, and

designs emerge from self-organizing teams

At regular intervals, the team reflects on how

to become more effective, then tunes and

adjusts its behavior accordingly

FeaturesIterative

1. Entire work is distributed in incremental units called iteration:

2. Development time of each iteration is small (couple of weeks) and

fixed;

3. Every Iteration is a mini increment of the functionality and is build on

top of previous iteration;Feature driven

1. More emphasis is on providing the required features in the application;

2. 80/20 principle is applied to decide the 20% features which would be

used 80% of the time ( Pareto Principle );

Active Customer involvement

1. There is lot of client involvement and face-to-face interaction;

2. Every iteration is tested and approved by client;

3. The feedback obtained is implemented in subsequent iterations;

FeaturesPriority based delivery

1. Features are prioritized depending on customer need, development

risk etc.;

2. High priority features are developed first;

3. After every iteration, the project priorities are re-evaluated;Adaptive

1. The applications that are developed can receive new requirements

throughout its development;

2. The goal is not to remove the uncertainty in the very beginning;

3. But is to adapt to the changing needs;

Empowered Teams

1. The project teams are generally small and have lot of interaction and

communication;

2. Since entire team is actively involved, team is empowered to take

decisions;

3. No separate team to manage project;

FeaturesPeople Centric

1. Emphasis is on using the adequately skilled people to do the

development than on following the processes;

2. The documentation and other non-development activities are

minimized and more time is devoted to development and testing;

More disciplined

1. So the process involves lot of team and self discipline thus, it requires

highly skilled and organized team members;

Rapid development

1. Being rapid, everything has to be delivered correctly first time.

FeaturesSimplicity

1. Emphasis is on keeping things as simple as possible and being open to

change;Fixed Time

1. Each iteration has a fixed time span in which it is delivered;

Benefits

For the customer

1. Customer is more actively involved, and gets higher

priority;

2. He gets to know regular and frequent status of the

application;

3. Requirements are accepted after each iteration;

4. Since the methodology emphasizes rapid delivery,

time-to-market is less. So the key functionalities can

be available to use sooner;

5. Delivery is defined by fixed timescale. So customer is

assured of receiving some functionality by a fixed

time period;

6. More Testing is done, so better software quality is

delivered;

Benefits

For the project team

• Project teams are involved more actively

in all the stages;

• The teams collaboratively take the

decisions and are more empowered;

• Development is Incremental, teams can

focus on the specific requirements at any

given point of time;

Benefits

For the project team

• More emphasis is on developing the

application only;

• The teams receive frequent feedback as the

testing is integrated; so the rework is reduced;

• Less time is spent in gathering requirements as

all the requirements are not gathered upfront

and are implemented as and when they arise;

Benefits

For the project team

• Less cost of development as rework,

management, documentation and other

non-development work related cost is

reduced;

• Teams develop applications collaboratively

and in cooperative environment;

• So less time is required for planning;

Differences

Requirements Fixed Evolve

AgileTraditional

Time & People May Change Fixed

Costumer Involvement

Before, After Throughout

Negotiable Estimates Schedule

Testing After Work Integrated

Feedback After Work During

Concentration On Processes; Reviews Finished Work

Focus On Plan On Value

Stages Requirements, Design, Code, Test, Feedbacks

Plan-Do-Check-Adjust

When

We use Agile when …

We have the customer

available.

We can split the deliver.

The requirements are flexible.

The team is skilled enough.

When

Because we will need

Organization support

Hierarchy ready to empower

teams

Culture open to changes

Focus on add value to the business

Infrastructure and team support

Preferable the team and the customer should be co-

located

Hardware support for continuous integration

and other practices

Highly skilled & flexible people

More & frequent testing

How

Starts with a kick-off meeting

1. Get requirements and / or feedback;

2. Plan & evaluate priorities;

3. Design;

4. Develop;

5. Test;

6. Document what is done;

7. Deliver;

12

3

4

56

7

Split the functionalities in small delivers and repeat:

Practices

ScrumKanban

eXtreme Programing

Agile

Mod

ellin

gScrumBan

Lean Software Development

Agile

Unifi

ed P

roce

ss

Dyn

am

ic S

yste

ms D

evelo

pm

en

t M

eth

od

s

Cry

stal

Cle

ar

Feature Driven Development

Scrum

Is an agile process that allows us to

focus on delivering the

highest business value in the

shortest time.

Allows us to rapidly and repeatedly inspect actual work.

The business sets the priorities. The Teams self-organize to determine the best way to deliver the highest priority features.

So that in the end of an iteration anyone can see real work and decide to release it as is or continue to enhance it for another iteration.

What

Scrum

No specific engineering practices

prescribed

Self-organizing teams

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

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

Characteristics

Uses generative rules to create an agile environment for

delivering projects

Scrum

SprintRequirements

Starts with a kick-off meeting

• Scrum projects make

progress in a series of

“sprints”;

• Typical duration is 2–4

weeks or a calendar

month at most;

• Product is designed,

coded, and tested during

the sprint;

• No changes during a

sprint;

Design

Do

Test

ScrumRather than doing all of one thing at a time...

… Scrum teams do a little of everything all the time

Requirements

Design

Build

Test

Requirements

Design

Build

Test

Scrum

Framework

Roles Ceremonies

Artefacts

Scrum

Roles

Product Owner Scrum Master

Team

Scrum

Product Owner

Starts with a kick-off meeting

• Define the features of the product;

• Decide on release date and content;

• Be responsible for the profitability of the

product (R.O.I.);

• Prioritize features according to market

value;

• Adjust features and priority every

iteration, as needed;

• Accept or reject work results;

Scrum

Scrum Master

Starts with a kick-off meeting

• Removes impediments;

• Represents management to the project;

• Responsible for enacting Scrum values

and practices;

• Ensure that the team is fully functional

and productive;

• Enable close cooperation across all roles

and functions;

• Shield the team from external

interferences;

Scrum

Team

Members should be full-time

• Teams are self-organizing:

• Ideally, no titles but rarely a possibility;

• Cross-functional:

• Programmers, testers, user experience

designers, etc.;

• Members should be full-time;

• Membership should change only between

sprints;

Scrum

Ceremonies

Sprint Planning

Sprint ReviewSprint

Retrospective

Daily Scrum

Scrum

Sprint Planning MeetingPlanning

Decide how to achieve sprint goal

(design)

Create Sprint backlog (tasks) from

Product Backlog (Features/Stories)

Estimate Sprint Backlog in hours.

Scrum

Daily Scrum

ParametersDaily15-minutesStand-Up

Not for problem solvingJust to InformOnly team members and Scrum Master talkWhole world is invitedOthers may talk if Team allow

Scrum

Daily Scrum

What will you do today ?

1

2

3Is anything in your way ?

What did you do yesterday ?

3Quest

ions

Scrum

Sprint Review/Demo

Members should be full-time

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

Scrum

Sprint Retrospective

Members should be full-time

• Periodically take a look at what is and is

not working;

• Done after every sprint;

• Whole team participates:

• Scrum Master;

• Product owner;

• Team;

• Possibly customers and others;

Scrum

Sprint RetrospectiveWhole team gathers and discusses what they’d like to:

Start Doing

Continue Doing

Stop Doing

Scrum

Artefacts

Product Backlog

…Product

Increment

Sprint Backlog

Scrum

Product Backlog

Members should be full-time

• Prioritized list of the functionality to be

developed in a product or service;

• User stories have emerged as the best

and most popular form of product backlog

items;

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

Scrum

Sprint Backlog

Members should be full-time

• The list of tasks identified by the Scrum

team during sprint planning;

• Its is estimated in Hours;

• Individuals sign up for work of their own

choosing;

• Estimated work remaining is updated

daily;

• Any team member can add, delete or

change the sprint backlog;

• Individuals sign up for work of their own

choosing;

Scrum

Product Increment

Members should be full-time

• In every Sprint is produced one;

• Must be of high enough quality to be

given to users

• Must meet the Scrum Team's current

Definition of Done

• Each component of it be acceptable

to the Product Owner

Scrum

User Story

Members should be full-time

• Short, simple description of a feature told

from the perspective of the person who

desires the new capability;

• They typically follow a simple template:

• As a <type of user>, I want <some

goal> so that <some reason>;

• Should contain the conditions of

satisfaction for the story be consider done

(Acceptance Criteria);

Scrum

Task Board

Members should be full-time

• Used to update the changes of state of the tasks during the

sprint;

• Each story have a row to the board;

• Each column represents a state of the work;

• The tasks change of state until be finished;

Scrum

Burn Down Charts

Members should be full-time

• Show the amount of work remaining

either in a sprint or a release:

• The Release Burn Down Chart

tracks the release remaining work;

• The Sprint Burn Down Chart tracks

the sprint remaining work;

• They determining at a glance whether

a sprint or release is on schedule to

have all planned work finished by the

desired date;

Scrum

This is Scrum

Kanban

The Kanban is an agile process based on Lean practices and

aims to streamline the development process of a

product

Means Visual SignalingVisibility into the status of the work and how it is proceeding

Shows what is happening on the process.Allowing to detect the problems during the process.

Gives more precise direction on how to invest the energy into only the most valuable work

What

Kanban

Change the priorities anytime

Visualization of the work flow

Deliver anytime

No need of iterations

Characteristics

Optimize Existing Processes

Introduction of visualization and

the limiting of work-in-progress

(WIP) will catalyse change with

minimal disruption

Kanban

Core Principles1 - Visualize the Workflow

Represent the work items and the workflow on a card wall or electronic

board;2 - Limit Work-in-Progress (WIP)Set agreed upon limits to how many work items are in progress at a time;

3 - Measure & Manage FlowTrack work items to see if they are proceeding at a steady, even pace;

4 - Make Process Policies ExplicitAgree upon and post policies about how work will be handled;

5 - Use Models to Evaluate Improvement OportunitiesAdapt the process using ideas from Systems Thinking;

Kanban

Visualize the workflowTodo InProgres BlockedTest Done

Members should be full-time

Kanban

Visualize the workflow• The card wall should reflects the current work process, with

the intent to improve it over time.

• Draw columns on the board that represent the activities

performed, in the order first performed.

• The cards themselves could be sticky notes or index cards.

• They may represent features, stories or tasks.

• Critical information for a card would be title, reference

number, and date it entered the system;

Kanban

Limit Work In Progress ( W.I.P)

Todo InProgres BlockedTest Done

W.I.P: 10 W.I.P: 5 W.I.P: 4 W.I.P: 3

Members should be full-time

Kanban

Limit Work In Progress ( W.I.P)

• A limit on work-in-progress constrains how many work items

can be in each workflow step at a time;

• When a work item progresses, a slot opens and a new work

item can flow into the workflow step;

• A key result of a W.I.P. limit is that blocked work “holds up

the line”;

• No new work can progress on the workflow step until the

block is resolved;

• The W.I.P. limit provokes the conversations that lead to

improvements;

Kanban

Limit Work In Progress ( W.I.P)How big a limit ?

• W.I.P. limits for workflow steps should be set as an average

number of items per person;

• Limits should be in the range of one to three items per person,

pair or team;Agreed upon limits ?

• W.I.P. limits should be agreed upon through consensus with up-

and downstream stakeholders and senior function management

as well as the development team;

• Not every step must have a limit;

Kanban

Limit Work In Progress ( W.I.P)

No W.I.P. limit?

Care should be taken when establishing any unlimited on workflow steps !!!

• Does not introduce bottlenecks;

• Cause excessive transaction;

• Cause excessive coordination costs when are made;

Kanban

Measure And Manage Flow

Todo InProgres BlockedTest Done

W.I.P: 10 W.I.P: 5 W.I.P: 4 W.I.P: 3

Lead Time

KanbanMeasure And Manage Flow

Lead TimeStarts when the request is made and ends at delivery;

Is what the customer sees;

Cycle TimeStarts when work begins on the request and ends when the item is ready for

delivery;

What the team can influence by itself by changing its work processReaction TimeThe time until the work begins on the request.

Lead TimeReaction

To reduce Lead Times one should reduce Cycle Time. But often the time before the work starts is really long.

So this wait time should be reduced also.

Cycle Time

KanbanExplicit Process policies

It is often best to post explicit process policies in a public team area such as next to the card wall

Workflow

Should agree upon policies regarding:

W.I.P Limits

Approvals Prioritization

Other Process Topics

KanbanUse models to evaluate improvement

• Womack & Jones on Waste Reduction

• Eliyahu M. Goldratt on Theory of Constraints

• John Seddon and Peter Senge on Systems Thinking

• W. Edwards Deming’s System of Profound Knowledge and specifically his work

on variability

• Taiichi Ohno (Toyota Production System) on muda, muri and mura.

Flow Time

Gather data on system performance as:

W.I.P

Useful models to learn and use may include work from:

Kanban Vs ScrumScrum Kanban

Fixed-length iterations Required Optional

Commitment to a specific amount of work

Required - at the personal daily level and at the team level (per

sprint)Optional

Metrics for planning process improvement

Velocity Lead Time

Cross-functional teams Required Optional

Item size So it can be completed within one sprint

No particular

Prescribed diagram type Burn down chart No particular

Work-in-progress limits Per sprint Per workflow state

Kanban Vs ScrumScrum Kanban

Estimations Required Optional

Adding new items to ongoing iteration

Not allowed Allowed

Sharing sprint backlog/ kanban board

Within one teamWith multiple teams or

individuals

Prescribed team roles Project Owner, Scrum Master, Team Member

No

Board life-time Reset after each iteration Persistent

Prioritization Requires a prioritized product backlog

No

How do you work?

Kanban Scrum

• Your work is often interrupted with new,

immediate tasks.

• You need to be flexible and highly

responsive to changes.

• You are unable to lock your backlog for a

couple of weeks.

• Your work more often involves repeatable

tasks than new ones.

• You do feature development which relies

heavily on stakeholders' feedback.

• You can run only one project at a time.

Kanban Vrs Scrum

What is your team type?

Kanban Scrum

• You have a small, medium or large

team of specialists in the same or

related fields.

• Your team is small and cross-

functional.

Kanban Vrs Scrum

What is the specificity of your organization?Kanban Scrum

• Your organization has low maturity.

• You have a limited capability of risk

taking, change management and

decisions making.

• You have time to let the culture and

performance evolve and improve.

• Your organization is highly mature.

• You are capable of assessing risk, managing

changes, evaluating alternatives and making

good quality decisions.

• You can only make changes in your

company using shock therapy - revolution in

your organizational culture and approach to

team and project management

Kanban Vrs Scrum

Sources

Manifesto for Agile Software Development

http://www.agilemanifesto.org/

http://www.mountaingoatsoftware.com/

Portions of this presentation are based on the next sources:

http://www.indicthreads.com/1439/quick-introduction-to-agile-software-development/

http://refcardz.dzone.com/refcardz/getting-started-kanban

Questions