Healthcare is changing its practices with cross-collaboration and lean practices. Implementing Agile, however, can be challenging. Here are our Top 5 Agile Pitfalls and how to avoid them.

1. Vol 1.
5MOST
COMMON
Agile
Pitfalls
Top
FreeStrategy Guide
for Digital
Transformation
Podcast • Youtube Videos • Blog • Downloadable Resources
Healthcare
Focus

2. While the concept behind Agile is laud-
able, there are pitfalls which can be
worth planning for. After eight years oper-
ating daily with Agile, I can confidently say
these pitfalls are common, yet preventable.
This article highlights the top 5 pitfalls your
healthcare team may plan for and offers a free
guide to plan your Agile transition strategy.
Page 2

3. Top 5 Agile PitfallsDigital Transformations
Simulation Centers with-
guest Thomas Dongili
Precision Medicine with
guest Nick Jacobs
Efficient Resource
Allocation in healthcare
using AI
The false dychotomy o
Paternalistic and
participative care
healthcare leaders meet during
PODCAST
EPISODES
YOU MIGHT
ENJOY
1Moving Target When
decisionmakers take on a
project, they want to know the
project’s scope. Yet, Agile means
signing the contract before
clearly determining the scope.
This is the source of two com-
mon problems: (1) Since a clear
scope is traditionally a prerequi-
site for obtaining a budget, it may
be difficult to obtain buy-in, and
(2) since the scope is a moving
target, it may be at odds with
your (internal) clients’ expecta-
tions.
2Mis-Estimated Sprint
Committing to a sprint
requires a reasonable under-
standing of the workload and the
team’s capacity. In Agile, esti-
mates are imprecise, because
they do not account for the
programmer’s level of seniority.
This can easily lead to mis-cali-
brated sprints and delays on the
critical path.
3Technical Debt In order to
successfully close a sprint,
all stories within the sprint
must be completed. In Agile,
timely delivering a solu-
tion that works well in the
short-term (with intention for
rework) can be considered
preferable to engineering
a longer-term solution that
would fail the sprint. This
built-in incentive can some-
times create what is dubbed
“technical debt” – that is,
sprint delivery with known re-
work required in the future.
4Cost of benching The
mis-estimation pitfall
previously mentioned also
creates an added, implicit
cost. For every over-esti-
mated spring, your (internal)
client will be paying for people
to be “on the bench” - that
is, idle. While adding stories
mid-sprint is the most com-
mon method to tackle this
mis- estimation, the quality of
the last-minute features can
suffer. It can also impact the
quality of the specifications
for the upcoming sprint, as
the analyst shifts his attention
away from the next sprint’s
requirements gathering.
5Cost of Under
Documenting
Tests and Sprint Acceptance are
built on a common understanding
of scope. In Agile, the product
owner has discretion over how lean
to make the documentation.Driven
to an extreme, lean documentation
can create over-dependency on
the product owner. It may make
bug tracking and test execution
longer. It may also lead to unnec-
essary reworks as first time only
after after development.
Page 3healthcarefocus.org/

4. Agile
transition
strategy
guide

5. Page 5
The Moving
Target
The
Mis-Estimated
Sprint
The
technical
debt
The
cost of
benching
The
cost of
under-
documenting
How can I help my stakeholders adjust delivery expec-
tations?
Is budget attribution in my healthcare organization
aligned with the Agile philosophy?
How can I build trust with my internal client?
How can I factor in developers’ seniority levels when
estimating a sprint?
How can I parse stories to avoid inter-dependencies?
What board or mental system can I create to monitor
critical path stories closely?
What ways can I incorporate architectural design or lon-
ger-term thinking within the sprint?
Have we clearly stated our position regarding technical
debt within the team and with the (internal) client?
What mechanisms can I set to allow for technical debt
recuperation?
How can I preventively catch and adjust inflation
estimation trends in my team?
Can I stagger sprints to allow for a buffer in
requirements gathering and test writing?
Have I considered the trade-offs between idleness
and sprint quality?
Have I considered the trade-offs between under-docu-
mented and rework?
Have I sought out preferences from team members for
whom the requirements are written for?
ex. Developers? Clients? Testers?
Your Check-list for successful
Agile Transitions
healthcarefocus.org/