CAJ 017 - Mike Ackerbauer - Creative agile tips
1
Backlog Maintenance Iteration Planning Daily Standup Retrospective Showcase Doing the work Blockers Clarify - HIGH Clarify - LOW Ideate - High Ideate - LOW Clarify Implement Ideate Develop Clarify Implement Ideate Develop Implement Ideate Develop Clarify Implement Ideate Develop Clarify Implement Ideate Develop Clarify Implement Ideate Develop Consider building a feeder mechanism for ideas (empathy map, stakeholder group) Clarify Implement Ideate 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 Team Preference 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 [email protected]
-
Upload
coaching-agile-journeys -
Category
Business
-
view
84 -
download
0
Transcript of CAJ 017 - Mike Ackerbauer - Creative agile tips
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 afeeder mechanismfor ideas (empathymap, stakeholder
group)
Clarify ImplementIdeate Develop
Develop - HIGH
Develop - LOW
Implement - HIGH
Implement - LOW
Apply acommon set
of "done"critieria forevery story
Clarify
Try a 5 Why'sexercise
Do a root causeanalysis
Team will enjoythis; consider
rotating who is"scribe" so each
team member getsto have fun
Team could spendtoo much time on
each idea; considersetting a time limit
for discussion
Avoid lettingit become asolutioning
session
Team will enjoythis; consider
rotating who is"scribe" so each
team member getsto have fun
Team could spendtoo much time on
each idea; considersetting a time limit
for discussion
Be sure to clarifyONLY the tasks;
don't try to rewritethe acceptance
criteria
Avoid thetendency to
over-engineerthe solution
Go for novelapproaches inwhat stories
you write andwhy
Highlight theessence ofthe story
Refine yourdone
conditions
Refineacceptance
critieria
Avoid thetendency toover-analyz
e
Avoid "paralysis"because you feellike some detailis not perfectly
clear
This is agile, "goodenough" is OK (you
can fix it later). Makean assumption anddocument it so you
can move on
Make sureyou haveSMARTtasks
Even if not a"development" team,
consider usingZenHub as an easyway to keep track ofany assumptions you
have to make
Make sure yourdone conditionsare applicable toall stories (have
internalconsistency)
Be open tonovel
approachesto solving a
blocker
Document yourassumptions
and revisit at theretrospective
Avoid writingstories that do
not meet auser need
Don'trewrite
acceptancecritieria
Make sureto writeSMARTtasks
Don't let a blockerlinger; any oneperson blocked
means the wholeteam's velocity is
at stake
Look for "goodenough"
solution, notthe "best"solution
Make sureyour stories
are groundedin user needs
Avoid thetendency toget bogged
down inpro/con lists
Try anevaluation
matrix to weighthe criticalfactors of a
story
For Priority, tryrunning stories
through atournament (A>B,A>C, C>B, D>A) =
D,A,C,B
Get a basicplan of actiontogether andkeep moving
Avoidover-analyzin
g; keepmoving
Don't baseyour ideas onan assumed
problem
Make sure to get toa comfort level so
the one who isblocked feels theright problem is
being addressed
Determine howyou will completethe stories; what
are the necessarytasks?
Avoid "paralysis"because you feellike some detailis not perfectly
clear
Get to a placewhere you can
move forward onan MVP-type
problemstatement
Avoidblameshifting onthings that did
not go well
Be sure totimebox what did
not go well
If there are a lot ofthings to debrief,consider doing anideation session
separately
Make sure tocapture stories
from yourprevious
retrospective
Make sure tocapture stories
from yourprevious
retrospective
Avoid tendencyto delve into too
much detailduring
showcase
Encouragecuriosity
Encouragecuriosity
Encouragecuriosity
Focus onvalue, notpolished
presentations
Avoidtendency toshowcase
complicatedscenarios
Focus ontelling a
story
Try to think of thesimplest scenario that
you can showcase(hint: focus onstory/feature
acceptance criteria)
Focus on thevalue of theoutcome, as
opposed to theprocess or
details
Ask yourself,"why does
this productmatter?"
Avoid trap ofskimming over
AcceptanceCriteria
If you have ahigh clarifier onyour team, let
them be "scribe"for story writing
Make sureto writeSMARTtasks
Team will wantto "gloss over"
tasks assomething "we
all know"
Keep trackof yourbacklog
items
Find easy ways tocapture your workprogress (eg, useGitHub issues and
comments)
Team members willhave a tendency to
make implementationdecisions and forgetto share with the rest
of the team
Document yourprogress (evenif not related to
a story)
Read up ondifferent
Retrospectivetechniques
(retrium.com)
Use powerfulquestions as a
way toencourage
input
askpowerful
(clarifying)questions
Team membersmay be
reluctant todiscuss issues
askpowerful(ideating)questions
askpowerful
(developing)questions
Avoid trap ofnot listeningcarefully tostakeholder
questios
Consider thetechnique of "repeatback the question"(so stakeholder can
confirm/clarify) beforeanswering
Team will havetendency to write
Acceptancecriteria that are"how' and not
"what"
Don't beafraid ofLOTS ofstories
Put yourself inthe shoes of a
particulartype of user
Avoid the trapof not clarifyingthe "who" in the
user story (ie,the "as a ...")
Express ideasby telling a story
about how aspecific usercan benefit
Focus yourdiscussions onthe "what" of
each story, notthe "how"
Team will want to"slip into
solutioning"which is not part
of backlogmaintenance
Avoidtemptation tochange theAcceptance
criteria
Focus on whatthings need to bedone to meet the
acceptancecriteria
Focus on"how" ideas,not "what"
ideas
Use yourclarifiers anddevelopers topare down list
of tasks
as "howmight we ... "questions togather task
'ideas'
Avoid addingnew stories
while refiningprioritized
stories
Avoid doingmore workthan is trulynecessary
Focus onthe explicit
task(s)
Add newideas to theparking lot
Avoid trying toover thinkmultiplepossiblesolutions
see theblocker as an
MVP in amicrocosm
Save"solution"
discussionsto end of
retrospective
During discussionof what didn't go
well, team willwant to spend
time solutioning
highlightthe
essence
highlightthe
essence
Avoid trap ofspending too
much timesolutioning;
showcase is forLISTENING tostakeholders
Avoidoversellingthe value /outcome
Reassurestakeholder(s)that multiple
solutions existbut don't go into
detail
Remember to"W.A.I.T."(why am Italking)
Team will want toadopt the first ideathat comes along,
instead ofexploring options
Considerregularly
scheduledDesign Thinking
exercises
try anempathymappingexercise
Avoidsolutioning or
jumping on thefirst solutionmentioned
Ask this final questionbefore you finishfleshing out each
story: "is there anyway to make this
simpler or easier?"
Try not tojump on the
first story youlike
No iteration plan isperfect; avoid the trapof continuing to workon a task that is notpanning out simply
because it's part of thestory
The next DailyStandup is an
opportunity to raisethe issue and tweak
your plan ifsomething is not
going well
Engage newideas on their
merits, nottheir pitfalls
Don't kill an ideaon how to solve
a blocker justbecause itdoesn't "fit"
Affirm yourteammate by
affirming aproposed
idea
Try the POINtmethod
(Positives,Opportunities,Issues, New
Thinking)
The team will notwant to spend
enough time onpossible solutionsto issues raised in
the retro
highlight theessence of
whatworked/didn't
work
Avoidfleshing outnew ideas
Pick 1 thing to fixso as not to
overwhelm theteam with having
to produce a lot ofideas
Don't reverseengineer
what didn'tgo well
Avoid falling intodefensiveness
whenstakeholders
give feedback
Don't prematurelycut off a
productivebrainstorming
session with thestakeholder
Allow timefor Q&A
Stay in the mindsetthat by showing themwhat they asked for,
you are reallytriggering them tofurther clarify what
they really want
Avoid trap of"killing" ideasbecause ofpotential
risks/costs
Limit potentialrisks/costs to only
those that areessential
acceptancecriteria
Keep storysizing in mind
whendetermining thenumber of tasks
It's OK toclarify what
the story willNOT
accomplish
Avoid the tendency to"pile on" whenblockers are
mentioned (i.e., addingblockers not essentialto acceptance criteria)
"Just thefacts,
ma'am"
Be disciplinedabout using
"parking lots"(post-standup
follow upmeetings)
Avoidover-solutio
ning
Don't let yourdesire to "dig in"
to each issuederail the stand
up
Stick to thestories in
progress orblockers
Don't moveforward without
hearing fromevery team
member
Remember thestandup is to share
updates on stories inprogress; move the
status forward and getto blockers (or back to
work!)
Don't engageblockers during
standup
Consider asking theteam to write whatthey are going to
share at the standupin Slack before the
standup
Savesolutions toblockers for
post-standup
Consider asking theteam to write whatthey are going to
share at the standupin Slack before the
standup
Team will have atendency to want toexplore solutions to
blockers in detail(and derail the
stand-up)
Save ideasfor
post-standup/ backlog
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank
Avoid tendency toidentify blockers
which are notstrictly related to
acceptancecriteria
Keep theiteration
flow going!
Put areas ofimprovementinto parkinglot (for retro)
Avoid doingmore workthan is trulynecessary
Avoidadding new
tasks
Focus onthe explicit
task(s)
Add newideas to theparking lot
Blockers arelogjams that needto be removed /
resolved; notnecessarily solved
Select theeasiest
solution tounblock the
blocker
Resolve,don't
"solve"
Pick upthoughts
from parkinglot
Time box the"what didn't
go well"discussion
Add solutionthoughts toparking lot
For complexproblems,
consider anexploratory taskfor the backlog
Pick 1 thing tofix so as not
to overwhelmthe team
Avoidfrightening
stakeholderswith "riskoverload"
Prepare inadvance whichkey risks youwant to havestakeholders
clarify
Supportshowcase
with detailsonly when
needed
Be sure tocheck off tasks
and movestories as theyare completed
Save newtasks for theparking lot
Don't addtasks to your
"to-do" list thatare not in the
story
Pair with a highimplementer
when workingon a story
Establishteam rewards
for closingstories
Don't redefinethe story afteryou commit to
it
Consider whattechnical debtneeds to be
reduced
Create a "punchlist" of tasks forthe story you
select
Ensure the teamfocuses on
story-relatedtopics
Try not to pushor oversell your
idea forresolving a
blocker
Allow time forreflection
Celebrate teamaccomplishments
Don't blow offteam
achievements
Ask: "how might wemake this better?" (ie,
is this really doingthe best job of
meeting acceptancecriteria)
Don'tassume it's
"goodenough"
Ask: "is this thebest way toremove thisblocker right
now?"
Be deliberate inconsidering
quality
Outcomemust be to
resumeforward
progress
Don't focuson
solutioning
Focus ontask/storyprogress
Be sure totimebox thestandup and
move non-storyitems to
post-standup
Focus onbreaking the
iterationlogjam
Don't rushtopics that needto be covered -but do so in the
post-standup
Be open tonovelty inhow youexecute
tasks
Don'tunderestimate
the effort
Team willhave a
tendency togloss over
details
Considerthe effortbounds ofthis story
Ask key openquestions from theuser's perspective(what would make
the experiencebad)
Assumemore effort is
necessarythan less
If in doubton sizing,go with
larger size
Ask: "whatare we
missing?"
Team will have atendency to latch on
to first way toimplement instead
of consideringalternatives
Allow time foreach story to
consideralternative
solutions beforewriting tasks
Avoid"perfecting"your work
Don't be"done" with astory/task too
quickly
Take time in theiteration to
improvefunctionality
Focus on "how"the tasks shouldanswer the story
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank Team will want topick 1st way to
remove blocker(which may notbe best way)
Take the timepost stand upto talk through
blockers
Team membersmay not get toroot cause of
problems
Don't assume theteam will
automatically getbetter based on
informationgathered
Each retro shouldend with team
commit to makesomething better
Don't assume theteam knows how
to get better
Make sure retrohas time box forconsidering how
to get better
Capturestakeholderfeedback on
areas forimprovement
askpowerful
(developing)questions
Probe newrequests from
stakeholders toask whichalternative
solution theywould like
Trap isassuming
stakeholdersknow whatthey want
Reinforce thatstory should
focus onoutcomes that
appeal tostakeholder
Team may want to"skip" writing
complete storyand completeacceptance
criteria
Take time towrite complete
story (as a, Iwant, so that)
Don't rush thetime it takes toreach shared
understanding
Don'tcommit to a
story toosoon
Stay in touchwith your teamabout what you
are doing (orhave done)
Don't let yourdesire to get
things done get inthe way of gettingthings done right.
Make sure team fullyunderstands what itis committing itself
to before putting thestory into the
iteration
Avoid the trapof taking on
too manystory points
Team will havea tendency to
avoiddocumenting
progress
Leverage toolsthat make
documentingprogress easy(e.g. GitHub)
Team memberswill have a
tendency toreport too much
detail
Ask the team towrite what they
are going to shareat the standup inSlack before the
standup
Make sure yoursolution for the
blocker covers allaspects of the
blocker
Ask: "is this thebest way toremove thisblocker right
now?"
Allow forfeedback to
improvealternatives
Don't movetoo quickly to"what's next"
Use team'ssuccess to buildan even better
backlog
Givestakeholders
time to reviewand ask
questions
Avoid temptation tomove quickly
through showcasewithout allowing
time for Q&A
Open yourplanning call byrestating next
milestone team istrying to achieve
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank
Don't assumeyou know yourstakeholder's
requirements /expectations
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank Team will have atendency to notwant to focus onclosing out tasks
in a timely manner
Consider using atask burn downchart to clearlysee remaining
work
Team will tendto be vague inreporting workaccomplished
Considernumbering tasksfor iteration and
have teammembers report by
task number
Consider asking theteam to write whatthey are going to
share at the standupin Slack before the
standup
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank
most likely thereis a high teampreference inanother area.
this sectionintentionally
left blank
Team collaboration do's & don'ts
Don't writestory tasks
yet
Do this
Avoid this
Legend
Te
am P
refe
ren
ce
Agile Practice
Clarify preferenceEnjoys exploring challenges and opportunities�Likes to examine the detailsWants a clear understanding of the issue�Prefers a methodical approach to solving problems�May suffer from “analysis paralysis”
Ideate preferenceLikes to look at the big picture�Enjoys toying with ideas and possibilitiesLikes to stretch his or her imaginationEnjoys thinking in more global and abstract termsTakes an intuitive approach to innovationMay overlook details
Develop preferenceEnjoys putting together workable solutions�Likes to examine the pluses and minuses of an ideaLikes to compare competing solutionsEnjoys analyzing potential solutions�Enjoys planning the steps to implement an ideaMay get stuck in developing the perfect solution
Implement preferenceLikes to see things happen�Enjoys giving structure to ideas so they become a realityEnjoys seeing ideas come to fruitionLikes to focus on “workable” ideas and solutionsTakes the Nike approach to innovation (i.e., “Just Do It!”)May leap to action too quickly
