A presentation for Agile Arizona 2017. Where is your project on the agility continuum (scale), and what might you tweak to get a little more agility (even in a waterfall culture).

1. The Agility Continuum
Where is your project (or product or team)
on the agility scale?
Thene Sheehy
October, 2017
PMP, ACP, CSP, ScrumStudy SMC & Trainer

2. Who am I?
Thene Sheehy
Program Manager/Specialist, Center for Enablement
PetSmart, since Nov, 2016
15 years in Telecom IT
8 years in Healthcare IT
…. And various others
Data Analyst/Architect
Data Management
Director, App Dev & Project Management
Project/Program Manager
Scrum Master
… Lifelong Learner

3. “We might be the Mobile Dev team, and yes… we are delivering new
features every two weeks, but we aren’t agile enough.”
“My team plans and delivers upgrades to our vendor package software
that the store/merchandise planning team uses. Since we don’t do
real Dev work, we can’t be agile.”
“Our vendor gives us a MS Project plan for upgrades, and we just plan
and deploy it. No need for agile on this. We prefer waterfall.”
“We use offshore developers, and offshore testers, so we can’t be agile.”
“We can’t deliver to production every 2 weeks, so we shouldn’t use
agile.”
Who has heard these Sound Bites ?

4. 4
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.
Consider the Agile Founding Fathers
No ‘black and white’ agile here!
Agilemanifesto.org

5. 5
The Agility Continuum
An approach to increase agility a little bit at a time
Waterfall/
Planned
Agile/
Flexible

6. 6
The Agility Continuum
A Million Points on the Continuum
Where is your team now?
Where do you want to be?
Given the culture & constraints, can you be a little more agile?

7. 7
The ‘Simple’ Prototype
Waterfall Agile
10DimensionstoAssess

8. 8
Traditional
Strong Controls
Sequential Phases
Known & Optimized Tasks
Low Tolerance for Change
Delivery at End
The Agility Continuum 1-Dimension
A Million Points on the Continuum
Where is your team now? Where do you want to be?
Iterative
Lighter Controls
Iterate Phases*
Some Tolerance for Change
Delivery in Phases
Highly Iterative
Lightest Controls
Iterate Constantly
High Tolerance for Change
Adaptive & Empirical
Ongoing Releases
If waterfall is your most appropriate style,
can you still gain benefits from some agile techniques?

9. 9
Project/Team Dimensions
➢ Governance & Change Management
➢ Scope Management
➢ Schedule Management
➢ Team Management
➢ Cost Management
➢ Quality Management
➢ Communications Management
➢ Risk Management
➢ Vendor Management
➢ Stakeholder Management
The Agility Continuum – 2nd Dimension
Look familiar to the
PMP’s in the room?
These are 10
Knowledge Areas in
the PMP Process Chart.

10. 10
• Consider one of your projects.
• As we discuss each facet of the project, score your project as:
• Waterfall level 1, 2, 3 (3 is the extreme)
• Agile 1, 2, 3 (3 is the extreme)
• Add the Waterfall and Agile points at the bottom of each column (W3 and A3 are 3 points)
• Highlight the facet(s)/ dimensions where you want the benefit of Agile Thinking and
Agile Methods, but have constraints or culture holding you back.
The Agility Continuum - Assessment
Scoring

11. 11

12. Ready?
12

13. 13
Project Governance & Change Management
The Agility Continuum
Characteristics at the endpoints of the spectrum
• Centralized command/control structure
• Project Charter, PBC, FBC – require
detailed scope, schedule, and cost up
front, and little tolerance for change
• PLT includes multiple stakeholders who
govern as a committee
• ePMO has oversight and monitors
progress
• CR’s for all Changes
• PLT governs and approves all changes
• Strong Project Management role
• Cost estimates determined centrally, by
PM
• Product Owner (PO) take lead for prioritization,
scope
• PO funnels and channels other stakeholder
input
• Product Roadmap is defined but flexible
• PO defines the MVP and releasable Versions
• ROI of each enhancement is justified
independently and used in ongoing re-
prioritization
• Scrum Master coaches on process, facilitates
team, removes impediments
• PO is actively involved on a daily basis to clarify
questions, check progress, validate results, and
answer business questions
• Backlog can be groomed constantly, and re-
prioritized every sprint (usually 2 weeks)
• Distributed and shared governance – product
owner, scrum master, and team
W3 W2 W1 0 A1 A2 A3

14. 14
Scope Management
The Agility Continuum
Characteristics at the endpoints of the spectrum
• Pure waterfall – requirements
documented in advance and approved.
• Phases follow in sequence…. Design,
Dev, Testing, Deployment (no iterations)
• Requirements fully documented, in detail,
and signed off by PLT team (or proxies)
• All architecture and design is completed
up front, before any Dev work begins. No
room for error.
• Epics & User Stories can be planned up front in
Product Roadmap, and loosely planned in Release
Plan (over multiple Iterations/Sprints).
• Adaptive planning approach – scope is loose and
can be adjusted by Product Owner every iteration.
• Kanban approach has no planning; just pick and
pull, whereas scrum includes sprint planning
• Single Product Backlog ensures prioritization is clear
• Product Owner manages Scope and Prioritization
• Product Owner defines User Stories with Acceptance
Criteria
• Requirements evolve as business needs change
• Requirements (in User Stories) are small units of work
that can deliver value quickly
• Lightweight documentation encourages a focus on
conversation with scrum/project team members (and
minimizes overhead time)
• Tasks to deliver each story are handled within the
work for the User Story so that done is ‘done’
(including testing, as much as is possible)
• User Story work should include the creation of Test
Cases, Test Data, and Automated Tests, where
possible
W3 W2 W1 0 A1 A2 A3

15. 15
Schedule Management
The Agility Continuum
Characteristics at the endpoints of the spectrum
• Project tasks are knowable and
estimable
• Project tasks have known dependencies
• Schedule is trustable and fixed
• Low tolerance for schedule changes due
to dependencies
• Project schedule is optimized to be
repeatable
• Project schedule often includes ‘wait
times’ for approvals and resource
availability issues
• Project delays in the early phases crunch
remaining work toward the same
immovable end date
• Delivery speed and dates provided by
business owner and PM
• Short (bi-weekly) cycles for PDCA (plan, dev, check, adjust),
but do not dictate production releases
• Ongoing releases (anywhere from daily to monthly)
• Release to production in smallest possible units to get
maximum value into the hands of the business
• Stable teams enable stabilizing velocity, enabling accurate
work estimates
• Minimized story dependencies enables independent delivery
into production and simplified planning
• Schedule/work estimates are completed by
scrum/project/work team to increase accuracy, and ensure
clarity/understanding
• Product Owner protects the project/scrum team from
interruptions and distractions during the sprint cycle to ensure
they meet commitments
• Scrum Master and Product Owner clear daily impediments to
increase team ‘flow’ and help ensure they meet sprint
commitments.
• Project/Scrum team commitments align to sprint end dates;
precision for mid-sprint deliveries not required to reduce
overhead; short time-boxes increase accountability
• Delivery speed and dates provided by team
W3 W2 W1 0 A1 A2 A3

16. 16
Team Management
The Agility Continuum
Characteristics at the endpoints of the spectrum
• Team members often on multiple
projects
• PM’s often manage multiple projects
• Team members report directly to their
‘resource’ manager, and dotted line
to the PM; priority conflicts arise often
• Project delays for team members
working the early phases often
compress time schedules for the
team members working the latter
phases (usually QA and Ops)
• Project Manager ‘cracks the whip’ to
hold on to scope, schedule, cost, and
quality expectations
• Team members are fully allocated to short ‘burst’ projects
to minimize wait times, increase focus, and reduce
‘context switching’
• Consistent teams over time increases accuracy of
estimates, and enables the team to move into the
‘performing’ phase (Tuckman model)
• Higher team autonomy and responsibility increase
engagement and quality – team commits based on their
understanding of work items and recent velocity
• Scrum master acts a facilitator, negotiator, servant leader
W3 W2 W1 0 A1 A2 A3

17. 17
Cost/Budget Management
The Agility Continuum
Characteristics at the endpoints of the spectrum
• Full scope and schedule defined up
front so that cost and ROI can be
calculated
• Changes to cost are avoided and
require significant levels of approvals
• Focus on meeting original cost
estimates despite changing business
needs during the project
• Smaller deliverable work units allow for less work to create
estimates along with higher accuracy
• Stable teams enable higher accuracy in cost and
schedule estimates
• Cost estimates are sub-servient to flexible scope to serve
changing business needs
• Work units delivered to production sooner and more
frequently increase the overall asset value (because
pieces are in production/usage sooner) – ROI goes up
naturally
• Cost, value, and ROI are defined per User Story to
increase flexibility in delivery schedule
• Large project estimates are allowed a greater margin of
error; re-forecasting is limited to (maybe) quarterly
(infrequently, to avoid overhead work
• Lean Thinking looks for ways to eliminate waste from the
project and minimize overhead
• Total project cost can be estimated based on release
plan, list of user stories, story points, and historical team
velocity
W3 W2 W1 0 A1 A2 A3

18. 18
Quality Management
The Agility Continuum
Characteristics at the endpoints of the spectrum
• Product is tested after fully developed
• Bugs are found by QA during late-stage
testing, long after the developer did the
initial work; Developer has to find and re-
focus attention late in the project
• Dev team has often moved on to the
next round of work when QA team begins
and bugs are found
• Sprint Review/Demo for Product Owner and Stakeholders
every 2 weeks holds team accountable for quality
delivery throughout
• Sprint Review/Demo every 2 weeks holds Product Owner
accountable to their product; issues are found early
when they are less costly to modify (minimize rework)
• Sprint Review/Demo every 2 weeks keeps PO from
business engaged in the project and gets them ‘hooked’
on seeing the product come to life
• Integrating testing during development prevents bugs
and enables fixing bugs quickly (reducing cost) to
increase quality
• Pair programming shares the testing and quality burden,
and increases quality of code, and can increase
engagement
• Sprint Retrospectives every 2 weeks allows the team to
reflect and improve process throughout the project
lifecycle
• Including the development of test cases, test data, and
automated tests within the sprint helps grow the test bed,
and speed testing
W3 W2 W1 0 A1 A2 A3

19. 19
Communications Management
The Agility Continuum
Characteristics at the endpoints of the spectrum
• Weekly/Bi-weekly status report is written
(spun) by the Project Manager for the
management team
• Communication by the PM with PLT and
the project team is less frequent and
more formal
• Use of MS Project often reduces the
visibility of status (tough to use tool)
• Product Owner is actively engaged in the project and
needs less formal status reporting
• Work tools (JIRA/Confluence) make the project
information public at all times, and easily shareable
• Project wiki (confluence space) enable all team
members to see and edit project information; tool can
present information and capture approvals, when
needed
• JIRA reports can display on project wiki (confluence
space) with live up-to-date status information.
• Scrum Ceremonies keep team members (including
Product Owner) engaged and communicating verbally –
Sprint Planning, Daily Standups, Sprint Review/Demo,
Sprint Retrospective
• Daily Standup helps clear issues quickly and keep the
team on track to meet their sprint bi-weekly commitment
W3 W2 W1 0 A1 A2 A3

20. 20
Risk Management
The Agility Continuum
Characteristics at the endpoints of the spectrum
• Formal Risk & Issue Logs
• Formal mitigation planning for risks
• Risks and Issues often defined by PM and
PLT, and less by project team
• Risks and Issues are often just the major
items, and less often include the daily
team issues
• Risk and Issue Logs often reviewed and
updated infrequently (along with status)
• Less formal Risk/Issue logs, if at all
• Risk Mitigation Tasks in Backlog
• Risk-adjusted Backlog
• Daily Impediments may be tracked in
JIRA/Confluence, but are often solved
without the overhead of tracking
• Product questions are asked/answered
daily by the Product Owner; no time
delays
W3 W2 W1 0 A1 A2 A3

21. 21
Vendor Management
The Agility Continuum
Characteristics at the endpoints of the spectrum
• Vendor contracts define the full scope of
work and expected result (needing more
detailed requirements)
• Vendor contracts often have a high
Change Fee with change approval
process
• Vendors often do their work separately
from the client with infrequent status
reporting and less frequent review/demos
• Vendor contracts are written to purchase
skills and knowledge within a
collaborative, iterative approach
• Changes have no added cost because
no detailed scope of work was defined
up front
• Vendor contract defines iterative cycle
expectations, and process expectations
for bi-weekly re-planning, daily standups,
and bi-weekly product reviews; vendor
monitoring and accountability is built into
the process
W3 W2 W1 0 A1 A2 A3

22. 22
Stakeholder Management
The Agility Continuum
Characteristics at the endpoints of the spectrum
• Stakeholders are identified upfront, and
PM meets with them to gather their
needs, expectations, communication
style, risks and issues.
• Formal stakeholder management is the
PM’s responsibility
• PM produces formal status reports for
Stakeholders, often different styles for
each one
• Stakeholders often function as a
requirements approval committee (and
change approval); conflicting priorities
often arise
• Product Owner is chosen to act as ‘front
man’ for stakeholders, and is granted
authority to make decisions, prioritize
enhancements (user stories), define
acceptance criteria, and review/approve
work product
• PO interacts with the Stakeholders, leaving
the project/scrum team to focus on
developing/delivering the work product
• Unlike Stakeholders, the PO is intimately
involved in the project on a daily basis to
clear up questions and impediments
immediately
• Stakeholders and PO have full transparent
access to project info whenever they need
it, via the work tools (JIRA/Confluence)
W3 W2 W1 0 A1 A2 A3

23. 23
The Agility Continuum
How did your
project/team score?
Can you make any
incremental
improvements?
Which culture/process
constraints are holding
you back?

24. 24
Top 10 Agile Accelerators
….. Useful EVEN in a Waterfall World
Dimension Agility Accelerator
Governance &
Change Management
Scope Management
Schedule Management
Team Management
Cost Management
Quality Management
Communications
Management
Risk Management
Vendor Management
Stakeholder Management
Fully-involved Product Owner/Manager
3-month Roadmap & 2-week Planning
Daily Standups, 2-week Reviews, 3 mo Road-mapping
Fully-allocated & Focused Teams
Estimates per Item w/Frequent Delivery to Production
Embedded & Continuous Testing
2-week Reviews & Team Status Wiki
(Transparent Information Radiators)
Risk-adjusted Backlog &
Fully-involved Product Owner/Manager
Collaboration without Handoffs
Product Owner as Visionary, Prioritizer,
Negotiator, Engagement, Newsperson

25. 25
Agile is a way of thinking, not a methodology.
Even waterfall projects can inject a bit of agile thinking & techniques.
Many of the agile techniques are not unique to agile, and useful.
All project teams can use agile techniques to improve outcomes.
Like yoga, Agile is a ‘Practice’ which allows for ongoing improvement
Agile isn’t JUST about the delivery cycle!
Where is your team now? How far could you take them?
The Agility Continuum

26. Discussion Time
26