Register for future talks like this at www.coachingagilejourneys.com Date: 11/14/17 Time: 4:00-5:00 PM EST Speaker: Mike Ackerbauer Topic: Understanding the Keys to Breakthrough Teams Description: Why do some Agile teams become shining innovators and others struggle? This talk will guide teams to understand the natural elements and flow of team problem solving. They will learn techniques to tailor the process for each team’s members. By doing so, they will unlock the natural innovative nature of every team member and find the “wisdom of the crowd” — how the people on an Agile team can wring out every last ounce of their creative best in service to their projects and each other. Speaker Bio: Mike Ackerbauer is the Whole Team Evangelist for IBM CIO’s Agile Academy, and links teams to exceptional tools and practices for extraordinary outcomes for their customers. A self-described transformation junkie, Mike is a former technology guy who discovered he has more passion for developing the people who develop technology. Mike is also a certified rock balancer and buffalo wings fanatic. Speaker’s links/social media: twitter.com/macker http://ack-labs.com https://www.linkedin.com/in/michaelackerbauer/

1. Backlog Maintenance Iteration Planning Daily Standup Retrospective ShowcaseDoing the work Blockers
Clarify - HIGH
Clarify - LOW
Ideate - High
Ideate - LOW
Clarify ImplementIdeate Develop Clarify ImplementIdeate Develop
ImplementIdeate Develop
Clarify ImplementIdeate Develop Clarify ImplementIdeate Develop
Clarify ImplementIdeate Develop
Consider building a
feeder mechanism
for ideas (empathy
map, stakeholder
group)
Clarify ImplementIdeate Develop
Develop - HIGH
Develop - LOW
Implement - HIGH
Implement - LOW
Apply a
common set
of "done"
critieria for
every story
Clarify
Try a 5 Why's
exercise
Do a root cause
analysis
Team will enjoy
this; consider
rotating who is
"scribe" so each
team member gets
to have fun
Team could spend
too much time on
each idea; consider
setting a time limit
for discussion
Avoid letting
it become a
solutioning
session
Team will enjoy
this; consider
rotating who is
"scribe" so each
team member gets
to have fun
Team could spend
too much time on
each idea; consider
setting a time limit
for discussion
Be sure to clarify
ONLY the tasks;
don't try to rewrite
the acceptance
criteria
Avoid the
tendency to
over-engineer
the solution
Go for novel
approaches in
what stories
you write and
why
Highlight the
essence of
the story
Refine your
done
conditions
Refine
acceptance
critieria
Avoid the
tendency to
over-analyz
e
Avoid "paralysis"
because you feel
like some detail
is not perfectly
clear
This is agile, "good
enough" is OK (you
can fix it later). Make
an assumption and
document it so you
can move on
Make sure
you have
SMART
tasks
Even if not a
"development" team,
consider using
ZenHub as an easy
way to keep track of
any assumptions you
have to make
Make sure your
done conditions
are applicable to
all stories (have
internal
consistency)
Be open to
novel
approaches
to solving a
blocker
Document your
assumptions
and revisit at the
retrospective
Avoid writing
stories that do
not meet a
user need
Don't
rewrite
acceptance
critieria
Make sure
to write
SMART
tasks
Don't let a blocker
linger; any one
person blocked
means the whole
team's velocity is
at stake
Look for "good
enough"
solution, not
the "best"
solution
Make sure
your stories
are grounded
in user needs
Avoid the
tendency to
get bogged
down in
pro/con lists
Try an
evaluation
matrix to weigh
the critical
factors of a
story
For Priority, try
running stories
through a
tournament (A>B,
A>C, C>B, D>A) =
D,A,C,B
Get a basic
plan of action
together and
keep moving
Avoid
over-analyzin
g; keep
moving
Don't base
your ideas on
an assumed
problem
Make sure to get to
a comfort level so
the one who is
blocked feels the
right problem is
being addressed
Determine how
you will complete
the stories; what
are the necessary
tasks?
Avoid "paralysis"
because you feel
like some detail
is not perfectly
clear
Get to a place
where you can
move forward on
an MVP-type
problem
statement
Avoid
blameshifting on
things that did
not go well
Be sure to
timebox what did
not go well
If there are a lot of
things to debrief,
consider doing an
ideation session
separately
Make sure to
capture stories
from your
previous
retrospective
Make sure to
capture stories
from your
previous
retrospective
Avoid tendency
to delve into too
much detail
during
showcase
Encourage
curiosity
Encourage
curiosity
Encourage
curiosity
Focus on
value, not
polished
presentations
Avoid
tendency to
showcase
complicated
scenarios
Focus on
telling a
story
Try to think of the
simplest scenario that
you can showcase
(hint: focus on
story/feature
acceptance criteria)
Focus on the
value of the
outcome, as
opposed to the
process or
details
Ask yourself,
"why does
this product
matter?"
Avoid trap of
skimming over
Acceptance
Criteria
If you have a
high clarifier on
your team, let
them be "scribe"
for story writing
Make sure
to write
SMART
tasks
Team will want
to "gloss over"
tasks as
something "we
all know"
Keep track
of your
backlog
items
Find easy ways to
capture your work
progress (eg, use
GitHub issues and
comments)
Team members will
have a tendency to
make implementation
decisions and forget
to share with the rest
of the team
Document your
progress (even
if not related to
a story)
Read up on
different
Retrospective
techniques
(retrium.com)
Use powerful
questions as a
way to
encourage
input
ask
powerful
(clarifying)
questions
Team members
may be
reluctant to
discuss issues
ask
powerful
(ideating)
questions
ask
powerful
(developing)
questions
Avoid trap of
not listening
carefully to
stakeholder
questios
Consider the
technique of "repeat
back the question"
(so stakeholder can
confirm/clarify) before
answering
Team will have
tendency to write
Acceptance
criteria that are
"how' and not
"what"
Don't be
afraid of
LOTS of
stories
Put yourself in
the shoes of a
particular
type of user
Avoid the trap
of not clarifying
the "who" in the
user story (ie,
the "as a ...")
Express ideas
by telling a story
about how a
specific user
can benefit
Focus your
discussions on
the "what" of
each story, not
the "how"
Team will want to
"slip into
solutioning"
which is not part
of backlog
maintenance
Avoid
temptation to
change the
Acceptance
criteria
Focus on what
things need to be
done to meet the
acceptance
criteria
Focus on
"how" ideas,
not "what"
ideas
Use your
clarifiers and
developers to
pare down list
of tasks
as "how
might we ... "
questions to
gather task
'ideas'
Avoid adding
new stories
while refining
prioritized
stories
Avoid doing
more work
than is truly
necessary
Focus on
the explicit
task(s)
Add new
ideas to the
parking lot
Avoid trying to
over think
multiple
possible
solutions
see the
blocker as an
MVP in a
microcosm
Save
"solution"
discussions
to end of
retrospective
During discussion
of what didn't go
well, team will
want to spend
time solutioning
highlight
the
essence
highlight
the
essence
Avoid trap of
spending too
much time
solutioning;
showcase is for
LISTENING to
stakeholders
Avoid
overselling
the value /
outcome
Reassure
stakeholder(s)
that multiple
solutions exist
but don't go into
detail
Remember to
"W.A.I.T."
(why am I
talking)
Team will want to
adopt the first idea
that comes along,
instead of
exploring options
Consider
regularly
scheduled
Design Thinking
exercises
try an
empathy
mapping
exercise
Avoid
solutioning or
jumping on the
first solution
mentioned
Ask this final question
before you finish
fleshing out each
story: "is there any
way to make this
simpler or easier?"
Try not to
jump on the
first story you
like
No iteration plan is
perfect; avoid the trap
of continuing to work
on a task that is not
panning out simply
because it's part of the
story
The next Daily
Standup is an
opportunity to raise
the issue and tweak
your plan if
something is not
going well
Engage new
ideas on their
merits, not
their pitfalls
Don't kill an idea
on how to solve
a blocker just
because it
doesn't "fit"
Affirm your
teammate by
affirming a
proposed
idea
Try the POINt
method
(Positives,
Opportunities,
Issues, New
Thinking)
The team will not
want to spend
enough time on
possible solutions
to issues raised in
the retro
highlight the
essence of
what
worked/didn't
work
Avoid
fleshing out
new ideas
Pick 1 thing to fix
so as not to
overwhelm the
team with having
to produce a lot of
ideas
Don't reverse
engineer
what didn't
go well
Avoid falling into
defensiveness
when
stakeholders
give feedback
Don't prematurely
cut off a
productive
brainstorming
session with the
stakeholder
Allow time
for Q&A
Stay in the mindset
that by showing them
what they asked for,
you are really
triggering them to
further clarify what
they really want
Avoid trap of
"killing" ideas
because of
potential
risks/costs
Limit potential
risks/costs to only
those that are
essential
acceptance
criteria
Keep story
sizing in mind
when
determining the
number of tasks
It's OK to
clarify what
the story will
NOT
accomplish
Avoid the tendency to
"pile on" when
blockers are
mentioned (i.e., adding
blockers not essential
to acceptance criteria)
"Just the
facts,
ma'am"
Be disciplined
about using
"parking lots"
(post-standup
follow up
meetings)
Avoid
over-solutio
ning
Don't let your
desire to "dig in"
to each issue
derail the stand
up
Stick to the
stories in
progress or
blockers
Don't move
forward without
hearing from
every team
member
Remember the
standup is to share
updates on stories in
progress; move the
status forward and get
to blockers (or back to
work!)
Don't engage
blockers during
standup
Consider asking the
team to write what
they are going to
share at the standup
in Slack before the
standup
Save
solutions to
blockers for
post-standup
Consider asking the
team to write what
they are going to
share at the standup
in Slack before the
standup
Team will have a
tendency to want to
explore solutions to
blockers in detail
(and derail the
stand-up)
Save ideas
for
post-standup
/ backlog
most likely there
is a high team
preference in
another area.
this section
intentionally
left blank
Avoid tendency to
identify blockers
which are not
strictly related to
acceptance
criteria
Keep the
iteration
flow going!
Put areas of
improvement
into parking
lot (for retro)
Avoid doing
more work
than is truly
necessary
Avoid
adding new
tasks
Focus on
the explicit
task(s)
Add new
ideas to the
parking lot
Blockers are
logjams that need
to be removed /
resolved; not
necessarily solved
Select the
easiest
solution to
unblock the
blocker
Resolve,
don't
"solve"
Pick up
thoughts
from parking
lot
Time box the
"what didn't
go well"
discussion
Add solution
thoughts to
parking lot
For complex
problems,
consider an
exploratory task
for the backlog
Pick 1 thing to
fix so as not
to overwhelm
the team
Avoid
frightening
stakeholders
with "risk
overload"
Prepare in
advance which
key risks you
want to have
stakeholders
clarify
Support
showcase
with details
only when
needed
Be sure to
check off tasks
and move
stories as they
are completed
Save new
tasks for the
parking lot
Don't add
tasks to your
"to-do" list that
are not in the
story
Pair with a high
implementer
when working
on a story
Establish
team rewards
for closing
stories
Don't redefine
the story after
you commit to
it
Consider what
technical debt
needs to be
reduced
Create a "punch
list" of tasks for
the story you
select
Ensure the team
focuses on
story-related
topics
Try not to push
or oversell your
idea for
resolving a
blocker
Allow time for
reflection
Celebrate team
accomplishments
Don't blow off
team
achievements
Ask: "how might we
make this better?" (ie,
is this really doing
the best job of
meeting acceptance
criteria)
Don't
assume it's
"good
enough"
Ask: "is this the
best way to
remove this
blocker right
now?"
Be deliberate in
considering
quality
Outcome
must be to
resume
forward
progress
Don't focus
on
solutioning
Focus on
task/story
progress
Be sure to
timebox the
standup and
move non-story
items to
post-standup
Focus on
breaking the
iteration
logjam
Don't rush
topics that need
to be covered -
but do so in the
post-standup
Be open to
novelty in
how you
execute
tasks
Don't
underestimate
the effort
Team will
have a
tendency to
gloss over
details
Consider
the effort
bounds of
this story
Ask key open
questions from the
user's perspective
(what would make
the experience
bad)
Assume
more effort is
necessary
than less
If in doubt
on sizing,
go with
larger size
Ask: "what
are we
missing?"
Team will have a
tendency to latch on
to first way to
implement instead
of considering
alternatives
Allow time for
each story to
consider
alternative
solutions before
writing tasks
Avoid
"perfecting"
your work
Don't be
"done" with a
story/task too
quickly
Take time in the
iteration to
improve
functionality
Focus on "how"
the tasks should
answer the story
most likely there
is a high team
preference in
another area.
this section
intentionally
left blank Team will want to
pick 1st way to
remove blocker
(which may not
be best way)
Take the time
post stand up
to talk through
blockers
Team members
may not get to
root cause of
problems
Don't assume the
team will
automatically get
better based on
information
gathered
Each retro should
end with team
commit to make
something better
Don't assume the
team knows how
to get better
Make sure retro
has time box for
considering how
to get better
Capture
stakeholder
feedback on
areas for
improvement
ask
powerful
(developing)
questions
Probe new
requests from
stakeholders to
ask which
alternative
solution they
would like
Trap is
assuming
stakeholders
know what
they want
Reinforce that
story should
focus on
outcomes that
appeal to
stakeholder
Team may want to
"skip" writing
complete story
and complete
acceptance
criteria
Take time to
write complete
story (as a, I
want, so that)
Don't rush the
time it takes to
reach shared
understanding
Don't
commit to a
story too
soon
Stay in touch
with your team
about what you
are doing (or
have done)
Don't let your
desire to get
things done get in
the way of getting
things done right.
Make sure team fully
understands what it
is committing itself
to before putting the
story into the
iteration
Avoid the trap
of taking on
too many
story points
Team will have
a tendency to
avoid
documenting
progress
Leverage tools
that make
documenting
progress easy
(e.g. GitHub)
Team members
will have a
tendency to
report too much
detail
Ask the team to
write what they
are going to share
at the standup in
Slack before the
standup
Make sure your
solution for the
blocker covers all
aspects of the
blocker
Ask: "is this the
best way to
remove this
blocker right
now?"
Allow for
feedback to
improve
alternatives
Don't move
too quickly to
"what's next"
Use team's
success to build
an even better
backlog
Give
stakeholders
time to review
and ask
questions
Avoid temptation to
move quickly
through showcase
without allowing
time for Q&A
Open your
planning call by
restating next
milestone team is
trying to achieve
most likely there
is a high team
preference in
another area.
this section
intentionally
left blank
Don't assume
you know your
stakeholder's
requirements /
expectations
most likely there
is a high team
preference in
another area.
this section
intentionally
left blank Team will have a
tendency to not
want to focus on
closing out tasks
in a timely manner
Consider using a
task burn down
chart to clearly
see remaining
work
Team will tend
to be vague in
reporting work
accomplished
Consider
numbering tasks
for iteration and
have team
members report by
task number
Consider asking the
team to write what
they are going to
share at the standup
in Slack before the
standup
most likely there
is a high team
preference in
another area.
this section
intentionally
left blank
most likely there
is a high team
preference in
another area.
this section
intentionally
left blank
Team collaboration do's & don'ts
Don't write
story tasks
yet
Do this
Avoid this
Legend
TeamPreference
Agile Practice
Clarify preference
Enjoys exploring challenges and opportunities
Likes to examine the details
Wants a clear understanding of the issue
Prefers a methodical approach to solving problems
May suffer from “analysis paralysis”
Ideate preference
Likes to look at the big picture
Enjoys toying with ideas and possibilities
Likes to stretch his or her imagination
Enjoys thinking in more global and abstract terms
Takes an intuitive approach to innovation
May overlook details
Develop preference
Enjoys putting together workable solutions
Likes to examine the pluses and minuses of an idea
Likes to compare competing solutions
Enjoys analyzing potential solutions
Enjoys planning the steps to implement an idea
May get stuck in developing the perfect solution
Implement preference
Likes to see things happen
Enjoys giving structure to ideas so they become a reality
Enjoys seeing ideas come to fruition
Likes to focus on “workable” ideas and solutions
Takes the Nike approach to innovation (i.e., “Just Do It!”)
May leap to action too quickly
macker@us.ibm.com