software development with scrum methodology bhawani nandan prasad

Bhawani Nandan Prasad - IT process expert

Agile Software Development

with Scrum Methodology

Bhawani Nandan Prasad

IT Process Leadership

B.E. Computer Science, EMBA Senior Management, MBA marketing

PMI-ACP, Scrum Master

7/28/2014


Objective

To help you understand the principles of Agile software development and help you practice the Scrum methodology to ultimately improve your software development experience

7/28/2014

Ground rules

This is YOUR workshop

Your time, my watch

Active participation is encouraged

Bhawani Nandan Prasad - IT process expert 7/28/2014


Session Plan

Day-1

Getting Started

Issues with Traditional Methods

Overview and history of Agile

Agile Principles

Agile methodologies

Scrum Methodology

Scrum Overview

Different roles in Scrum

Implementing Scrum

Day-2

Managing Scrum Projects

Estimation

Tracking

Communication

Best practices

Engineering practices

People practices

Risks and challenges

Myth v/s reality

Putting into practice!

Summary and Discussion 7/28/2014

Why bother about Agile?

Israel Gat: Cutter Consortium:

“Agile can do to software development what

internet did to computing”

“Agile is a train. Either you get on to it or you

will be under it”

PMI research: Use of Agile has tripled

from December 2008 to May 2011

Gartner: 80% of software development

projects would use Agile by end of 2012 Bhawani Nandan Prasad - IT process expert 7/28/2014


Problems with Software Development

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

Delivered RoI falls short of expectations

7/28/2014


Traditional Software Development

Design

Coding

Testing

Deploy Advantage: Logically sound

Disadvantage: Assumes predictability!

Analysis

7/28/2014


Evolution of Agile

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

Has significant parallels with “Lean movement”

in the manufacturing world

Is also similar to “spiral models”, except spiral

iterations are longer and rely on “prototypes,

where Agile emphasizes “working software”

7/28/2014


Providing early value

Value Realized

Time

Incremental delivery

All-at-once

Delivery

7/28/2014


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

7/28/2014


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.

7/28/2014


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.

7/28/2014



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.

7/28/2014



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.

7/28/2014


Agile Methodologies: Crystal Clear

Developed by Alistair Cockburn

Used by small teams (2-8 people) and based on the following 3 core principles Frequent delivery: Complete features and

deliver for pilot

Reflective improvement: Think about what is not working and fix it (process or code)

Osmotic communication: Entire team is co-located, everybody has the option of participating or ignoring

7/28/2014


Agile Methodologies: Feature Driven

Development

Developed by Jeff DeLuca with contributions from a number of others

Short phases that are completed “per feature”

8 principles of FDD Domain Object modeling to understand the domain

Developing by feature

Class “ownership”

Feature teams

Inspection

Regular builds

Configuration management

Visibility of reports (tracking and reporting)

7/28/2014


Agile methodologies: Dynamic Systems

Development Method

Iterative and incremental methodology

Time and resources are fixed; features are variable

Requirements categorized and prioritized according to the MoSCoW criteria M: Must have

S: Should have

C: Could have

W: Wont have this time

7/28/2014


Agile methodologies: Extreme

Programming (XP)

Emphasizes engineering practices to frequently deliver high quality products

Four basic values: Simplicity

Communication

Feedback

Courage

Recognized by practices like … Test-driven development

Pair programming

Continuous integration and re-factoring

Coding standards

7/28/2014

Rational Unified Process

Based on the software product by Rational

Software – later acquired by IBM

6 Best practices

Develop iteratively, risk as the primary driver

Manage requirements

Employ components-based architecture

Model software visually

Continuously verify quality

Control changes Bhawani Nandan Prasad - IT process expert 7/28/2014

Rational Unified Process (continued)

Four project lifecycle phases

Inception

Elaboration

Construction

Transition

Six engineering disciplines

Business modeling, Requirements, Analysis and Design,

Implementation, Test, Deployment

Three supporting disciplines

Environment, Configuration and Change management, Project

management


Rational Unified Process (Continued)



Scrum

Founded by Ken Schwaber, Mike Beedle,

Jeff Sutherland and others

Well known for simple, robust

management framework

Scrum is a rugby term where the team

huddles together before starting play

Very popular in the Agile community

7/28/2014

Scrum Cheat sheet

7/28/2014 Bhawani Nandan Prasad - IT process expert


Scrum Basics

Backlog

Item

Priority

Product

Owner

Inputs from Customers,

Team, Execs, Support,

etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint 1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup

Once agreed, Sprint end date &

deliverables do NOT change

7/28/2014


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

7/28/2014


Product Backlog

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint 1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup



7/28/2014


Product backlog

List of everything that could ever be of value to the business for the team to produce.

Defined in terms of “epics” and “user stories”

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

7/28/2014


Example of Product Backlog

Description Size

Utility to mark all positions to market

at end of trading day 20

Report on outstanding positions for

SEBI filing 10

On-the-fly introduction of securities

into intra-day trading 5

Upgrade server platform to JRE 1.6 5

Fix intermittent problem with index

window flickering (Defect

No.0002413)

10

Integrate Mark-to-market utility with

trading system (execute every hour) 20

List of requirements in

descending order of

priority

Can be …

Functional or non-

functional

Technical upgrades

Significant bug-fixes

7/28/2014


User Stories and Epics

Epic: High-level theme that combines a set of planned features or requirements Examples … Scalability improvements to handle processing rate of

100 transactions per second

Usability improvements

User Story: A short description of a planned feature or requirement. Examples … Modify server code to support multi-threading

Reduce the size of packets sent over

Reduce number of clicks to checkout to 5

Support Section 508 recommendations

7/28/2014


Epics and user stories

Can include any or all of the following

New features

Modification or Deletion of existing features

Bug-fixes to existing software

Internal clean-up tasks like code re-factoring,

support for new technologies, etc.

Should all result in “adding value” to the

customer!

7/28/2014


User Stories

Should be small

Typically no more than 40 man hours of effort

Should be deliverable as a unit (de-

coupled or loosely coupled)

Should be described in as much detail as

is necessary to “validate successful

completion”

May contain child stories or tasks

7/28/2014

Writing good user stories

Example templates

As a [role], I can [feature] so that [reason]

E.g. As a account holder, I can check my balances online so that I can

maintain daily balance

Use 3”X5” index cards (ensure that you don’t write too much)

Make it testable by writing acceptance criteria

Given [context] <and/or [some more context]> When [event] Then

[outcome] <and/or [another outcome]

E.g. Given account balance is negative and no direct deposit is scheduled

on the day when the account holder tries to withdraw money then the bank

will deny the request and send the account holder an alert

Connect the dots by thinking of all possible scenarios

More references:

http://www.agilemodeling.com/artifacts/userStory.htm



How to split stories Ref: Bill Wake’s “20 Ways to Split Stories”: http://xp123.com/xplor/xp0512/index.shtml

The Big Picture • Research vs. Action

If a story is too hard, one split is to spend some time researching solutions to it.

• Spike vs. Implementation You can buy learning for the price of a spike (a focused, hands-on experiment on some

aspect of the system).

A spike might last an hour, or a day, rarely longer.

• Main Flow vs. Alternate Flows (Use case terminology.) The main flow - the basic happy path - is usually the one with the

most value.

• Manual vs. Automated If there's a manual process in place, it's easier to just use that for a while before throwing it

away.

• Buy vs. Build Sometimes, what you want already exists, and you can just buy it. For example, you might

find a custom widget that costs a few hundred dollars. It might cost you many times that to develop yourself.

Other times, the "off-the-shelf" solution is a poor match for your reality, and the time you spent customizing it might have been better spent developing your own solution.

7/28/2014


How to split stories

User Experience

Batch vs. Online A batch system doesn't have to interact directly with the user.

Single User vs. Multi-User Keep concurrency, access control issues, etc. in abeyance for

some time.

API-only vs. User Interface It's easier to not have a user interface at all. For example, if

you're testing your ability to connect to another system, the first cut might settle for a unit test calling the connection objects.

Generic UI vs. Customer UI At one level, you can use basic widgets before you get fancy

with their styles. To go even further, something like Naked Objects infers a default user interface from a set of objects.

7/28/2014

http://www.nakedobjects.org/

http://www.nakedobjects.org/


20 ways to split stories

“Ilities”

• Static vs. Dynamic It's easier to calculate something once than ensure it has the correct value every time its

antecedents change.

• Ignore errors vs. handle errors While it's less work to ignore errors, that doesn't mean you should swallow exceptions.

Rather, the recovery code can be minimized.

• Transient vs. Persistent Let's you get the objects right without the worries about changing the mapping of persisted

data.

• Low fidelity vs. High fidelity You can break some features down by quality of result. E.g., a digital camera could start as a

1-pixel black-and-white camera, then improve along several axes: 9 pixels, 256 pixels, 10,000 pixels; 3-bit color, 12-bit color, 24-bit color; 75% color accuracy, 90% color accuracy, 95% color accuracy." (William Pietri)

• Small scale vs. large scale "A system that works for a few people for moderate data sets is a given. After that, each step

is a new story. Don't forget the load tests!" (William Pietri)

• Unreliable vs. Reliable "Perfect uptime is very expensive. Approach it incrementally, measuring as you go." (William

Pietri)

7/28/2014


Sprints

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint 1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup



7/28/2014


Sprints!

Refers to an “iteration”

Typically 1-4 weeks long

Produces an enhanced version of the software

All engineering activities (Code, Unit Test, System,

Regression test) must be completed within the Sprint

Should be “near releasable quality”

A “release” or project contains multiple sprints

As many as is necessary to create substantial “value” to

the customer

7/28/2014


Sprint at a glance

7/28/2014


Sprint Planning Meeting

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint 1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup



7/28/2014


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” (heijunka!)

Attended by Team, Product owner, Scrum Master

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

7/28/2014


Sprint Calendar - Example

Mon Tues Wed Thurs Fri

3 4 5 6 7

10 Sprint

Planning

11 First day of

Sprint

12 13 14

17 18 19 20 Last day of

Sprint

21 Review &

Retrospective

24 25 26 27 28

7/28/2014


How Sprint Planning should work

Clarifying questions about stories asked

Determine how many stories can “fit” into

a Sprint

Stories are broken down to tasks and

assigned to individuals

Estimates may be modified if necessary

Tip: Some pre-preparation (story-

grooming) helps make the meeting short

7/28/2014


Sprint backlog (planning template)

Story Task Owner Estimate Utility to mark all positions to

market at end of trading day

Generate and test query to get

open positions

Sanjay 2

Determine formula for M2M

based on regulations

Shreya 4

Call web service to custodial

services for margin calls

Kapil 8

Email notifications to account

owners about margin position

Manish 2

Write and execute unit tests Sanjay 8

Test story end-to-end Murali 16

Upgrade server to JRE 1.6 Changes to the build system

and installer

Larry 8

Try out latest patch of JRE 1.6

to make sure it works

Gaurav 16

Limited regression testing Alex 24

7/28/2014


No changes during a sprint!

Once team has committed, no changes can be made to the Sprint deliverables

Details will emerge during Sprint, but no new work or substantially changed work

No Changes to Sprint Duration either

Sprint ends on planned date whether has completed its commitment or not

The Product Owner can …

Change the Product backlog before the next Sprint

Terminate a Sprint (used very rarely)

7/28/2014


The team

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint 1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup



7/28/2014

The team!

Usually 7 + or – 2

As low as 3 or as high as 15

Resources can be shared (but ideally should not be)

Can change between Sprints (but ideally shouldn’t)

Can be distributed (but better when co-located)

Is “cross-functional”

Has all the skills necessary to produce another increment of

“potentially shippable” product

Is “self-managing”

Is empowered enough to do whatever it takes to produce the

potentially shippable product, within organizational constraints


Self-Managed Teams Game!



The “Scrum Master” role

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint 1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup



7/28/2014

Scrum Master

What he SHOULD do

Serve the team

Facilitate the team’s interactions

Help remove the “blocks” surfaced by the team

Protect the team

From outside interference or disturbance

Resolve conflicts internally and externally

Support the team’s use of Scrum

Organize and facilitate the Scrum rituals

Audit the compliance with Scrum practices


Scrum Master

What he SHOULD NOT do

MANAGE the team

DIRECT the team members

Assign tasks

“Drive the team”

Make decisions for the team

Over-rule team members

Direct product strategy or roadmap

Rule on technical issues



Daily Standup Meeting

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint 1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup



7/28/2014


Daily standup meetings

Ground-rules

Every weekday

Whole team attends

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

7/28/2014

Role of testing/QA in Scrum

No separate QA team

Quality is everyone’s responsibility

One team that is responsible for the

product delivery

No more adversarial relationship between Dev

and QA

QA is lot tougher with Agile

Near releasable quality each Sprint is a huge

challenge


Testing best practices

Continuous testing and regression

Automate as much testing as possible

Testers to participate in story elaboration

and estimation

Test early and test often

Close coordination between Developer and

Tester needed

Move towards “test driven development”


Test-Driven Development

Never write a single line of code until there

is a failed automated test

How to do it?

Design: Figure out what you want to do

Test: Write a test to express the design (it

should FAIL)

Implement: Write the code

Test again: Now the test should pass


Test frameworks/tools for TDD

Xunit

Junit (http://junit.org)

cppunit (http://cppunit.sourceforge.net)

Ruby

PHPunit

Jsunit

TAP (Test Anything Protocol)

http://testanything.org

Other test libraries

e.g. http://opensourcetesting.org

Use code coverage tools (e.g. Clover, Emma, Cobertura)


http://testanything.org/

http://opensourcetesting.org/


Orderly closure of Sprints

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint 1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup



7/28/2014


Sprint review

Purpose of Sprint Review

Demo (not just slides) what the team has built

Generate feedback which Product Owner can

incorporate in the product backlog

Decide about “release” of the builds to the

stakeholders (alpha, beta, etc.)

Attended by Product Owner, Managers,

Scrum Master and Team

Usually lasts 2 Hrs 7/28/2014

Sprint “done” criteria

Software with all features work as defined by the

user story

All QA testing for completed features is done

with no pending defects

Regression tests pass

All documentation is completed

Planned stories demonstrated to the Product

Owner, Customer and other stakeholders


What happens if Done criteria are not

met?

Incomplete stories move to the backlog

and prioritized again before the next Sprint

Retrospective to determine why the plan

commitment was not met

Under no circumstances can you “extend”

a Sprint!



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)

7/28/2014


How to make retrospectives effective

Have fun (e.g. bring in food, recognize star

performers from the previous sprint)

One person facilitates (Scrum Master)

Do not stifle opinion – collect all inputs

Arrive at few (2-3) things to change

Follow up!

Assign specific actions

Token penalty if improvements are repeated!

7/28/2014


Engineering best-practices

Continuous integration: “Automated”

nightly builds

Mandatory code reviews (integrated with

code check-ins) and unit tests

Automated testing:

Sanity tests, executed daily

Regression tests, executed per iteration

Test-driven development

7/28/2014


Typical life-cycle in a Scrum World

Repeated as long as it

takes to create a

releasable product

High-level Roadmap

For a Release

7/28/2014


Wrapping up the release!

Once the work required for the release is done Final readiness checks for a “release”

Can be preceded by one or more “hardening” sprints No new features added during hardening

Focus on fixing bugs, packaging, regression testing, performance testing, etc.

Hardening sprints can be split across the release (need not all be at the end)

Resist temptation to bank on hardening sprints to do required bug fixes – it quickly turns into waterfall in disguise

7/28/2014

Release “done” criteria

Customer acceptance received

Beta feedback incorporated

Release documentation (e.g. Release Notes, Read me

First, etc.) is completed

Non-functional requirements (e.g. Performance,

Usability, etc.) are tested and validated

Regulatory and compliance requirements are met (e.g.

Section 508, ECCN, License agreements, etc.)

All planned integrations with other products are tested

and working



Release Planning

Aims at coming up with a “long-term roadmap”

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

Estimate of what and how much can be accomplished in a release

Identify and tie up dependencies on external factors or events

Prepare 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

Product Owner and optionally other stakeholders can attend

Advance preparation (understanding epics, priorities, dependencies, etc.) help this go faster

7/28/2014

Release planning exercise



Managing Scrum Projects

Estimation

Tracking

Challenges

7/28/2014


Estimation

Types of estimation

Top-down

Ask the expert!

Analogous

Parametric

Bottom-up (Detailed)

Estimation is not necessarily more difficult

in Scrum, it is just that Scrum exposes bad

estimates quicker!

7/28/2014


Principles in estimating

Team (people who are actually working on

the stories) has the final word

Team can ask clarifying questions

Achieving precision in estimation is not so

important

Being “predictable” is!

7/28/2014


Ideal days

Number of days a story should take in “ideal” circumstances

This allows for expected distractions (e.g. normal worker only puts in 5 hours of actual work in an 8 hour day)

Conversion of ideal days to actual days depends upon … Whether the resource is novice or experienced

How much distraction should be accounted for

7/28/2014


Story points

Story points An analogous estimation technique

Establish a benchmark story that can be considered as 1 story point

Estimate other stories “relative to” the benchmark

Story points assigned are usually in modified Fibonacci series: 1, 2, 3, 5, 8, 13, 20

Correlation of story points to man hours is based on past experience

7/28/2014


Estimation game – Planning poker!

See www.planningpoker.com for details

and online version of the game

7/28/2014

http://www.planningpoker.com/


Tracking Agile Projects

Team should ideally manage progress – should

NOT be micro-managed

Tracking mechanisms

Daily stand-up meetings

Scrum-of-Scrums

Burn-down chart (automated or manual)

Progress chart

7/28/2014


Burn-down chart

7/28/2014


Burn-down basics

Tracks number of hours (or days) worth of

work remaining in the Sprint

Should be a downward sloping curve,

hitting zero before the last day of a Sprint

Requires data to be updated daily (could

be done during or after Daily Stand-up

meetings)

7/28/2014


Progress chart

7/28/2014


Progress Chart

Set of post-it notes (one per story) that

move from Planned to In progress to

Completed

Posted on a board at a place where it is

visible to the entire team

Clearly define criteria for “Done” or

“Completed”

Primitive, but highly effective!

7/28/2014


Agile Metrics

Velocity: Functionality delivered per iteration (story points or number of stories or another measure)

Defects per iteration (Absolute number or weighted average)

Other measures Standards violation per sprint

Level of automation (% of automatable tests)

Number of tests developed per story

Stories planned/Stories delivered

Scrum Maturity Model

Use metrics to target the behavior you want to encourage/eliminate!

7/28/2014


Stakeholders

Anybody who “can impact” or “can be impacted by” the project (for good or bad)

Common stakeholders Managers (various levels!)

Scrum Master

Team

Product Owner

Customer and/or sponsor

End user

Subject Matter Experts

Other political/vested interests

Chicken or pig?

7/28/2014


Communication guidelines

Type of Stakeholder Opportunities to engage

Who only want to ensure smooth

progress (e.g. Managers)

Involve in demos

Give access to dashboards and

metrics

Who are “result-oriented” (e.g.

customer, end-user)

Involve in demos, early

acceptance testing

Customize visibility

Give decision authority!

Who are direct contributors (e.g.

Team)

Involve throughout the project

(transparency and Trust)

Who are observers (e.g. SME’s) Involve in demos

Ask for opinions, participation 7/28/2014


Common (scrum-specific) risks

Integration challenges on complex inter-dependent projects Daily/Periodic integrations

Call out dependencies early and plan

Tendency to delay bug-fixes in a rush to complete features Use periodic “hardening” iterations

Define and follow “done” criteria for iterations

Blocking issues derailing Sprints Proactive tracking of blocking issues

Scrum Master to get Management attention

7/28/2014

Common (scrum-specific) risks

Team follows Scrum principles, but Product Owner, Management,

Customer don’t!

Educate everybody about Scrum (basic principles)

Find a way to meet everybody’s needs

Activities requiring lot of R&D/Design would never be done in one

Sprint

Find a way to break into modular tasks/stories

Make use of “Spike” stories

Previously deployed software breaks and customer

escalations block new work Reserve time for “Support” activities

Make a “Sustaining Engineering” team



Let us put it into practice!

Agile Simulation!

7/28/2014


Tools used in Agile 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/)

Freeware tools

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

Sprintr (http://www.sprintr.com)

7/28/2014

http://studios.thoughtworks.com/mingle-agile-project-management







http://www.versionone.com/

http://xplanner.org/index.html


“Managing” Agile projects

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 …

Provide “Functional” and/or “Technical” expertise – help the team solve

problems

Help the team understand the larger context of the project

“Protect” the team during prioritization battles

Foster the right “culture” in the team – team metrics over individual

Represent the team at external forums

Be risk managers for the projects

Administer rewards and recognition!

Focus on “What” to do (portfolio decisions) rather than “How”

Additional reading: http://www.infoq.com/articles/scrum-

management-deemer

7/28/2014

Applying Agile on Maintenance and

Enhancement projects

Ask yourself these questions:

Can you define a clear, prioritized backlog?

Can you estimate your “defect fixes” with reasonable accuracy?

If the answers to both is YES, then you can apply Agile

techniques

Provide a larger buffer for uncertainties

References:

http://www.linkedin.com/answers/product-management/product-

design/product-design/PRM_PDS_PDG/166734-863751

http://agileworld.blogspot.com/2007/04/applying-agilescrum-

practices-in.html


http://www.linkedin.com/answers/product-management/product-design/product-design/PRM_PDS_PDG/166734-863751









Agile in RFP responses

Advantages you can highlight to your customer:

Customers get early visibility (potentially an alpha

drop every few weeks!)

Customers get nearly infinite capacity to change

requirements (in between Sprints)

But you must forewarn them that:

You expect much more involvement from the

“business” (directly or through Product Owner)

They cannot expect instant gratification on change

requests

The team must be allowed to “self-manage” Bhawani Nandan Prasad - IT process expert 7/28/2014

Agile in Fixed Price projects

In the event of a change in scope, you could

either –

Add Sprints to your release/project (additional cost)

Trade one feature for another (re-prioritize) at no cost

to the customer

In a nutshell, Change Management process

would work the same way as before

But you would get much more flexibility to absorb

change


Agile in Distributed Teams

Same “best practices” that work on all

distributed teams

Cultural exchange/sensitivity

Team pages with pictures

Invest in collaboration tools (Webex,

Livemeetings, Skype, Video conferences, etc.)

Schedule Scrum rituals to suit everybody’s

timings – if necessary, share the pain!


Parallels of Agile with Lean

5 Principles of Lean

Specify the value

Identify the value stream (what creates value)

Create Flow

Manage using “pull” based systems (Kanban)

Strive to achieve perfection


Basic tenets of Lean

Reduce waste/re-work, by …

Avoiding production of items not needed

Keeping minimum inventory

Preventing unnecessary processing

Preventing unnecessary movement of people

Preventing unnecessary transport of goods

Reducing waiting time

Not producing anything that does not meet a customer

need


Kanban v/s Agile

Kanban is actually a system for process control

Invented by Taichi Ohno at Toyota (>50 years ago)

Principles of Kanban:

It is a “pull based system”

There is only a small “buffer” in front of each

processing step

The system is continuously improved by “Kaizen”

Some teams use a Kanban system on

software projects to maintain a constant flow of

items through the software life-cycle Bhawani Nandan Prasad - IT process expert 7/28/2014

Kanban v/s Agile

Kanban emphasizes “flow” rather than

iterations

Work done immediately reduces “induced

waste”

Focus on time and reducing delays

Time from getting information till we need it

(e.g. requirements)

Time from making an error to fix it

Time from needing information and getting it


Cycle time


Request

0.5

Approve

0.1

Requirements

60

Signoff

1

Analyze

40

Design

40

Review

2

Code

80

Test

40

Deploy

3

80 80 80 80

40

80

80 80 80

20% rework 65% rework

Actual time spent = 0.5+0.1+60+1+40+40+2+(0.2*(40+2))+80+40+0.65*(80+40)+3 = 353

Elapsed time = 353+80+80+80+80+80+2*40+80+2*80+80 = 1173

Process cycle efficiency = 353/1173 = 30%

7/28/2014

Kanban Board


Approved Under

review

Ready

For

Dev

Analysis Ready

For

Design

Design Ready

For

Code

Coding Ready

For

Test

Test Ready

For

Deploy

Deploy

7/28/2014

Agile certifications: Certified Scrum

Master

Scrum Alliance (www.scrumalliance.org): Offers Certified

Scrum Master and Certified Scrum Product Owner

Requirements

Attend a Scrum training given by a “Certified Scrum Trainer”

Costs between $500-$1000

Scrum Trainer submits application

Pass an online evaluation

Renew it every 2 years

For more details see:

http://www.scrumalliance.org/pages/faq_training_and_ce

rtification


http://www.scrumalliance.org/

http://www.scrumalliance.org/pages/faq_training_and_certification

http://www.scrumalliance.org/pages/faq_training_and_certification

Agile certifications: Professional

Scrum Master

Launched by Ken Schwaber

www.scrum.org

Professional Scrum Master (2 levels)

Also Professional Scrum Product Owner (2

levels) and Professional Scrum Developer

Open to all (pass assessments at 85%

passing mark)

Scrum.org also offers trainings

$100 for Level-1 and $500 for Level-2 Bhawani Nandan Prasad - IT process expert 7/28/2014

Agile certifications: PMI – Agile

Certified Professional

Offered by Project Management Institute (www.pmi.org)

Costs $435 (members) and $495 (non-members)

Membership $129

Requirements

1 year of General Project Management experience and 8 months

of Agile Project management experience

21 hours training required

Assessment (100 multiple choice questions)


http://www.pmi.org/


Important links

Scrum Alliance

www.scrumalliance.org

Ken Schwaber’s site on Scrum

www.scrum.org

Agile references

www.agilealliance.org

www.agilebok.org

http://agile.vc.pmi.org/Public/Home.aspx

7/28/2014



http://www.agilealliance.org/

http://www.agilebok.org/

http://agile.vc.pmi.org/Public/Home.aspx

To sum it up!

Advantages of Agile

Helps to reduce “waste”

by always focusing on

highest priority items

Enforces disciplined

change management,

while greatly enhancing

ability to absorb changes

Enhances “visibility” into

the development process

and improves productivity

Disadvantages of Agile

Some teams and some

people will not like it

Partial or haphazard

implementation of Agile

will makes things worse

than before!

It will not resolve your

engineering problems –

but it will make it visible

sooner!



Risk Management in Agile

Risk: An “uncertain” event that may impact an expected outcome for good or bad

Agile has in-built risk management mechanism because it will make things visible sooner!

Facets of risk events Probability

Impact

Response

7/28/2014

Transforming to Agile

Must

If Waterfall is working for you, do not use Scrum – Ken

Schwaber!

Understand what you want to get out of Agile and measure what

you are getting

Get customer and senior management buy-in

Good to do

Education for key roles: Scrum masters, Product Owners and

also for General Managers

Get a coach/mentor, join communities

Some people/teams will never be comfortable – do not force

them!



Sample risk register

7/28/2014

Managing large/integrated teams

Multiple teams working on the same

product or application

Split in a way that each is at least

somewhat de-coupled from each other

Each team should be cross-functional

Manage dependencies and integrations

carefully

Scrum of Scrums

Product coordination teams



Scrum-of-scrums

Useful in situations where multiple scrum

teams are working for a single or

integrated set of projects

Representative from each Scrum attends

SoS focuses on the “inter-dependencies”

SoS need not be daily

Frequency depends on the nature of the

dependencies

7/28/2014

Product coordination team

Identify few (2 or 3) people whose job is to

coordinate across teams

Opportunities to coordinate

High priority epics or stories that require

multiple teams to work on

Technical dependencies

Ensuring consistency and uniformity of design

Coordination may be a full-time or part-time role


Which methodology is best?

RUP is a pretty good framework for enterprise, large

scale projects with a high level of complexity and inter-

dependencies

if you can afford to buy their tools

FDD is good if you are big on OO methodology

Crystal Clear is good if you have co-location

XP is good if your challenge is engineering practices

Scrum is good for a robust management framework –

and is by far the most popular!

There isn’t a right or wrong methodology – use one that

works for you!



Thank You

[email protected]

Certified scrum Master \

Product Owner

7/28/2014

mailto:[email protected]

software development with scrum methodology bhawani nandan prasad

Technology