Agile formanagers by-bhawaninandanprasad

Bhawani Nandan Prasad

Agile for Managers

Author: Bhawani Nandan Prasad

EMBA in Senior Management Program from IIM Calcutta MBA in Marketing and

General Management from Stratford University, Virginia, USA

B.E. Computer Science from BITS


Objective

To help you understand the principles of Agile software development and better “manage” software development projects using the Agile methodologies

Agenda

Why Agile?

Agile/Scrum primer

Basics of “managing” in Agile

Planning Agile Projects

Monitoring and controlling

Projects involving multiple teams

Risk management in Agile

Managing distributed Agile teams

Communication on Agile projects

Agile contracting

Summary, Q&A


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

74% of IT professional surveyed had practiced Agile in

some form or other; 55% for 2 years or more

Love it or hate it, you cannot IGNORE Agile!



Problems with Software Development

Excessively long “time to market” for products

Customer orientation is lacking

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

Usage of features in a system


Waterfall v/s Agile


Agile primer

Agile means incremental; iterative development

Develop in small chunks, learning from each

experience

There are various methodologies, which can be

called “Agile”

Scrum, Extreme Programming, FDD, DSDM, Crystal,

AUP, etc.

The main purpose of being Agile is to be

“responsive” to the customer and to be “flexible”

Please see: http://www.agilemanifesto.org


http://www.agilemanifesto.org/

Agile principles about “management”

Principle No. 2: Welcome changing

requirements, even late in development. Agile

processes harness change for the customer’s

competitive advantage

Customers want a change => You must try to fulfill it

=> Coach the team to be flexible and adaptable

Principle No. 4: Business people and developers

must work together daily throughout the project

Build teams in a way that fosters open communication

between the “business” and the development team


Agile principles about “management”

Principle No.5: Build projects around motivated

individuals. Give them the environment and

support they need, and trust them to get the job

done.

Spend a lot of time around “building high performance

teams” => You manage the team; the team manages

the project

Principle No.11: The best architectures,

requirements and designs emerge from self-

organizing teams

Let the team “self-organize”; Do not “interfere”



Basics of Scrum life-cycle

Backlog

Item

Priority

Product

Owner

Inputs from Customers,

Team, Execs, Support,

etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup

Once agreed, Sprint end date &

deliverables do NOT change

What a manager should NOT do

A manager having “line” or “reporting” authority

should NOT

Second guess team’s estimates

Assign tasks

Technical decisions for the team

Over-rule team decisions about process

Rule over product roadmap or priorities

Compromise principle of “self-management” and “self-

organization”



So what SHOULD a manager do?

A project manager or coordinator operating in a “matrix”

environment can be trained to morph into a Scrum Master

Line managers should …

“Build” the team with the right “culture” in the team

Become mentor or coach

Help the team understand the larger context of the project

“Protect” the team during prioritization battles

Represent the team at external forums

Help the team manage risks

Administer rewards and recognition!

Become “servant leaders”

Manager 2.0: A new role for the manager (Pete Deemer) http://www.scrumalliance.org/articles/148-manager--the-role-of-the-manager-in-scrum

http://www.scrumalliance.org/articles/148-manager--the-role-of-the-manager-in-scrum


Managers role in planning

Provide the pre-requisites/hygiene factors for planning Identify and invite appropriate stakeholders

Meeting location; travel budget; team building

Ensure a good “process” is in place for decision making. E.g. Use of appropriate techniques (e.g. Brainstorming) and

participation

Help with conflict resolution if necessary

Ensure the right “principles” are being used in planning. E.g. Team’s estimates have to be respected

How much to “pack” a release?


Principles in estimating

Underestimation is typically underestimated (i.e.

overestimation is overestimated)

Most leaders always feel the urge to deal with

overestimation, but rarely feel the need to deal with

underestimation

But underestimation is more prevalent and perhaps

more dangerous

Nothing is impossible for the man who doesn’t have to do

it himself (A.H.Weiler)

It always takes longer than you expect, even if you take

into account Hofstadter’s law

So what do managers do with

estimates?Know (and respect) the team’s estimates

Help the team defend estimates and to convey them

gracefully

Provide a range of values based on the amount of

information available and confidence level

Be transparent about buffers needed

Use appropriate anchors based on historical data

(bring your experience to bear)

Come up with options to make decisions palatable

Option-1: All features and extend the date

Option-2: Keep the date and cut some features

Don’t say YES when you want to say NO

Monitoring and Controlling

The team should monitor and control its

own progress

The manager should:

Ensure checks and balances with a “light touch”

approach

Help the team come up with the right “metrics”

Take decisions when re-planning or re-

baselining is necessary

Focus on building and enabling the team


Information radiators

Anything that makes information visible

Has to be easily noticeable, with minimum

of effort

Purpose is to make progress (or lack of it)

visible

Based on the principle of “stop to fix

problems” – Andon calls

Enable the team to take the “right” actions


Information radiator (examples)


Information radiator (examples)



Burn-down chart

Burn-down chart (bar charts)



Progress chart

Cumulative Flow Diagram (example)Backlog Status (Story Points)

Defined In-Progress Completed Accepted

223 61 9 115.25

Velocity

Last 2 Iterations 93

Best 2 Iterations 93

Worst 2 Iterations 93

Summary

With current velocity and iterations remaining, expect to conclude Release as scheduled.

MAR AP

R

MAY JU

N

AUG SE

P

OC

T

JU

L

I3

6/22 – 7/17

I5

8/03 – 8/28

I1

4/27 – 5/22

I2

5/25 – 6/19

I4

7/20 – 7/31

I6

8/31 – 9/25

I7

9/28 – 11/13

NO

V

Solution: AO 7.6



Other types of charts

Parking lot diagram Niko Niko calendar


Agile Metrics

Einstein: Everything that counts cannot be counted, everything that can be counted, does not count

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

Defects per iteration (Absolute number or weighted average)

Other measures

Escaped defects

Standards violation per sprint

Level of automation (% of automatable tests)

Number of tests developed per story

Stories planned/Stories delivered

Scrum Maturity Model

Earned value management

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

Performance management

How does manager get feedback about

performance of team members?

Through regular 1X1’s: Interaction with team

Feedback from stakeholders

Feedback from peers

Do NOT use numeric objectives for individuals

Round-the-year appraisals


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 (Look-ahead planning)

Scrum of Scrums

Product coordination teamsBhawani Nandan Prasad


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

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



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 eventsProbability

Impact

Response

Common risk areas for projects

Intrinsic schedule flaw (wrong/incorrect

estimates)

Specification breakdown (failure to

achieve stakeholder consensus)

Scope creep

Personnel loss

Productivity variationReference: The software project manager’s bridge to agility; Michele

Sliger and Stacia Broderick, Addison Wesley (2008)



Common risks on Agile projects

Integration challenges on complex inter-dependent projectsDaily/Periodic integrations

Call out dependencies early and plan

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

Define and follow “done” criteria for iterations

Blocking issues derailing iteration goalsProactive tracking of blocking issues

Scrum Master to get Management attention

Common risks on Agile projects

Team follows Agile principles, but other stakeholders,

Management, Customer don’t! Educate everybody about Agile (basic principles)

Find a way to meet everybody’s needs

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

done in one iteration 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


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 Agile rituals to suit everybody’s

timings – if necessary, share the pain!


Communication

There is no such thing as “over-

communication”

It takes 7 exposures and 3 hits to internalize a

message

Osmotic communication

Ref: Agile software development: A cooperative

game by Alistair Cockburn

Encourage transparency and feedback

Remove barriers to communicationBhawani Nandan Prasad

Agile workspaces

Co-locate to the extent possible

Plenty of white-board space and space for information

radiators

Pairing work-stations

Necessary facilities and spaces nearby (e.g. Pantry,

terminals for net surfing, etc.)

Caves and commons: Space for private work as well as

project work

Erg second: Amount of time spent in “waiting for a

response”



“Selling” Agile

Advantages you can highlight:

Customers get early visibility (potentially an alpha drop every few

weeks!)

Customers get nearly infinite capacity to change requirements

(in between iterations)

But you must forewarn them that:

You expect much more involvement from the “business”

They cannot expect instant gratification on change requests

The team has to be given autonomy to be self-managing:

Their estimates have to be respected!

They decide how to go about their work

They cannot be disturbed in the middle of the iteration


Copyright (c) Sandeep Shouche 2011

Contract types

Contract typesCost reimbursable (Cost risk with the buyer)

Cost plus fixed fee (seller’s profit is known)

Cost plus incentive fee (costs + fees + bonus)

Cost plus award fee (award at buyer discretion)

Cost plus percentage

Time & Material (When buyer wants to be in control, usually for small amounts)

Fixed price (Cost risk with the seller)Firm FP

FP with incentive fee

FP with Economic Price Adjustment

Revenue/Profit share

Agile in Fixed Price projects

Agile manifesto: We value customer collaboration over

contract negotiation

Agile principle: We welcome changing requirements,

even late in the project – agile processes must harness

change for the customer’s competitive advantage

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


Rolling agile contracts

Try to reflect the agility in development

also into the contracting. For example …

Allow for a high-level initial statement of work,

without getting too detailed (allow details to flow

in later)

Mechanism for customer to accept deliveries

faster (and release payments faster)

A mechanism for cancelling the contract at any

time (whenever sufficient value is realized) –

perhaps by paying a base amountBhawani Nandan Prasad

Outsourcing Agile projects

Along with other competencies, check if the team is

competent with Agile

As far as possible, outsource logical chunk of work

through a SoW

Appoint a Product Owner or Onsite Customer

representative

Be aware of your responsibilities as a customer – attend

demos, provide timely feedback, no changes in the

middle of iterations

Treat contract team exactly like “your team”

Transforming to Agile


Ken Schwaber (co-founder of Scrum)

If waterfall is working for you, do not follow Scrum

75% of the teams that use Scrum are not getting full value from

it

Having said that:

The successful implementation of Scrum will have a profound

transformation

Start on the journey anticipating resistance, but also start only if

you are convinced about the benefits



Step-1: Start with one or few teams that are willing to try it

out

Do not start if customer AND/OR senior management is not willing

Skepticism is fine (even welcome), but resistance to change or

closed mind is dangerous

Find a champion or evangelist who is influential

Step-2: Understand what you are trying to achieve and find

a way to measure it

Sell the benefits, but do not over-sell it

Fore-warn people that it is hard

Step-3: Call it a pilot for as long as possible

This will make the initial chaos and mess easier to accept



Step-4: Be prepared to help:

Education for team members is important

Assign a coach/mentor; do not assume they will solve all problems

on their own

Spend a lot more time with people who hate Scrum – find a way to

involve them in the change

Achieve initial successes and over-communicate about it

Step-5: Understand some teams and people will NOT like it

Do not force them or get drawn into a battle

Ask if it is at least “better than before”?

Make it safe for people to change their mind or withdraw

Summary

Make the team self-managing

Team manages the project

Manager is a “servant leader”

Manager manages the team and “environment”

Coach the team to make reliable plans

Establish a good set of metrics for tracking

Ensure smooth communication and

information radiators


Summary

If you have multiple teams working on the

same project

Make sure they are set up correctly

Create integration forums

Encourage team to flag risks and deal with

them (earlier you fail, faster you recover)

Ensure contracts are set up correctly and

are able to support agility



Thank [email protected]

Technology

Agile formanagers by-bhawaninandanprasad