Agile formanagers by-bhawaninandanprasad
-
Upload
bhawani-nandan-prasad -
Category
Technology
-
view
85 -
download
0
description
Transcript of 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
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
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!
Bhawani Nandan Prasad
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
Waterfall v/s Agile
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
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”
Bhawani Nandan Prasad
Bhawani Nandan Prasad
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”
Bhawani Nandan Prasad
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
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?
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
Information radiator (examples)
Bhawani Nandan Prasad
Information radiator (examples)
Bhawani Nandan Prasad
Bhawani Nandan Prasad
Burn-down chart
Burn-down chart (bar charts)
Bhawani Nandan Prasad
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
Bhawani Nandan Prasad
Other types of charts
Parking lot diagram Niko Niko calendar
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
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
Bhawani 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
Bhawani Nandan Prasad
Bhawani Nandan Prasad
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)
Bhawani Nandan Prasad
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
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!
Bhawani Nandan Prasad
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”
Bhawani Nandan Prasad
Bhawani Nandan Prasad
“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
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
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
Transforming to Agile
Bhawani Nandan Prasad
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
Transforming to Agile
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
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
Bhawani Nandan Prasad
Bhawani Nandan Prasad
Thank [email protected]