O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
Backlog Maintenance Iteration Planning Daily Standup Retrospective ShowcaseDoing the work Blockers
Clarify - HIGH
Clarify ...
Próximos SlideShares
Carregando em…5
×

1

Compartilhar

Baixar para ler offline

CAJ 017 - Mike Ackerbauer - Creative agile tips

Baixar para ler offline

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/

Livros relacionados

Gratuito durante 30 dias do Scribd

Ver tudo

CAJ 017 - Mike Ackerbauer - Creative agile tips

  1. 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
  • deewakergv

    May. 7, 2020

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/

Vistos

Vistos totais

376

No Slideshare

0

De incorporações

0

Número de incorporações

279

Ações

Baixados

6

Compartilhados

0

Comentários

0

Curtir

1

×