Agile 101 for Resource Planners

| 1 | Introduction to Agile
Agile 101 for Resource
Planners
Jerry Manas
Author, The Resource Management and Capacity Planning
Handbook
VP, Customer Success and Learning Services, PDWare

Presenter
Jerry Manas  Author of The Resource Management and Capacity Planning
Handbook, Napoleon on Project Management, Managing the Gray
Areas and more
 VP, Customer Success & Learning Services, PDWare
 Past clients include the Bill and Melinda Gates Foundation, the
government of Iceland, Walgreens, Citi Latin America, CHOP,
Comcast, Hot Topic, and others.
 Work highlighted in the Houston Chronicle, National Post, Globe
and Mail, Huffington Post, Chicago Sun Times, and others
 Twitter: @jerrymanas

Topics
• Agile History, Principles, & Benefits
• Agile Terminology & Roles
• Six Unique Characteristics of Agile
• Addressing Management Fears
About Agile
• Agile in Mixed Environments
• Agile Resource Planning
• SAFe (Scaled Agile Framework)

Input Output

What we need is
more
documentation!

Cone of Uncertainty*
*Ref.SteveMcConnell,Construx

The Agile Alliance and the “Agile Manifesto”
Feb 2001 Summit, Snowbird Ski Resort, Utah: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair
Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron
Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland,
Dave Thomas
(17 Thought Leaders formed The Agile Alliance)

Escape from Dilbertville
A Declaration of
Independence… from
corporate bureaucracy
and pointy-haired bosses

Managing Uncertainty: Key Principles of Agile
How Agile Projects
Work:
• Work as a team
• Work in short
iterations
• Expect & welcome
change
• Deliver something
each iteration
• Focus on business
priorities
• Work closely with
the customer
• Inspect and adapt

Agile Manifesto: 12 Principles

Waterfall vs Agile
Plan-Driven
Value-Driven
Features
Features
Cost
Cost
Schedule
Schedule
Estimated
Fixed
Waterfall Agile

Why the Rush to Agile?
Pros Cons
Shorter development cycles Everybody does it differently
Direct feedback from customers Requires significant culture change,
especially within management
Emphasis on team ownership Reduced predictability???
Accommodates change more easily Still fairly new, not well-benchmarked
Continuous testing yields improved quality

Benefits of Agile
• Faster Value Delivered to User . . .
because of iterative process
• Reduced Uncertainty . . . because
of product & customer focus
• Better Decision Making . . . because
of collaborative focus
• Increased Trust . . . because of
incremental value
• Fewer Errors. . . because of greater
communication
• Clearer Accountability… because of
delineated roles

I think I’d rather
manage a large software
development project.
It’s Better than Herding Cats

“We’re going to use something called...”

Watch Out For Misconceptions

So… when you say “agile”…

What Agile is NOT*
• NOT anti-methodology, just against corporate waste
• NOT anti-documentation, just against excessive,
premature, never-read, and never-maintained tomes
• NOT against modeling, just against diagrams that will
sit unused in a file cabinet
• NOT against planning, but aware of the limits of
planning in a turbulent environment
*Ref.JimHighsmith,TheAgileAlliance

Reducing Waste – Do Nothing Useless
• Excessive approvals
• Redundant processes
• Bad handoffs
• Rework
• Wasteful forms
• Unused data
• Lengthy documents

Flavors of Agile
• Scrum
– Originated in Japan for product development in 1986
– Popularized by Jeff Sutherland and Ken Schwaber in the
90s
– Sprints; Daily meetings
• Crystal Clear
– Alistair Cockburn
– People/team focused
• Extreme Programming (XP)
– Kent Beck
– Stresses testing & feedback loops
• Adaptive Software Development
– Jim Highsmith & Sam Bayer – Based on RAD (Rapid Appl.
Development)
– Speculate, Collaborate, Learn
• Dynamic Systems Development (DSDM)
– Based on RAD
– Initiated by DSDM Consortium in London; Jennifer
Stapleton, Director
– Agile-like, conforms to ISO 9000 & PRINCE2

Typical Agile/Scrum Terminology
• Features are defined in user stories, which identify the user(s), action(s), and benefits.
• User Stories are estimated in relative story points (though some organizations use ideal days).
Story points are a measure of relative complexity and effort. As work is completed, developers
“earn” points.
• The team works collaboratively on prioritized stories from a backlog in fixed-time iterations called
sprints (generally 1 to 4 weeks in duration).
• After each sprint, the team and stakeholders hold a retrospective to assess progress and plan
next steps (i.e. evolutionary planning).
• Progress is tracked via a burndown chart, which tracks work completed over time (versus
planned) for the current sprint.
• Velocity measures story points completed per sprint.
• A release is generally made up of multiple sprints. Generally, the end product isn’t delivered until
the release.

Agile/Scrum Process
Story
Story
Story
Story
Story
Story
BACKLOG
Prioritized
Features
Story
Story
Story
SPRINT #1, #2, ETC.
Plan &
Develop
Evaluate
Learn
Functionality
SPRINT DEMO
• Users
• Actions
• Benefits
• Points
• Users
• Actions
• Benefits
• Points

Organizing Stories: Themes, Epics, and Features
• Theme – high level objective
• Epic – group of related features/stories
• Feature – a specific product feature
• Story – an Independent, Negotiable, Valuable,
Estimatable, Small, Testable (INVEST)
requirement
• Tasks – Actions to deliver the story (usually
managed offline)
*Ref.JimHighsmith,TheAgileAlliance

Scrum – Daily Sprint Meetings
• Led by the Scrum Master
• Purpose: Information Sharing, NOT
Problem Solving
• Goal: Cohesiveness
• Keep under 15 minutes
• Each person answers 3 questions, as
relevant to the Sprint:
– What have I done since yesterday’s
meeting?
– What am I doing today?
– What barriers am I facing?
• Stay out of the weeds!! Address
issues offline.
• The Product Owner may attend, but
as a silent observer.

Common Agile Roles
• Product Manager/Owner – determines the product vision and ensures that
features listed in the backlog are prioritized and understood; provides User
Stories (users/actions/benefits)
• Customer – monitors progress and provides input for valuable deliverables
• Development Manager/SCRUM Master/Project Manager - populates sprints from the
project backlog & updates story points based on planning sprints; facilitates daily
meetings and sprint demos
• Developers – are assigned to stories & make testing notes against stories; report
effort for cost tracking purposes
• Resource Managers - optimize resource utilization across multiple projects &
ensure resource availability on critical projects
• QA/QE Manager/Testers – focuses on quality assurance/engineering, including
process improvements, testing, and measurement

Six Unique Characteristics of Agile
1. Traditional Cost Baselines are irrelevant
2. Up-front written specifications don’t apply
3. The devil is in the details (the PM needs business and use case
knowledge)
4. It’s all about the product
5. Agile projects are community-driven
6. Agile projects are often relatively small and low risk
Q: How does this impact the role of the project
manager?

10 Common Management Fears About Agile
1. It won’t work for big, complex projects
2. It’s too open-ended. We can’t predict costs. It’s “sanctioned
scope creep”
3. It sounds like “back of the napkin” design & planning
4. It’s too “techie” focused
5. Software developers don’t talk the same language as customers
6. Customers don’t have time to get involved in planning
7. We don’t want our customers to see our dirty laundry
8. This “teamwork” approach doesn’t sound efficient
9. Daily meetings? Our employees will feel like they’re under a
microscope
10. It’s too rigid and inhibits individual creativity

Some are utterly against the idea…

Addressing Management Fears
1. Be Flexible – Use the right methodology for the right job
2. Focus on business symptoms – over technical solutions
3. See for Yourself – assess the user experience (before and
after)
4. See more broadly – don’t just focus on the software; Look at
process and behaviors
5. Sweat the small stuff – engage a business analyst to catch
small details
6. Bridge the culture gap – between technicians and customers
7. Embrace change, not chaos – avoid “Not only do we change,
we oscillate!”
8. Think product, not project – manage by features and releases
9. Gain commitment – to attend retrospectives and open demos
10. Focus on outcomes and value – not activities or hours

When NOT to use Agile
1. Initiatives that need requirements defined up front,
and heavy documentation
2. Formal specs are needed for auditability, safety, or
precision
3. Scope and requirements are known, can be defined,
and are unlikely to change much
4. Lots of approvals needed by multiple parties
5. Culture or stakeholders are unwilling to embrace an
Agile approach
6. Customers/users are not generally available to
participate
7. Team lacks interpersonal skills or heavy technical
knowledge (can’t be empowered)
8. Team is too large to be effective at cross-
communication

Agile &Virtual Teams
• As predicted by analysts, an
increasing percentage of
knowledge-based project work is
being completed by distributed
virtual teams.
• The presents new challenges in
collaboration, a central tenet of
Agile
• An understanding of online
collaboration tools is key

A Dose of Reality
• More and more companies are
implementing and experimenting
with Agile
• Relatively few companies are
Full Agile (mostly startups)
• There is still the need to
communicate the productivity
and value of Agile-driven
initiatives in traditional terms
– Scope – what will it do?
– Time - when will it be ready?
– Resources - who is working on
it?
– Cost - what is it costing us?

Guidelines for Mixed Environments
• Don't let ideology get in the way of common sense
(Agile was meant as a cure for that!)
• Understand the success factors for Iterative
Methodologies vs. Waterfall
• For senior management reporting, the key
milestones should be “methodology agnostic.” This
implies getting creative with project templates and
milestone dependencies.
• Agile Resource Management: For the core Agile
team, planning resources at a project and team level
is best. Non-Agile allocations can be done more
granularly if needed.

Resource Planning: Traditional vs. Agile
Traditional
• Plan individual workload
• Utilization-focused metrics (Are
the people busy?)
– Resource Demand over time
• Assignments based on project
priorities
• Project/task assignments
• Resources allocated to projects
Agile
• Plan team workload
• Velocity/Burndown metrics (Are they
delivering value? At what pace?)
– Points Earned over time
• Assignments based on prioritized
backlog
• Team assignments
• Resources allocated to teams

“But resource
planning is
unnecessary in
Agile! We all
work as a
team!”

Why Agile Resource Planning is Necessary
• Though scope isn’t fixed, it’s still estimated as to
what can be delivered when, within given
capacity.
• In some organizations, people aren’t fully
dedicated to a team, and some teams aren’t fully
dedicated to one project.
• The people paying the bills still generally want to
know what the people are working on, the
benefits being delivered and at what cost.
• Teams are rarely 100% static over time. At some
point, team members come and go, take
vacations, etc. Teams can self-manage this, but a
little planning never hurts!

Independent of the way
projects are managed
IN HYBRID ENVIRONMENTS, THE GOAL IS TO DEVELOP A
RESOURCE PLANNING MECHANISM THAT IS:
Invisible to the project
managers
Complete in combining
all aspects of the
projects
Light in
Implementation

ALLOCATING RESOURCES TO TEAMS

ASSIGNING TEAMS TO PROJECTS

AGILE RESOURCE PLAN (EXTRAPOLATED)
Since we know how much the resources are
allocated to a team...

COMBINED FORECASTED ALLOCATION

COMBINED PROJECT DEMAND ALLOCATION

COMBINED RESOURCE UTILIZATION

Scaled Agile Framework® (SAFe®)
• Developed by Scaled Agile, Inc. (Dean Leffingwell)
• Combines Lean and Agile methods into an enterprise
framework
• Tiered, aligned approach:
– Portfolio (Vision, Themes, Funding, Creation of
EPICs/Initiatives, Kanban approach)
– Program (Value Steams, Features, Program Backlog)
– Team (Refined Team Backlog, Iteration Goals, Stories)
• Agile teams organized by long-term Agile Release
Trains (ARTs) that own value streams.
– Execute vision, roadmap, program backlog, completing
goals in fixed, short term (e.g. 10 week) “program
increments” – a “continuous flow of value”
– If you miss a train, catch the next one!
• Heavy emphasis on empowered culture
• Some say overly prescriptive (ironically)

Summary: Principles of Agile
• Piecemeal iterations with fixed time and
cost, but evolving features as learnings
emerge
• Rapid and ongoing delivery of value (i.e.
working software) throughout the
project
• Close and frequent collaboration between
developers and customers to minimize
misunderstandings
• Developers are trusted to deliver to
customer needs; they are told what is
needed, not how to accomplish it

For More Information
 jerry.manas@pdware.com
 Twitter: @jerrymanas www.pdware.com
sales@pdware.com

Agile 101 for Resource Planners

Recommended

Recommended

More Related Content

Similar to Agile 101 for Resource Planners

Similar to Agile 101 for Resource Planners (20)

More from Jerry Manas

More from Jerry Manas (11)

Recently uploaded

Recently uploaded (17)

Agile 101 for Resource Planners

Editor's Notes