Agile for Managers Guide

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

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
Sprint
1-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

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)

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

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 events
Probability
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 variation
Reference: 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 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 iteration goals
Proactive 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 communication

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 types
Cost 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 amount

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 You
bhawani_Nandan@yahoo.com

Agile for Managers Guide

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (15)

Semelhante a Agile for Managers Guide

Semelhante a Agile for Managers Guide (20)

Mais de Bhawani N Prasad

Mais de Bhawani N Prasad (20)

Último

Último (20)

Agile for Managers Guide