48
Agile Software Development Bhawani Nandan Prasad

Agile project management

Embed Size (px)

DESCRIPTION

Learn Agile Software development in one hour by Bhawani Nandan Prasad

Citation preview

Page 1: Agile project management

Agile Software Development

Bhawani Nandan Prasad

Page 2: Agile project management

Objectives

Agile DevelopmentBasics

Traditional methods

Iterative development

Benefits of iterative development

Different flavors of Agile

“Managing” Agile projectsSelf-organization and self-management

Tracking Agile projects (without micro-managing)

PMBOK and Agile

Q&A

Page 3: Agile project management

Problems Companies Face

Excessively long “time to market” for products

Customer orientation is lacking

Over-engineered products (~60% features on a product are never used!)

Cost of delivering software is too high Poor productivity of teams

Too much “wasted work” to fix defects and rework designs

Software quality is poor

Ability to responding to change is low

Employee morale is low (and attrition rates are high!)

Project failure rate is too high (~70% or more)

RoI delivered falls short of expectations

Page 4: Agile project management

Traditional Software Development

Design

Coding

Testing

DeployAdvantage: Logically sound

Disadvantage: Assumes predictability!

Analysis

Page 5: Agile project management

The answer …

Iterative development, done in small incremental chunks, validating requirements at each step

Agile development evolved in mid-90’s – the word “Agile” was adopted in 2001

Various flavors of Agile development include … Scrum (the most popular)

Extreme Programming (or XP)

Crystal Clear

Adaptive software development

Feature driven software development

Dynamic Systems Development Method (DSDM); etc.

Has significant parallels with “Lean movement” in the manufacturing world, though they are not necessarily analogous

Page 6: Agile project management

Providing early value

Value Realized

Time

Incremental delivery

All-at-once

Delivery

Page 7: Agile project management

Agile Manifesto – Feb 2001

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

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,

Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,

Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C.

Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Page 8: Agile project management

12 Principles of Agile

1. Our highest priority is to satisfy the customer

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

Page 9: Agile project management

12 Principles of Agile (continued)

4. Business people and developers must work

together daily throughout the project.

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.

Page 10: Agile project management

12 Principles of Agile (continued)

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.

9. Continuous attention to technical excellence and good design enhances agility.

Page 11: Agile project management

12 Principles of Agile (continued)

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.

Page 12: Agile project management

Characteristics of Agile Process

1. Modularity

2. Iterative

3. Time-Bound

4. Parsimony - minimal number of activities necessary to mitigate risks and achieve their goals

5. Adaptive

6. Incremental

7. Convergent - actively attacking all of the risks

8. People-Oriented

9. Collaborative

Page 13: Agile project management

Scrum Basics

Page 14: Agile project management

Product Owner

Responsible for managing Project RoI and risk

Responsible for consolidating all inputs into what

the team should produce and turn it into a

prioritized “backlog”

Participate actively in the sprint planning and

sprint review meetings and is available to the

team throughout the sprint

Determines release plan and communicates to

everybody

Page 15: Agile project management

The Team

Page 16: Agile project management

The team!

Ideally 7 people + or – 2

Has worked with as high as 15 and as small as 3

Team can be change between Sprints (better not to)

Can be distributed (better results when co-located)

Cross-functional

Posses all the skills necessary to produce an increment

of potentially shippable product

Self Managing

Empowered to do whatever is necessary to produce the

potentially shippable product, within the constraints of

the organization’s standards.

Page 17: Agile project management

Scrum Master!

Page 18: Agile project management

Scrum Master!

Scrum Master helps the team achieve success using Scrum by Serving the team

Facilitate the team’s group interaction to help the team achieve its full potential

Helps to remove blocks that are surfaced by the team

Protecting the teamProtects team from outside interference or disruption

Supporting the team’s use of ScrumOrganizes and facilitates Scrum related practices

Reminds the team Scrum standards

Page 19: Agile project management

Product backlog

Page 20: Agile project management

Product backlog

List of everything that could ever be of value to

the business for the team to produce.

Ranked in order of priority

Priority is a function of business value and risk

Product owner can make any changes they want

before start of a Sprint / Sprint Planning meeting

It can be addition of new items, changing or removing or

existing items or re-ordering them

Ideally for 2 sprints items should be well defined

Page 21: Agile project management

Example of product backlog

Page 22: Agile project management

Sprint planning meeting

Page 23: Agile project management

Sprint planning meeting

Goal:

For the team to make good commitment around what it will

deliver by the end of the Sprint

What’s a Good Commitment?

Clearly understood by all

Shared among team

Achievable without sacrificing quality

Achievable without sacrificing sustainable pace

Attended by Team, Product owner, Scrum Master

Usually take 1-2 Hrs for each week of Sprint duration

Page 24: Agile project management

Sprint calendar – 2 week iterations

Page 25: Agile project management

Sprint backlog

Page 26: Agile project management

No changes during a sprint!

Once team has committed no changes

No changes to deliverables

Details will emerge during Sprint, but no new work or

substantially changed work

Product Owner can terminate the Sprint if necessary

No Changes to Sprint Duration

Sprint ends on planned date whether has completed its

commitment or not

However Product Owner can make the changes

to the remaining Product backlog before the start

of the next Sprint

Page 27: Agile project management

Daily standup meeting

Page 28: Agile project management

Daily standup meetings

Every weekday

Whole team attends (including QA)

Everyone stands

15 minutes or less

Everyone reports three things

What was able to accomplish since last meeting

What will try to accomplish since by next meeting

What is blocking me

No discussion, conversation until end of meeting

Update of artifacts after standup

Page 29: Agile project management

Closing a sprint

Page 30: Agile project management

Sprint review

Purpose of Sprint Review

Demo (not power point presentation) what the

team has built

Generate feedback which Product Owner can

incorporate in the product backlog

Attended by Product Owner, Managers,

Scrum Master and Team

Usually lasts 2 Hrs

Followed by Sprint Retrospectives

Page 31: Agile project management

Sprint retrospective

What it is?

1-2 Hr meeting followed by each Sprint Review/Demo

Attended by Product Owner, Scrum Master, Team

What’s working and what could work better

Why does Retrospective matter

Accelerate visibility

Accelerate actions to improve

It’s a key mechanism of continuous improvements

(Inspect & Adopt)

Page 32: Agile project management

Advantages of Agile Development

Customer is able to see “value” much faster

Near releasable product every 2 weeks!

Reduces “waste” by continuously validating the

output

Forces orderly management of changes during

the life-cycle

Page 33: Agile project management

Disadvantages of Agile development

Scrum doesn’t fix anything, team has to do it

May feel like things are worse at the beginning due to Scrum

makes all dysfunction visible

Bad product will be delivered sooner

Some team or Organization are not ready for it

Team willingness is important

Managements active support is important

Inevitably some people will get fed up and leave

Partial adoption is worse than none

Page 34: Agile project management

Agile or Waterfall?

If Waterfall is working for you, don’t use

Scrum! – Ken Schwaber

See link: http://leadinganswe rs.typepad.

com/leading_ answers/files/ agile_suitabilit

y_filters. pdf

Page 35: Agile project management

Engineering best-practices

Teams need to be prepared to work with “minimal” specifications

“Test-driven” development

Continuous integration: “Automated” builds and tests

Highly functional, motivated teams are needed

Ability to work in cross-functional teams is critical

Page 36: Agile project management

“Managing” Agile projects

Note that Scrum does NOT talk about a role for “Manager” or “Project Manager”.

So what do Managers do on Scrum projects? A project manager or coordinator operating in a “matrix”

environment can be trained to morph into a Scrum Master

Line managers (who have reporting authority) should …

Be the “Functional” and/or “Technical” expert

Help the team understand the larger context of the project

“Protect” the team during prioritization battles

Foster the right “culture” in the team

Act as a mentor or a coach to the team

Represent the team at external forums

Be risk managers for the projects

Page 37: Agile project management

Release Planning

Though Sprint contents can change, there often needs to be a long-term “roadmap” for software projects – evolved during “release planning” sessions

What should happen during a release planning? Prepare of a release roadmap with “epics” defined at high level

High-level guesstimate of what and how much can be accomplished in a release

Identify project dependencies on external factors or events

Prepare and secure approval for a high-level project plan with milestones

Mode of release planning Usually face-to-face, lasting up to a week

The entire team need not attend– key representatives should be identified

Product Owner and optionally other stakeholders can attend

Page 38: Agile project management

Tracking Agile Projects

Contrary to perception, managers should NOT micro-manage Scrum teams

Tracking mechanismsDaily stand-up meetings

Scrum-of-Scrums (for bringing a number of inter-related Scrum teams together)

Burn-down chart (automated or manual)

Progress chart

Common metrics in AgileVelocity (Stories/Story points delivered/Sprint)

Stories Delivered/Stories Planned

Scrum Maturity Model

Page 39: Agile project management

Burn-down chart

Page 40: Agile project management

Progress chart

Page 41: Agile project management

Agile and Process (Myth V/s Reality)

Myth Reality

Agile means no documentation Agile means “just-enough”

documentation

Agile works on “trust” and is informal,

hence cannot work with CMMi and

other process models

Agile actually enforces discipline and

frequent check points. Many CMMi

Level-5 and ISO certified teams use

Agile

Agile works only with “mature” teams Having a mature team helps, but it is

no different from conventional models

Agile works only when teams are co-

located

Co-location helps communication, but

it is no different from conventional

models

Agile is cowboy programming, does

not allow any time for design

Agile calls for “just-enough” design

effort – nothing stops teams spending

time on design

Page 42: Agile project management

Tools used in Scrum project management

In principle, Agile likes simple, easy-to-use tools.

Agile projects can very well be managed using

post-its, spreadsheets, etc.

Some of the other tools in vogue are …

Rally (http://www.rallydev.com/)

Mingle (http://studios.thoughtworks.com/mingle-agile-

project-management)

Scrum Desk (http://www.scrumdesk.com)

VersionOne (http://www.versionone.com/)

X-planner (http://xplanner.org/index.html) (open-source)

Page 43: Agile project management

Agile and PMBOK

All the Agile practices can be mapped to the

processes in the PMBOK

Agile is a wonderful framework (mainly) for

executing and monitoring/controling processes

But 23 processes in the PMBOK have no

matching practice in Agile

Agile does not obviate the need for conventional

project management methods, but

“supplements” it

Page 44: Agile project management

Agile and Program Management

Programs may contain components

(projects) executed in the Agile model

The challenge is to make sure that

dependencies are identified out and

honored

Projects to compromise flexibility for

getting more predictability in programs

Page 45: Agile project management

Iteration Wise Features & DependenciesProduct = <name> IC #1 IC #2 IC #3 IC #4 IC #5 IC#6 IC >6

Key Features/

Themes in IC

1. Asset &

Network

Discovery

(without

Topology)

1. Agent

detection

2. Normalization/

reconciliation

of Windows

data with CD

1. Normalizatio

n of

Windows

and Unix # 1

2. Agent

detection –

queries and

GUI

configuration

• Normalized

Unix and

Windows

asset

discovery # 2

• GUI-based

Domain

import

• New database

support

(Oracle 10g,

SQL Server

2005)

• GUI wizard

optimization

(grouping

methods)

1. Model

convergence to

CDM (Classes

and atributes)

2. Unix &

Windows

normalization

3. Map sharing,

4. export (filtering

per instance via

GUI)

5. Wizard

parameters

ordering

1. GUI features and

model change

finalization

2. Other discoveries

and asset data

normalization

(tokenid generation

and export to CDM)

3. Domain hostname

management (allow

hostname entry)

4. Wizard paramenters

ordering

1. Bug-fixes

2. Integration with any revised

drops

3. Documentation

Delivered On:

Best Case Date =

Most Likely Date =

Worst Case Date =

12/20/2006

12/16/2005

12/23/2005

1/17/2006

01/13/2006

01/17/2006

01/21/2006

1/31/2006

01/27/2006

01/31/2006

02/06/2006

02/16/2006

02/10/2006

02/14/2006

02/21/2006

02/21/2006

02/24/2006

02/28/2006

3/1/2006

3/6/2006

3/8/2006

Product dependencies (need) IC #1 IC #2 IC #3 IC #4 IC #5 IC #6

<Project>

(by worst case date)

ABC 2.0

locked

down

12/9/2005

Unit tested

drop of

XYZ 5.3

1. ABC 2.1

early

access

drop

1. ABC 2.1 early

access drop

1. XYZ 5.3

release

candidate

drop

XYZ 5.3 release

candidate

drop)

XYZ 5.3 release candidate

drop

<Project>

(by worst case date)

<Project>

(by worst case date)

<Project>

(by worst case date)

Page 46: Agile project management

Integrations and Dependencies

NOT on Track Concern On Track

Product using this

product

Suppor

ted

Revisio

ns

Stat

us Comments, Issues, notes

ITSM 7.0

SIM (via CMDB) 7.0

Product dependency

(used by this product)

Suppor

ted

Revisio

ns

Stat

us Comments, Issues, notes

CMDB 2.0

Mostly on track. Only issue is that TD

needs “early access” drops of CMDB

before the drop dates to ensure that

nothing blocks the inter-op cycle

Marimba CD 7.0 Need to discover Marimba agent and

reconcile output with CD

Page 47: Agile project management

Important links

Scrum Alliance

www.scrumalliance.org

Wikipedia on Scrum

http://en.wikipedia.org/wiki/Scrum_(developmen

t)

Page 48: Agile project management

Thank You