Agile Project Management

We manage learning.
“Building an Innovative Learning Organization. A Framework to Build a Smarter
Workforce, Adapt to Change, and Drive Growth”. Download now!
NetCom Learning
NetCom Learning – Managed Learning Services
Agenda
Module 1: Project Management – A Reality Check
Module 2: Overview of Waterfall Model
Module 3: Understanding Agile Development
Module 4: Understanding Agile Project Delivery
Module 5: Deep Dive – SCRUM Framework
Module 6: Deep Dive – Lean Methodology
Module 7: Applying SCRUM & Lean to Non-IT projects
Module 8: Requirements Management
Module 9: Estimation
Module 10: Project Planning
Module 11: Project Execution and Tracking
Module 12: Agile Adoption

5
Module 1

Project Management – A Reality Check

6
Are We Building the Right Thing?

7
Challenges of a Project Manager
1. Dealing with changing requirements (Scope Creep)
2. Lack of resources and/or Quality of resources
3. Unrealistic schedules
4. Issues with technologies – unproven, nascent
5. Overburdened by existing complexity – documentation, reporting,
etc.
6. Too many dependencies
7. Managing stakeholder expectations

8
Module 2

Overview of Waterfall Model

9
Waterfall Model

1. Simple and easy to understand and use.

2. Easy to manage due to the rigidity of the model.
3. Phases are executed and completed one at a time. No overlaps.
4. Works well for non-complex projects.

10
Understanding the Waterfall Model
1. Freeze the end-product in all respects when project starts
2. Requires detailed estimation and planning upfront
3. Changes mid-way can cause delays

11
Challenges with the Waterfall Model
1. Managing changing requirements during the ALM/SDLC
2. Don’t get to see the end product until the end of ALM/SDLC
3. Loaded with risk and uncertainty
4. Challenges in dealing with complexity upfront

12
Module 3

Understanding Agile Development

13
Understanding Agile Development
• Agile Development is an alternative to traditional project
management
• Focus on customer satisfaction
• Adapts well to deal with uncertainties and changing situations
• Delivers in increments following an iterative process
• Continuous attention to all aspects of delivery – Planning, Design,
Delivery, Quality...
• Empowers team to make decisions
• Follows an inspect-and-adapt approach
14
Traditional vs. Agile - Lifecycle
Agile = Deliver Value Early

15
Traditional vs. Agile – Value Proposition

16
Traditional vs. Agile – Value Proposition

17
Traditional vs. Agile – Value Proposition

18
Projects Suited for Agile Delivery
The most appropriate projects for agile are ones with aggressive
deadlines, high degree of complexity, and high degree of novelty
(uniqueness) to them.

Novelty: If you are building the same things

over and over again, you have mastered the
nuances. You don’t need Agile

Urgency : Time boxes and iterations keeps the

intensity and focus going

Complexity: Anything that requires that extra

bit of functionality or variation that is unique.

19
Module 4

Understanding Agile Project Delivery

20
Are We Building the Right Thing?

21
The Promise That Agile Holds

22
The Paradigm Shift
• Plan Driven Approach: Scope remains fixed, while Resources and Schedules are
adjusted

• Change Driven Approach: Scope is adjusted while Resources and Schedules are
fixed

23
Agile Framework
Relationship between Values, Principles and Practices

24
Agile Manifesto (Values)

25
12 Principles of Agile Development
1. Satisfying customer is top priority
2. Welcome changing requirements even late in development
3. Deliver working software frequently
4. Development teams and business work together
5. Most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
6. The primary measure of success is working software
7. The Team regularly reflects on work
8. Build projects around motivated people
9. Continuous attention to technical excellence and good design
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. Agile processes promote sustainable development – Sponsors, developers and
users should be able to maintain a constant pace indefinitely

26
Agile Process Framework

27
Agile Methodology Flavors

28
Xtreme Programming

29
XP Values
Communication: Building and disseminating institutional knowledge among members
of the development team. Helps developers have a shared vision. Happens through
collaboration between users and developers, frequent verbal communication, and
feedback, simple design, common metaphors.

Simplicity: Start with a simple solution. Extra functionality can be added later.

Feedback: Feedback looked in three dimensions : Feedback from the system,

Feedback from the customer and feedback from the developers.

Courage: Developers feel comfortable with refactoring, knowing when to throw away;
courage to remove source code when obsolete

Respect: Respect for other as we as self-respect. For example, developers should

never commit changes that break compilation, that makes existing unit tests fail, or
that otherwise delays the work of their peers.

30
Feature Driven Development (FDD)
• Starts with a Domain Object Model and focus on OO
• Developed on real systems of Scale
• Eight Practices
1. Developing by Feature
2. Class Code Ownership
3. Feature Team
4. Inspections
5. Regular Build Schedule
6. Configuration Management
7. Reporting/Visibility of Results

31
Dynamic Systems Development Method
(DSDM)
1. Assume can’t build perfectly first time
2. 20% of time can deliver 80% of proposed system
3. Therefore focus on highest value – sounds like scrum, right?
4. Core practices
5. Time Boxing
6. MoSCoW prioritization
7. Modelling but only at user level
8. Prototyping – helps with understanding and awareness
9. Testing – focused on User no specifics on lower levels of
testing
10. Configuration Management – any increment is reversible 32
Agile Methods and Practices

http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf
33
Agile Succeeding

34
Agile Benefits Quantified

35
Agile And Lean Compared

36
Module 5

Deep Dive: SCRUM

37
SCRUM – How it evolved
• Takeuchi and Nonaka – coined in The New Product Development Game in 1986
• 1993 First Project Easel Corp by Jeff Sutherland, formalized by Ken Schwaber and Jeff
Sutherland in 1995
• 2002 Scrum Alliance formed
• It is now probably the fastest-growing approach to software development globally
• Used in many Fortune 100 companies globally
• Google • Sun
• Infosys • Wipro
• TCS • IBM
• Nokia • Lockheed-Martin
• HP • Agilent
• EMC • GE

38
SCRUM Definition

“ An agile framework that allows us to focus on delivering the highest

business value in the shortest time”

Mike Cohn

39
What is SCRUM?
• Incremental and Iterative
• High Level - Not prescriptive – although there are boundaries
• Emphasis on Collaboration
• Easy to understand – hard to execute
• Change as Opportunity
• Goal(s) oriented
• Empirical Process – Inspect and Adapt, Transparency
• Suited to Complex product development – cynefin framework, agile practices still
useful in other quadrants!

40
SCRUM is Not
1. Lacking Discipline – Inspection and Adaption, Just in Time Sprint and Release
Planning, XP engineering practices take discipline
2. Gantt chart detailed plan
3. Not a Silver Bullet – each project is different and has differing needs – but stick to the
core values and roles when applying it

41
Why SCRUM became popular
• More business value sooner
• Greater visibility
• Improved productivity and Discipline
• Less waste
• Higher quality
• Stronger teams with better morale
• Better return-on-investment for projects
• Visible Structure

42
SCRUM– An Overview

43
SCRUM Values

44
SCRUM Lifecycle

45
SCRUM Challenges
• It’s hard!
• It requires significant change
• Change in practices and skills
• Change in organization, planning, budgeting, HR
• Change in mindset and culture
• It makes all dysfunction visible
• Scrum doesn’t fix anything: we have to do it
• If we don’t address the problems, it will be painful
• Bad products will be delivered sooner, and doomed projects will fail faster
• Partial adoption may be worse than none at all
• Be forewarned: many Scrum adoptions fail!

46
SCRUM Roles

47
Pigs and Chickens

48
The SCRUM Team – Product Owner (PO)
• Owns vision for the product to be produced/released
• Creates and maintains the Product Backlog
• Final decision maker on prioritization of Product Backlog items

49
The SCRUM Team – SCRUM Master
• Facilitates implementation of the
process
• Builds self-organizing teams
• Removes team’s constraints and
impediments
• Protects the team from external
disturbances
• Empowers the team through Servant
Leadership
• Helps create visible Information
Radiators
• Coaches the team for successful
implementation

50
The SCRUM Team
• 7 people, +/- 2 – The Right Size
• Cross-functional team - includes
design, coding, testing, and other
resources required for potentially
shippable software
• Self-organizing and self-managing
• Inspect and Adapt through Daily
Scrum Meeting and Retrospective
• Assist PO to groom the backlog
• Plan the sprint
• Swarm over tasks – minimize Idle
work
• Musketeer attitude
• High bandwidth communications –
Face to Face always best
• Transparent, Focused (no more than 2
tasks), works sustainably, stays
together

51
Understanding the role of the Project
Manager

52
Agile Project Manager Responsibility
Ask the following questions
• How are Agile Projects Managed?
• Is the Scrum Master considered the Agile Project Manager?
• Who handles traditional project management responsibilities?
• Does this Scale?

Agile processes distribute the traditional project manager's responsibilities

• Task assignment and day-to-day project decisions –Team
• Responsibility for scope/schedule trade-offs - Product Owner
• Quality management – Team, Product Owner & Scrum Master
• Other traditional project management responsibilities - One or more of these
roles

53
Project Manager in SCRUM

54
Agile Teams
Staffing
• Team composition and interaction changes.
• Co-location of teams and or collaboration via
communication tools
• Roles and responsibilities of team members are clearly
defined
• Consider the use of an agile coach on the team

55
An Exercise in Responsibilities
ROUND 1: In a Non-Agile Environment

TEAM OTHER

PROJECT MANAGER

56
An Exercise in Responsibilities
ROUND 2: In an Agile Environment

TEAM OTHER

PROJECT MANAGER
SCRUM MASTER

57
6 Time-boxed ceremonies
A timebox is a fixed period of time, during which something must be done.

Daily Scrum How are we doing?

Sprint How often can we deliver?

Release
Planning What or how much do we do and when?

Sprint
Planning How do we do it?

Sprint Review How did we do it? Fit for purpose/use?

Sprint
Retrospective
How do we do better? Inspect and Adapt

58
Duration of Timeboxes
Maximum For Sprints of 6 For Sprints of 4 For Sprints of 2 For Sprints of 1
Duration weeks weeks weeks week

Release 1.5 days 1 day ½ day 2 hours

Planning
Sprint Planning 1.5 days 1 day ½ day 2 hours

Sprint Review 6 hours ½ day 2 hours 1 hour

Sprint 6 hours ½ day 2 hours 1 hour

Retrospective
Daily Scrum 15 minutes 15 minutes 15 minutes 15 minutes

These are the maximum durations of each timebox. Meetings may adjourn early, if
the agenda is completed before the allotted time

59
SCRUM Artifacts
• User Stories
• Product Backlog
• List of functional & non-functional
requirements
• Sprint Backlog
• Prioritized list of stories for a
given Sprint
• Sprint Burndown Chart
• A chart showing completion of
stories over time
• Release Burndown Chart

60
SCRUM – Putting It All Together

61
3 Key Tenets: Deliver-Empower-Adapt
1. Deliver Early & Often
Delivering a fully completed increment every time (sprint). This allows
stakeholders to enjoy the business benefits early rather than waiting for
the full life-cycle.

2. Empower your teams

Innovation does not come from compliance. Those doing knowledge
work are best qualified to organize that work. Scrum requires teams to
enforce professional boundaries, so they can achieve results

3. Inspect and Adapt

High performing teams are those that adjust their work to meet the
current reality. Scrum offers both quantitative and qualitative
techniques to assess how we can avoid disaster and improve
performance

62
Module 6

Deep Dive – Lean Methodology

63
Defining Lean
• Lean is a continuous improvement methodology
focused on managing processes, and improving them by
compressing time, rather than sweating assets
• Application of principles and techniques to eliminate
waste and improve efficiency of the process
• Focuses on flow, the value stream and eliminating
muda, the Japanese word for waste
• It is production of goods using less of everything
• Was generated from the Just-in-time (JIT) philosophy
of continuous and forced problem solving. JIT enables
making components available where they are needed
when they are needed, just at the time when needed.
64
Historical Perspective
• Underpinning of Lean Philosophy is that an organization must leverage the
knowledge and brain power of every employee to help the company change for the
better everyday to meet its goals.
• Toyota Production System – 1948 - 1975
• Developed by Taiichi Ohno, Shigeo Shingo and Eiji Toyoda
• Toyota produces automobiles for the general public of Japan
• Implemented JIT based production
• Toyota became one of the top 10 companies in the world
• 2007 - became the largest car manufacturer
• Focused on eliminating three kinds of waste
• Muri
• Mura
• Muda

65
Types of Waste
MUDA
Any activity that consumes resources
without creating value for the customer.
Unneeded processes or steps:
• Using expensive tools instead of simpler
ones
• Having meetings when not required
• Excessive paperwork
• Duplication of work
MURA
Unevenness, irregularity or Inconsistency in an
operation
MURI
Overburdening of equipment, facilities, people
caused by Muda and Mura Pushing people or
equipment beyond allowed limits
66
Lean Principles

67
The 7 Wastes
Wastes in Wastes in Software
Manufacturing Development
Inventory Partially Work Done
Extra Processing Paperwork or extra
documentation
Over Production Extra Features
Transportation Building the Wrong
Thing
Waiting Waiting for
Information
Motion Task Switching &
Motion
Defects Bugs

68
7 Principles of Lean Software
Development
1. Eliminating waste

2. Build quality in

3. Create knowledge

4. Defer commitment

5. Deliver fast

6. Respect people

7. Optimize the whole

69
Implementing Lean Techniques

Identify Pull

Seek Map the

Perfection Value Stream

Establish Pull Create Flow

70
Value Stream Mapping
• It is the process of identifying and charting the flow of information, processes, and
goods or services across the entire supply chain from the supplier to customer possession
• Includes both value-added and non value-added activities
• Allows for “seeing” areas of waste in current state
• Enables you to remove waste and improve cycle time and efficiency

71
How People Benefit From Lean

72
How Customers Benefit From Lean

73
Module 7

Applying SCRUM and Lean for Non-IT Projects

74
Applying SCRUM to Construction
Industry

75
Applying SCRUM to a Sales Scenario
• Current Organization Challenges:
• Update on sales opportunities and status updates is weekly and bi-weekly
• Resources are working on low value deals or non-deal closing activities
• Teams losing focus and randomized due to multiple directions
• Reactive decision making leading to delays and lost opportunities

76
Applying SCRUM to a Sales Scenario
• Backlog
• Deals to be closed this quarter
• Deals to be developed in the following quarters
• User Story
• Objective goals to be achieved
• Tasks
• Activities identified to achieve the targets
• Impediments
• Challenges / Issues blocking progress
• Release
• Target Sales Volume / Numbers
• Sprint
• Month / Quarter
• SCRUM Master
• Sales Manager

77
Applying SCRUM to a Sales Scenario
• List of sales objectives to be achieved forms the Product Backlog
• Developing a quarter by quarter sales plan maps to the Release Plan to get the
product out.
• The immediate quarter’s target maps to the Sprint Plan
• A daily standup meeting of 30 minutes is held with the Sales team to take status
update and discussing impediments, followed by another 30 minutes of prioritization
discussion
• The Sales Manager acts as the SCRUM master during the Standup Meeting to help his
team by removing the impediments and providing them with all the resources and
support. He will also work closely with the management to ensure that the team does
not get randomized and remain focused.
• Embrace change and adapt
• Empower the team to speak-up and communicate and facilitate team decision making.

78
 Applying Lean Principles to Construction
Industry
Lean Construction is an adaption of Lean principles and practices to design and execution of
construction projects. Lean construction supplements traditional construction management
approaches by focusing on:
1. Creating material and information flows
2. Maximizing value generation
3. Using plan, execute and control paradigms

Although Lean Construction shares many principles with Lean Production, it is different in how it is
practiced.
Shared Principles:
1. Optimization of entire system through collaboration and systematic learning
2. Continual improvement and pursuit of perfection involving everyone in the system
3. Focus on delivering value desired by the owner/client/end-user
4. Creating flow by eliminating obstacles to value creation and elimination of processes that create no
value
5. Creating pull production
Differences:
1. Construction projects are unique.
2.Multiple contractors/suppliers act under different commercial arrangements
3.Construction environments are typically outdoors and/or difficult to control
4.Communication challenges caused by teams being geographically separated
79
Module 8

Requirements Management

80
Creating and Managing a Product
Backlog
• A backlog contains a broad list of descriptions of all required features, wish-list items,
etc. prioritized by business value. It is the “What” that will be built.
• It contains rough estimates of both business value and development effort.
• Product Owner is in charge of defining priorities in the Product Backlog
• Maintain Story Lists

81
Creating and Managing a Product
Backlog

82
Creating and Managing a Product
Backlog

83
Techniques for Requirements Gathering
• Brainstorming, Interviews
• Prototyping – Create screen prototypes for clear requirements
• Functional Modelling
• Use Cases (Scenario-driven approach) and Storyboards
• User Stories

84
User Stories

85
Principles of User Stories - The 3 C’s

86
Principles of User Stories – Types of
Stories
Theme:
• A set of related user stories that may be combined together and treated as a single
entity for either estimating or release planning
• A Theme is kept for ease of estimation and planning
• Example: Support for Database will involve defining schema, migrating existing data,
creating reports and so on

Epic:
• Large user stories with low priority and too big to implement in one iteration
• Broken down further into smaller user stories and the lower level child stories are
assigned priorities for planning
• An Epic, by its very size alone, is often a Theme!

87
Principles of User Stories – Types of
Stories

88
User Story Example
As a customer service rep., I can search for a customer so that I can view his/her
account details.

• When searching by a valid account number, the account is shown

• When searching by a valid name and SSN, the account is shown
• If no results are found, show appropriate message
• Acceptance tests?

89
User Story Attributes - INVEST
Every user story (requirement) should meet the below
criteria (INVEST acronym) for it to be considered complete:

• Independent
• Negotiable
• Valuable (to users/customers)
• Estimate-able
• Small
• Testable

90
Non-Functional Requirements

• Write a story for them

• They can also become part of the Definition of Done.
• e.g.: Internationalization would affect all stories in some way.
• Other stories
• Knowledge Acquisition Stories – e.g.: explore a new technology, spike solution
• Technical Stories – e.g., set up DB table

91
Gathering User Stories - Workshop
• User Story Workshop
Product Owner, Scrum Master and Development Team together with
stakeholders to build detailed requirements

• Story Mapping (Jeff Patton)

• Decompose High Level Activity into a workflow with further
decomposition into tasks
• Divide into a hierarchy of Themes, Epics and Stories
• Workflows are useful even if not doing the technique explicitly
• Natural prioritization can emerge

92
Gathering User Stories – User Story
Mapping
Story Mapping (Jeff Patton)
• Decompose High Level Activity into a workflow with further decomposition into
tasks
• Divide into a hierarchy of Epics, Themes and Stories
• Workflows are useful even if not doing the technique explicitly
• Natural prioritization can emerge

93
User Story Smells
• Interdependent Stories
• Gold Plating
• Too Many Details (not INVEST)
• Thinking Too Far Ahead (waterfall mindset)
• Language Issues
• Business Dominated – concepts not understood by
Developer
• Developer Dominated – too much technical jargon

94
User Story Splitting
• A story may not fit within an iteration, it’s too large to estimate (epic)
• Examples (from Mike Cohn – Agile Estimating and Planning)
• Split by Data Boundary.
• As a borrower, I want to pay off my loan
• As a borrower, I want to pay off my loan without overpayments
• As a borrower if I accidently repay too much, I get a refund if it’s
over 2??
• Split by Operational Boundaries – C.R.U.D.
• Cross cutting concerns, e.g. logging can be another user story

95
Backlog Prioritization
Agile Prioritization Technique - MoSCoW

Must have (or Minimum Usable Subset)

Should have
Could have
Won’t have (but Would like in future)

‘Must Haves‘ are features that must be included before the product can be launched. It is
good to have clarity on this before a project begins, as this is the minimum scope for the
product to be useful.
‘Should Haves‘ are features that are not critical to launch, but are considered to be
important and of a high value to the user.
‘Could Haves‘ are features that are nice to have and could potentially be included
without incurring too much effort or cost. These will be the first features to be removed
from scope if the project’s timescales are later at risk.
‘Won’t Haves‘ are features that have been requested but are explicitly excluded from
scope for the planned duration, and may be included in a future phase of development.

96
Minimal Marketable Features - MVP

97
Velocity
Measuring Velocity

Fully “done, done” story points are counted

Partially completed stories do not count at all

• Don’t imply precision by saying you completed 4.7 points out of 8
• That last 10% can take 90% of the time
• The business value is not achieved until it is done, done (or do smaller stories)

The actual velocity of the last two iterations is the planned velocity of the next

98
Module 9

Estimation

99
Agile Estimation
• What are some of the traditional techniques you are aware of?
• What are you estimating?

100
Traditional Estimation Techniques
• Count/Compute/Judge
• Calibrate & Historical Data
• Individual Expert Judgement
• Decomposition & Recomposition
• Estimation by Analogy
• Expert Judgement in Groups: e.g. Wideband Delphi

Source: “Software Estimation: Demystifying the Black Art” by Steve McConnell

101
Estimation “Best” Practice

Schedule

Size Effort Cost

Features

102
Challenges
e.g., 10K LOC
Schedule

Size Effort Cost

Features

• No perfect measure of size

• Do we measure in Lines of code, Function points, Story points?

103
Challenges

Eg: 10K LOC

Eg: 10 person months

Human Influences can make a 14x difference in total project effort/cost according to
Cocomo II (The Constructive Cost Model)
104
Challenges
Eg: 10K LOC Eg: 10 Staff months Eg: 6 months duration

Schedule

Size Effort Cost

Features
Schedule In Months = 3.0 x Staff months1/3

Need to cater for many overheads

e.g.: holidays, full time/part time, dependencies

105
Agile Delivery – Doesn’t Estimate
Schedule
Schedule

Size Effort Cost

Features

Agile Delivery estimates size in story points or ideal hours & over iterations. Team
capacity and velocity drives schedule.

106
Story Points
• Measure of Complexity - A simple way to estimate level of effort expected for a Story
based on size and complexity
• Estimate of Size, not Duration Estimates are based on size, not duration (derived
empirically once Iterations have started)
• Relative Weighting Story points are a relative measure (research has shown humans
are better at this)
• Additive Puts estimates in units that can be added together (unlike time-based
estimates!)
• Constrained to Set of Values Often scored on a scale based on Fibonacci Numbers (0,
1, 2, 3, 5, 8, 13, 20, 40, 100)

107
Planning Poker
An iterative approach to estimating Steps:

• Each estimator is given a deck of cards, each

card has a valid estimate written on it
• Customer/Product owner reads a story and it’s
discussed briefly
• Each estimator selects a card that’s his or her
estimate
• Cards are turned over so all can see them
• Discuss differences (especially outliers)
• Re-estimate until estimates converge

108
Agile Estimation - Workflow

109
Planning Poker – Why It Works
• Multiple Experts - Delphi Method
• People doing the work are best placed to estimate it
• Generates a lively debate - Consensus
• It’s fun!
• Let’s try it - curiosity

110
Let’s Play Planning Poker
• We are having a massive party
• Lots to prepare!
• Want to make a large fruit salad
• Never made one before...
• What can we do in time?

111
Starting Point

112
Estimation Techniques
Consider
• Risk (sharp knife, spiky/slippery skin) Acceptance Criteria
• Effort (size of fruit) • Rockmelon, banana, mango, coconut,
• Complexity (cutting difficulty) pineapple skin off
• Relativity (to existing estimates) • Pear, apple skin on

Definition of Done
• All seeds removed (except strawberry
& banana)
• All fruit to be washed
• Bite-sized pieces

113
Velocity Chart

114
Relative Sizing

115
Determining Team Velocity

116
Determining # Sprints To Complete

117
Module 10

Project Planning

118
Have A Vision
• Establish the vision for the product - concise
to the point
• Examples
• Elevator Statement – can you state
the
goal in a 30 second elevator ride
• Product Datasheet – do the one
pager
• Product Vision Box – Draw the box
the
product ships in
• Conference Slides – two, three slides
not bullet points
• Press Release – imagine the press
release you’d create – write it down
• Magazine Review – a fictitious review
of the product
119
SCRUM Planning

120
Release Planning

121
Release Planning

Refer : http://www.scmpatterns.com/pubs/crossroads-mirror/2008-05-CMCrossroads.pdf
122
Release Planning

123
Sprint Backlog

124
Sprint Planning

125
Sprint Planning

126
Sprint Planning – Best Practice

127
Typical Project Plan

128
Module 11

Project Execution & Tracking

129
Daily Standup (SCRUM) Meeting
Goal
• Enable to team to share progress with each other
• Make visible blocks (impediments) daily for whole team to see

Everyone stands in a circle and reports 3 things

• What did I do since the last Daily Scrum Meeting?
• What will I try to do by the next Daily Scrum meeting?
• What are my blocks?

15 minutes maximum

No discussion or debate: listening only

• After meeting ends, discuss and problem-solving can start

Team and ScrumMaster only

• Team can invite PO or others if they wish, but it’s up to the team

After the meeting, ScrumMaster leads the removal of blocks

130
Information Radiator
• Was coined by Alistair Cockburn
• Graphical Representation of Project Status & Key aspects displayed in Team
Workspace
• Current iteration’s work set ( user stories)
• Current work assignments
• Number of tests written, passed, failed
• Number of user stories delivered
• Status of key servers
• Results of actions from previous retrospective
• Keeps team focused on tasks and actions needing priority and attention
• Helps drive transparency across the organization

131
A Burndown Chart

132
Sprint Burndown

133
Sprint Burnup Chart

134
Release Burndown

135
Sprint Review

136
Sprint Retrospective

137
Techniques for Sprint Retrospective
• Post-it brainstorming
• Dot voting
• Timeline
• Team Radar

138
Sprint Retrospective – An Example
Suggested Topics
• What went well, What could be better,
What will we do about it
• What should we continue doing, What
should we start doing, What should we stop
doing

Suggested Tools
• Whiteboards, Flipcharts, Index Cards, Sticky
Notes

Team mind-map exercise to understand relationships of project issues

139
Module 12

Agile Adoption

140
Your First Agile Pilot Project

141
Best Practices
Easy and continuous access to resources
• Source code repository (Bitbucket, Github, etc)
• Continuous Integration Server (Jenkins, Bamboo, etc)
• Bug Tracking tool (JIRA, Bugzilla, etc)
• Wiki (Confluence, etc)
• Project Management Tool (JIRA, etc)

Setup infrastructure to support team member communication

• Sprint meetings
• Offline discussions
• Knowledge sharing sessions

Regular people movement for short periods

• Mixing of people to overcome cultural issues, etc.,
• One Team feeling

142
Making Agile Adoption Successful
• Use a Physical Board or Good Software
• Start collecting and using statistics
• Engage a coach / consultant
• Action over talking
• Give everyone training and start group-wide discussions
• Enthuse, Pull, don’t PUSH
• Be clear on Why
• Process and Technical , adopt technical side as well as process side
• Get Product Management / Owner Flow to developers clear and clean
• Structure changes – Functional groups

143
SCRUM in Action
Scrum Meetings
• Sprint Planning
• Daily Stand Up
• Sprint Review
• Sprint Retrospectives

Co-Located Teams
• Easier communication &
collaboration
• Sprint execution comparatively easier

Distributed Teams
• Teams with some overlapping time
period
• Teams with no overlapping time
period

144
Watch the Live Demonstration

Watch the recorded webinar here!

Recommended Courses

NetCom Learning offers a comprehensive portfolio for Agile Project

Management training options. Please see below the list of recommended
courses:

Agile Project Management

Managing Agile Projects Using TFS 2017
PMI Agile Certified Practitioner (PMI-ACP)®
Check out more Agile Project Management training options with NetCom
Learning – CLICK HERE
Our live webinars will help you to touch base a wide variety of IT, soft skills and
business productivity topics; and keep you up to date on the latest IT industry trends.
Register now for our upcoming webinars:

5 Practices of Exemplary Leadership – May 04

A Deep Dive in the World of IT Networking (Part 1) – May 09

How to Manage & Secure Data with Microsoft Datacenters?- May 11

VMware vCenter 6.5 Consoles and Connections – May 15

Office 365 on any Platform (Windows, Mac, Mobile/Tablet) – May 18

 Special Promotion

Whether you're learning new IT or Business skills, or you are developing a learning plan for
your team, now you can register for our Guaranteed to Run classes with confidence.
From Microsoft, to CompTIA, to CISSP; all classes delivered by top-notch instructors in in-
person Instructor-led Classroom or Live Online.
Learn more»
To get latest technology updates, please follow our social media pages!
THANK YOU !!!

We manage learning.
“Building an Innovative Learning Organization. A Framework to Build a
Smarter Workforce, Adapt to Change, and Drive Growth”. Download now!