Agile For PMs v6

IBM Global Business Services
Agile for Project Managers
1 Introduction to Scrum | 2013 © Copyright IBM Corporation 2016

Agile - What It Is
A methodology?

A process?
 A
a product
development &
management

framework
A project
management
tool?
2 © Copyright IBM Corporation 2016

The Agile Manifesto – 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.

The new way of Working

Iterative and Incremental
Vertical Slices
User Interface
Object Model Vertical Slice – real

business value in
one iteration
Data Model

Meeting or exceeding a planned ROI based on staying within

budget and time has clear economic benefits - Risk is a key
value driver.
Agile Value Delivery
n.. iterations
High
Risk vs. Value Working Increments
Low Illustrative only
Time
All risks taken are limited in time through time boxed iterations. Time boxing allows
adaptation and adjustment within the development and maintenance process.
Source Picture: http://guntherverheyen.com/category/agile/page/3/

How Will It Help?
 Micro-
manage?
 More control to
the Product
development
team
Agile helps deliver
“Business Value”,
More control More visibility rather than just
on the to the “Projects” by
resources? Customer providing control,
visibility and
flexibility
Things
More flexibility
delivered on
to the
time and within
Management
budget?

Agile Framework
Agile Framework
Agile is a conceptual framework for undertaking software

engineering projects
Extreme Dynamic Systems

Programming (XP) Scaled Agile Feature
SCRUM Unified Process Crystal Development Kanban
Framework Driven Dev
Method (DSDM):
•Based on values •Small teams of •Frequent •interactive •3 primary phases: •Develop feature •Incremental,
•Simplified version
of simplicity, 8-12 people Delivery knowledge base Pre-Project, list, Plan, Design, Evolutionary
communication, of Rational Unified
for implementing Project Life-Cycle , Build by Feature Change
feedback, Process – reduced •Reflective agile practices
•“Backlog” defined improvement Post-Project
courage, requirements that at enterprise •Kanban board
and respect will be addressed scale help team
understand how
in each Sprint •Based on Lean they are doing
•Start with simple
solution, add and Agile and also what to
•Daily 15 min. principles do next
complexity Scrum meeting
through to discuss
refactoring work for the day
Agile Techniques: The above methods involve a range of techniques including:

Test-driven development Continuous integration Static Analysis
Planning game Design improvement Coding standard
Pair Programming Small releases Sustainable pace
Refactoring Simple design Whole team

Waterfall versus Agile: Four Key Differentiators

Waterfall Agile
• Solution outline • Sprint based (Short runs)
• Design, Coding, Unit testing • Frequent releases
• Integration test 1. Process • Backlog based approach
• Deploy, Go-live • Ceremonies
• BRD, SRD, solution architecture, • EPICs User Stories

test strategy, test plan
• Backlogs & Sprint plans
• Architecture models, design 2. Deliverables • Deployed code (frequent)
models, unit test cases
• Test Plans & Test scripts
• Deployed code
• Project management tools (MPP / • Rational Toolset (RTC, RRC,

Excel Plans) RQM and so on.)
• Rational Toolset (RTC, RRC, RQM, 3. Tools • Urbancode Deploy / Release /
and so on) custom Jenkins
• Development tools / IDEs
• BRR, SRR, PDR, CDR, TRR, PRR • Sprint Review

4.
• Overall Progress tracking (Cost, Governance / • Sprint Retrospective
effort, progress % and so on.) Metrics • Product Demo
• Burn-down & Burn-up

What Is Scrum?
 Scrum refers to a holistic or “rugby” approach—where teams goes the distance as

a unit, passing the ball back and forth—as opposed to the traditional sequential or
“relay race” approach for managing new product development

Scrum Framework
Roles
Product Owner
Scrum Master
Team
Stakeholders Ceremonies
Sprint Planning
Daily Scrum Meeting
Sprint Review
Sprint Retrospective Artifacts
User Stories
Product Backlog
Sprint Backlog
Burn Down Charts

Scrum Framework
Roles
Product Owner
Scrum Master
Team
Sprint Planning
Daily Scrum Meeting
Sprint Review
User Stories
Product Backlog
Sprint Backlog
Burn Down Charts

User Stories: Components
A User Story describes functionality that will be useful to a stakeholder of the system.
User Stories are comprised of three things
1 2 3
A brief description of
Conversations about Tests that convey
the story used for
the story and document details
planning
4 5
Assumptions Estimating Elements
IBM Customized Additional Elements

User Story Prioritization - MoSCoW
Letter Stands for Which means

 Minimum set of essential requirements, without which the
M Must Have system would be useless (MMF)

 All of these requirements must be satisfied.
 Important requirements for which there is a short-term work-
around. The system is useful without them.
S Should Have  These requirements can be included in the initial project

scope, but may be removed from the project scope to
accommodate changed requirements.
 These requirements are valuable and nice-to-have, but can
easily be left out of the solution.
C Could Have
 These requirements may be left out of the initial scope of the
release in order to accommodate a time constraint.
 Time-permitting
Would Have/Won’t
W have
 As changes to requirements or project progress dictates, lower
priority requirements may be removed from the scope of the
project.

Product Backlog
Product Owner lists items in descending order of priority (highest priority item is
listed first, next-highest is second, etc.)

Product and Sprint Backlog
Product Backlog Sprint Backlog

• The Requirements • Individuals signs up for work of
• A list of all desired work on the their own choosing
project • Estimated work remaining is
• Ideally expressed such that each updated daily
item has value to the users or • Any team member can add,
customers of the product delete, change the Sprint backlog
• Prioritized by the Product owner • If work is unclear, define a sprint
(MoSCoW rule) backlog item with a larger
• Reprioritized at the start of each amount of time and break it
Sprint down later
• Update work remaining as more
becomes known

Burndown Chart

Scrum Framework
Roles
Product Owner
Scrum Master
Team
Sprint Planning
Daily Scrum Meeting
Sprint Review
User Stories
Product Backlog
Sprint Backlog
Burn Down Charts

Sprint Planning
19

Sprint Planning
What’s on the Product

 Team understands details of what Product Owner has Owner’s “shopping list”?
prioritized on Product Backlog
 Team decides how much productive time it has available How much “money” do we
during the Sprint have in our bank account?
 Team decides how many Product Backlog items it can How many items on the
commit to complete during Sprint shopping list can we afford to
“buy” with that “money”?

Daily Scrum Meeting
 Every weekday
 Whole team attends
 Everyone stands
 Lasts 15 minutes or less
 Everyone reports 3 things only to each
other
– What was I able to accomplish since
last meeting?
– What will I try to accomplish by next
meeting?
– What is blocking me?
 No discussions or conversations until
meeting ends
 Product Owner can attend and report
 Update of artifacts after standup
 Following the Scrum meeting, team
updates the Product Backlog and Scrum
Master updates the Burndown Chart

Task Board
TO DO IN PROGRESS DONE
Task: Configure database Task: Configure database Task: Configure database Task: Configure database
and SpaceIDs for Trac and SpaceIDs for Trac and SpaceIDs for Trac and SpaceIDs for Trac
Owner: Sanjay Owner: Sanjay Owner: Sanjay Owner: Sanjay

Time Remaining: Time Remaining: Time Remaining: Time Remaining:
4 hrs 4 hrs 4 hrs 4 hrs
Task: Configure database Task: Configure database Task: Configure database

and SpaceIDs for Trac and SpaceIDs for Trac and SpaceIDs for Trac
Owner: Sanjay Owner:` Sanjay Owner: Sanjay

Time Remaining: Time Remaining: Time Remaining:
4 hrs 4 hrs 4 hrs
Owner: Sanjay Owner:` Sanjay Owner: Sanjay Owner: Sanjay


Owner: Sanjay Owner: Sanjay Owner: Sanjay

4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs


Task Board



4 hrs 4 hrs 4 hrs
Owner: Sanjay Owner: Sanjay Owner: Sanjay Owner:` Sanjay



4 hrs 4 hrs 4 hrs



Owner: Sanjay Owner: Sanjay Owner:` Sanjay

4 hrs 4 hrs 4 hrs
Owner: Sanjay Owner: Sanjay Owner:` Sanjay Owner: Sanjay


Task Board



4 hrs 4 hrs 4 hrs



4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs


The Sprint Review
26

Sprint Review
 Purpose of the Sprint Review is

– Demo what the team has built
– Generate feedback which the Product Owner can incorporate in the Product
Backlog
 Attended by Team, Product Owner, ScrumMaster, functional managers, and
any other stakeholders
 A demo of what’s been built and not a presentation about what’s been built
– No Power Points allowed!
 Usually lasts 1-2 hours
 Followed by Sprint Retrospective

The Sprint Retrospective
28

Sprint Retrospective aka Review and Improve

 What is it?
– 1-2 hour meeting following each Sprint
Demo
– Attended by Product Owner, Team and
ScrumMaster
– Usually a neutral person will be invited in
to facilitate
– Presents what’s working and what could
work better Four Square Method
 Why does the Retrospective matter?
– Accelerates visibility
– Accelerates action to improve

Scrum Framework
Roles
Product Owner
Scrum Master
Team
Sprint Planning
Daily Scrum Meeting
Sprint Review
User Stories
Product Backlog
Sprint Backlog
Burn Down Charts

Roles
1. Development Teams
What They Are/Do

 What They Aren’t/Don’t Do

 Are responsible for implementing the  Pick up tasks that are dependent on
product other members, instead carry out “paired
 Are self-organizing and comprise full- programming”
timers  Change the requirements without
 Are cross-functional consulting the Product Owner
 Follow Continuous Integration  Design the entire solution at once
 Identify the deployment strategy early in  Keep work shelved for a long time
the game  Delay testing activities
 Reuse as much as possible  Waste time creating unnecessary
 Refactors as they go documentation, instead they automate
 Attend daily scrums without fail  Waste time trying to resolve external
issues, instead they seek help from the
Scrum Master

Roles
2. Scrum Masters
What They Are/Do


 Act as "Servant Leaders“ and Process  Own the Development team
Coaches  Own the product
 Remove obstacles  Change the requirements without
 Protect the Development Teams from consulting the Product Owner
external influences  Assign tasks to Development Team
 Chart the Agile Methodologies suitable members
for the team  Micro-manage
 Run Sprint Retrospective meetings
 Empower each team member by
encouraging them to openly
communicate their challenges
 Represent the management to the
team/project and vice-versa

Roles
3. Product Owners
What They Are/Do


 Ensure optimal business value is  Own the individuals and tasks
achieved  Micro-manage
 Own the Product and the Development  Re-define any Agile processes to fit into
Teams (as a whole) the project without consulting Scrum
 Own schedule, scope, and cost Masters
 Perform product backlog prioritization  Assign tasks to Development Team
 May act as a customer proxy members
 Encourage Development Teams to self-  Define schedule, scope, and cost all
serve alone
 Encourage innovative ideas  Use defects to assess quality
 Promote refactoring and redesign, cross  Change Development Team members
training, and automation regularly
 Run Sprint Review meetings
 Represent the customer to the team and
vice-versa
No Changes During Sprint

Principles of Agile Metrics
 Affirms and reinforces Lean and Agile principles

 Measures outcome, not output
 Follows trends, not numbers
 Don't produce metrics that no one wants
 Don't introduce metrics that require significant work to produce.
 Provides feedback on a frequent and regular basis
 Be honest about how management uses metrics. Don't use metrics to
compare teams or individuals
 Take team maturity into account when selecting metrics
 Use metrics as a basis for discussion, not as a final decision point

Metrics
Must Have Nice to Have
• Project Lag
• Technical Debt
• Value per Sprint
• Velocity • Customer Satisfaction
• Burndown • Scrum Master Efficiency
• Burnup • Number of Stories (in story points)
• Estimates vs. Actuals Released
• Defect Density • Number of Stories (in story points)
• Defect Distribution Accepted by the customer
• Defect Escape Density • Amount of work deferred from Sprint
• Code Coverage • Amount of extra work “Done” in the
• Attendance in Sprint Meetings Sprint
• Static Code Analysis • Number of tasks added or removed
• No. of Features Accepted during sprint
• Percentage of Features Completed • Availability of Product Owner
• Number of times code checked in
(measures CI)

5 Levels of Agile Planning

Release planning

Velocity – Based on Historical Data
Team’s Recent Sprints
90 points
120 points
100 points
~105 size points per Sprint

How to Plan a Release in Scrum
 Prioritize the tasks – MoSCoW Principle

 Calculate velocity then apply to the Product Backlog:
Team’s velocity is
~105 points per
Sprint
This is 620 points
Therefore, in 6 of Product Backlog
Sprints, the team
should be able to
complete 6 x 105
= 630 points worth of
Product Backlog

Estimation Guidance
Agile estimation can get tricky and there are multiple ways of doing it. The most widely used
method is explained below, using t-shirt production as an example:
Development Team and Product Owner do high-level size estimation of the Product
1 Backlog by assigning t-shirt sizes. This is done during Product Backlog Refinement.
Example: Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL), and so on.
The t-shirt sizes are then converted to story points. This is done during Product Backlog
2 Refinement.
Example : The t-shirt size "XS" can be assigned a value of 2 story points, "S“ 3 story
points, "M" 5 story points, "L" 8 story points, "XL" 13 story points, and so on. The story
points are ordered in progressive increments, such as Fibonacci series (as in our
example), or multiples of 2, and so on.
Story Points are then further refined as ideal days for sprint backlogs and ideal hours for
3 tasks. This is done during the Sprint Planning.
Example : A backlog item of size 5 story points can take 4 days to complete, which again
can be broken into individual tasks that may take anywhere between 2-8 hours to be done.

IBM@Agile Estimating Process

Sales &
Solutioning Design & Delivery
Signed Contract
Discover Sprint 0 Sprint 0 - n
Planning Poker
SLIM Estimate Assign Estimates
SLIM Estimate Agile Adjuster to the Stories
Initial Top Identify Initial Sprint Identify Create Create

Down Sprint & Release (Update) Product Sprint
Estimate Length Planning Velocity Backlog Backlog
Focus: Focus:
Full Life Cycle : Full Life Cycle
Optional:
Advises Only used for
Scheduling
Solution Manager Delivery Team Delivery Team
Recommendation: Top-down (fully lifecycle) estimate required discovery phase

42 1 © Copyright IBM Corporation 2016
0
Module 6:
Using Scrum for
Multi-Location Development

Distributed Agile Guidance
If work is distributed
Capture all communications
independently between
Optimize team size in one platform (preferably
locations, try to have
the tool)
separate Scrum Masters
Sprint Reviews and

Retrospectives should be Run the Scrum of Scrums Be aware of the time
done once by including all meeting at least once a differences and run daily
the team members week scrums accordingly
Arrange face-to-face
Make sure all team members interactions - Use
across locations are using teleconference in place of Distribute work evenly and
the same tool emails for important encourage cross-reviews
conversations

Daily Scrum and Scrum of Scrums key for distributed Large Teams
 Daily scrum for India Dev team at 10 AM India TimeN
 Scrum of Scrums at San Jose, USA at 9 AM Pacific Time
 India Dev Team Scrum Master participates in both
Daily Scrum Scrum of Scrums
• Done yesterday • Tasks done for each team
• Plan for today • Issue Resolution across teams
• Obstacles?
Iteration Planning 24 Hrs

• Review Product Backlog
• Decide & Estimate Sprint
backlog
• Commit to Iteration duration
3 Weeks
Product Backlog
Prioritized
Features
Iteration Task
Testable Product
expanded by team
Increment

Overview
Agile Project Management
The idea is that if you give teams the tools they need to
succeed, help them understand the business value of their
problem-solving, and provide them with the space and time
to complete their work, the need for command-and-control
management disappears.

The New Role of the Manager
 4 Possibilities
– ScrumMaster
 Possible issues?
– Product Owner
– Team Member
– “Manager 2.0”

Manager 2.0
Decide task assignments among the team members and Provide coaching and mentorship to team-members
assign them
Keep track of whether team-members have done the Surface issues to the team that they might overlook –
tasks I’ve assigned to them scaling, performance, security, etc.
Make commitments on behalf of the team about how Provide input on features, functionality, and other aspects
much they can get done by X date of what’s being produced
Give direction to the team on how to do the work, so they Do performance evaluations and provide feedback to
can meet the commitment I made team-members
Convince team that the commitments made on their Provide advice and input to the team on difficult technical
behalf are attainable issues that come up
Monitor the team's progress, to make sure they stay on Plan training for team, and do career-development and
schedule, and aren't having problems planning with team-members
Conduct weekly update and 1:1 meetings with team, to Stay abreast of latest developments in the technology
surface issues, and provide direction their team uses, industry news, etc
Recruit, interview and hire new members of the team Plan and oversee budgets and financials, and think about
tools, skills and other future needs
Fire team-members who are consistently not able to Help remove impediments that the team is not able or
perform well-placed to resolve themselves

Leading Effectively
Management Focus Leadership Focus
Tasks / Things People
Control Empowerment
Efficiency Effectiveness
Doing things right Doing the right things
Speed Direction
Practices Principles
Command Communication
Servant Leadership
• Shield team from interruptions
• Remove impediments to progress
• Re (Communicate) Project Vision
• Carry food and water
Leadership Tools and Techniques

• Modeling Desired Behavior – Honesty, Forward-looking, Competent, Inspiring
• Communicating the Project Vision
• Enabling Others to Act
• Being Willing to Challenge the Status Quo

Agile Contract Types

Agile Contracts
Product Vision, Regular Feedback and Continuous Improvements are Key aspects of
an Agile contract among others
Regular
Continuous Feedback  Governance framework
Improveme where regular feedback is
nts not a choice, but a
necessity
 Demo and Reflection
Specify
 Provide a framework for Vision
bringing in innovation
 Allocate Budget
 Define high level vision of
product
 Define key roles to
achieve the goals
Agile Contract

Time and Material
Time and Material type contracts are a good fit for Agile Engagements
 Takes care of the changes in requirements, schedule

Time and Material
and priorities at an operational level
 No expensive change management procedures
 Promotes shared ownership and partnership behavior
 ‘ONE TEAM’ concept, critical to the success of Agile.
Time and Material contracts put all the risks with the client, therefore difficult to push
with client’s leadership team at times. No incentive for innovation

Time and Material Contd …
Time and Material with

outcome linked payment
 A framework agreement under a T&M arrangement is signed.
 Client and IBM mutually agree on estimation model and Sprint
completion criteria during Release planning stage
 Additional considerations under this engagement type are:
- A suitable risk reward on top of base contract
- Client is offered an exit route with a penalty.
Client is rest assured that, IBM shall work towards completing the sprints on time
and with quality. Payments are linked to outcome

Fixed Price / Fixed Capacity Contract
Fixed Price / Fixed Capacity (FPFC) is most suitable for Agile whereas a contract with
Fixed Price / Fixed scope must be avoided.
 Fixed team working in iterations which are time-boxed and the

Fixed Price with scope of the work is defined just before that iteration starts
Fixed Capacity
 Gives flexibility for adjusting business priorities and changing
requirements
 Helps the management in budget forecasting
 Can add performance based pricing components on top of

FPFC
Overall price is fixed with a fixed capacity but the scope is NOT fixed. Most
Suitable for Agile, Widely used within the Industry

Fixed Price / Fixed Capacity Contract Contd …
Agile contract with Fixed Price / Fixed scope must be avoided.
Fixed Price with a  Fixed Price with a fixed scope defined upfront (high risk)
Fixed Scope
 Should have a 3 months ‘checkpoint phase’ to address the
following:
- Establish estimation methodology, sprint acceptance terms
- Establish a prioritized backlog
- Agree on a velocity for a Sprint
Considered to be most unsuitable contract type, should be considered only in

exceptional circumstances after proper due diligence

Agile Tools Evolving Inventory
Static Code Analyzer FT Load Test

Planning / Collaboration Design SCM
• PMD • RFT • LoadRunner
• JIRA + GreenHopper • RAD • CVS
J2EE • Beam • QTP • JMeter
• Rational Team • SVN
Concert • PurifyPlus • Seleniu • RPT
Dev Env. • VSS
• ScrumWorks m • Batch Scripts
• Eclipse • ClearCase
• Mingle • Watir • Open STA
• intelliJ CI • soapUI
UT • Cruise Control Code Audit Defect Mgt

Acceptance Test
• Bamboo • CheckStyle • Jira
• JUnit • Cucumber
• Hudson • BugZilla
• NUnit • JBehave
• BuildForge • QC
Code Coverage • SpecFlow
• Apache Ant • RQM
• Corbetura
• Apache Maven
• Emma
• Jcoverage
Life Cycle Management: Rational Team Concert

Waterfall to Agile Transformation

Agile Adoption Process: Five Phased Approach
A. Understand
Context
Process: Understand current processes, plan, establishment
milestones; conduct viability assessment workshop
• Scrum enablement workshop Deliverables: Understand key deliverables
• Sprint planning workshop (requirements, architecture, design, codebase etc.),
• Review workshops on tools / CM / test and the context and Vision of the Product
plan / Release plan Tools: Understand current tool-base and flexibility
Governance: Understand team structure, roles,
E. InGame governance, project metrics. B. Set Vision
Process: Manage sprints and revise backlog / Process: Establish Agile processes / enablement
sprints on an ongoing basis strategy (full or parts) and product delivery strategy;
identify 30-60-90 day plan
Deliverables: Ongoing refinement of all deliverables
including codebase / tested code. Deliverables: Create deliverable mapping
Tools: Configuration management guidance & Tools: Establish target toolset and adoption strategy
compliance review, Configure toolset, Implement Governance: Strategize Conversion
build / test and deployment automation
• Agile enablement workshop – contextual
Governance: Conduct grooming sessions
• Requirements / user stories workshops
• Staffing & governance workshop
• Backlog planning workshop
• Tools requirements workshop
• Release planning workshop
• Tools strategy workshop D. Groom C. Refine
Process: Understand Backlog creation and prioritization Process: Understand Agile processes definition, release
and sprint planning planning guidance and approach finalization
Deliverables: Refine Epics / User Stories and other Deliverables: Identify deliverables, translate requirements
requirements and system requirements to Epic / User Story formats
Tools: Identify and provision the tools Tools: Understand tooling design and base enablement
Governance: Understand stakeholder alignment on Governance: Identify components that need to be Agile,
versioning and requirements as well as team formulation Agile enable teams, identify and realign roles, team
formation template and suggestions

Agile @ IBM
https://w3-
connections.ibm.com/communities/service/html/communityoverview?communityUuid=4a1097cb-f0cf-
4b2b-9aff-b06c7b33836c

AD&I North America
Agile@Maintenance Overview
Mail: Agile Maintenance/Austin/Contr/IBM Wiki: https://ibm.biz/adi-aatm

© Copyright IBM Corporation 2016
Overview
What is Agile@Maintenance?
 The 'next step' to leverage the success of this year's AD&I Agile experiments
 It is not intended to deliver an overall transformation on any particular account, but to establish a
successful showcase for Agile in one or two application tracks where maintenance is in scope by making a
measurably recognized contribution to reducing a backlog of maintenance tickets on those accounts.
What are the goals and objectives of Agile@Maintenance?
 Get all accounts at a consistent level
 Select only one or two application tracks where maintenance is in scope
 Reduce the backlog of maintenance tickets for a focused area of an account by 25%
 Demonstrate a successful Agile approach to the client
 Drive additional business opportunities for larger Agile transformation deals
What are the benefits/business value to AD&I and the client?
 AD&I - improved efficiency of maintenance teams, increased client sat and drive future business growth
 Client - highest value repairs are delivered the soonest, smaller backlog of repair tickets
 Drive actionable plan for Agile adoption in account
How do I get started?
 Sign up for an Agile@Maintenance Deployment Planning Workshop
 Schedule a workshop via Agile Maintenance/Austin/Contr/IBM now!

Objectives
 Achieve productivity improvements by applying methods from the Agile approach to application
maintenance
 Identify actionable items for a deployment plan that could be adopted by a large number of AD&I
accounts with application maintenance scope
 Apply to a large number of accounts with broad but narrow approach to get a Fast Start to the
Agile@Maintenance program
 Conduct a one-day session for each account (stay until done)
 Work in conjunction with global Agile@GBS approach and the re-solution workshops
 Participants are expected to have a basic understanding of Agile principles and values – see Base Agile
Training (and more) at https://ibm.biz/adi-aatm-education

Measuring Success
Sample Metrics


Backup Slides

Agile Projects @ IBM

Available Time During Sprint
Sprint Length 2 weeks
Workdays During Sprint 8 days
Avail Days During

Team Member Avail Hours Per Day Total Avail Hrs in Sprint
Sprint*
Tracy 8 4 32 28 25
Sanjay 7 5 35 31
Phillip 8 3 24
Jing 5 5 25
*Net of holidays and other

days out of the office
The Sprint Backlog
Day of Sprint
Backlog Initial
Task Owner 1 2 3 4 5 6
Item Est.
Design business logic Sanjay 4
Design user interface Jing 2
Implement back-end
Tracy 2
code
Enable all users
Implement front-end
to place book in Tracy 6
code
shopping cart
Complete
Joe 8
documentation
Unit testing Philip 4
Regression testing Philip 2
Implement back-end
Tracy 5
code
Upgrade
transaction Complete
Joe 6
processing documentation
module Unit testing Philip 3
Regression testing Philip 3
Total 214
Scrum Advantages
 Accelerate Time to Market

 Early and Continuous Customer Validation
 Greater Visibility into Project Progress
 Early Defect Detection and Prevention
 Risk Reduction and Quality Improvements
 Improve Team Morale

Scrum Disadvantages
 It’s hard!
 Makes all dysfunction visible
– Scrum doesn’t fix anything. The team has to do it
– Feels like things are worse at the beginning
 Bad products will be delivered sooner, and doomed projects will fail faster
 High risk of turnover
– Some people will refuse to stay on a Scrum team
– Some people will refuse to stay if Scrum is abandoned
 Partial adoption may be worse than none at all
 If adoption fails, time will have been wasted, and some people may leave

Agile Mapped to Traditional Practices

Traditional Agile
Defining Envisioning
Defines and authorizes the project Defines the product sufficiently to provide a
sandbox with borders in which to work
Planning Roadmap
Describes how the project will be managed Translates the vision into a set of features and an
expected timebox in which to deliver them
Executing Release
Helps the project groups work together to Helps the team incrementally and iteratively
complete the work develop potentially shippable code
Monitoring and Controlling Adapting
Checks the progress of the project and corrects Integrates planned stopping points to inspect and
problems adapt the process and product
Closing Closing
Formally closes each phase or the project and Team reflects on achievements and decision-
receives approval of the project work making per lessons learned

Integration Management
Integration Management Agile Planning

Develop project charter or plan Develop roadmap and backlog
Execute the project plan Do iteration work
Direct, manage, monitor, control Facilitate, lead, collaborate
Integrated change control Constant feedback, ranked backlog
Scope and Time Management TimeBoxes

Collect requirements, define scope Develop and select product backlog
Create Work Breakdown Structure (WBS) Define features for release/sprint
Define and sequence activity Team selects features, tasks for sprint
Control schedule Refine story estimates per team velocity

Integration Management
Quality Management Integrated Quality

Quality Planning Responsibility of entire team
Quality Assurance QA integrated into sprints, retrospectives
Quality Control Unit testing in each iteration
Human Resource Management Self-Managing Teams

Human Resource Planning Dedicated team of 7 +/- 2 members
Team Development Cross-functional, collaborative teams
Team Management Servant leadership, self-managing teams

Agile – Metrics @IBM

Following Metrics have been identified for Agile Projects, based on recommendations from AgileatIBM.
Projects will submit Agile Metrics as an Attachment to SWE Sheet
Name of Metric What does it Indicate Mandatory/Optional

Defects per user story Quality of Deliverable Mandatory
This will measure our
Number of times code checked in Continuous Integration (CI) Optional
% of CI Build failures CI build quality Mandatory

Automated Code Review errors, warnings /sprint or per build Static Code Analysis Mandatory
Team's progress during the
Burndown , Burnup chart sprint Mandatory
Team efficiency , E = Velocity/Number of Person Days worked Teams Productivity Mandatory
Pair programming – number of task done with static/dynamic pair
programming Optional
Effective WBS during sprint
Number of new tasks added/removed during the sprint Planning Optional
Availibility of Product Owner – How long it took for the queries to
be replied Access to product owner Optional
Code Quality and Unit test
Code coverage coerage Mandatory
Time box iteration – change of scope of duration during a sprint Change Management Optional
Effective Team facilitation
Time taken to solve impediments of the Team members/Team by Scrum master Optional

Distributed Agile Guidance
Implementation • Mitigation Strategy

Challenges
•Establish base toolset for communication

•Document Sharing/Discussions/Meetings
Simulate Co-Location •Common Forums/Repositories/Protocols
•Video Conferencing (several open screens in project room)
•At least one handshake meeting between onshore and offshore teams per day
• Exchange Visits, Visibility of Roadmaps, Part of decision

Building ONE TEAM culture Making, Build “One Team”
• Establish maximum possible Automation in the development

Proper handover/Handshaking lifecycle
among the technical Teams • Continuous integration, release and deployment
• Automated testing
• Implement robust Agile project management tools (e.g. real

End to End Visibility of Status time soft copy of storyboard)

Agile For PMs v6

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Agile For PMs v6

Загружено:

Авторское право:

Доступные форматы

IBM Global Business Services

Agile for Project Managers

1 Introduction to Scrum | 2013 © Copyright IBM Corporation 2016

2 © Copyright IBM Corporation 2016

The Agile Manifesto – 2001

We are uncovering better ways of developing

Individuals and interactions over processes and tools

That is, while there is value in the items on

3 Introduction to Scrum | 2013 © Copyright IBM Corporation 2016

The new way of Working

4 © Copyright IBM Corporation 2016

Iterative and Incremental

Object Model Vertical Slice – real

5 © Copyright IBM Corporation 2016

Meeting or exceeding a planned ROI based on staying within

Risk vs. Value Working Increments

Low Illustrative only

Source Picture: http://guntherverheyen.com/category/agile/page/3/

6 © Copyright IBM Corporation 2016

How Will It Help?

7 © Copyright IBM Corporation 2016

Agile is a conceptual framework for undertaking software

Extreme Dynamic Systems

Agile Techniques: The above methods involve a range of techniques including:

Planning game Design improvement Coding standard

Pair Programming Small releases Sustainable pace

Refactoring Simple design Whole team

8 Introduction to Scrum | 2013 © Copyright IBM Corporation 2016

Waterfall versus Agile: Four Key Differentiators

• BRD, SRD, solution architecture, • EPICs User Stories

• Project management tools (MPP / • Rational Toolset (RTC, RRC,

• BRR, SRR, PDR, CDR, TRR, PRR • Sprint Review

9 © Copyright IBM Corporation 2016

 Scrum refers to a holistic or “rugby” approach—where teams goes the distance as

10 © Copyright IBM Corporation 2016

11 © Copyright IBM Corporation 2016

12 © Copyright IBM Corporation 2016

User Stories: Components

User Stories are comprised of three things

Assumptions Estimating Elements

IBM Customized Additional Elements

User Story Prioritization - MoSCoW

Letter Stands for Which means

M Must Have system would be useless (MMF)

S Should Have  These requirements can be included in the initial project

14 © Copyright IBM Corporation 2016

15 © Copyright IBM Corporation 2016

Product and Sprint Backlog

Product Backlog Sprint Backlog

16 © Copyright IBM Corporation 2016

17 © Copyright IBM Corporation 2016

18 © Copyright IBM Corporation 2016

19 © Copyright IBM Corporation 2016

What’s on the Product

21 © Copyright IBM Corporation 2016

Daily Scrum Meeting

22 © Copyright IBM Corporation 2016

Owner: Sanjay Owner: Sanjay Owner: Sanjay Owner: Sanjay

Task: Configure database Task: Configure database Task: Configure database

Owner: Sanjay Owner:` Sanjay Owner: Sanjay

Owner: Sanjay Owner:` Sanjay Owner: Sanjay Owner: Sanjay

Task: Configure database Task: Configure database Task: Configure database

Owner: Sanjay Owner: Sanjay Owner: Sanjay