http://pearllanguage.org/api.php?action=feedcontributions&user=Martien&feedformat=atomPearl Language - User contributions [en]2024-03-29T06:43:17ZUser contributionsMediaWiki 1.37.1http://pearllanguage.org/index.php?title=Disagree_and_commit&diff=3047Disagree and commit2023-12-18T15:03:38Z<p>Martien: += Jeff Bezos interview</p>
<hr />
<div>{{Oyster<br />
|goal=disagree while making progress in a complex world<br />
|stage=Sparkle<br />
|context=discussing a controversial topic in a volatile and complex world<br />
|wish=You want to make progress, even when several people have different, sometimes confliction opinions and perspectives.<br />
|so=Express your disagreement while committing to support the implementation of the selected option.<br />
|wish full=You want to make progress, even when several people have different, sometimes confliction opinions and perspectives.<br />
|background=In a complex world, there are often multiple paths towards a goal, and often experts tend to have different opinions about the same topic.<br />
<br />
Here's how it works: If you feel strongly about an idea, but don't have a group's consensus or full agreement, ask your colleagues to take a chance on you.<br />
<br />
“If you have conviction on a particular direction even though there's no consensus,” Bezos writes, “it's helpful to say, ‘Look, I know we disagree on this but<br />
will you gamble with me on it? Disagree and commit?’”<br />
|therefore full=Express your disagreement while committing to support the implementation of the selected option.<br />
}}<br />
*{{p|consent}}<br />
*{{p|ritual dissent}}<br />
<br />
Jeff Bezos explains what it means to disagree and commit. This short video sums up Amazon’s dominance and why they act so fast internally as a company. 🚀<br />
<br />
{{quote|Disagree and commit is a really important principle that saves a lot of arguing.|Jeff Bezos}}<br />
<br />
There will be disagreements in any endeavor in life where you have teammates.<br />
<br />
{{quote|In society, and inside companies, we have a bunch of mechanisms we use to resolve disputes. And a lot of them are really bad. An example of a really bad way of coming to an agreement is compromise.|Jeff Bezos}}<br />
<br />
He continues:<br />
<br />
{{quote|The advantage of compromise as a resolution mechanism is that it’s low energy, but it doesn’t lead to truth… You shouldn’t allow compromise to be used when you can know the truth.|Jeff Bezos}}<br />
<br />
Another bad resolution mechanism is the more stubborn person winning:<br />
<br />
{{quote|You have two executives who disagree and they just have a war of attrition. And whichever one gets exhausted first, capitulates to the other one. Again you haven’t arrived at truth and it’s very demoralizing.|Jeff Bezos}}<br />
<br />
Jeff tells people on his team to never get to a point where you’re resolving something by who gets exhausted first:<br />
<br />
{{quote|Escalate that. I’ll help you make the decision.|Jeff Bezos}}<br />
<br />
When making decisions, you want to get as close to the truth as possible:<br />
<br />
{{quote|Exhausting the other person is not truth-seeking. And compromise is not truth-seeking.|Jeff Bezos}}<br />
<br />
But there are a lot of cases where no one knows the real truth and that’s where “disagree and commit” comes in:<br />
<br />
{{quote|Escalation is better than war of attrition. Escalate to your boss and say ‘we can’t agree on this. We like each other and respect each other, but we strongly disagree with each other and need you to make a decision so we can move forward.’ Decisiveness and moving forward on decisions as quickly as you responsibly can is how you increase velocity. Most of what slows things down is taking too long to make decisions.|Jeff Bezos}}<br />
<br />
Companies tend to organize hierarchically in which the more senior person ultimately makes the decision. But as Jeff explains in the clip below, that wasn’t always the case—he would often be the one to disagree and commit:<br />
<br />
{{quote|I would often say: ‘You know what, I don’t think you’re right. But I’m going to gamble with you and you’re closer to the ground truth than I am. I’ve known you for 20 years—you have great judgement. I don’t know that I’m right either—all of these decisions are complicated. Let’s do it your way.’ But at least then you’ve made a decision, and I’m agreeing to commit to that decision. I’m not going to be second guessing it. I’m not going to be sniping at it. I’m not going to be saying ‘I told you so.’ I’m going to actively try to make sure it works. That’s a really important teammate behavior.|Jeff Bezos}}<br />
<br />
Source: https://x.com/BlackLabelAdvsr/status/1736443129715150963</div>Martienhttp://pearllanguage.org/index.php?title=Retrospective_meeting&diff=3046Retrospective meeting2023-11-15T16:13:09Z<p>Martien: /* How Navy Seals evolve using After-Action Reviews */ typo</p>
<hr />
<div>==Retrospective structure==<br />
Any meeting deserves a good structure. A default structure for a retrospective meeting looks like:<br />
#'''Set The Stage'''—to get everyone’s attention in the room (flaps down!)<br />
#'''Gather Data'''—to get everyone on the same page (just the facts, no feelings)<br />
#'''Generate Insights'''—to find out what hurts most<br />
#'''Decide What To Do'''—to implement one single improvement item<br />
#'''Close The Retrospective'''—to collect improvement actions for next retrospective<br />
<br />
==How Navy Seals evolve using After-Action Reviews==<br />
<br />
The Navy Seals only use three questions to review missions. Their breakthrough, and how it will radically improve your performance: AARs (After-Action Reviews) review projects, missions, training exercises or any other event you want to reflect on. There’s a world of difference between an effective AAR and a post-mortem bitch session. '''The magic is in the phrasing of the questions.'''<br />
<br />
Here’s how to do them:<br />
<br />
# '''What Went Well'''—Start every AAR by asking '''What replicable new learning did we gain from what went well?'''. In any post-mortem, our brains can naturally focus on what went wrong. However, it is critical to get clear on what went ''right'' so the good can be repeated.<br />
# '''What Did Not Go Well'''—Next, move on to constructive criticism. Frame the conversation with a similar question: '''What replicable new learning did we gain from what did ''not'' go well?''' Note that the question isn’t asking what went wrong, but specifically what is the new '''lesson''' we can incorporate in our future behavior.<br />
<br />
# '''New Standards'''—Finally, combine the insights from the first two steps, and assess the following: Drawing upon questions 1 and 2, '''what changes can we make to our processes to systematically improve our consistent excellence?'''<br />
<br />
This reinforces that the standard is excellence, clear process is how we get there, and asks what improvements to our process move us ahead?<br />
<br />
* Each participant should complete these questions in writing ''24 hours in advance''.<br />
* AAR sessions begin with reading all of the written feedback.<br />
* Then the meeting owner leads the discussion of each question.<br />
<br />
With excellence as the standard:<br />
# What went well—'''keep doing'''<br />
# What lessons exist from what didn’t go well—'''stop doing'''<br />
# How will we modify our processes going forward—'''change doing'''<br />
<br />
==Default retrospective==<br />
===Set the stage===<br />
#Two truths and a lie.<br />
#Reiterate the {{p|retrospective prime directive}}.<br />
<br />
===Gather data===<br />
#Present outcomes of previous improvement actions.<br />
#Present standard data like:<br />
#*Average cycle or lead time.<br />
#*Average throughput.<br />
#*Predictability.<br />
#*Changes in team composition and/or availability.<br />
#Create a timeline of the period under review; list the days of each week (Mon–Fri).<br />
#Collect events that happened. This is neutral, objective data, e.g.<br />
#*Mon: start using the new server<br />
#*Tue: deployed five stories<br />
#*Wed: had a beer<br />
#*…<br />
#Create three swim lanes as timeline<br />
#*Set tick marks for every day.<br />
#*Create four typical swim lanes:<br />
#**neutral :-|<br />
#**mad X-(<br />
#**sad :-(<br />
#**glad :-)<br />
#*Optional: add lanes for the other two emotions:<br />
#**afraid 8-[<br />
#**guilty ^_^;<br />
#Collect facts & feelings: events and observations in appropriate swim lane, cluster at will.<br />
<br />
===Generate insights===<br />
#Create table with three columns:<br />
##Good—behavior and practices you want to hone.<br />
##Bad—behavior and practices you want to improve.<br />
##Ugly—behavior and practices you want to stop.<br />
===Decide what to do===<br />
#Split table into top and bottom halves, thus creating six cells in total:<br />
##Top: Me/We (within team's scope).<br />
##Bottom half: They (beyond team's scope).<br />
#Generate measurable actions and goals in each of the six cells.<br />
#Order them—when will you take action on which improvement item?<br />
#Use the Good to try and fix the Bad and Ugly.<br />
<br />
===Close the retrospective===<br />
#Help, Hinder Hypothesis; or<br />
#ROTI.<br />
#+/Delta<br />
<br />
==Retrospective questions==<br />
*What went well?<br />
*What can be improved?<br />
*What have we learned?<br />
*What do we still not know?<br />
*What still puzzles us?<br />
*What wishes do we have?<br />
*Which single experiment will we do (to speed up)?<br />
*What did this iteration produce?<br />
*What was the team aiming for?<br />
*How did the result meet (or not meet) expectations?<br />
*What’s going on elsewhere in the organization that affects the team as they go into the retrospective?<br />
**For example, are there rumors of layoffs?<br />
**Has there been a recent merger?<br />
**A canceled product?<br />
*What is the history of previous project reviews?<br />
**What happened?<br />
**What was the follow-up?<br />
*What are the relationships between team members?<br />
**How is their work interdependent?<br />
**What are their personal connections and working relationships?<br />
*What are team members feeling?<br />
**What are their concerns or anxieties?<br />
**What are they excited about?<br />
*What kind of outcome will achieve value for the time invested— both for the retrospective sponsor and the team?<br />
*How has the team worked with facilitators before?<br />
<br />
==Keep your retros fresh==<br />
*Also conduct {{p|retrospective meeting}}s at other times than in between {{p|sprints}}.<br />
*Consider to ‘{{p|good bad ugly}}’ them, and physically crushing the ‘bad’ and ‘ugly’ after having collected them, and then ‘{{p|perfection game}}’ the ‘good’.<br />
*{{p|tip top}} each other, just like a {{p|temperature reading}}. Top identifies something you value in the other. Tip is a request—petition, solicitation, prayer, desire—for specific behavior of the other.<br />
*Turn the focus outward and ask yourself, “What can we give back to our environment?”<br />
<br />
==Alternative retrospective Format==<br />
Pick two of these three key focal points in mind for every retrospective:<br />
*speed;<br />
*fun; and<br />
*quality.<br />
<br />
==Sources==<br />
*{{book|Agile Retrospectives|Making Good Teams Great|Esther Derby, Diana Larsen}}<br />
{{WebSourceListItem<br />
|url=https://m.signalvnoise.com/the-9-questions-that-uncover-the-most-surprising-insights-from-employees-b7bc0d20ede8<br />
|site=Signal v. Noise<br />
|person=Claire Lew<br />
|title=The 9 questions that uncover the most surprising insights from employees<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/rising-continuous-retrospective<br />
|site=InfoQ<br />
|person=Shane Hastie<br />
|title=Linda Rising on Continuous Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.agilecafe.org/story-cubes-build-your-story-with-cubes-in-the-next-retrospective/<br />
|site=Agile Cafe<br />
|person=Omar Bermudez<br />
|title=Story cubes: Build your story with cubes in the next retrospective<br />
}}<br />
{{WebSourceListItem<br />
|url=https://masteringtheobvious.wordpress.com/2015/03/17/rollin-rollin-rollin-using-story-cubes-to-jazz-up-team-retrospectives/<br />
|site=Mastering the Obvious<br />
|person=Ellen Grove<br />
|title=Rollin’ Rollin’ Rollin': Using Story Cubes to jazz up team retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/01/hypotheses-retrospectives<br />
|site=InfoQ<br />
|person=Ben Linders<br />
|title=Adding Purpose and Hypotheses to Agile Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/02/retrospective-actions-done<br />
|site=InfoQ<br />
|person=Ben Linders<br />
|title=Having Actions Done from Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.targetprocess.com/blog/2010/11/development-practice-retrospectives-in-kanban.html<br />
|site=Target Process<br />
|person=Michael Dubakov<br />
|title=Development practice: Retrospectives in Kanban<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2015/08/self-cleaning.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Self cleaning<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/minibooks/agile-retrospectives-value<br />
|site=InfoQ<br />
|person=Luis Gonçalves, Ben Linders<br />
|title=Getting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercises<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/06/power-anonymous-retrospectives<br />
|site=InfoQ<br />
|person=Rui Miguel Ferreira<br />
|title=The Power of Anonymous Retrospectives<br />
}} ← must have its own {{p|anonymous retrospective}}<br />
{{WebSourceListItem<br />
|url=http://leankit.com/blog/2014/09/run-effective-standups-retrospectives/<br />
|site=LeanKit<br />
|person=Chris Hefley<br />
|title=How to Run Effective Standups and Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2014/12/whats-next.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=What’s next?<br />
}}<br />
{{tag|kanban}}<br />
{{tag|retrospective}}<br />
{{tag|ritual}}</div>Martienhttp://pearllanguage.org/index.php?title=Retrospective_meeting&diff=3045Retrospective meeting2023-11-15T16:11:35Z<p>Martien: /* How Navy Seals evolve */ Refactor, Tidy</p>
<hr />
<div>==Retrospective structure==<br />
Any meeting deserves a good structure. A default structure for a retrospective meeting looks like:<br />
#'''Set The Stage'''—to get everyone’s attention in the room (flaps down!)<br />
#'''Gather Data'''—to get everyone on the same page (just the facts, no feelings)<br />
#'''Generate Insights'''—to find out what hurts most<br />
#'''Decide What To Do'''—to implement one single improvement item<br />
#'''Close The Retrospective'''—to collect improvement actions for next retrospective<br />
<br />
==How Navy Seals evolve using After-Action Reviews==<br />
<br />
The Navy Seals only use three questions to review missions. Their breakthrough, and how it will radically improve your performance: AARs (After-Action Reviews) review projects, missions, training exercises or any other event you want to reflect on. There’s a world of difference between an effective AAR and a post-mortem bitch session. '''The magic is in the phrasing of the questions.'''<br />
<br />
Here’s how to do them:<br />
<br />
# '''What Went Well'''—Start every AAR by asking '''What replicable new learning did we gain from what went well?'''. In any post-mortem, our brains can naturally focus on what went wrong. However, it is critical to get clear on what went ''right'' so the good can be repeated.<br />
# '''What Did Not Go Well'''—Next, move on to constructive criticism. Frame the conversation with a similar question: '''What replicable new learning did we gain from what did ''not'' go well?''' Note that the question isn’t asking what went wrong, but specifically what is the new '''lesson''' we can incorporate in our future behavior.<br />
<br />
# '''New Standards'''—Finally, combine the insights from the first two steps, and assess the following: Drawing upon questions 1 and 2, '''what changes can we make to our processes to systematically improve our consistent excellence?'''<br />
<br />
This reinforces that the standard is excellence, clear process is how we get there, and asks what improvements to our process move us ahead?<br />
<br />
- Each participant should complete these questions in writing ''24 hours in advance''.<br />
- AAR sessions begin with reading all of the written feedback.<br />
- Then the meeting owner leads the discussion of each question.<br />
<br />
With excellence as the standard:<br />
# What went well—'''keep doing'''<br />
# What lessons exist from what didn’t go well—'''stop doing'''<br />
# How will we modify our processes going forward—'''change doing'''<br />
<br />
==Default retrospective==<br />
===Set the stage===<br />
#Two truths and a lie.<br />
#Reiterate the {{p|retrospective prime directive}}.<br />
<br />
===Gather data===<br />
#Present outcomes of previous improvement actions.<br />
#Present standard data like:<br />
#*Average cycle or lead time.<br />
#*Average throughput.<br />
#*Predictability.<br />
#*Changes in team composition and/or availability.<br />
#Create a timeline of the period under review; list the days of each week (Mon–Fri).<br />
#Collect events that happened. This is neutral, objective data, e.g.<br />
#*Mon: start using the new server<br />
#*Tue: deployed five stories<br />
#*Wed: had a beer<br />
#*…<br />
#Create three swim lanes as timeline<br />
#*Set tick marks for every day.<br />
#*Create four typical swim lanes:<br />
#**neutral :-|<br />
#**mad X-(<br />
#**sad :-(<br />
#**glad :-)<br />
#*Optional: add lanes for the other two emotions:<br />
#**afraid 8-[<br />
#**guilty ^_^;<br />
#Collect facts & feelings: events and observations in appropriate swim lane, cluster at will.<br />
<br />
===Generate insights===<br />
#Create table with three columns:<br />
##Good—behavior and practices you want to hone.<br />
##Bad—behavior and practices you want to improve.<br />
##Ugly—behavior and practices you want to stop.<br />
===Decide what to do===<br />
#Split table into top and bottom halves, thus creating six cells in total:<br />
##Top: Me/We (within team's scope).<br />
##Bottom half: They (beyond team's scope).<br />
#Generate measurable actions and goals in each of the six cells.<br />
#Order them—when will you take action on which improvement item?<br />
#Use the Good to try and fix the Bad and Ugly.<br />
<br />
===Close the retrospective===<br />
#Help, Hinder Hypothesis; or<br />
#ROTI.<br />
#+/Delta<br />
<br />
==Retrospective questions==<br />
*What went well?<br />
*What can be improved?<br />
*What have we learned?<br />
*What do we still not know?<br />
*What still puzzles us?<br />
*What wishes do we have?<br />
*Which single experiment will we do (to speed up)?<br />
*What did this iteration produce?<br />
*What was the team aiming for?<br />
*How did the result meet (or not meet) expectations?<br />
*What’s going on elsewhere in the organization that affects the team as they go into the retrospective?<br />
**For example, are there rumors of layoffs?<br />
**Has there been a recent merger?<br />
**A canceled product?<br />
*What is the history of previous project reviews?<br />
**What happened?<br />
**What was the follow-up?<br />
*What are the relationships between team members?<br />
**How is their work interdependent?<br />
**What are their personal connections and working relationships?<br />
*What are team members feeling?<br />
**What are their concerns or anxieties?<br />
**What are they excited about?<br />
*What kind of outcome will achieve value for the time invested— both for the retrospective sponsor and the team?<br />
*How has the team worked with facilitators before?<br />
<br />
==Keep your retros fresh==<br />
*Also conduct {{p|retrospective meeting}}s at other times than in between {{p|sprints}}.<br />
*Consider to ‘{{p|good bad ugly}}’ them, and physically crushing the ‘bad’ and ‘ugly’ after having collected them, and then ‘{{p|perfection game}}’ the ‘good’.<br />
*{{p|tip top}} each other, just like a {{p|temperature reading}}. Top identifies something you value in the other. Tip is a request—petition, solicitation, prayer, desire—for specific behavior of the other.<br />
*Turn the focus outward and ask yourself, “What can we give back to our environment?”<br />
<br />
==Alternative retrospective Format==<br />
Pick two of these three key focal points in mind for every retrospective:<br />
*speed;<br />
*fun; and<br />
*quality.<br />
<br />
==Sources==<br />
*{{book|Agile Retrospectives|Making Good Teams Great|Esther Derby, Diana Larsen}}<br />
{{WebSourceListItem<br />
|url=https://m.signalvnoise.com/the-9-questions-that-uncover-the-most-surprising-insights-from-employees-b7bc0d20ede8<br />
|site=Signal v. Noise<br />
|person=Claire Lew<br />
|title=The 9 questions that uncover the most surprising insights from employees<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/rising-continuous-retrospective<br />
|site=InfoQ<br />
|person=Shane Hastie<br />
|title=Linda Rising on Continuous Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.agilecafe.org/story-cubes-build-your-story-with-cubes-in-the-next-retrospective/<br />
|site=Agile Cafe<br />
|person=Omar Bermudez<br />
|title=Story cubes: Build your story with cubes in the next retrospective<br />
}}<br />
{{WebSourceListItem<br />
|url=https://masteringtheobvious.wordpress.com/2015/03/17/rollin-rollin-rollin-using-story-cubes-to-jazz-up-team-retrospectives/<br />
|site=Mastering the Obvious<br />
|person=Ellen Grove<br />
|title=Rollin’ Rollin’ Rollin': Using Story Cubes to jazz up team retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/01/hypotheses-retrospectives<br />
|site=InfoQ<br />
|person=Ben Linders<br />
|title=Adding Purpose and Hypotheses to Agile Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/02/retrospective-actions-done<br />
|site=InfoQ<br />
|person=Ben Linders<br />
|title=Having Actions Done from Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.targetprocess.com/blog/2010/11/development-practice-retrospectives-in-kanban.html<br />
|site=Target Process<br />
|person=Michael Dubakov<br />
|title=Development practice: Retrospectives in Kanban<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2015/08/self-cleaning.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Self cleaning<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/minibooks/agile-retrospectives-value<br />
|site=InfoQ<br />
|person=Luis Gonçalves, Ben Linders<br />
|title=Getting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercises<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/06/power-anonymous-retrospectives<br />
|site=InfoQ<br />
|person=Rui Miguel Ferreira<br />
|title=The Power of Anonymous Retrospectives<br />
}} ← must have its own {{p|anonymous retrospective}}<br />
{{WebSourceListItem<br />
|url=http://leankit.com/blog/2014/09/run-effective-standups-retrospectives/<br />
|site=LeanKit<br />
|person=Chris Hefley<br />
|title=How to Run Effective Standups and Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2014/12/whats-next.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=What’s next?<br />
}}<br />
{{tag|kanban}}<br />
{{tag|retrospective}}<br />
{{tag|ritual}}</div>Martienhttp://pearllanguage.org/index.php?title=Retrospective_meeting&diff=3044Retrospective meeting2023-11-15T11:31:32Z<p>Martien: += Navy Seals AAR</p>
<hr />
<div>==Retrospective structure==<br />
Any meeting deserves a good structure. A default structure for a retrospective meeting looks like:<br />
#'''Set The Stage'''—to get everyone’s attention in the room (flaps down!)<br />
#'''Gather Data'''—to get everyone on the same page (just the facts, no feelings)<br />
#'''Generate Insights'''—to find out what hurts most<br />
#'''Decide What To Do'''—to implement one single improvement item<br />
#'''Close The Retrospective'''—to collect improvement actions for next retrospective<br />
<br />
==How Navy Seals evolve==<br />
<br />
The Navy Seals only use three questions to review missions. Their breakthrough, and how it will radically improve your performance: AARs review projects, missions, training exercises or any other event you want to reflect on. There’s a world of difference between an effective AAR and a post-mortem bitch session. ''' The magic is in the phrasing of the questions. '''<br />
<br />
Here’s how to do them:<br />
<br />
===Step 1: What Went Well===<br />
<br />
Begin every AAR by asking this question:<br />
<br />
- “ '''What replicable new learning did we gain from what went well?'''”<br />
<br />
In any post-mortem, our brains can naturally focus on what went wrong. However, it is critical to get clear on what went RIGHT so the good can be repeated.<br />
<br />
===Step 2: What Did Not Go Well===<br />
<br />
After reviewing what went well and the successes you can repeat in the future, move on to constructive criticism. Frame the discussion with a similar question:<br />
<br />
- “ '''What replicable new learning did we gain from what did not go well?'''”<br />
<br />
Note that the question isn’t asking what went wrong… but specifically what is the new '''lesson''' we can incorporate for the future.<br />
<br />
===Step 3: New Standards===<br />
<br />
Once you have dissected the lessons from what went well and what didn’t, turn your focus to the future. Combining the insights from the first two steps, we assess the following:<br />
<br />
- “Drawing upon questions 1 and 2, '''what changes can we make to our processes to systematically improve our consistent tactical excellence? '''”<br />
<br />
This reinforces that the standard is excellence, clear process is how we get there, and asks what improvements to our process move us ahead?<br />
<br />
Process note - each participant should complete these questions in writing 24 hours in advance.<br />
<br />
AAR sessions begin with reading all of the written feedback.<br />
<br />
Then the meeting owner leads the discussion of each question.<br />
<br />
That’s an AAR process at a high level.<br />
<br />
# What went well (to be repeated)<br />
# What lessons exist from what didn’t go well<br />
# How we’ll modify our processes going forward (with excellence as the standard)<br />
<br />
Give it a shot.<br />
<br />
==Default retrospective==<br />
===Set the stage===<br />
#Two truths and a lie.<br />
#Reiterate the {{p|retrospective prime directive}}.<br />
<br />
===Gather data===<br />
#Present outcomes of previous improvement actions.<br />
#Present standard data like:<br />
#*Average cycle or lead time.<br />
#*Average throughput.<br />
#*Predictability.<br />
#*Changes in team composition and/or availability.<br />
#Create a timeline of the period under review; list the days of each week (Mon–Fri).<br />
#Collect events that happened. This is neutral, objective data, e.g.<br />
#*Mon: start using the new server<br />
#*Tue: deployed five stories<br />
#*Wed: had a beer<br />
#*…<br />
#Create three swim lanes as timeline<br />
#*Set tick marks for every day.<br />
#*Create four typical swim lanes:<br />
#**neutral :-|<br />
#**mad X-(<br />
#**sad :-(<br />
#**glad :-)<br />
#*Optional: add lanes for the other two emotions:<br />
#**afraid 8-[<br />
#**guilty ^_^;<br />
#Collect facts & feelings: events and observations in appropriate swim lane, cluster at will.<br />
<br />
===Generate insights===<br />
#Create table with three columns:<br />
##Good—behavior and practices you want to hone.<br />
##Bad—behavior and practices you want to improve.<br />
##Ugly—behavior and practices you want to stop.<br />
===Decide what to do===<br />
#Split table into top and bottom halves, thus creating six cells in total:<br />
##Top: Me/We (within team's scope).<br />
##Bottom half: They (beyond team's scope).<br />
#Generate measurable actions and goals in each of the six cells.<br />
#Order them—when will you take action on which improvement item?<br />
#Use the Good to try and fix the Bad and Ugly.<br />
<br />
===Close the retrospective===<br />
#Help, Hinder Hypothesis; or<br />
#ROTI.<br />
#+/Delta<br />
<br />
==Retrospective questions==<br />
*What went well?<br />
*What can be improved?<br />
*What have we learned?<br />
*What do we still not know?<br />
*What still puzzles us?<br />
*What wishes do we have?<br />
*Which single experiment will we do (to speed up)?<br />
*What did this iteration produce?<br />
*What was the team aiming for?<br />
*How did the result meet (or not meet) expectations?<br />
*What’s going on elsewhere in the organization that affects the team as they go into the retrospective?<br />
**For example, are there rumors of layoffs?<br />
**Has there been a recent merger?<br />
**A canceled product?<br />
*What is the history of previous project reviews?<br />
**What happened?<br />
**What was the follow-up?<br />
*What are the relationships between team members?<br />
**How is their work interdependent?<br />
**What are their personal connections and working relationships?<br />
*What are team members feeling?<br />
**What are their concerns or anxieties?<br />
**What are they excited about?<br />
*What kind of outcome will achieve value for the time invested— both for the retrospective sponsor and the team?<br />
*How has the team worked with facilitators before?<br />
<br />
==Keep your retros fresh==<br />
*Also conduct {{p|retrospective meeting}}s at other times than in between {{p|sprints}}.<br />
*Consider to ‘{{p|good bad ugly}}’ them, and physically crushing the ‘bad’ and ‘ugly’ after having collected them, and then ‘{{p|perfection game}}’ the ‘good’.<br />
*{{p|tip top}} each other, just like a {{p|temperature reading}}. Top identifies something you value in the other. Tip is a request—petition, solicitation, prayer, desire—for specific behavior of the other.<br />
*Turn the focus outward and ask yourself, “What can we give back to our environment?”<br />
<br />
==Alternative retrospective Format==<br />
Pick two of these three key focal points in mind for every retrospective:<br />
*speed;<br />
*fun; and<br />
*quality.<br />
<br />
==Sources==<br />
*{{book|Agile Retrospectives|Making Good Teams Great|Esther Derby, Diana Larsen}}<br />
{{WebSourceListItem<br />
|url=https://m.signalvnoise.com/the-9-questions-that-uncover-the-most-surprising-insights-from-employees-b7bc0d20ede8<br />
|site=Signal v. Noise<br />
|person=Claire Lew<br />
|title=The 9 questions that uncover the most surprising insights from employees<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/rising-continuous-retrospective<br />
|site=InfoQ<br />
|person=Shane Hastie<br />
|title=Linda Rising on Continuous Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.agilecafe.org/story-cubes-build-your-story-with-cubes-in-the-next-retrospective/<br />
|site=Agile Cafe<br />
|person=Omar Bermudez<br />
|title=Story cubes: Build your story with cubes in the next retrospective<br />
}}<br />
{{WebSourceListItem<br />
|url=https://masteringtheobvious.wordpress.com/2015/03/17/rollin-rollin-rollin-using-story-cubes-to-jazz-up-team-retrospectives/<br />
|site=Mastering the Obvious<br />
|person=Ellen Grove<br />
|title=Rollin’ Rollin’ Rollin': Using Story Cubes to jazz up team retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/01/hypotheses-retrospectives<br />
|site=InfoQ<br />
|person=Ben Linders<br />
|title=Adding Purpose and Hypotheses to Agile Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/02/retrospective-actions-done<br />
|site=InfoQ<br />
|person=Ben Linders<br />
|title=Having Actions Done from Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.targetprocess.com/blog/2010/11/development-practice-retrospectives-in-kanban.html<br />
|site=Target Process<br />
|person=Michael Dubakov<br />
|title=Development practice: Retrospectives in Kanban<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2015/08/self-cleaning.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Self cleaning<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/minibooks/agile-retrospectives-value<br />
|site=InfoQ<br />
|person=Luis Gonçalves, Ben Linders<br />
|title=Getting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercises<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/06/power-anonymous-retrospectives<br />
|site=InfoQ<br />
|person=Rui Miguel Ferreira<br />
|title=The Power of Anonymous Retrospectives<br />
}} ← must have its own {{p|anonymous retrospective}}<br />
{{WebSourceListItem<br />
|url=http://leankit.com/blog/2014/09/run-effective-standups-retrospectives/<br />
|site=LeanKit<br />
|person=Chris Hefley<br />
|title=How to Run Effective Standups and Retrospectives<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2014/12/whats-next.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=What’s next?<br />
}}<br />
{{tag|kanban}}<br />
{{tag|retrospective}}<br />
{{tag|ritual}}</div>Martienhttp://pearllanguage.org/index.php?title=OKR&diff=3043OKR2023-07-23T15:24:07Z<p>Martien: /* Sources */ += Gitlab » Stella Treas » Objectives and Key Results (OKRs)</p>
<hr />
<div>{{Oyster<br />
|goal=keep everyone moving forward as a team—aligned autonomy<br />
|stage=Sparkle<br />
|context=culture, productivity and alignment all in flux.<br />
|wish=Keep everyone moving forward as an aligned and autonomous team.<br />
|so=Co-create and publish objectives and key results on all levels in your organization.<br />
|image=OKR Best Practices.png{{!}}600px<br />
|prologue=To achieve great things, two things are needed: a plan and not quite enough time. —Leonard Bernstein<br />
|wish full=Keep everyone moving forward as a team in a world where culture, productivity and alignment are all in flux.<br />
|background={{quote|The greater danger for most of us lies not in setting our aim too high and falling short, but in setting our aims too low and achieving our mark.|Michelangelo}}<br />
<br />
Goals aren’t promises, they’re hypotheses<br />
<br />
Not reaching a goal can be just as valuable as reaching it, just as disproving a hypothesis is as valuable as proving it<br />
<br />
The purpose of a goal is to '''maximize your learning''', not commit to a predetermined outcome.<br />
<br />
# Don’t plan ahead of what you know now, or you’re just spinning fantasies.<br />
# What you know now will likely be wrong in a few weeks.<br />
<br />
I’m not saying "don’t plan." I’m saying that the plan is dynamic, constantly changing as you learn, and you’re always learning.<br />
<br />
==Forces==<br />
*{{p|metrics drive behavior}}<br />
*People hate corporate acronyms that mandate work more than just corporate acronyms.<br />
*Multiple teams often depend on one another to succeed.<br />
*No one person knows everything going on inside the organization.<br />
*Personal objectives that are directly and clearly connected to the broader goals of the company are more inspiring and imaginative.<br />
*Public information that everyone can see help make you feel you are toiling in a thriving environment with your manager’s approval.<br />
*Public goals and clear results:<br />
**encourage people to ask for resources; and<br />
**easily spot where you can support your colleagues;<br />
**force different types of thinking around how people ask for help from others and helps amplifying this type of dialog.<br />
*Airing things out releases anxiety and let’s people get creative—that’s when interesting things happen.<br />
*Stretched goals:<br />
**help you to be ambitious enough the push you beyond your limits; and<br />
**focuses conversations about what is truly needed to beat expectations;<br />
**encourages to {{p|question everything}}; and<br />
**forces {{p|questions that matter}} like:<br />
***“I’d have to completely solve this hard problem”; or<br />
***“I need to completely rethink how I’m addressing X or Y.”<br />
*Having clear objectives, especially those tied to developing your skills, are a key part of career development.<br />
*People love hitting their marks.<br />
*Key results that are always tied to money block seeing other, diverse objectives in the mix—it will make people play safe rather than being ambitious and entrepreneurial.<br />
*Regular updates and reviews of objectives and key results spur increased dialogue between employees, co-workers, managers, and leadership and allows recognition to be spread out over time, which tends to be more rewarding.<br />
*Self-inflicted objectives and goals are much more powerful than top-down goals dictated from higher organizational levels.<br />
<br />
{{okrs}}:<br />
*serve as a layer of communication that holds the company together;<br />
*are designed for accountability;<br />
*are enforced with scores;<br />
*elevates its game;<br />
*can become a part of the culture;<br />
*use the following structure:<br />
**high level objective;<br />
**a more detailed description of why that objective is important—a summary of how the objective aligns with the broader goals of both the person’s team and the company; and<br />
**three to five key results that will help them achieve that goal.<br />
*track results on a quantitative basis—key results are not general or subjective actions you plan to take, and should always include numbers to make it clear how much has been achieved. For example, if Mary’s objective is to improve her sales prospecting skills, one key result might be to spend two hours a week shadowing Jennifer, the team member who demonstrates the most prospecting success;<br />
*are something for people look at, every quarter, every week, every day—consistently setting goals turns goal-setting into a habit and changes how people think about their work and approach their everyday to-dos; it puts in place natural milestones that make you think about what you need to do next and aim high;<br />
*are stretched goals in order to be effective—achieving 70% of your goals is just about perfect for {{okrs}}—if you achieve 100% of your goals, you’re not trying hard enough (cf. Sun Tzu: bow tension);<br />
*are a tool for motivating and aligning people to work together by increasing transparency, accountability and empowerment;<br />
*make it easier than ever to keep people focused and collect feedback, inside and outside management meetings;<br />
*facilitate continual coaching of yourself and others and develops your whole ecosystem;<br />
|therefore full=Encourage people to spend time defining their own {{okrs}} and then to meet specifically with their managers to incorporate their feedback. Spend your time defining {{okrs}}, not measuring them. Look at {{okrs}} as a way to communicate so there’s clarity about the {{p|unity of purpose}}. Tweak and tune your {{okrs}} to be more about collaboration and less about action items. Publish them for everyone to see (next to your {{p|flow board}}. Figure out how to put {{okrs}} work best for you. ‘Retroprospect’ your {{okrs}} with a {{p|season beat}} and make it a part of your {{p|operations review}}. Hold people publicly accountable for failing to regularly update their {{okrs}}. Have 60% of your {{okrs}} defined by employees, not leadership.<br />
|new=Consider creating an {{p|impact map}} to discover and express the right {{okrs}}.<br />
<br />
Grading should be a simple exercise at every {{p|season beat}}, five minutes tops. Score an objective by averaging the individual key result scores underneath it. This is also why it’s so important to make those key results quantitatively measurable.<br />
<br />
'''Warning'''<br />
*Do not mix {{okrs}} and performance reviews; do not use it as a weapon against your employees in performance reviews.<br />
}}<br />
==Sharpening Questions==<br />
<br />
==Typical Progress Meeting==<br />
*Ask people to share their quick wins—one or two notable things they or their team has achieved since last time.<br />
*Ask people what progress has been made agains their {{okrs}}: <br />
**What are the areas that are still keeping you up at night?<br />
**Where do you need help?'<br />
**Everyone shares one or two things that are causing them the biggest concerns about hitting their {{okrs}}<br />
*Have the major concerns guides the meeting’s conversation in the right direction—because they’re always focused on removing roadblocks, they always feel like time well spent.<br />
<br />
Smashing Magazine:<br />
:Schedule deadlines as specific tasks, not the ends of phases. Rather than “Content will be completed by 4 April 2010,” state “Review the content over lunch on 4 April 2010.” This ties the deadline to an event at which results must be shown. Mini-deadlines tied to specific events are more powerful than general statements.<br />
<br />
==Sources==<br />
<br />
{{WebSourceListItem<br />
|url= https://about.gitlab.com/company/okrs/<br />
|site=Gitlab<br />
|person=Stella Treas<br />
|title= Objectives and Key Results (OKRs)<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/resources/get-aligned-strategy-first-okr-second/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=Looking to get aligned? Put strategy first, OKR second<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://quietstars.com/lax2020/<br />
|site=Quiet Stars<br />
|person=Adrian Howard<br />
|title=OKRs That Don't Suck<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://link.medium.com/uw3MScjdA6<br />
|site=Medium<br />
|person=Ian Batterbee<br />
|title=Designing for motivation with the goal-gradient effect<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://felipecastro.com/en/blog/book-review-measure-what-matters/<br />
|site=Felipe Castro<br />
|title=Measure What Really Matters<br />
|about=Good, bad and ugly of the book with the same title<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://medium.com/@mcleanonline/4-key-lessons-ive-learned-about-okrs-3f4b902ae9f8<br />
|site=Medium<br />
|person=Richard McLean<br />
|title=4 key lessons I’ve learned about OKRs<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://hackernoon.com/beyond-outcomes-over-outputs-6b2677044214<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Beyond “Outcomes Over Outputs”<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2018/05/how-vc-john-doerr-sets-and-achieves-goals<br />
|site=HBR<br />
|person=Daniel McGinn<br />
|title=How VC John Doerr Sets (and Achieves) Goals<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/<br />
|site=re:Work<br />
|title=Guide: Set goals with OKRs<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=http://felipecastro.com/en/okr-tools/<br />
|site=Filipe Castro<br />
|title=OKR Tools<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=http://eleganthack.com/the-art-of-the-okr/<br />
|site=Eleganthack<br />
|title=The Art of the OKR<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/untangling-okrs-with-a-big-visual-board-6153afa12213<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Untangling OKRs with a Big, Visual Board<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=http://okrexamples.co/company-okr-examples<br />
|site=OKR Examples<br />
|title=Company OKR Examples<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/18-things-your-okrs-shouldnt-do-23c8b57a455f<br />
|site=Medium<br />
|person=John Cutler<br />
|title=18 Things Your OKRs Shouldn’t Do…<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://dannorth.net/2017/05/01/applying-okrs/<br />
|site=Dan North & Associates<br />
|person=Dan North<br />
|title=Applying OKRs<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://medium.com/startup-tools/okrs-5afdc298bc28<br />
|site=Medium<br />
|person=@niket<br />
|title=The Fundamentals » OKRs<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://docs.google.com/document/d/1OHpQOvZz76_10ebJP2AKvvXUF3H9yd6FC89F5jS4mks<br />
|site=Google Docs<br />
|person=@niket<br />
|title=Startup OKRs Template<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=http://firstround.com/review/How-to-Make-OKRs-Actually-Work-at-Your-Startup/<br />
|site=First Round<br />
|title=How to Make OKRs Actually Work at Your Startup<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://blog.weekdone.com/introduction-okr-objectives-key-results/<br />
|site=Weekdone<br />
|person=Jüri Kaljundi<br />
|title=Introduction to OKR – Objectives and Key Results<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/blog/okr-vs-kpi/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=OKR vs. KPI: How they compare and how they work together<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Change&diff=3042Change2023-07-13T08:02:21Z<p>Martien: /* Sources */ += https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior</p>
<hr />
<div>[[File:If you don't like it, change it.jpg|right]]<br />
{{quote|Big changes feel like existential threats. Small changes support learning.|@estherderby}}<br />
{{quote|If change is hard, make it continuous.|@OlafLewitz}}<br />
{{quote|The world changes continuously; seek evolution, not stability.|@wisdomalive}}<br />
{{quote|If change is happening on the outside faster than on the inside the end is in sight.|Jack Welch}}<br />
{{quote|You have to change before you have to.|Jack Welch}}<br />
{{quote|Failure isn’t fatal, but failure to change might be.|John Wooden}}<br />
{{quote|The only way to make sense out of change is to plunge into it, move with it, and join the dance.|Alan Watts}}<br />
{{quote|Change is always personal, otherwise there is no change.|Stephen Parry (@LeanVoices)}}<br />
{{quote|Everyone thinks of changing the world, but no one thinks of changing himself.|Leo Tolstoy}}<br />
{{quote|The trees that are slow to grow bear the best fruit.|Molière}}<br />
{{quote|Perfection is attained by slow degrees; it requires the hand of time.|Voltaire}}<br />
{{quote|The world changes continuously; seek evolution, not stability.|@wisdomalive}}<br />
*One definition of change is doing something you never did before.<br />
*All change in organizations is belief change. So, create {{p|belief statements}}.<br />
*PDCA has been around for decades and pretty much any feedback loop tool/method whether it be Toyota Katas, Agile Retrospectives and even Lean Startup are re-inventions of that cycle<br />
*Each organization is unique and a custom approach to change is absolutely necessary<br />
*change is really hard and unpredictable<br />
*involve the people who are being asked to change in the change itself<br />
*ADKAR method.<br />
<br />
You can't make tough decisions without answering tough questions. Avoiding tough questions chokes change.<br />
<br />
Organizations that take a mechanistic approach to managing work and people would likely go the route of a re-org because the hierarchy and structure is how work gets done. Organizations that take an organic approach to organizational design will watch how the structure emerges and that's a scary concept for many people. Spotify and Valve are great examples of that.<br />
<br />
80% of change programs fail. Fail means negative ROI.<br />
<br />
Trying to improve the practices of the engineering department without paying attention to the rest of the organization is similar to trying to change an organ within a body without understanding the impact on the rest of the body.<br />
<br />
How do we make long-term changes? How can you stick to writing or meditating or exercising for months on end, for years, to see the amazing results you’d really like to see?<br />
<br />
*Focus on the step in front of you. Give up on the results.<br />
*Be curious about what it’s really like when you try it. Give up on the fantasy.<br />
*Be motivated by compassion for yourself and helping others. Don’t be motivated by achieving the ideal.<br />
*Savor the slow change. Don’t be caught up in quick results.<br />
*Find happiness in the learning. Forget about the happiness of the outcome.<br />
*Learn about yourself is the entire point. Don’t worry about perfect execution.<br />
<br />
And you will learn about yourself. You will have slow change. You will help yourself and others through this change. You will find out what it’s really like when you put in the effort. You will find happiness in each step, in the learning you experience along the way.<br />
<br />
{{author|Seth Godin}} on [http://sethgodin.typepad.com/seths_blog/2015/09/rearranging-our-prejudices.html Rearranging our prejudices]:<br />
<br />
<blockquote>Change is the point. It's what we seek to do to the world around us.<br />
<br />
Change, actual change, is hard work. And changing our own minds is the most difficult place to start.<br />
<br />
It's also the only place to start.<br />
<br />
It's hard to find the leverage to change the way you see the world, hard to pull on your thoughtstraps. But it's urgent.<br />
<br />
{{quote|A great many people think they are thinking when they are merely rearranging their prejudices…|William James}}<br />
</blockquote><br />
<br />
{{necklace|title=Change|theme=change}}<br />
==Sources==<br />
*https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior<br />
*Seth Godin on Familiarity http://sethgodin.typepad.com/seths_blog/2017/05/in-search-of-familiarity.html<br />
*Kotter<br />
*Drucker<br />
*Senge<br />
*Peter Lencioni (5 Dysfunctions of a Team, Getting Naked)<br />
*Heath brothers (Made to Stick and Switch)<br />
*Virginia Satir<br />
*Myers Briggs (and other Jung-based models like Discovery Insights)<br />
*"Images of Organization" by Gareth Morgan (circa 1984) tremendously valuable as far as understanding organizational design patterns and structures<br />
*http://blogs.hbr.org/taylor/2013/09/the_more_things_change_the_mor_1.html<br />
*[[50 reasons why we cannot change]]<br />
*{{book|Change Artistry|Essays on Change Artistry|Esther Derby}}.<br />
{{WebSourceListItem<br />
|url=http://www.estherderby.com/2016/09/forgotten-questions-of-change.html<br />
|site=Esther Derby<br />
|title=Forgotten Questions of Change<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.utas.edu.au/__data/assets/pdf_file/0004/313834/Coaching-Conversations-for-Change-part-1.pdf<br />
|site=University of Tasmania<br />
|title=Coaching conversations for change (part 1)<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blogs.hbr.org/2013/11/the-pace-of-technology-adoption-is-speeding-up/<br />
|site=HBR<br />
|person=Rita McGrath<br />
|title=The Pace of Technology Adoption is Speeding Up<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2014/02/done-to-us-vs-things-we-do.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Done to us vs. things we do<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/interviews/derby-language-change<br />
|site=InfoQ<br />
|person=Craig Smith<br />
|title=Esther Derby on Language, Communication and Change<br />
|kind=interview<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2014/03/what-does-it-sound-like-when-you-change-your-mind.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=What does it sound like when you change your mind?<br />
}} on '''paradigm shift'''.<br />
{{WebSourceListItem<br />
|url=http://blogs.hbr.org/2014/04/to-create-change-leadership-is-more-important-than-authority/<br />
|site=HBR<br />
|person=Greg Satell<br />
|title=To Create Change, Leadership Is More Important Than Authority<br />
}}<br />
{{WebSourceListItem<br />
|url=http://bigthink.com/1000-words/alan-watts-on-change<br />
|site=Big Think<br />
|person=Alan Watts<br />
|title=Alan Watts on Change<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blogs.hbr.org/2014/05/stress-isnt-a-threat-its-a-signal-to-change/<br />
|site=HBR<br />
|person=David Brendel<br />
|title=Stress Isn’t a Threat, It’s a Signal to Change<br />
}}<br />
{{WebSourceListItem<br />
|url=http://fasterthan20.com/2014/03/principles-for-effecting-change-in-complex-social-systems/<br />
|site=Faster Than 20<br />
|person=Eugene Eric Kim<br />
|title=Principles For Effecting Change In Complex Social Systems<br />
}}<br />
{{WebSourceListItem<br />
|url=http://zenhabits.net/slowchange/<br />
|site=Zen Habits<br />
|person=Leo Babuta<br />
|title=The Frustratingly Slow Pace of Making Changes<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2015/07/7-things-leaders-do-to-help-people-change<br />
|site=HBR<br />
|person=Jack Zenger, Joseph Folkman<br />
|title=7 Things Leaders Do to Help People Change<br />
}}<br />
*http://blog.atos.net/blog/2014/03/17/agile-myths-change-without-cost/<br />
*http://www.agilemodeling.com/essays/costOfChange.htm<br />
*http://www.marcandangel.com/2015/05/20/7-reasons-its-time-to-move-on-and-embrace-change/<br />
*https://hbr.org/2015/07/changing-an-organizations-culture-without-resistance-or-blame<br />
{{WebSourceListItem<br />
|url=http://www.slideshare.net/estherderby/six-rulesforchangepdf<br />
|site=SlideShare<br />
|person=Esther Derby<br />
|title=Six Rules For Change<br />
}}<br />
{{tag|change}}<br />
{{tag|stress}}<br />
{{tag|learn}}<br />
{{verb}}</div>Martienhttp://pearllanguage.org/index.php?title=Focus&diff=3041Focus2023-06-27T11:42:40Z<p>Martien: += File:Steve Jobs and Jony Ive reflect.jpeg</p>
<hr />
<div>[[File:Steve Jobs and Jony Ive reflect.jpeg]]<br />
<br />
Shortly after Steve Jobs returned as the CEO of Apple in 1997, he met with Jony Ive, Apple’s Senior VP of industrial design. Apple had 40 products on the market. “Jony, how many things have you said no to?” Jobs asked. Ive was confused. “You have to understand,” Jobs said, “There are measures of focus, and one of them is how often you say no.” “What focus means,” Jobs taught Ive, “is saying no to something that you—with every bone in your body—think is a phenomenal idea, and you wake up thinking about it, but you say no to it because you're focusing on something else.”<br />
<br />
Jobs walked up to a whiteboard and drew a 2 x 2 grid. On top, he wrote “Consumer” and “Professional.” Down the side, “Portable” and “Desktop.” <br />
Four products—meet Apple’s new radically focused product line, Jobs said.<br />
<br />
After that meeting, over the next two decades, Jobs and Ive—focused on making a few high-quality products while saying no to everything else—transformed a dying, near-bankrupt company into one of the most valuable companies in the world, worth over $2.9 trillion.<br />
<br />
====Takeaway 1====<br />
<br />
The philosopher Marcus Aurelius pointed out that the focus of doing less “brings a double satisfaction.”:<br />
* you get the satisfaction of having fewer things to do; and…<br />
* you get the satisfaction of doing those fewer things at a higher level. You get “to do less, better.”<br />
<br />
During Steve Jobs’ first visit to Jony Ive’s design studio, he looked around, and then he said, “Fuck, you’ve not been very effective, have you?” It was clear to Jobs that Ive was full of ideas and potential he wasn’t able to execute or fulfill under Apple’s previous leadership.<br />
In the Jobs era of “doing less, better,” Ive was very effective. Some products he designed include: iMac, iPod, iPhone, iPad, Apple Watch, and AirPods.<br />
<br />
====Takeaway 2====<br />
<br />
Even though he slashed the product line down to four products, Jobs loved to have and hear ideas. “Steve used to say to me,” Ive said, “and he used to say this a lot, ‘Hey, Jony, here’s a dopey idea.’ And sometimes they were: really dopey. Sometimes they were truly dreadful. But sometimes they took the air from the room, and they left us both completely silent.”<br />
<br />
It made me think of what Jerry Seinfeld identifies as the ultimate skill of the artist: “taste and discernment.” “It’s one thing to create,” Seinfeld says. It’s one thing to have ideas. “The other is you have to choose. ‘What are we going to do, and what are we not going to do?’” What are we going to add to the product line, and what are we not going to add? “This is a gigantic aspect of [artistic] survival,” Seinfeld continues. “It’s kind of unseen—what’s picked and what is discarded—but mastering that is how you stay alive.”<br />
<br />
——<br />
<br />
“Everything just got simpler. That’s been one of my mantras—focus and simplicity.” — Steve Jobs<br />
<br />
Seth Godin, “The number #1 reason to focus”:<br />
:You will care more about the things that aren't working yet, you'll push through the dip, you'll expend effort and expose yourself to fear.<br />
:When you have a lot of balls in the air, it's easy to just ignore the ones that make you uncomfortable or that might fall.<br />
:Success comes from doing the hard part. When the hard part is all you've got, you're more likely to do it.<br />
:And this is precisely why it's difficult to focus. Because focusing means acknowledging that you just signed up for the hard part.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2014/06/the-number-1-reason-to-focus.html<br />
|site=InfoQ<br />
|person=Seth Godin<br />
|title=The number #1 reason to focus<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.inc.com/magazine/201403/jason-fried/basecamp-focus-one-product-only.html|site=Inc.<br />
|person=Jason Fried<br />
|title=Why 37signals Refocused on a Single Product: Basecamp<br />
}}<br />
{{tag|{{PAGENAME}}}}<br />
{{verb}}</div>Martienhttp://pearllanguage.org/index.php?title=File:Steve_Jobs_and_Jony_Ive_reflect.jpeg&diff=3040File:Steve Jobs and Jony Ive reflect.jpeg2023-06-27T11:41:19Z<p>Martien: Steve Jobs and Jony Ive reflect on their relationship.
https://appleinsider.com/articles/21/10/04/jony-ive-remembers-reflects-on-his-relationship-with-steve-jobs</p>
<hr />
<div>== Summary ==<br />
Steve Jobs and Jony Ive reflect on their relationship.<br />
<br />
https://appleinsider.com/articles/21/10/04/jony-ive-remembers-reflects-on-his-relationship-with-steve-jobs</div>Martienhttp://pearllanguage.org/index.php?title=Focus&diff=3039Focus2023-06-27T11:32:12Z<p>Martien: += Steve Jobs & Jony Ive</p>
<hr />
<div>Shortly after Steve Jobs returned as the CEO of Apple in 1997, he met with Jony Ive, Apple’s Senior VP of industrial design. Apple had 40 products on the market. “Jony, how many things have you said no to?” Jobs asked. Ive was confused. “You have to understand,” Jobs said, “There are measures of focus, and one of them is how often you say no.” “What focus means,” Jobs taught Ive, “is saying no to something that you—with every bone in your body—think is a phenomenal idea, and you wake up thinking about it, but you say no to it because you're focusing on something else.”<br />
<br />
Jobs walked up to a whiteboard and drew a 2 x 2 grid. On top, he wrote “Consumer” and “Professional.” Down the side, “Portable” and “Desktop.” <br />
Four products—meet Apple’s new radically focused product line, Jobs said.<br />
<br />
After that meeting, over the next two decades, Jobs and Ive—focused on making a few high-quality products while saying no to everything else—transformed a dying, near-bankrupt company into one of the most valuable companies in the world, worth over $2.9 trillion.<br />
<br />
====Takeaway 1====<br />
<br />
The philosopher Marcus Aurelius pointed out that the focus of doing less “brings a double satisfaction.”:<br />
* you get the satisfaction of having fewer things to do; and…<br />
* you get the satisfaction of doing those fewer things at a higher level. You get “to do less, better.”<br />
<br />
During Steve Jobs’ first visit to Jony Ive’s design studio, he looked around, and then he said, “Fuck, you’ve not been very effective, have you?” It was clear to Jobs that Ive was full of ideas and potential he wasn’t able to execute or fulfill under Apple’s previous leadership.<br />
In the Jobs era of “doing less, better,” Ive was very effective. Some products he designed include: iMac, iPod, iPhone, iPad, Apple Watch, and AirPods.<br />
<br />
====Takeaway 2====<br />
<br />
Even though he slashed the product line down to four products, Jobs loved to have and hear ideas. “Steve used to say to me,” Ive said, “and he used to say this a lot, ‘Hey, Jony, here’s a dopey idea.’ And sometimes they were: really dopey. Sometimes they were truly dreadful. But sometimes they took the air from the room, and they left us both completely silent.”<br />
<br />
It made me think of what Jerry Seinfeld identifies as the ultimate skill of the artist: “taste and discernment.” “It’s one thing to create,” Seinfeld says. It’s one thing to have ideas. “The other is you have to choose. ‘What are we going to do, and what are we not going to do?’” What are we going to add to the product line, and what are we not going to add? “This is a gigantic aspect of [artistic] survival,” Seinfeld continues. “It’s kind of unseen—what’s picked and what is discarded—but mastering that is how you stay alive.”<br />
<br />
——<br />
<br />
“Everything just got simpler. That’s been one of my mantras—focus and simplicity.” — Steve Jobs<br />
<br />
Seth Godin, “The number #1 reason to focus”:<br />
:You will care more about the things that aren't working yet, you'll push through the dip, you'll expend effort and expose yourself to fear.<br />
:When you have a lot of balls in the air, it's easy to just ignore the ones that make you uncomfortable or that might fall.<br />
:Success comes from doing the hard part. When the hard part is all you've got, you're more likely to do it.<br />
:And this is precisely why it's difficult to focus. Because focusing means acknowledging that you just signed up for the hard part.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2014/06/the-number-1-reason-to-focus.html<br />
|site=InfoQ<br />
|person=Seth Godin<br />
|title=The number #1 reason to focus<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.inc.com/magazine/201403/jason-fried/basecamp-focus-one-product-only.html|site=Inc.<br />
|person=Jason Fried<br />
|title=Why 37signals Refocused on a Single Product: Basecamp<br />
}}<br />
{{tag|{{PAGENAME}}}}<br />
{{verb}}</div>Martienhttp://pearllanguage.org/index.php?title=Even_over&diff=3038Even over2023-06-21T07:23:03Z<p>Martien: /* Sources */ += Notes</p>
<hr />
<div>{{Oyster<br />
|goal=make choices, to implement and deploy strategy<br />
|stage=Sparkle<br />
|theme=Decide<br />
|context=end of the week and your team needs to make critical choices by the close of business, but you’re on an overseas flight, unreachable and unable to help. The team has two options on the table and both seem equally compelling although each have dramatic long-term consequences if they get it wrong.<br />
|wish=Always making the right call on time keeps you from drifting and puts you at peace.<br />
|so=Publish and pin “even over” statements all over the place.<br />
|wish full=Always making the right call on time keeps you from drifting and puts you at peace, even when away from decision-makers. You want {{p|decision-makers near the action}} making good and consistent decisions, possibly sacrificing one thing for the other while keeping everyone aligned—{{p|aligned autonomy}}.<br />
|background=Strategic planning is a necessary process but, ultimately, distributed teams need to make decisions with limited time and information. If your strategy is trapped in a lengthy document or worse a single executive's head, teams will be more likely to drift off-strategy over time and/or be slowed down as they need to run every decision by one person who owns the strategy.<br />
<br />
Busy teams need simple heuristics, or rules of thumb, to guide their decision making. One tool we recommend is an {{p|even over}} statement. These are simple phrases that teams can pin up on a wall and use as strategic touchstones in their work.<br />
<br />
Examples:<br />
*{{evenover|Profit margin|revenue growth}}.<br />
*{{evenover|Sustainability|profitability}}.<br />
*{{evenover|Innovation|predictability}}.<br />
*{{evenover|Best in class customer service|best in class product features}}.<br />
*{{evenover|Star teams|star players}}.<br />
*{{evenover|Taking a real lunch break|catching up on emails while you eat at your desk}}.<br />
*{{evenover|Feedback|Harmony}}.<br />
*{{evenover|Collaboration|Focus}}.<br />
*{{evenover|Impact|Following the Plan}}.<br />
|therefore full=Gather your values, goals, objectives, and desired behaviours and generate valuable outcomes based on them. Get specific and honest on each of those outcomes and tradeoffs. List all tradeoffs as “''blank'' even over ''blank''”, rank them, and put posters of them on the wall for everyone to see.<br />
}}<br />
==Feel the difference==<br />
<br />
Compare this:<br />
*{{evenover|Small organizations|global enterprises}}.<br />
*{{evenover|User growth|revenue conversion}}.<br />
*{{evenover|Initial signup retention|existing user retention}}.<br />
*{{evenover|Desktop experience|mobile experience}}.<br />
<br />
To this:<br />
*{{evenover|Global enterprises|small organizations}}.<br />
*{{evenover|Revenue conversion|user growth}}.<br />
*{{evenover|Existing user retention|initial signup retention}}.<br />
*{{evenover|Mobile experience|desktop experience}}.<br />
<br />
Same company, totally different behaviour.<br />
<br />
==Traits of strong {{p|even over}} statements==<br />
The best and strongest {{p|even over}} statements:<br />
*reflect the current state of your business and team;<br />
*align with the {{p|intent at least two levels up}};<br />
*ease decision-making consistency, quality, and speed at all levels;<br />
*feel personally relevant and honest;<br />
*may require a fierce defence in explanation;<br />
*will cost you something—with every choice you make for one thing, you sacrifice another (a.k.a. opportunity cost);<br />
*feels tough, because of the difficult tradeoff between the designated choices;<br />
*educe specific behaviour, hence culture;<br />
*facilitate a focused {{p|aligned autonomy}};<br />
*contribute to {{p|explicit policy}};<br />
*encourage honesty and accountability;<br />
*generate positive energy;<br />
*can be hard to master on your first try;<br />
<br />
==How to Generate Even Over Statements==<br />
<br />
#'''Gather what you have'''. Reflect on any existing purpose/mission/values charters and/or strategy documents your team may have already generated. Don't worry if you haven't done this yet, most teams follow an unwritten strategy even if they haven't captured it for sharing. Use this opportunity to make your strategy more explicit. Specifically, keep your eye out for<br />
##stated goals or objectives; and <br />
##defined values, behaviors, or principles.<br />
#'''Brainstorm positive outcomes, traits, and goals aligned with your values and/or strategy'''. Create a list of what your team values most. Examples: accountability, productivity, total honesty, fat profit margins, social responsibility, etc.<br />
#'''Get specific and honest about the tradeoff likely required''' for every positive you listed. For example, a fat profit margin is likely achieved with a less competitive price point. Total honesty may create interpersonal conflicts and stressful creative reviews. React and reflect on these costs as a team. If this is your first time writing {{p|even over}} statements, expressing the cost of a positive outcome may be difficult so we've provided some practice exercises you can try below.<br />
#'''Fill in the blanks''': ''outcome A'' {{p|even over}} ''outcome B''. The first blank is the preferred positive outcome (e.g. 'A fat profit margin'), the second blank is the tradeoff–only expressed as a positive outcome itself (e.g. 'A competitive price point').<br />
#'''Vote and rank'''. If you're generating {{p|even over}} statements with your team, give everyone an opportunity to vote for the statements which best reflect the strategic direction at-hand and most honestly capture how the team behaves. Ultimately, you want to arrive at '''no more than five''' {{p|even over}} statements.<br />
<br />
'''Pro Tip''': An {{p|even over}} statement should feel like it '''costs you something'''. Because of opportunity costs, every choice you make is a sacrifice. Therefore, the hallmark of a strong {{p|even over}} statement is how difficult the tradeoff feels between the designated choices. For example, “{{evenover|being rich|being poor}}” is a bad {{p|even over}} statement because it in no way forces a choice.<br />
<br />
==Get Some Practice==<br />
<br />
{{p|even over}} statements can be hard to master on your first try, but don't give up–we believe they can be incredibly useful for your team. When we work with clients, we introduce two practice exercises that can be more personally relevant and a bit fun. For each prompt, run through the steps above.<br />
<br />
'''Generate {{p|even over}} statements that describe how you approached dating when/if you were single in your 20's.'''<br />
<br />
Some examples:<br />
<br />
*{{evenover|Physical attraction|shared interests}}.<br />
*{{evenover|Neighbors|soulmates}}.<br />
*{{evenover|Likes the same music|also wants to have children}}.<br />
*{{evenover|Has a real job|every other positive attribute}}.<br />
<br />
'''Now, generate {{p|even over}} statements that describe how you decided on where you currently live.'''<br />
<br />
Some examples:<br />
<br />
*{{evenover|Short commute|exciting night life}}.<br />
*{{evenover|Good schools|good restaurants}}.<br />
*{{evenover|A large kitchen|a walk-in closet}}.<br />
*{{evenover|Courteous neighbors|air conditioning}}.<br />
<br />
In each of the examples, both the attribute on the left and the right of the statement are positive, yet the people who wrote these expressed an interest in one positive attribute even at the cost of the other.<br />
<br />
The best {{p|even over}} statements feel personally relevant, honest, and might even require a fierce defense in explanation.<br />
<br />
==How to Use Even Over Statements==<br />
<br />
Now that you've developed and refined your {{p|even over}} statements, find every opportunity to incorporate them into daily decision making. If you're a physically co-located team, use the walls around you and write or pin up the statements. If you're remote or distributed, paste them into your working documents or project management tools. As you make decisions, encourage everyone on the team to recite your {{p|even over}} statements and ensure they still reflect the current state of your business and team.<br />
<br />
'''Takeaway''': Your team may have already developed implicit {{p|even over}} statements; or rather, individuals on your team may have already developed conflicting {{p|even over}} statements. By clearing elaborating on your values as a team, you'll be able to make better, more consistent decisions over time.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=http://futureofwork.nobl.io/future-of-work/how-to-distill-a-strategy-into-simple-rules-of-thumb-for-busy-teams<br />
|site=NOBL<br />
|title=Use "Even Over" Statements to Distill a Strategy Into Simple Rules of Thumb<br />
}}<br />
{{WebSourceListItem<br />
|url=https://focus.parabol.co/strategic-prioritization-using-even-over-statements-fb63e78e7b4d<br />
|site=Parabol<br />
|person=Jordan Husney<br />
|title=Strategic Prioritization Using ‘Even Over’ Statements<br />
}}<br />
==Notes==<br />
Every decision—product, tech, whatever—that the people doing the work cannot make slows things down. Businesses tell me the thing they need to improve most is delivery speed. Interesting they can't see the connection.</div>Martienhttp://pearllanguage.org/index.php?title=Feedback&diff=3037Feedback2023-05-23T07:47:21Z<p>Martien: += Industrial Logic » Tim Ottinger » Rules for Receiving Feedback</p>
<hr />
<div>==Sources==<br />
<br />
{{WebSourceListItem<br />
|url=https://www.industriallogic.com/blog/rules-for-receiving-feedback/<br />
|site=Industrial Logic<br />
|person=Tim Ottinger<br />
|title= Rules for Receiving Feedback<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://flowchainsensei.wordpress.com/2012/09/26/how-to-give-feedback/<br />
|site=Think Different<br />
|person=Bob Marshall<br />
|title=How to Give Feedback<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=http://blogs.hbr.org/2013/12/building-a-feedback-rich-culture/<br />
|site=HBR<br />
|person=Ed Batista<br />
|title=Building a Feedback-Rich Culture<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=http://blogs.hbr.org/2014/02/to-get-honest-feedback-leaders-need-to-ask/<br />
|site=HBR<br />
|person=Jim Kouzes, Barry Posner<br />
|title=To Get Honest Feedback, Leaders Need to Ask<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/auto-scaling-feedback<br />
|site=InfoQ<br />
|person=Philipp K. Janert<br />
|title=Reliable Auto-Scaling using Feedback Control<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2015/02/i-dont-care-enough-to-give-you-constructive-feedback.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=We don't care enough to give you constructive feedback<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2015/08/the-key-to-giving-and-receiving-negative-feedback<br />
|site=HBR<br />
|person=Joseph Grenny<br />
|title=The Key to Giving and Receiving Negative Feedback<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2015/08/a-6-part-structure-for-giving-clear-and-actionable-feedback<br />
|site=HBR<br />
|person=Marshall Goldsmith<br />
|title=A 6-Part Structure for Giving Clear and Actionable Feedback<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/peer-feedback-loops-2<br />
|site=InfoQ<br />
|person=Siegfried Kaltenecker<br />
|title=Peer feedback loops: How we may benefit and what is needed to realize their potential<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/peer-feedback-loops-1<br />
|site=InfoQ<br />
|person=Siegfried Kaltenecker<br />
|title=Peer Feedback Loops: Why Metrics and Meetings Are Not Enough<br />
}}<br />
<br />
{{tag|feedback}}<br />
{{tag|source}}<br />
{{verb}}</div>Martienhttp://pearllanguage.org/index.php?title=OKR&diff=3036OKR2023-02-09T11:10:18Z<p>Martien: </p>
<hr />
<div>{{Oyster<br />
|goal=keep everyone moving forward as a team—aligned autonomy<br />
|stage=Sparkle<br />
|context=culture, productivity and alignment all in flux.<br />
|wish=Keep everyone moving forward as an aligned and autonomous team.<br />
|so=Co-create and publish objectives and key results on all levels in your organization.<br />
|image=OKR Best Practices.png{{!}}600px<br />
|prologue=To achieve great things, two things are needed: a plan and not quite enough time. —Leonard Bernstein<br />
|wish full=Keep everyone moving forward as a team in a world where culture, productivity and alignment are all in flux.<br />
|background={{quote|The greater danger for most of us lies not in setting our aim too high and falling short, but in setting our aims too low and achieving our mark.|Michelangelo}}<br />
<br />
Goals aren’t promises, they’re hypotheses<br />
<br />
Not reaching a goal can be just as valuable as reaching it, just as disproving a hypothesis is as valuable as proving it<br />
<br />
The purpose of a goal is to '''maximize your learning''', not commit to a predetermined outcome.<br />
<br />
# Don’t plan ahead of what you know now, or you’re just spinning fantasies.<br />
# What you know now will likely be wrong in a few weeks.<br />
<br />
I’m not saying "don’t plan." I’m saying that the plan is dynamic, constantly changing as you learn, and you’re always learning.<br />
<br />
==Forces==<br />
*{{p|metrics drive behavior}}<br />
*People hate corporate acronyms that mandate work more than just corporate acronyms.<br />
*Multiple teams often depend on one another to succeed.<br />
*No one person knows everything going on inside the organization.<br />
*Personal objectives that are directly and clearly connected to the broader goals of the company are more inspiring and imaginative.<br />
*Public information that everyone can see help make you feel you are toiling in a thriving environment with your manager’s approval.<br />
*Public goals and clear results:<br />
**encourage people to ask for resources; and<br />
**easily spot where you can support your colleagues;<br />
**force different types of thinking around how people ask for help from others and helps amplifying this type of dialog.<br />
*Airing things out releases anxiety and let’s people get creative—that’s when interesting things happen.<br />
*Stretched goals:<br />
**help you to be ambitious enough the push you beyond your limits; and<br />
**focuses conversations about what is truly needed to beat expectations;<br />
**encourages to {{p|question everything}}; and<br />
**forces {{p|questions that matter}} like:<br />
***“I’d have to completely solve this hard problem”; or<br />
***“I need to completely rethink how I’m addressing X or Y.”<br />
*Having clear objectives, especially those tied to developing your skills, are a key part of career development.<br />
*People love hitting their marks.<br />
*Key results that are always tied to money block seeing other, diverse objectives in the mix—it will make people play safe rather than being ambitious and entrepreneurial.<br />
*Regular updates and reviews of objectives and key results spur increased dialogue between employees, co-workers, managers, and leadership and allows recognition to be spread out over time, which tends to be more rewarding.<br />
*Self-inflicted objectives and goals are much more powerful than top-down goals dictated from higher organizational levels.<br />
<br />
{{okrs}}:<br />
*serve as a layer of communication that holds the company together;<br />
*are designed for accountability;<br />
*are enforced with scores;<br />
*elevates its game;<br />
*can become a part of the culture;<br />
*use the following structure:<br />
**high level objective;<br />
**a more detailed description of why that objective is important—a summary of how the objective aligns with the broader goals of both the person’s team and the company; and<br />
**three to five key results that will help them achieve that goal.<br />
*track results on a quantitative basis—key results are not general or subjective actions you plan to take, and should always include numbers to make it clear how much has been achieved. For example, if Mary’s objective is to improve her sales prospecting skills, one key result might be to spend two hours a week shadowing Jennifer, the team member who demonstrates the most prospecting success;<br />
*are something for people look at, every quarter, every week, every day—consistently setting goals turns goal-setting into a habit and changes how people think about their work and approach their everyday to-dos; it puts in place natural milestones that make you think about what you need to do next and aim high;<br />
*are stretched goals in order to be effective—achieving 70% of your goals is just about perfect for {{okrs}}—if you achieve 100% of your goals, you’re not trying hard enough (cf. Sun Tzu: bow tension);<br />
*are a tool for motivating and aligning people to work together by increasing transparency, accountability and empowerment;<br />
*make it easier than ever to keep people focused and collect feedback, inside and outside management meetings;<br />
*facilitate continual coaching of yourself and others and develops your whole ecosystem;<br />
|therefore full=Encourage people to spend time defining their own {{okrs}} and then to meet specifically with their managers to incorporate their feedback. Spend your time defining {{okrs}}, not measuring them. Look at {{okrs}} as a way to communicate so there’s clarity about the {{p|unity of purpose}}. Tweak and tune your {{okrs}} to be more about collaboration and less about action items. Publish them for everyone to see (next to your {{p|flow board}}. Figure out how to put {{okrs}} work best for you. ‘Retroprospect’ your {{okrs}} with a {{p|season beat}} and make it a part of your {{p|operations review}}. Hold people publicly accountable for failing to regularly update their {{okrs}}. Have 60% of your {{okrs}} defined by employees, not leadership.<br />
|new=Consider creating an {{p|impact map}} to discover and express the right {{okrs}}.<br />
<br />
Grading should be a simple exercise at every {{p|season beat}}, five minutes tops. Score an objective by averaging the individual key result scores underneath it. This is also why it’s so important to make those key results quantitatively measurable.<br />
<br />
'''Warning'''<br />
*Do not mix {{okrs}} and performance reviews; do not use it as a weapon against your employees in performance reviews.<br />
}}<br />
==Sharpening Questions==<br />
<br />
==Typical Progress Meeting==<br />
*Ask people to share their quick wins—one or two notable things they or their team has achieved since last time.<br />
*Ask people what progress has been made agains their {{okrs}}: <br />
**What are the areas that are still keeping you up at night?<br />
**Where do you need help?'<br />
**Everyone shares one or two things that are causing them the biggest concerns about hitting their {{okrs}}<br />
*Have the major concerns guides the meeting’s conversation in the right direction—because they’re always focused on removing roadblocks, they always feel like time well spent.<br />
<br />
Smashing Magazine:<br />
:Schedule deadlines as specific tasks, not the ends of phases. Rather than “Content will be completed by 4 April 2010,” state “Review the content over lunch on 4 April 2010.” This ties the deadline to an event at which results must be shown. Mini-deadlines tied to specific events are more powerful than general statements.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/resources/get-aligned-strategy-first-okr-second/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=Looking to get aligned? Put strategy first, OKR second<br />
}}<br />
{{WebSourceListItem<br />
|url=https://quietstars.com/lax2020/<br />
|site=Quiet Stars<br />
|person=Adrian Howard<br />
|title=OKRs That Don't Suck<br />
}}<br />
{{WebSourceListItem<br />
|url=https://link.medium.com/uw3MScjdA6<br />
|site=Medium<br />
|person=Ian Batterbee<br />
|title=Designing for motivation with the goal-gradient effect<br />
}}<br />
{{WebSourceListItem<br />
|url=https://felipecastro.com/en/blog/book-review-measure-what-matters/<br />
|site=Felipe Castro<br />
|title=Measure What Really Matters<br />
|about=Good, bad and ugly of the book with the same title<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@mcleanonline/4-key-lessons-ive-learned-about-okrs-3f4b902ae9f8<br />
|site=Medium<br />
|person=Richard McLean<br />
|title=4 key lessons I’ve learned about OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hackernoon.com/beyond-outcomes-over-outputs-6b2677044214<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Beyond “Outcomes Over Outputs”<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2018/05/how-vc-john-doerr-sets-and-achieves-goals<br />
|site=HBR<br />
|person=Daniel McGinn<br />
|title=How VC John Doerr Sets (and Achieves) Goals<br />
}}<br />
{{WebSourceListItem<br />
|url=https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/<br />
|site=re:Work<br />
|title=Guide: Set goals with OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=http://felipecastro.com/en/okr-tools/<br />
|site=Filipe Castro<br />
|title=OKR Tools<br />
}}<br />
{{WebSourceListItem<br />
|url=http://eleganthack.com/the-art-of-the-okr/<br />
|site=Eleganthack<br />
|title=The Art of the OKR<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/untangling-okrs-with-a-big-visual-board-6153afa12213<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Untangling OKRs with a Big, Visual Board<br />
}}<br />
{{WebSourceListItem<br />
|url=http://okrexamples.co/company-okr-examples<br />
|site=OKR Examples<br />
|title=Company OKR Examples<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/18-things-your-okrs-shouldnt-do-23c8b57a455f<br />
|site=Medium<br />
|person=John Cutler<br />
|title=18 Things Your OKRs Shouldn’t Do…<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dannorth.net/2017/05/01/applying-okrs/<br />
|site=Dan North & Associates<br />
|person=Dan North<br />
|title=Applying OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/startup-tools/okrs-5afdc298bc28<br />
|site=Medium<br />
|person=@niket<br />
|title=The Fundamentals » OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://docs.google.com/document/d/1OHpQOvZz76_10ebJP2AKvvXUF3H9yd6FC89F5jS4mks<br />
|site=Google Docs<br />
|person=@niket<br />
|title=Startup OKRs Template<br />
}}<br />
{{WebSourceListItem<br />
|url=http://firstround.com/review/How-to-Make-OKRs-Actually-Work-at-Your-Startup/<br />
|site=First Round<br />
|title=How to Make OKRs Actually Work at Your Startup<br />
}}<br />
{{WebSourceListItem<br />
|url=https://blog.weekdone.com/introduction-okr-objectives-key-results/<br />
|site=Weekdone<br />
|person=Jüri Kaljundi<br />
|title=Introduction to OKR – Objectives and Key Results<br />
}}<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/blog/okr-vs-kpi/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=OKR vs. KPI: How they compare and how they work together<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Slack_speeds_up&diff=3035Slack speeds up2023-01-17T19:18:22Z<p>Martien: /* Sources */ +=. *https://jessitron.com/2023/01/16/resilience-and-waste-in-software-teams/</p>
<hr />
<div>{{Oyster<br />
|goal=get more done with less resources<br />
|stage=Sparkle<br />
|theme=Lean, Kanban<br />
|context=an organization with a lot of work.<br />
|wish=getting more done in less time<br />
|so=secure slack time in your system<br />
|image=Power-of-slack.png<br />
|wish full=getting more done in less time<br />
|background=Seth Godin says:<br />
Avoiding a problem with foresight and good design is a cheap, highly leveraged way to do your work.<br />
<br />
Extinguishing a problem before it gets expensive and difficult is almost as good, and far better than paying a premium when there's an emergency.<br />
<br />
Fretting about an impending problem, worrying about it, imagining the implications of it... all of this is worthless.<br />
<br />
The magic of slack (a little extra time in the chain, a few extra dollars in the bank) is that it gives you the resources to stop and avoid a problem or fix it when it's small. The over-optimized organization misunderstands the value of slack, so it always waits until something is a screaming emergency, because it doesn't think it has a moment to spare. Expensive.<br />
<br />
Action is almost always cheaper now than it is later.<br />
|therefore full=secure slack time in your system<br />
}}<br />
==Sources==<br />
*http://www.slideshare.net/pawelbrodzinski/efficient-or-just-busy<br />
*https://jessitron.com/2023/01/16/resilience-and-waste-in-software-teams/<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2016/05/problems.html<br />
|site=Seth’s Blog<br />
|person=Seth Goding<br />
|title=Problems<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Decide&diff=3034Decide2022-09-05T07:20:21Z<p>Martien: /* Sources */ += 10 decision-making principles that will help you make tough calls</p>
<hr />
<div>==Topics==<br />
*{{p|too many cooks spoil the broth}}<br />
*{{p|consent}}, a.k.a. integral decision-making<br />
*{{p|thumb protocol}}<br />
*{{p|delegation poker}}<br />
<br />
From top to bottom, your control, involvement and responsibility increases, and decision speed decreases.<br />
*You bless the decision, perhaps refine it a bit.<br />
*You suggest any improvements which the author processes into a new revision.<br />
*You can react within a time limit; no reaction implies your consent.<br />
*You get involved and the decision must have your consent.<br />
<br />
==Sources==<br />
<br />
{{WebSourceListItem<br />
|url=https://www.fastcompany.com/90781637/10-decision-making-principles-that-will-help-you-make-tough-calls<br />
|site=Fast Company<br />
|person=Robert Chen<br />
|title=10 decision-making principles that will help you make tough calls<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2017/03/a-4-step-process-to-help-senior-teams-prioritize-decisions<br />
|site=HBR<br />
|person=Peter Hopper, Jugnu Sakuja<br />
|title=A 4-Step Process to Help Senior Teams Prioritize Decisions<br />
}}<br />
{{WebSourceListItem<br />
|url=https://www.infoq.com/articles/book-review-product-mastery<br />
|site=InfoQ<br />
|person=Geoff Watts<br />
|title=Book Q&A on Product Mastery<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blog.crisp.se/2013/11/05/henrikkniberg/how-we-make-decisions|site=Crisp<br />
|person=Henrik Kniberg<br />
|title=How we make decisions<br />
}}; see {{p|decision spectrum}} and {{p|bun owner}}.<br />
{{WebSourceListItem<br />
|url=http://bigthink.com/big-think-mentor/make-better-decisions-redefining-giving-up<br />
|site=Big Think<br />
|title=Make Better Decisions: Redefining “Giving Up”<br />
}}<br />
{{WebSourceListItem<br />
|url=http://bigthink.com/think-tank/unlike-voters-fish-make-better-group-decisions<br />
|site=Big Think<br />
|person=Alex Berezow<br />
|title=Unlike Voters, Fish Make Better Group Decisions<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/three-guidelines-business<br />
|site=InfoQ<br />
|person=Michael Nir<br />
|title=Three Practical Guidelines for Business Decisions<br />
}}<br />
*http://sethgodin.typepad.com/seths_blog/2015/01/when-to-decide.html<br />
*https://hbr.org/2015/01/make-it-easy-for-decision-makers-to-approve-your-deal<br />
*http://sethgodin.typepad.com/seths_blog/2015/05/how-to-go-faster.html<br />
{{necklace<br />
|title=Decision-making<br />
|theme=decide<br />
}}<br />
{{verb}}</div>Martienhttp://pearllanguage.org/index.php?title=OKR&diff=3029OKR2021-12-16T09:48:13Z<p>Martien: Fantasies</p>
<hr />
<div>{{Oyster<br />
|goal=keep everyone moving forward as a team—aligned autonomy<br />
|stage=Sparkle<br />
|context=culture, productivity and alignment all in flux.<br />
|wish=Keep everyone moving forward as an aligned and autonomous team.<br />
|so=Co-create and publish objectives and key results on all levels in your organization.<br />
|image=OKR Best Practices.png{{!}}600px<br />
|prologue=To achieve great things, two things are needed: a plan and not quite enough time. —Leonard Bernstein<br />
|wish full=Keep everyone moving forward as a team in a world where culture, productivity and alignment are all in flux.<br />
|background={{quote|The greater danger for most of us lies not in setting our aim too high and falling short, but in setting our aims too low and achieving our mark.|Michelangelo}}<br />
<br />
Goals aren’t promises, they’re hypotheses<br />
<br />
Not reaching a goal can be just as valuable as reaching it, just as disproving a hypothesis is as valuable as proving it<br />
<br />
The purpose of a goal is to '''maximize your learning''', not commit to a predetermined outcome.<br />
<br />
# Don’t plan ahead of what you know now, or you’re just spinning fantasies.<br />
# What you know now will likely be wrong in a few weeks.<br />
<br />
I’m not saying "don’t plan." I’m saying that the plan is dynamic, constantly changing as you learn, and you’re always learning.<br />
<br />
==Forces==<br />
*{{p|metrics drive behavior}}<br />
*People hate corporate acronyms that mandate work more than just corporate acronyms.<br />
*Multiple teams often depend on one another to succeed.<br />
*No one person knows everything going on inside the organization.<br />
*Personal objectives that are directly and clearly connected to the broader goals of the company are more inspiring and imaginative.<br />
*Public information that everyone can see help make you feel you are toiling in a thriving environment with your manager’s approval.<br />
*Public goals and clear results:<br />
**encourage people to ask for resources; and<br />
**easily spot where you can support your colleagues;<br />
**force different types of thinking around how people ask for help from others and helps amplifying this type of dialog.<br />
*Airing things out releases anxiety and let’s people get creative—that’s when interesting things happen.<br />
*Stretched goals:<br />
**help you to be ambitious enough the push you beyond your limits; and<br />
**focuses conversations about what is truly needed to beat expectations;<br />
**encourages to {{p|question everything}}; and<br />
**forces {{p|questions that matter}} like:<br />
***“I’d have to completely solve this hard problem”; or<br />
***“I need to completely rethink how I’m addressing X or Y.”<br />
*Having clear objectives, especially those tied to developing your skills, are a key part of career development.<br />
*People love hitting their marks.<br />
*Key results that are always tied to money block seeing other, diverse objectives in the mix—it will make people play safe rather than being ambitious and entrepreneurial.<br />
*Regular updates and reviews of objectives and key results spur increased dialogue between employees, co-workers, managers, and leadership and allows recognition to be spread out over time, which tends to be more rewarding.<br />
*Self-inflicted objectives and goals are much more powerful than top-down goals dictated from higher organizational levels.<br />
<br />
{{okrs}}:<br />
*serve as a layer of communication that holds the company together;<br />
*are designed for accountability;<br />
*are enforced with scores;<br />
*elevates its game;<br />
*can become a part of the culture;<br />
*use the following structure:<br />
**high level objective;<br />
**a more detailed description of why that objective is important—a summary of how the objective aligns with the broader goals of both the person’s team and the company; and<br />
**three to five key results that will help them achieve that goal.<br />
*track results on a quantitative basis—key results are not general or subjective actions you plan to take, and should always include numbers to make it clear how much has been achieved. For example, if Mary’s objective is to improve her sales prospecting skills, one key result might be to spend two hours a week shadowing Jennifer, the team member who demonstrates the most prospecting success;<br />
*are something for people look at, every quarter, every week, every day—consistently setting goals turns goal-setting into a habit and changes how people think about their work and approach their everyday to-dos; it puts in place natural milestones that make you think about what you need to do next and aim high;<br />
*are stretched goals in order to be effective—achieving 70% of your goals is just about perfect for {{okrs}}—if you achieve 100% of your goals, you’re not trying hard enough (cf. Sun Tzu: bow tension);<br />
*are a tool for motivating and aligning people to work together by increasing transparency, accountability and empowerment;<br />
*make it easier than ever to keep people focused and collect feedback, inside and outside management meetings;<br />
*facilitate continual coaching of yourself and others and develops your whole ecosystem;<br />
|therefore full=Encourage people to spend time defining their own {{okrs}} and then to meet specifically with their managers to incorporate their feedback. Spend your time defining {{okrs}}, not measuring them. Look at {{okrs}} as a way to communicate so there’s clarity about the {{p|unity of purpose}}. Tweak and tune your {{okrs}} to be more about collaboration and less about action items. Publish them for everyone to see (next to your {{p|flow board}}. Figure out how to put {{okrs}} work best for you. ‘Retroprospect’ your {{okrs}} with a {{p|season beat}} and make it a part of your {{p|operations review}}. Hold people publicly accountable for failing to regularly update their {{okrs}}. Have 60% of your {{okrs}} defined by employees, not leadership.<br />
|new=Consider creating an {{p|impact map}} to discover and express the right {{okrs}}.<br />
<br />
Grading should be a simple exercise at every {{p|season beat}}, five minutes tops. Score an objective by averaging the individual key result scores underneath it. This is also why it’s so important to make those key results quantitatively measurable.<br />
<br />
'''Warning'''<br />
*Do not mix {{okrs}} and performance reviews; do not use it as a weapon against your employees in performance reviews.<br />
}}<br />
==Typical Progress Meeting==<br />
*Ask people to share their quick wins—one or two notable things they or their team has achieved since last time.<br />
*Ask people what progress has been made agains their {{okrs}}: <br />
**What are the areas that are still keeping you up at night?<br />
**Where do you need help?'<br />
**Everyone shares one or two things that are causing them the biggest concerns about hitting their {{okrs}}<br />
*Have the major concerns guides the meeting’s conversation in the right direction—because they’re always focused on removing roadblocks, they always feel like time well spent.<br />
<br />
Smashing Magazine:<br />
:Schedule deadlines as specific tasks, not the ends of phases. Rather than “Content will be completed by 4 April 2010,” state “Review the content over lunch on 4 April 2010.” This ties the deadline to an event at which results must be shown. Mini-deadlines tied to specific events are more powerful than general statements.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/resources/get-aligned-strategy-first-okr-second/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=Looking to get aligned? Put strategy first, OKR second<br />
}}<br />
{{WebSourceListItem<br />
|url=https://quietstars.com/lax2020/<br />
|site=Quiet Stars<br />
|person=Adrian Howard<br />
|title=OKRs That Don't Suck<br />
}}<br />
{{WebSourceListItem<br />
|url=https://link.medium.com/uw3MScjdA6<br />
|site=Medium<br />
|person=Ian Batterbee<br />
|title=Designing for motivation with the goal-gradient effect<br />
}}<br />
{{WebSourceListItem<br />
|url=https://felipecastro.com/en/blog/book-review-measure-what-matters/<br />
|site=Felipe Castro<br />
|title=Measure What Really Matters<br />
|about=Good, bad and ugly of the book with the same title<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@mcleanonline/4-key-lessons-ive-learned-about-okrs-3f4b902ae9f8<br />
|site=Medium<br />
|person=Richard McLean<br />
|title=4 key lessons I’ve learned about OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hackernoon.com/beyond-outcomes-over-outputs-6b2677044214<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Beyond “Outcomes Over Outputs”<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2018/05/how-vc-john-doerr-sets-and-achieves-goals<br />
|site=HBR<br />
|person=Daniel McGinn<br />
|title=How VC John Doerr Sets (and Achieves) Goals<br />
}}<br />
{{WebSourceListItem<br />
|url=https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/<br />
|site=re:Work<br />
|title=Guide: Set goals with OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=http://felipecastro.com/en/okr-tools/<br />
|site=Filipe Castro<br />
|title=OKR Tools<br />
}}<br />
{{WebSourceListItem<br />
|url=http://eleganthack.com/the-art-of-the-okr/<br />
|site=Eleganthack<br />
|title=The Art of the OKR<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/untangling-okrs-with-a-big-visual-board-6153afa12213<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Untangling OKRs with a Big, Visual Board<br />
}}<br />
{{WebSourceListItem<br />
|url=http://okrexamples.co/company-okr-examples<br />
|site=OKR Examples<br />
|title=Company OKR Examples<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/18-things-your-okrs-shouldnt-do-23c8b57a455f<br />
|site=Medium<br />
|person=John Cutler<br />
|title=18 Things Your OKRs Shouldn’t Do…<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dannorth.net/2017/05/01/applying-okrs/<br />
|site=Dan North & Associates<br />
|person=Dan North<br />
|title=Applying OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/startup-tools/okrs-5afdc298bc28<br />
|site=Medium<br />
|person=@niket<br />
|title=The Fundamentals » OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://docs.google.com/document/d/1OHpQOvZz76_10ebJP2AKvvXUF3H9yd6FC89F5jS4mks<br />
|site=Google Docs<br />
|person=@niket<br />
|title=Startup OKRs Template<br />
}}<br />
{{WebSourceListItem<br />
|url=http://firstround.com/review/How-to-Make-OKRs-Actually-Work-at-Your-Startup/<br />
|site=First Round<br />
|title=How to Make OKRs Actually Work at Your Startup<br />
}}<br />
{{WebSourceListItem<br />
|url=https://blog.weekdone.com/introduction-okr-objectives-key-results/<br />
|site=Weekdone<br />
|person=Jüri Kaljundi<br />
|title=Introduction to OKR – Objectives and Key Results<br />
}}<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/blog/okr-vs-kpi/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=OKR vs. KPI: How they compare and how they work together<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=OKR&diff=3028OKR2021-12-16T09:41:10Z<p>Martien: Goal is to maximalize your learning.</p>
<hr />
<div>{{Oyster<br />
|goal=keep everyone moving forward as a team—aligned autonomy<br />
|stage=Sparkle<br />
|context=culture, productivity and alignment all in flux.<br />
|wish=Keep everyone moving forward as an aligned and autonomous team.<br />
|so=Co-create and publish objectives and key results on all levels in your organization.<br />
|image=OKR Best Practices.png{{!}}600px<br />
|prologue=To achieve great things, two things are needed: a plan and not quite enough time. —Leonard Bernstein<br />
|wish full=Keep everyone moving forward as a team in a world where culture, productivity and alignment are all in flux.<br />
|background={{quote|The greater danger for most of us lies not in setting our aim too high and falling short, but in setting our aims too low and achieving our mark.|Michelangelo}}<br />
<br />
Goals aren’t promises, they’re hypotheses<br />
<br />
Not reaching a goal can be just as valuable as reaching it, just as disproving a hypothesis is as valuable as proving it<br />
<br />
The purpose of a goal is to **maximize your learning**, not commit to a predetermined outcome<br />
<br />
==Forces==<br />
*{{p|metrics drive behavior}}<br />
*People hate corporate acronyms that mandate work more than just corporate acronyms.<br />
*Multiple teams often depend on one another to succeed.<br />
*No one person knows everything going on inside the organization.<br />
*Personal objectives that are directly and clearly connected to the broader goals of the company are more inspiring and imaginative.<br />
*Public information that everyone can see help make you feel you are toiling in a thriving environment with your manager’s approval.<br />
*Public goals and clear results:<br />
**encourage people to ask for resources; and<br />
**easily spot where you can support your colleagues;<br />
**force different types of thinking around how people ask for help from others and helps amplifying this type of dialog.<br />
*Airing things out releases anxiety and let’s people get creative—that’s when interesting things happen.<br />
*Stretched goals:<br />
**help you to be ambitious enough the push you beyond your limits; and<br />
**focuses conversations about what is truly needed to beat expectations;<br />
**encourages to {{p|question everything}}; and<br />
**forces {{p|questions that matter}} like:<br />
***“I’d have to completely solve this hard problem”; or<br />
***“I need to completely rethink how I’m addressing X or Y.”<br />
*Having clear objectives, especially those tied to developing your skills, are a key part of career development.<br />
*People love hitting their marks.<br />
*Key results that are always tied to money block seeing other, diverse objectives in the mix—it will make people play safe rather than being ambitious and entrepreneurial.<br />
*Regular updates and reviews of objectives and key results spur increased dialogue between employees, co-workers, managers, and leadership and allows recognition to be spread out over time, which tends to be more rewarding.<br />
*Self-inflicted objectives and goals are much more powerful than top-down goals dictated from higher organizational levels.<br />
<br />
{{okrs}}:<br />
*serve as a layer of communication that holds the company together;<br />
*are designed for accountability;<br />
*are enforced with scores;<br />
*elevates its game;<br />
*can become a part of the culture;<br />
*use the following structure:<br />
**high level objective;<br />
**a more detailed description of why that objective is important—a summary of how the objective aligns with the broader goals of both the person’s team and the company; and<br />
**three to five key results that will help them achieve that goal.<br />
*track results on a quantitative basis—key results are not general or subjective actions you plan to take, and should always include numbers to make it clear how much has been achieved. For example, if Mary’s objective is to improve her sales prospecting skills, one key result might be to spend two hours a week shadowing Jennifer, the team member who demonstrates the most prospecting success;<br />
*are something for people look at, every quarter, every week, every day—consistently setting goals turns goal-setting into a habit and changes how people think about their work and approach their everyday to-dos; it puts in place natural milestones that make you think about what you need to do next and aim high;<br />
*are stretched goals in order to be effective—achieving 70% of your goals is just about perfect for {{okrs}}—if you achieve 100% of your goals, you’re not trying hard enough (cf. Sun Tzu: bow tension);<br />
*are a tool for motivating and aligning people to work together by increasing transparency, accountability and empowerment;<br />
*make it easier than ever to keep people focused and collect feedback, inside and outside management meetings;<br />
*facilitate continual coaching of yourself and others and develops your whole ecosystem;<br />
|therefore full=Encourage people to spend time defining their own {{okrs}} and then to meet specifically with their managers to incorporate their feedback. Spend your time defining {{okrs}}, not measuring them. Look at {{okrs}} as a way to communicate so there’s clarity about the {{p|unity of purpose}}. Tweak and tune your {{okrs}} to be more about collaboration and less about action items. Publish them for everyone to see (next to your {{p|flow board}}. Figure out how to put {{okrs}} work best for you. ‘Retroprospect’ your {{okrs}} with a {{p|season beat}} and make it a part of your {{p|operations review}}. Hold people publicly accountable for failing to regularly update their {{okrs}}. Have 60% of your {{okrs}} defined by employees, not leadership.<br />
|new=Consider creating an {{p|impact map}} to discover and express the right {{okrs}}.<br />
<br />
Grading should be a simple exercise at every {{p|season beat}}, five minutes tops. Score an objective by averaging the individual key result scores underneath it. This is also why it’s so important to make those key results quantitatively measurable.<br />
<br />
'''Warning'''<br />
*Do not mix {{okrs}} and performance reviews; do not use it as a weapon against your employees in performance reviews.<br />
}}<br />
==Typical Progress Meeting==<br />
*Ask people to share their quick wins—one or two notable things they or their team has achieved since last time.<br />
*Ask people what progress has been made agains their {{okrs}}: <br />
**What are the areas that are still keeping you up at night?<br />
**Where do you need help?'<br />
**Everyone shares one or two things that are causing them the biggest concerns about hitting their {{okrs}}<br />
*Have the major concerns guides the meeting’s conversation in the right direction—because they’re always focused on removing roadblocks, they always feel like time well spent.<br />
<br />
Smashing Magazine:<br />
:Schedule deadlines as specific tasks, not the ends of phases. Rather than “Content will be completed by 4 April 2010,” state “Review the content over lunch on 4 April 2010.” This ties the deadline to an event at which results must be shown. Mini-deadlines tied to specific events are more powerful than general statements.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/resources/get-aligned-strategy-first-okr-second/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=Looking to get aligned? Put strategy first, OKR second<br />
}}<br />
{{WebSourceListItem<br />
|url=https://quietstars.com/lax2020/<br />
|site=Quiet Stars<br />
|person=Adrian Howard<br />
|title=OKRs That Don't Suck<br />
}}<br />
{{WebSourceListItem<br />
|url=https://link.medium.com/uw3MScjdA6<br />
|site=Medium<br />
|person=Ian Batterbee<br />
|title=Designing for motivation with the goal-gradient effect<br />
}}<br />
{{WebSourceListItem<br />
|url=https://felipecastro.com/en/blog/book-review-measure-what-matters/<br />
|site=Felipe Castro<br />
|title=Measure What Really Matters<br />
|about=Good, bad and ugly of the book with the same title<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@mcleanonline/4-key-lessons-ive-learned-about-okrs-3f4b902ae9f8<br />
|site=Medium<br />
|person=Richard McLean<br />
|title=4 key lessons I’ve learned about OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hackernoon.com/beyond-outcomes-over-outputs-6b2677044214<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Beyond “Outcomes Over Outputs”<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2018/05/how-vc-john-doerr-sets-and-achieves-goals<br />
|site=HBR<br />
|person=Daniel McGinn<br />
|title=How VC John Doerr Sets (and Achieves) Goals<br />
}}<br />
{{WebSourceListItem<br />
|url=https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/<br />
|site=re:Work<br />
|title=Guide: Set goals with OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=http://felipecastro.com/en/okr-tools/<br />
|site=Filipe Castro<br />
|title=OKR Tools<br />
}}<br />
{{WebSourceListItem<br />
|url=http://eleganthack.com/the-art-of-the-okr/<br />
|site=Eleganthack<br />
|title=The Art of the OKR<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/untangling-okrs-with-a-big-visual-board-6153afa12213<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Untangling OKRs with a Big, Visual Board<br />
}}<br />
{{WebSourceListItem<br />
|url=http://okrexamples.co/company-okr-examples<br />
|site=OKR Examples<br />
|title=Company OKR Examples<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/18-things-your-okrs-shouldnt-do-23c8b57a455f<br />
|site=Medium<br />
|person=John Cutler<br />
|title=18 Things Your OKRs Shouldn’t Do…<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dannorth.net/2017/05/01/applying-okrs/<br />
|site=Dan North & Associates<br />
|person=Dan North<br />
|title=Applying OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/startup-tools/okrs-5afdc298bc28<br />
|site=Medium<br />
|person=@niket<br />
|title=The Fundamentals » OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://docs.google.com/document/d/1OHpQOvZz76_10ebJP2AKvvXUF3H9yd6FC89F5jS4mks<br />
|site=Google Docs<br />
|person=@niket<br />
|title=Startup OKRs Template<br />
}}<br />
{{WebSourceListItem<br />
|url=http://firstround.com/review/How-to-Make-OKRs-Actually-Work-at-Your-Startup/<br />
|site=First Round<br />
|title=How to Make OKRs Actually Work at Your Startup<br />
}}<br />
{{WebSourceListItem<br />
|url=https://blog.weekdone.com/introduction-okr-objectives-key-results/<br />
|site=Weekdone<br />
|person=Jüri Kaljundi<br />
|title=Introduction to OKR – Objectives and Key Results<br />
}}<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/blog/okr-vs-kpi/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=OKR vs. KPI: How they compare and how they work together<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Focus_on_focus_off&diff=3027Focus on focus off2021-08-18T08:41:38Z<p>Martien: += Difference between dialogue, discussion, & debate</p>
<hr />
<div>{{Oyster<br />
|goal=set the stage for productive communication<br />
|stage=Sparkle<br />
|theme=Agile<br />
|context={{p|retrospective meeting}}, for example, at the end of s {{p|sprint}}, after welcoming the participants and reviewing the goal and agenda.<br />
|wish=Setting the stage with a mind-set for productive communication helps participants set aside blaming and judgment—and fear of blaming and judgment.<br />
|so=Have everyone compare words like inquiry/advocacy, dialogue/debate, conversation/argument, their meaning, and how they impact behavior.<br />
|image=Focus-on-off.png{{!}}400px<br />
|wish full=Setting the stage with a mind-set for productive communication helps participants set aside blaming and judgment—and fear of blaming and judgment.<br />
|background=After describing productive and unproductive communication patterns, invite the participants to discuss what they mean for the gathering.<br />
<br />
===Steps===<br />
#Draw attention to the Focus On/Focus Off poster and briefly read through it.<br />
#Form small groups, with no more than four people per group. Ask each group to take one pair of words to define and describe. If there are more than four pairs/groups, it’s OK if more than one group has the same pair of words.<br />
#Ask each group to talk about:<br />
##what their two words mean;<br />
##what behaviors they represent; and<br />
##what impact each has on the team and the meeting.<br />
#Have each {{p|group reports out to the whole}} on their conversation.<br />
#Invite everyone to stay in the ‘Focus On’ mode.<br />
|therefore full=Have everyone compare words like ''inquiry''/''advocacy'', ''dialogue''/''debate'', ''conversation''/''argument'', and ''understanding''/''defending'', their meaning, and how they impact behavior. Use the outcome of the converstation as a lead-in to establish {{p|working agreements}} for the {{p|retrospective meeting}} and the {{p|team charter}}.<br />
|new=Participants will often keep this in mind during the rest of the meeting and behave accordingly.<br />
}}<br />
<br />
{{WebSourceListItem<br />
|url=https://utlc.uncg.edu/teaching/diversity-equity-and-inclusion__trashed/dialoguediscussiondebate/<br />
|site=UNC Greensbord<br />
|title=Difference between dialogue, discussion, & debate<br />
}}<br />
{{Source<br />
|source=Agile Retrospectives<br />
|author=Esther Derby, Diana Larsen<br />
|coder={{mvs}}<br />
|pattern=focus on/focus off<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=OKR&diff=3026OKR2021-02-09T11:43:41Z<p>Martien: /* Sources */ += Perdoo » Henrik-Jan van der Pol » Looking to get aligned? Put strategy first, OKR second</p>
<hr />
<div>{{Oyster<br />
|goal=keep everyone moving forward as a team—aligned autonomy<br />
|stage=Sparkle<br />
|context=culture, productivity and alignment all in flux.<br />
|wish=Keep everyone moving forward as an aligned and autonomous team.<br />
|so=Co-create and publish objectives and key results on all levels in your organization.<br />
|image=OKR Best Practices.png{{!}}600px<br />
|prologue=To achieve great things, two things are needed: a plan and not quite enough time. —Leonard Bernstein<br />
|wish full=Keep everyone moving forward as a team in a world where culture, productivity and alignment are all in flux.<br />
|background={{quote|The greater danger for most of us lies not in setting our aim too high and falling short, but in setting our aims too low and achieving our mark.|Michelangelo}}<br />
<br />
==Forces==<br />
*{{p|metrics drive behavior}}<br />
*People hate corporate acronyms that mandate work more than just corporate acronyms.<br />
*Multiple teams often depend on one another to succeed.<br />
*No one person knows everything going on inside the organization.<br />
*Personal objectives that are directly and clearly connected to the broader goals of the company are more inspiring and imaginative.<br />
*Public information that everyone can see help make you feel you are toiling in a thriving environment with your manager’s approval.<br />
*Public goals and clear results:<br />
**encourage people to ask for resources; and<br />
**easily spot where you can support your colleagues;<br />
**force different types of thinking around how people ask for help from others and helps amplifying this type of dialog.<br />
*Airing things out releases anxiety and let’s people get creative—that’s when interesting things happen.<br />
*Stretched goals:<br />
**help you to be ambitious enough the push you beyond your limits; and<br />
**focuses conversations about what is truly needed to beat expectations;<br />
**encourages to {{p|question everything}}; and<br />
**forces {{p|questions that matter}} like:<br />
***“I’d have to completely solve this hard problem”; or<br />
***“I need to completely rethink how I’m addressing X or Y.”<br />
*Having clear objectives, especially those tied to developing your skills, are a key part of career development.<br />
*People love hitting their marks.<br />
*Key results that are always tied to money block seeing other, diverse objectives in the mix—it will make people play safe rather than being ambitious and entrepreneurial.<br />
*Regular updates and reviews of objectives and key results spur increased dialogue between employees, co-workers, managers, and leadership and allows recognition to be spread out over time, which tends to be more rewarding.<br />
*Self-inflicted objectives and goals are much more powerful than top-down goals dictated from higher organizational levels.<br />
<br />
{{okrs}}:<br />
*serve as a layer of communication that holds the company together;<br />
*are designed for accountability;<br />
*are enforced with scores;<br />
*elevates its game;<br />
*can become a part of the culture;<br />
*use the following structure:<br />
**high level objective;<br />
**a more detailed description of why that objective is important—a summary of how the objective aligns with the broader goals of both the person’s team and the company; and<br />
**three to five key results that will help them achieve that goal.<br />
*track results on a quantitative basis—key results are not general or subjective actions you plan to take, and should always include numbers to make it clear how much has been achieved. For example, if Mary’s objective is to improve her sales prospecting skills, one key result might be to spend two hours a week shadowing Jennifer, the team member who demonstrates the most prospecting success;<br />
*are something for people look at, every quarter, every week, every day—consistently setting goals turns goal-setting into a habit and changes how people think about their work and approach their everyday to-dos; it puts in place natural milestones that make you think about what you need to do next and aim high;<br />
*are stretched goals in order to be effective—achieving 70% of your goals is just about perfect for {{okrs}}—if you achieve 100% of your goals, you’re not trying hard enough (cf. Sun Tzu: bow tension);<br />
*are a tool for motivating and aligning people to work together by increasing transparency, accountability and empowerment;<br />
*make it easier than ever to keep people focused and collect feedback, inside and outside management meetings;<br />
*facilitate continual coaching of yourself and others and develops your whole ecosystem;<br />
|therefore full=Encourage people to spend time defining their own {{okrs}} and then to meet specifically with their managers to incorporate their feedback. Spend your time defining {{okrs}}, not measuring them. Look at {{okrs}} as a way to communicate so there’s clarity about the {{p|unity of purpose}}. Tweak and tune your {{okrs}} to be more about collaboration and less about action items. Publish them for everyone to see (next to your {{p|flow board}}. Figure out how to put {{okrs}} work best for you. ‘Retroprospect’ your {{okrs}} with a {{p|season beat}} and make it a part of your {{p|operations review}}. Hold people publicly accountable for failing to regularly update their {{okrs}}. Have 60% of your {{okrs}} defined by employees, not leadership.<br />
|new=Consider creating an {{p|impact map}} to discover and express the right {{okrs}}.<br />
<br />
Grading should be a simple exercise at every {{p|season beat}}, five minutes tops. Score an objective by averaging the individual key result scores underneath it. This is also why it’s so important to make those key results quantitatively measurable.<br />
<br />
'''Warning'''<br />
*Do not mix {{okrs}} and performance reviews; do not use it as a weapon against your employees in performance reviews.<br />
}}<br />
==Typical Progress Meeting==<br />
*Ask people to share their quick wins—one or two notable things they or their team has achieved since last time.<br />
*Ask people what progress has been made agains their {{okrs}}: <br />
**What are the areas that are still keeping you up at night?<br />
**Where do you need help?'<br />
**Everyone shares one or two things that are causing them the biggest concerns about hitting their {{okrs}}<br />
*Have the major concerns guides the meeting’s conversation in the right direction—because they’re always focused on removing roadblocks, they always feel like time well spent.<br />
<br />
Smashing Magazine:<br />
:Schedule deadlines as specific tasks, not the ends of phases. Rather than “Content will be completed by 4 April 2010,” state “Review the content over lunch on 4 April 2010.” This ties the deadline to an event at which results must be shown. Mini-deadlines tied to specific events are more powerful than general statements.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/resources/get-aligned-strategy-first-okr-second/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=Looking to get aligned? Put strategy first, OKR second<br />
}}<br />
{{WebSourceListItem<br />
|url=https://quietstars.com/lax2020/<br />
|person=Adrian Howard<br />
|site=Quiet Stars<br />
|title=OKRs That Don't Suck<br />
}}<br />
{{WebSourceListItem<br />
|url=https://link.medium.com/uw3MScjdA6<br />
|person=Ian Batterbee<br />
|site=Medium<br />
|title= Designing for motivation with the goal-gradient effect<br />
}}<br />
{{WebSourceListItem<br />
|url=https://felipecastro.com/en/blog/book-review-measure-what-matters/<br />
|site=Felipe Castro<br />
|title=Measure What Really Matters<br />
|about=Good, bad and ugly of the book with the same title<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@mcleanonline/4-key-lessons-ive-learned-about-okrs-3f4b902ae9f8<br />
|site=Medium<br />
|person=Richard McLean<br />
|title=4 key lessons I’ve learned about OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hackernoon.com/beyond-outcomes-over-outputs-6b2677044214<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Beyond “Outcomes Over Outputs”<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2018/05/how-vc-john-doerr-sets-and-achieves-goals<br />
|site=HBR<br />
|person=Daniel McGinn<br />
|title=How VC John Doerr Sets (and Achieves) Goals<br />
}}<br />
{{WebSourceListItem<br />
|url=https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/<br />
|site=re:Work<br />
|title=Guide: Set goals with OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=http://felipecastro.com/en/okr-tools/<br />
|site=Filipe Castro<br />
|title=OKR Tools<br />
}}<br />
{{WebSourceListItem<br />
|url=http://eleganthack.com/the-art-of-the-okr/<br />
|site=Eleganthack<br />
|title=The Art of the OKR<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/untangling-okrs-with-a-big-visual-board-6153afa12213<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Untangling OKRs with a Big, Visual Board<br />
}}<br />
{{WebSourceListItem<br />
|url=http://okrexamples.co/company-okr-examples<br />
|site=OKR Examples<br />
|title=Company OKR Examples<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/18-things-your-okrs-shouldnt-do-23c8b57a455f<br />
|site=Medium<br />
|person=John Cutler<br />
|title=18 Things Your OKRs Shouldn’t Do…<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dannorth.net/2017/05/01/applying-okrs/<br />
|site=Dan North & Associates<br />
|person=Dan North<br />
|title=Applying OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/startup-tools/okrs-5afdc298bc28<br />
|site=Medium<br />
|person=@niket<br />
|title=The Fundamentals » OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://docs.google.com/document/d/1OHpQOvZz76_10ebJP2AKvvXUF3H9yd6FC89F5jS4mks<br />
|site=Google Docs<br />
|person=@niket<br />
|title=Startup OKRs Template<br />
}}<br />
{{WebSourceListItem<br />
|url=http://firstround.com/review/How-to-Make-OKRs-Actually-Work-at-Your-Startup/<br />
|site=First Round<br />
|title=How to Make OKRs Actually Work at Your Startup<br />
}}<br />
{{WebSourceListItem<br />
|url=https://blog.weekdone.com/introduction-okr-objectives-key-results/<br />
|site=Weekdone<br />
|person=Jüri Kaljundi<br />
|title=Introduction to OKR – Objectives and Key Results<br />
}}<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/blog/okr-vs-kpi/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=OKR vs. KPI: How they compare and how they work together<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Strategy&diff=3025Strategy2021-02-09T11:43:10Z<p>Martien: /* Sources */ += Perdoo » Henrik-Jan van der Pol » Looking to get aligned? Put strategy first, OKR second</p>
<hr />
<div>==Seth’ Blog » Why even bother to think about strategy?==<br />
There's confusion between tactics and strategy. It's easy to get tied up in semantic knots as you work to figure out the distinction. It's worth it, though, because strategy can save you when tactics fail.<br />
<br />
If a tactic fails, you should consider abandoning it.<br />
<br />
But that doesn't mean that there's something wrong with your strategy. Your strategy is what you keep doing even after you walk away from a tactic.<br />
<br />
A real estate broker could decide that her goal is to get more listings.<br />
<br />
And her strategy is to achieve that by becoming the most trusted person in town.<br />
<br />
There are then 100 tactics she can use to earn that trust. She can coordinate events, sponsor teams, host community meetings in her office, sponsor the local baseball team, be transparent about her earnings, hire countless summer interns at a fair wage, run seminars at the local library, etc. ...<br />
<br />
It doesn't matter if one or two or five of the tactics aren't home runs. They add up.<br />
<br />
But if once, just once, she violates someone's trust and expectations, the entire strategy goes out the window.<br />
<br />
Tactics are disposable.<br />
<br />
Strategy is for the long haul.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/resources/get-aligned-strategy-first-okr-second/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=Looking to get aligned? Put strategy first, OKR second<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2018/04/why-even-bother-to-think-about-strategy.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Why even bother to think about strategy?<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blogs.hbr.org/2014/04/forget-the-strategy-powerpoint/<br />
|site=HBR<br />
|person=John P. Kotter<br />
|title=Forget the Strategy PowerPoint<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blogs.hbr.org/2014/04/how-to-execute-a-15-word-strategy-statement<br />
|site=HBR<br />
|person=Alessandro Di Fiore<br />
|title=How to Execute a 15-Word Strategy Statement<br />
}}<br />
*https://hbr.org/2014/11/a-list-of-goals-is-not-a-strategy<br />
<br />
==Pages tagged with “Strategy”==<br />
{{#ask: [[Category:Strategy]]<br />
|format=ul<br />
}}<br />
<br />
{{tag|strategy}}<br />
{{noun}}</div>Martienhttp://pearllanguage.org/index.php?title=OKR&diff=3024OKR2020-10-19T14:42:14Z<p>Martien: /* Sources */ += Quiet Stars » Adrian Howard » OKRs That Don't Suck</p>
<hr />
<div>{{Oyster<br />
|goal=keep everyone moving forward as a team—aligned autonomy<br />
|stage=Sparkle<br />
|context=culture, productivity and alignment all in flux.<br />
|wish=Keep everyone moving forward as an aligned and autonomous team.<br />
|so=Co-create and publish objectives and key results on all levels in your organization.<br />
|image=OKR Best Practices.png{{!}}600px<br />
|prologue=To achieve great things, two things are needed: a plan and not quite enough time. —Leonard Bernstein<br />
|wish full=Keep everyone moving forward as a team in a world where culture, productivity and alignment are all in flux.<br />
|background={{quote|The greater danger for most of us lies not in setting our aim too high and falling short, but in setting our aims too low and achieving our mark.|Michelangelo}}<br />
<br />
==Forces==<br />
*{{p|metrics drive behavior}}<br />
*People hate corporate acronyms that mandate work more than just corporate acronyms.<br />
*Multiple teams often depend on one another to succeed.<br />
*No one person knows everything going on inside the organization.<br />
*Personal objectives that are directly and clearly connected to the broader goals of the company are more inspiring and imaginative.<br />
*Public information that everyone can see help make you feel you are toiling in a thriving environment with your manager’s approval.<br />
*Public goals and clear results:<br />
**encourage people to ask for resources; and<br />
**easily spot where you can support your colleagues;<br />
**force different types of thinking around how people ask for help from others and helps amplifying this type of dialog.<br />
*Airing things out releases anxiety and let’s people get creative—that’s when interesting things happen.<br />
*Stretched goals:<br />
**help you to be ambitious enough the push you beyond your limits; and<br />
**focuses conversations about what is truly needed to beat expectations;<br />
**encourages to {{p|question everything}}; and<br />
**forces {{p|questions that matter}} like:<br />
***“I’d have to completely solve this hard problem”; or<br />
***“I need to completely rethink how I’m addressing X or Y.”<br />
*Having clear objectives, especially those tied to developing your skills, are a key part of career development.<br />
*People love hitting their marks.<br />
*Key results that are always tied to money block seeing other, diverse objectives in the mix—it will make people play safe rather than being ambitious and entrepreneurial.<br />
*Regular updates and reviews of objectives and key results spur increased dialogue between employees, co-workers, managers, and leadership and allows recognition to be spread out over time, which tends to be more rewarding.<br />
*Self-inflicted objectives and goals are much more powerful than top-down goals dictated from higher organizational levels.<br />
<br />
{{okrs}}:<br />
*serve as a layer of communication that holds the company together;<br />
*are designed for accountability;<br />
*are enforced with scores;<br />
*elevates its game;<br />
*can become a part of the culture;<br />
*use the following structure:<br />
**high level objective;<br />
**a more detailed description of why that objective is important—a summary of how the objective aligns with the broader goals of both the person’s team and the company; and<br />
**three to five key results that will help them achieve that goal.<br />
*track results on a quantitative basis—key results are not general or subjective actions you plan to take, and should always include numbers to make it clear how much has been achieved. For example, if Mary’s objective is to improve her sales prospecting skills, one key result might be to spend two hours a week shadowing Jennifer, the team member who demonstrates the most prospecting success;<br />
*are something for people look at, every quarter, every week, every day—consistently setting goals turns goal-setting into a habit and changes how people think about their work and approach their everyday to-dos; it puts in place natural milestones that make you think about what you need to do next and aim high;<br />
*are stretched goals in order to be effective—achieving 70% of your goals is just about perfect for {{okrs}}—if you achieve 100% of your goals, you’re not trying hard enough (cf. Sun Tzu: bow tension);<br />
*are a tool for motivating and aligning people to work together by increasing transparency, accountability and empowerment;<br />
*make it easier than ever to keep people focused and collect feedback, inside and outside management meetings;<br />
*facilitate continual coaching of yourself and others and develops your whole ecosystem;<br />
|therefore full=Encourage people to spend time defining their own {{okrs}} and then to meet specifically with their managers to incorporate their feedback. Spend your time defining {{okrs}}, not measuring them. Look at {{okrs}} as a way to communicate so there’s clarity about the {{p|unity of purpose}}. Tweak and tune your {{okrs}} to be more about collaboration and less about action items. Publish them for everyone to see (next to your {{p|flow board}}. Figure out how to put {{okrs}} work best for you. ‘Retroprospect’ your {{okrs}} with a {{p|season beat}} and make it a part of your {{p|operations review}}. Hold people publicly accountable for failing to regularly update their {{okrs}}. Have 60% of your {{okrs}} defined by employees, not leadership.<br />
|new=Consider creating an {{p|impact map}} to discover and express the right {{okrs}}.<br />
<br />
Grading should be a simple exercise at every {{p|season beat}}, five minutes tops. Score an objective by averaging the individual key result scores underneath it. This is also why it’s so important to make those key results quantitatively measurable.<br />
<br />
'''Warning'''<br />
*Do not mix {{okrs}} and performance reviews; do not use it as a weapon against your employees in performance reviews.<br />
}}<br />
==Typical Progress Meeting==<br />
*Ask people to share their quick wins—one or two notable things they or their team has achieved since last time.<br />
*Ask people what progress has been made agains their {{okrs}}: <br />
**What are the areas that are still keeping you up at night?<br />
**Where do you need help?'<br />
**Everyone shares one or two things that are causing them the biggest concerns about hitting their {{okrs}}<br />
*Have the major concerns guides the meeting’s conversation in the right direction—because they’re always focused on removing roadblocks, they always feel like time well spent.<br />
<br />
Smashing Magazine:<br />
:Schedule deadlines as specific tasks, not the ends of phases. Rather than “Content will be completed by 4 April 2010,” state “Review the content over lunch on 4 April 2010.” This ties the deadline to an event at which results must be shown. Mini-deadlines tied to specific events are more powerful than general statements.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://quietstars.com/lax2020/<br />
|person=Adrian Howard<br />
|site=Quiet Stars<br />
|title=OKRs That Don't Suck<br />
}}<br />
{{WebSourceListItem<br />
|url=https://link.medium.com/uw3MScjdA6<br />
|person=Ian Batterbee<br />
|site=Medium<br />
|title= Designing for motivation with the goal-gradient effect<br />
}}<br />
{{WebSourceListItem<br />
|url=https://felipecastro.com/en/blog/book-review-measure-what-matters/<br />
|site=Felipe Castro<br />
|title=Measure What Really Matters<br />
|about=Good, bad and ugly of the book with the same title<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@mcleanonline/4-key-lessons-ive-learned-about-okrs-3f4b902ae9f8<br />
|site=Medium<br />
|person=Richard McLean<br />
|title=4 key lessons I’ve learned about OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hackernoon.com/beyond-outcomes-over-outputs-6b2677044214<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Beyond “Outcomes Over Outputs”<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2018/05/how-vc-john-doerr-sets-and-achieves-goals<br />
|site=HBR<br />
|person=Daniel McGinn<br />
|title=How VC John Doerr Sets (and Achieves) Goals<br />
}}<br />
{{WebSourceListItem<br />
|url=https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/<br />
|site=re:Work<br />
|title=Guide: Set goals with OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=http://felipecastro.com/en/okr-tools/<br />
|site=Filipe Castro<br />
|title=OKR Tools<br />
}}<br />
{{WebSourceListItem<br />
|url=http://eleganthack.com/the-art-of-the-okr/<br />
|site=Eleganthack<br />
|title=The Art of the OKR<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/untangling-okrs-with-a-big-visual-board-6153afa12213<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Untangling OKRs with a Big, Visual Board<br />
}}<br />
{{WebSourceListItem<br />
|url=http://okrexamples.co/company-okr-examples<br />
|site=OKR Examples<br />
|title=Company OKR Examples<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/18-things-your-okrs-shouldnt-do-23c8b57a455f<br />
|site=Medium<br />
|person=John Cutler<br />
|title=18 Things Your OKRs Shouldn’t Do…<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dannorth.net/2017/05/01/applying-okrs/<br />
|site=Dan North & Associates<br />
|person=Dan North<br />
|title=Applying OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/startup-tools/okrs-5afdc298bc28<br />
|site=Medium<br />
|person=@niket<br />
|title=The Fundamentals » OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://docs.google.com/document/d/1OHpQOvZz76_10ebJP2AKvvXUF3H9yd6FC89F5jS4mks<br />
|site=Google Docs<br />
|person=@niket<br />
|title=Startup OKRs Template<br />
}}<br />
{{WebSourceListItem<br />
|url=http://firstround.com/review/How-to-Make-OKRs-Actually-Work-at-Your-Startup/<br />
|site=First Round<br />
|title=How to Make OKRs Actually Work at Your Startup<br />
}}<br />
{{WebSourceListItem<br />
|url=https://blog.weekdone.com/introduction-okr-objectives-key-results/<br />
|site=Weekdone<br />
|person=Jüri Kaljundi<br />
|title=Introduction to OKR – Objectives and Key Results<br />
}}<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/blog/okr-vs-kpi/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=OKR vs. KPI: How they compare and how they work together<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Metric_drives_behavior&diff=3023Metric drives behavior2020-08-04T08:03:39Z<p>Martien: += {{quote|The purpose of measurements is to motivate the parts to do what is good for the organization as a whole.|Eli Goldratt}}</p>
<hr />
<div>{{tag|excellence}}<br />
----<br />
'''[https://seths.blog/2019/06/any-metric-you-can-buy-your-way-out-of/ Any metric you can buy your way out of…]'''<br />
<br />
Is probably not a useful metric to measure yourself by.<br />
<br />
If it’s important and you can spend money to fix it, by all means, go do that.<br />
<br />
But the helpful metrics are the ones where cash isn’t the solution.<br />
<br />
—Seth Godin<br />
----<br />
<br />
When starting out with metrics and KPI’s, consider…<br />
#If this went up what would we do differently?<br />
#If this went down, what would we do differently?<br />
#Given your answers why do you need the metric?<br />
<br />
<br />
Metrics for team coaching. Always be thinking:<br />
#If we improve this, what might we degrade?<br />
#Improvement takes time, how will we know when impact begins.<br />
#How much good for this metric is enough or too much, what signs do we look for?<br />
:—Troy Magennis<br />
<br />
The first things I'd check to diagnose bad quality:<br />
#how much work in progress<br />
#what % of the tasks have deadlines<br />
#how big the tasks are; and <br />
#are there any hand-offs.<br />
From my experience, nothing hurts quality more than those four. —Dimitri Kraivanov<br />
<br />
5 Basic Metric Rules:<br />
#Respect individual safety.<br />
#Show trends.<br />
#Compare data in context.<br />
#Highlight the unusual.<br />
#Balance the focus—the four balancing pillars are usually:<br />
##Quality<br />
##Productivity<br />
##Predictability, and<br />
##Responsiveness. <br />
(@t_magennis @elabor8)<br />
<br />
<br />
Metrics are not a yard-stick to control and manage people but serve to bring transparency to the teams.<br />
<br />
[https://www.bbc.co.uk/news/amp/business-41291483 Ryanair to cancel 40-50 flights per day for six weeks] to meet their “punctuality” metric, rather than focusing on customer’s {{p|fitness for purpose}} criterion '''on-time arrival''' metric. Ryanair noticed that punctuality—a vanity metric—had fallen below 80% and that cancelling less than 2% of its flights—affecting up to 285,000 passengers—would help it hit its annual punctuality target of 90%.<br />
<br />
'''To do''': Add quotes on behavior and control from ''{{p|don’t just do something, stand there!}}''<br />
<br />
{{quote|The purpose of measurements is to motivate the parts to do what is good for the organization as a whole.|Eli Goldratt}}<br />
{{quote|Good metrics are enlightening and help us make better decisions.|Scott Ambler}}<br />
{{quote|The most powerful statement managers can make about what is important in the organisation lies in what they choose to measure.|John Seddon}}<br />
{{quote|It is difficult to detect improvements or reductions in productivity because we feel busy regardless of our output. That’s why measurement is important.|Kanban}}<br />
{{quote|Measurements aren't about achieving certainty. They are about reducing uncertainty|@AgileSteveSmith}}<br />
{{quote|The purpose of measurements is to motivate the parts to do what is good for the organization as a whole.|Eli Goldratt}}<br />
{{quote|Every metric is a vanity metric if you are not using it to drive behavior.|Bill Sesko}}<br />
{{quote|Metrics are people, too.|Eric Ries}}<br />
{{quote|It’s better to be roughly right than precisely wrong|Maynard Keynes}}<br />
{{quote|Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.|Albert Einstein}}<br />
{{quote|What gets measured is what gets done.|unknown}}<br />
{{quote|You can game any metric.|unknown}}<br />
{{quote|Don't measure anything unless the data helps you make a better decision or change your actions.|Seth Godin}}, via {{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
{{quote|If you're not prepared to change your diet or your workouts, don't get on the scale.|Seth Godin}}, via <br />
{{quote|Even noisy data is better than no data.|David J. Anderson}}<br />
{{quote|Data always trumps opinion.|David J. Anderson}}<br />
{{quote|Without data, assumptions fill the void.|Julia Wester}}<br />
{{quote|When benefits are not quantified at all, assume there aren’t any.|Tom DeMarco}}<br />
{{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
<br />
Meten leidt tot weten(?!). To measure leads to knowledge.<br />
<br />
From {{book|The Lean Startup|Eric Ries}}: Actionable Metrics are<br />
#Actionable<br />
#Accessible<br />
#Auditable<br />
<br />
Use '''behaviour-driven metrics'''—metrics that deal with people and their actions with the system, e.g.<br />
*downloading the product;<br />
*login into the product;<br />
*posting and sharing a picture; and<br />
*commenting on a picture.<br />
Sounds like {{p|user stories}}.<br />
<br />
Use {{usage|actionable behavioural metrics one-pager}} throughout the organization.<br />
<br />
'''METRICS''':<br />
:'''M'''easure '''E'''verything '''T'''hat '''R'''esults '''I'''n '''C'''ustomer '''S'''atisfaction<br />
<br />
Have a look at {{p|pirate metrics}}.<br />
<br />
In other words, '''metrics drive behavior''', possibly related to the [http://en.wikipedia.org/wiki/Observer_effect_(physics) Observer Effect].<br />
<br />
Therefore:<br />
*Secure that all metrics lead to customer delight and value creation, potentially boosting the {{p|net promoter score}}, either, directly or indirectly.<br />
*Pick and design your metrics with great care as they drive human behavior, and therefore that of the organization.<br />
*Use metrics to guide improvements that accelerate the organization or ecosystem as a whole, not to measure activities of people. This is, pick metrics that {{p|optimize the whole}} on multiple levels of scale or granularity, e.g. {{p|epic}}, {{p|feature}}, and {{p|story}} level.<br />
*Limit metrics to numbers that quantify a certain outcome or the quality of certain input that is key for the quality of an outcome.<br />
*Select two to three universal metrics that apply to the whole unit, division or all teams.<br />
*Use {{p|ockham's razor}} to measure only the necessary things.<br />
*Aim the metric to maximize value creation.<br />
*Capture the metric in {{p|planguage}} to quantify quality.<br />
*Keep your metric elegant, terse, to the point.<br />
<br />
The worst thing that van happen with metrics is that people start feeling beat up, which means that they will start hiding data. If the management does not understand the constraints because the teams concerns about getting beat up for not being on time, then you never know where to help or how move resources around. If teams see management as helping to move resources around and provide creative and helpful changes, the issues will be made visible early, and you can respond and adjust in reaI·time. The leads to a positive reinforcing cycle that is key to the the agile management approach. (Source: [http://www.amazon.com/Practical-Approach-Large-Scale-Agile-Development/dp/0321821726 A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)])<br />
<br />
*'''Metrics without goals are naked'''—Metrics should always give you a clue on where you are regarding your goals. So, find out where you are, how you measure that, and where you want to be. Set up a metric that tracks your progress.<br />
*'''Balanced Metrics'''—Many metrics only focus on operational excellence. This creates a biased view on reality and distorts and deforms the organization as a whole. Therefore, balance metrics across the following dimensions:<br />
*#Operational Excellence<br />
*#*Velocity<br />
*#*Burn rate<br />
*#*Predictability<br />
*#*Sustainability<br />
*#*Meeting deadlines<br />
*#*Stay within budget<br />
*#*Meet quality requirements<br />
*#*Cohesive set {{p|user stories}} in a {{p|sprint}}<br />
*#User Orientation<br />
*#*Availability<br />
*#*Performance<br />
*#*User satisfaction ({{p|net promoter score}} ([[NPS]]))<br />
*#Business Value<br />
*#*Business value per € development<br />
*#*Business value realization<br />
*#Future Orientation<br />
*#*Enthusiasm and motivation<br />
*#*{{p|happiness index}}<br />
*#*Educational opportunities<br />
*#*Vision on future development<br />
*#*Innovative governance<br />
**Have participants brainstorm on metrics and put each of them in the most appropriate category. Next, pick one or two from each catagory to create balance.<br />
**Consider using {{p|planguage}} to capture metrics in a solid, comprehensive and consistent way.<br />
<br />
==Vanity Metrics==<br />
The book {{book|The Lean Startup|Eric Ries}} defines so called [[vanity metrics]].<br />
<br />
==Useful Metrics==<br />
Donald Reinertsen, author of Managing the Design Factory states that a good, useful metric is:<br />
*'''Simple'''—The ideal metrics are self-generating in the sense that they are created without extra effort in the normal course of business.<br />
*'''Relevant'''—One test of relevance is whether the metrics focus on things that are actually controllable by the people being measured. Psychologists have found that when people think that they can control something they are more motivated to control it. Measuring people on things they can not control simply causes stress, dissatisfaction, and alienation. Also, metrics must be relevant towards the end goal.<br />
*'''Leading'''—Managers like leading indicators, and prefer an imperfect forecast of the future to a perfect report on the past. It is better to measure the size of a test queue than it is to measure the processing times of individual tests because test queue size is a leading indicator of future delays in test processing. Accountants like lagging indicators that can be measured very accurately, but these point to things that have past.<br />
*'''Self-generating'''—Metrics are created without extra effort in the normal course of business, as in spin-off of daily activities.<br />
<br />
All metrics can be leading or lagging relative to some other metric. The important question is whether you can describe a coherent relationship between them.<br />
<br />
==KPIs==<br />
{{author|David J. Anderson}} on KPIs: Measure what matters to customers! All KPIs should be recognizable to your customer!<br />
'''Fit for purpose''' service delivery KPIs:<br />
*lead time;<br />
*quality;<br />
*predictability;<br />
*conformance;<br />
*safety.<br />
<br />
KPIs:<br />
*help to give direction<br />
*are meaningful for everyone<br />
*focus on trends rather than absolute numbers<br />
*focus on quality (speed will follow)<br />
*drive improvements in the way of working<br />
*challenge everyone to improve performance<br />
*are tied to a strategic objective<br />
*contribute to vision and mission<br />
*provide neutral and objective information, not judgement<br />
*flow top down and bottom up<br />
*are concrete but not a target<br />
*have at least one bound<br />
*are leading indicators<br />
*gives insight in and answers the question “Are we heading in the right direction?” at strategic (company), tactical (unit) and operational (team) level;<br />
*are reflected in the various flow state admission criteria (e.g. Definition of Ready, Definition of Done).<br />
<br />
Good KPIs are:<br />
*accessible<br />
*transparent—visibile to everyone<br />
*simple<br />
*understandable<br />
*actionable at the lowest organizational levels (team, individual)<br />
<br />
KPIs '''DO NOT'''s:<br />
*'''Do not''' use KPIs to compare teams or units;<br />
*'''Do not''' use or design KPIs to judge;<br />
*'''Do not''' create KPIs that threaten or scare people;<br />
<br />
Potential KPI trends you may want to track:<br />
*{{p|ka-ching moment}}s—every time an item is put in production a point is scored; higher is better; trend should be upwards as team speeds up, gets gelled;<br />
*{{p|average lead time distribution}}:<br />
**average time between moment item is pulled into team and ka-ching moment; shorter is better; trend should be downwards;<br />
**number of outliers (should decrease)<br />
*{{p|throughput}}—running average of completed items per time period (week, month, quarter, year); as team speeds up, trend should follow upwards;<br />
*{{p|happiness index}}—drives speed improvements; higher is better; trend should be upwards;<br />
*{{p|due date performance}}:<br />
**For the most recent month and for the year to date;<br />
**Optional year-on-year (or 12 months ago);<br />
*{{p|flow efficiency}}:<br />
**sum of work time divided by sum of waiting time for all items<br />
**good indicator of the waste in the system;<br />
*{{p|defect rate}} (a.k.a. bugs):<br />
**Defects represent opportunity cost and affect the lead time and throughput of the system.<br />
**Report the number of escaped defects as a percentage against the total WIP and throughput.<br />
**Keeping the number of bugs between 0 and 20 is a good policy for most projects.<br />
**Key questions:<br />
***Why is the number of new defects increasing? Did you relax some QA policies?<br />
***How did the high level of bugs in week 20 affect cycle time?<br />
***What was the impact on the cumulative flow diagram when the number of bugs increased?<br />
***Over time, work to make the defect rate fall to close to zero.<br />
***less is better;<br />
***trend should be downwards;<br />
*{{p|blocked items}}:<br />
**Blocked items have serious long term effects on the systems.<br />
**A team’s ability to quickly solve issues says a lot about the team’s performance and effectiveness.<br />
**Blocked items should always be visible on the board.<br />
**Tracking the status over time is usually a good way of knowing whether the team is moving in the right direction.<br />
**less blockers is better; downward trend;<br />
*{{p|failure load}}:<br />
**Failure Load (amount of rework) is a good indicator that you are improving as a whole organization and thinking at a system level.<br />
**Failure load tracks how many work items you process because of earlier poor quality—how many work items are production defects or new features that have been requested through your customer-service organization because of poor usability or a failure to anticipate user needs properly. <br />
**Ideally, Failure Load should fall over time. <br />
**less rework is better; downward trend preferred;<br />
<br />
The {{p|operations review}} is a monthly feedback loop for a number of these metrics.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://blog.usenotion.com/13-essential-software-development-metrics-to-ensure-quality-219cfc264ed1<br />
|site=Use Notion<br />
|title=13 Essential Software Development Metrics to Ensure Quality<br />
}}<br />
{{WebSourceListItem<br />
|url=https://productcraft.com/perspectives/not-all-metrics-have-to-be-actionable-gasp/<br />
|site=Product Craft<br />
|person=René Rosendahl<br />
|title=Not All Metrics Have to Be Actionable (Gasp!)<br />
|kind=Tweet<br />
}}<br />
{{WebSourceListItem<br />
|url=https://t.co/O3XrQNe6nd<br />
|site=Twitter<br />
|person=Omer van Kloeten<br />
|title=Quantifying Quality<br />
|kind=Tweet<br />
}}<br />
{{WebSourceListItem<br />
|url=http://focusedobjective.com/wp-content/uploads/2014/09/The-Economic-Impact-of-Software-Development-Process-Choice-Cycle-time-Analysis-and-Monte-Carlo-Simulation-Results.pdf<br />
|site=Focused Objective<br />
|person=Troy Magennis<br />
|title=The Economic Impact of Software Development Process Choice—Cycle-time Analysis and Monte Carlo Simulation Results<br />
|kind=PDF<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.slideshare.net/FocusedObjective/agile-2014-software-moneyball-troy-magennis<br />
|site=SlideShare<br />
|person=Troy Magennis<br />
|title=Agile 2014 Software Moneyball<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/10/scrum-metrics-for-hyperproductive-teams.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Scrum Metrics for Hyperproductive Teams<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/11/happiness-metric-wave-of-future.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Happiness Metric - The Wave of the Future<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dl.dropbox.com/u/33524813/LeanRiskManagement%20(Anderson%20Key%20Note).pptx<br />
|site=Dropbox<br />
|person=David J. Anderson<br />
|title=Lean Risk Management—Options, Liquidity & Hedging Risk using Kanban Systems<br />
}}, about Liquidity, WIP, Lead Time, Cycle Time, Process Efficiency.<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/not-destroy-team-metrics<br />
|site=InfoQ<br />
|person=Sean McHugh<br />
|title=How To Not Destroy your Agile Team with Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.sixsigmatraining.org/introduction-to-six-sigma/gaming-the-metrics.html<br />
|site=Pyzdek Institute<br />
|person=Thomas Pyzdek<br />
|title=Gaming the Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://leadinganswers.typepad.com/leading_answers/2010/02/smart-metrics-slides.html<br />
|site=Leading Answers<br />
|person=Mike Griffiths<br />
|title=Smart Metrics Slides<br />
}}<br />
{{WebSourceListItem<br />
|url=http://martinfowler.com/articles/useOfMetrics.html<br />
|site=Martin Fowler<br />
|person=Martin Fowler<br />
|title=An Appropriate Use of Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://theitriskmanager.wordpress.com/2013/12/07/outcome-based-process-metrics-a-focus-on-time-to-value/<br />
|site=The Risk Manager<br />
|person=Chris Matts<br />
|title=Outcome based Process Metrics—A focus on Time to Value<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.agilealliance.org/files/8213/9819/0015/ActionableMetricsAtSiemensHealthServices.pdf<br />
|site=Agile Alliance<br />
|person=Daniel Vacanti, Bennet Vallet<br />
|title=Actionable Metrics at Siemens Health Services<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2016/04/numbers-and-the-magic-of-measuring-the-right-thing.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Numbers (and the magic of measuring the right thing)<br />
}}<br />
<br />
*http://www.slideshare.net/JuliaWester/metrics-and-coaching<br />
*https://mattphilip.wordpress.com/2015/01/12/improvement-metrics/</div>Martienhttp://pearllanguage.org/index.php?title=Metric_drives_behavior&diff=3022Metric drives behavior2020-07-17T07:22:51Z<p>Martien: += When starting out with metrics and KPI’s, consider…</p>
<hr />
<div>{{tag|excellence}}<br />
----<br />
'''[https://seths.blog/2019/06/any-metric-you-can-buy-your-way-out-of/ Any metric you can buy your way out of…]'''<br />
<br />
Is probably not a useful metric to measure yourself by.<br />
<br />
If it’s important and you can spend money to fix it, by all means, go do that.<br />
<br />
But the helpful metrics are the ones where cash isn’t the solution.<br />
<br />
—Seth Godin<br />
----<br />
<br />
When starting out with metrics and KPI’s, consider…<br />
#If this went up what would we do differently?<br />
#If this went down, what would we do differently?<br />
#Given your answers why do you need the metric?<br />
<br />
<br />
Metrics for team coaching. Always be thinking:<br />
#If we improve this, what might we degrade?<br />
#Improvement takes time, how will we know when impact begins.<br />
#How much good for this metric is enough or too much, what signs do we look for?<br />
:—Troy Magennis<br />
<br />
The first things I'd check to diagnose bad quality:<br />
#how much work in progress<br />
#what % of the tasks have deadlines<br />
#how big the tasks are; and <br />
#are there any hand-offs.<br />
From my experience, nothing hurts quality more than those four. —Dimitri Kraivanov<br />
<br />
5 Basic Metric Rules:<br />
#Respect individual safety.<br />
#Show trends.<br />
#Compare data in context.<br />
#Highlight the unusual.<br />
#Balance the focus—the four balancing pillars are usually:<br />
##Quality<br />
##Productivity<br />
##Predictability, and<br />
##Responsiveness. <br />
(@t_magennis @elabor8)<br />
<br />
<br />
Metrics are not a yard-stick to control and manage people but serve to bring transparency to the teams.<br />
<br />
[https://www.bbc.co.uk/news/amp/business-41291483 Ryanair to cancel 40-50 flights per day for six weeks] to meet their “punctuality” metric, rather than focusing on customer’s {{p|fitness for purpose}} criterion '''on-time arrival''' metric. Ryanair noticed that punctuality—a vanity metric—had fallen below 80% and that cancelling less than 2% of its flights—affecting up to 285,000 passengers—would help it hit its annual punctuality target of 90%.<br />
<br />
'''To do''': Add quotes on behavior and control from ''{{p|don’t just do something, stand there!}}''<br />
{{quote|Good metrics are enlightening and help us make better decisions.|Scott Ambler}}<br />
{{quote|The most powerful statement managers can make about what is important in the organisation lies in what they choose to measure.|John Seddon}}<br />
{{quote|It is difficult to detect improvements or reductions in productivity because we feel busy regardless of our output. That’s why measurement is important.|Kanban}}<br />
{{quote|Measurements aren't about achieving certainty. They are about reducing uncertainty|@AgileSteveSmith}}<br />
{{quote|The purpose of measurements is to motivate the parts to do what is good for the organization as a whole.|Eli Goldratt}}<br />
{{quote|Every metric is a vanity metric if you are not using it to drive behavior.|Bill Sesko}}<br />
{{quote|Metrics are people, too.|Eric Ries}}<br />
{{quote|It’s better to be roughly right than precisely wrong|Maynard Keynes}}<br />
{{quote|Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.|Albert Einstein}}<br />
{{quote|What gets measured is what gets done.|unknown}}<br />
{{quote|You can game any metric.|unknown}}<br />
{{quote|Don't measure anything unless the data helps you make a better decision or change your actions.|Seth Godin}}, via {{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
{{quote|If you're not prepared to change your diet or your workouts, don't get on the scale.|Seth Godin}}, via <br />
{{quote|Even noisy data is better than no data.|David J. Anderson}}<br />
{{quote|Data always trumps opinion.|David J. Anderson}}<br />
{{quote|Without data, assumptions fill the void.|Julia Wester}}<br />
{{quote|When benefits are not quantified at all, assume there aren’t any.|Tom DeMarco}}<br />
{{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
<br />
Meten leidt tot weten(?!). To measure leads to knowledge.<br />
<br />
From {{book|The Lean Startup|Eric Ries}}: Actionable Metrics are<br />
#Actionable<br />
#Accessible<br />
#Auditable<br />
<br />
Use '''behaviour-driven metrics'''—metrics that deal with people and their actions with the system, e.g.<br />
*downloading the product;<br />
*login into the product;<br />
*posting and sharing a picture; and<br />
*commenting on a picture.<br />
Sounds like {{p|user stories}}.<br />
<br />
Use {{usage|actionable behavioural metrics one-pager}} throughout the organization.<br />
<br />
'''METRICS''':<br />
:'''M'''easure '''E'''verything '''T'''hat '''R'''esults '''I'''n '''C'''ustomer '''S'''atisfaction<br />
<br />
Have a look at {{p|pirate metrics}}.<br />
<br />
In other words, '''metrics drive behavior''', possibly related to the [http://en.wikipedia.org/wiki/Observer_effect_(physics) Observer Effect].<br />
<br />
Therefore:<br />
*Secure that all metrics lead to customer delight and value creation, potentially boosting the {{p|net promoter score}}, either, directly or indirectly.<br />
*Pick and design your metrics with great care as they drive human behavior, and therefore that of the organization.<br />
*Use metrics to guide improvements that accelerate the organization or ecosystem as a whole, not to measure activities of people. This is, pick metrics that {{p|optimize the whole}} on multiple levels of scale or granularity, e.g. {{p|epic}}, {{p|feature}}, and {{p|story}} level.<br />
*Limit metrics to numbers that quantify a certain outcome or the quality of certain input that is key for the quality of an outcome.<br />
*Select two to three universal metrics that apply to the whole unit, division or all teams.<br />
*Use {{p|ockham's razor}} to measure only the necessary things.<br />
*Aim the metric to maximize value creation.<br />
*Capture the metric in {{p|planguage}} to quantify quality.<br />
*Keep your metric elegant, terse, to the point.<br />
<br />
The worst thing that van happen with metrics is that people start feeling beat up, which means that they will start hiding data. If the management does not understand the constraints because the teams concerns about getting beat up for not being on time, then you never know where to help or how move resources around. If teams see management as helping to move resources around and provide creative and helpful changes, the issues will be made visible early, and you can respond and adjust in reaI·time. The leads to a positive reinforcing cycle that is key to the the agile management approach. (Source: [http://www.amazon.com/Practical-Approach-Large-Scale-Agile-Development/dp/0321821726 A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)])<br />
<br />
*'''Metrics without goals are naked'''—Metrics should always give you a clue on where you are regarding your goals. So, find out where you are, how you measure that, and where you want to be. Set up a metric that tracks your progress.<br />
*'''Balanced Metrics'''—Many metrics only focus on operational excellence. This creates a biased view on reality and distorts and deforms the organization as a whole. Therefore, balance metrics across the following dimensions:<br />
*#Operational Excellence<br />
*#*Velocity<br />
*#*Burn rate<br />
*#*Predictability<br />
*#*Sustainability<br />
*#*Meeting deadlines<br />
*#*Stay within budget<br />
*#*Meet quality requirements<br />
*#*Cohesive set {{p|user stories}} in a {{p|sprint}}<br />
*#User Orientation<br />
*#*Availability<br />
*#*Performance<br />
*#*User satisfaction ({{p|net promoter score}} ([[NPS]]))<br />
*#Business Value<br />
*#*Business value per € development<br />
*#*Business value realization<br />
*#Future Orientation<br />
*#*Enthusiasm and motivation<br />
*#*{{p|happiness index}}<br />
*#*Educational opportunities<br />
*#*Vision on future development<br />
*#*Innovative governance<br />
**Have participants brainstorm on metrics and put each of them in the most appropriate category. Next, pick one or two from each catagory to create balance.<br />
**Consider using {{p|planguage}} to capture metrics in a solid, comprehensive and consistent way.<br />
<br />
==Vanity Metrics==<br />
The book {{book|The Lean Startup|Eric Ries}} defines so called [[vanity metrics]].<br />
<br />
==Useful Metrics==<br />
Donald Reinertsen, author of Managing the Design Factory states that a good, useful metric is:<br />
*'''Simple'''—The ideal metrics are self-generating in the sense that they are created without extra effort in the normal course of business.<br />
*'''Relevant'''—One test of relevance is whether the metrics focus on things that are actually controllable by the people being measured. Psychologists have found that when people think that they can control something they are more motivated to control it. Measuring people on things they can not control simply causes stress, dissatisfaction, and alienation. Also, metrics must be relevant towards the end goal.<br />
*'''Leading'''—Managers like leading indicators, and prefer an imperfect forecast of the future to a perfect report on the past. It is better to measure the size of a test queue than it is to measure the processing times of individual tests because test queue size is a leading indicator of future delays in test processing. Accountants like lagging indicators that can be measured very accurately, but these point to things that have past.<br />
*'''Self-generating'''—Metrics are created without extra effort in the normal course of business, as in spin-off of daily activities.<br />
<br />
All metrics can be leading or lagging relative to some other metric. The important question is whether you can describe a coherent relationship between them.<br />
<br />
==KPIs==<br />
{{author|David J. Anderson}} on KPIs: Measure what matters to customers! All KPIs should be recognizable to your customer!<br />
'''Fit for purpose''' service delivery KPIs:<br />
*lead time;<br />
*quality;<br />
*predictability;<br />
*conformance;<br />
*safety.<br />
<br />
KPIs:<br />
*help to give direction<br />
*are meaningful for everyone<br />
*focus on trends rather than absolute numbers<br />
*focus on quality (speed will follow)<br />
*drive improvements in the way of working<br />
*challenge everyone to improve performance<br />
*are tied to a strategic objective<br />
*contribute to vision and mission<br />
*provide neutral and objective information, not judgement<br />
*flow top down and bottom up<br />
*are concrete but not a target<br />
*have at least one bound<br />
*are leading indicators<br />
*gives insight in and answers the question “Are we heading in the right direction?” at strategic (company), tactical (unit) and operational (team) level;<br />
*are reflected in the various flow state admission criteria (e.g. Definition of Ready, Definition of Done).<br />
<br />
Good KPIs are:<br />
*accessible<br />
*transparent—visibile to everyone<br />
*simple<br />
*understandable<br />
*actionable at the lowest organizational levels (team, individual)<br />
<br />
KPIs '''DO NOT'''s:<br />
*'''Do not''' use KPIs to compare teams or units;<br />
*'''Do not''' use or design KPIs to judge;<br />
*'''Do not''' create KPIs that threaten or scare people;<br />
<br />
Potential KPI trends you may want to track:<br />
*{{p|ka-ching moment}}s—every time an item is put in production a point is scored; higher is better; trend should be upwards as team speeds up, gets gelled;<br />
*{{p|average lead time distribution}}:<br />
**average time between moment item is pulled into team and ka-ching moment; shorter is better; trend should be downwards;<br />
**number of outliers (should decrease)<br />
*{{p|throughput}}—running average of completed items per time period (week, month, quarter, year); as team speeds up, trend should follow upwards;<br />
*{{p|happiness index}}—drives speed improvements; higher is better; trend should be upwards;<br />
*{{p|due date performance}}:<br />
**For the most recent month and for the year to date;<br />
**Optional year-on-year (or 12 months ago);<br />
*{{p|flow efficiency}}:<br />
**sum of work time divided by sum of waiting time for all items<br />
**good indicator of the waste in the system;<br />
*{{p|defect rate}} (a.k.a. bugs):<br />
**Defects represent opportunity cost and affect the lead time and throughput of the system.<br />
**Report the number of escaped defects as a percentage against the total WIP and throughput.<br />
**Keeping the number of bugs between 0 and 20 is a good policy for most projects.<br />
**Key questions:<br />
***Why is the number of new defects increasing? Did you relax some QA policies?<br />
***How did the high level of bugs in week 20 affect cycle time?<br />
***What was the impact on the cumulative flow diagram when the number of bugs increased?<br />
***Over time, work to make the defect rate fall to close to zero.<br />
***less is better;<br />
***trend should be downwards;<br />
*{{p|blocked items}}:<br />
**Blocked items have serious long term effects on the systems.<br />
**A team’s ability to quickly solve issues says a lot about the team’s performance and effectiveness.<br />
**Blocked items should always be visible on the board.<br />
**Tracking the status over time is usually a good way of knowing whether the team is moving in the right direction.<br />
**less blockers is better; downward trend;<br />
*{{p|failure load}}:<br />
**Failure Load (amount of rework) is a good indicator that you are improving as a whole organization and thinking at a system level.<br />
**Failure load tracks how many work items you process because of earlier poor quality—how many work items are production defects or new features that have been requested through your customer-service organization because of poor usability or a failure to anticipate user needs properly. <br />
**Ideally, Failure Load should fall over time. <br />
**less rework is better; downward trend preferred;<br />
<br />
The {{p|operations review}} is a monthly feedback loop for a number of these metrics.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://blog.usenotion.com/13-essential-software-development-metrics-to-ensure-quality-219cfc264ed1<br />
|site=Use Notion<br />
|title=13 Essential Software Development Metrics to Ensure Quality<br />
}}<br />
{{WebSourceListItem<br />
|url=https://productcraft.com/perspectives/not-all-metrics-have-to-be-actionable-gasp/<br />
|site=Product Craft<br />
|person=René Rosendahl<br />
|title=Not All Metrics Have to Be Actionable (Gasp!)<br />
|kind=Tweet<br />
}}<br />
{{WebSourceListItem<br />
|url=https://t.co/O3XrQNe6nd<br />
|site=Twitter<br />
|person=Omer van Kloeten<br />
|title=Quantifying Quality<br />
|kind=Tweet<br />
}}<br />
{{WebSourceListItem<br />
|url=http://focusedobjective.com/wp-content/uploads/2014/09/The-Economic-Impact-of-Software-Development-Process-Choice-Cycle-time-Analysis-and-Monte-Carlo-Simulation-Results.pdf<br />
|site=Focused Objective<br />
|person=Troy Magennis<br />
|title=The Economic Impact of Software Development Process Choice—Cycle-time Analysis and Monte Carlo Simulation Results<br />
|kind=PDF<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.slideshare.net/FocusedObjective/agile-2014-software-moneyball-troy-magennis<br />
|site=SlideShare<br />
|person=Troy Magennis<br />
|title=Agile 2014 Software Moneyball<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/10/scrum-metrics-for-hyperproductive-teams.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Scrum Metrics for Hyperproductive Teams<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/11/happiness-metric-wave-of-future.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Happiness Metric - The Wave of the Future<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dl.dropbox.com/u/33524813/LeanRiskManagement%20(Anderson%20Key%20Note).pptx<br />
|site=Dropbox<br />
|person=David J. Anderson<br />
|title=Lean Risk Management—Options, Liquidity & Hedging Risk using Kanban Systems<br />
}}, about Liquidity, WIP, Lead Time, Cycle Time, Process Efficiency.<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/not-destroy-team-metrics<br />
|site=InfoQ<br />
|person=Sean McHugh<br />
|title=How To Not Destroy your Agile Team with Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.sixsigmatraining.org/introduction-to-six-sigma/gaming-the-metrics.html<br />
|site=Pyzdek Institute<br />
|person=Thomas Pyzdek<br />
|title=Gaming the Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://leadinganswers.typepad.com/leading_answers/2010/02/smart-metrics-slides.html<br />
|site=Leading Answers<br />
|person=Mike Griffiths<br />
|title=Smart Metrics Slides<br />
}}<br />
{{WebSourceListItem<br />
|url=http://martinfowler.com/articles/useOfMetrics.html<br />
|site=Martin Fowler<br />
|person=Martin Fowler<br />
|title=An Appropriate Use of Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://theitriskmanager.wordpress.com/2013/12/07/outcome-based-process-metrics-a-focus-on-time-to-value/<br />
|site=The Risk Manager<br />
|person=Chris Matts<br />
|title=Outcome based Process Metrics—A focus on Time to Value<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.agilealliance.org/files/8213/9819/0015/ActionableMetricsAtSiemensHealthServices.pdf<br />
|site=Agile Alliance<br />
|person=Daniel Vacanti, Bennet Vallet<br />
|title=Actionable Metrics at Siemens Health Services<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2016/04/numbers-and-the-magic-of-measuring-the-right-thing.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Numbers (and the magic of measuring the right thing)<br />
}}<br />
<br />
*http://www.slideshare.net/JuliaWester/metrics-and-coaching<br />
*https://mattphilip.wordpress.com/2015/01/12/improvement-metrics/</div>Martienhttp://pearllanguage.org/index.php?title=OKR&diff=3021OKR2020-05-18T08:03:36Z<p>Martien: /* Sources */ += Medium » Ian Batterbee » Designing for motivation with the goal-gradient effect</p>
<hr />
<div>{{Oyster<br />
|goal=keep everyone moving forward as a team—aligned autonomy<br />
|stage=Sparkle<br />
|context=culture, productivity and alignment all in flux.<br />
|wish=Keep everyone moving forward as an aligned and autonomous team.<br />
|so=Co-create and publish objectives and key results on all levels in your organization.<br />
|image=OKR Best Practices.png{{!}}600px<br />
|prologue=To achieve great things, two things are needed: a plan and not quite enough time. —Leonard Bernstein<br />
|wish full=Keep everyone moving forward as a team in a world where culture, productivity and alignment are all in flux.<br />
|background={{quote|The greater danger for most of us lies not in setting our aim too high and falling short, but in setting our aims too low and achieving our mark.|Michelangelo}}<br />
<br />
==Forces==<br />
*{{p|metrics drive behavior}}<br />
*People hate corporate acronyms that mandate work more than just corporate acronyms.<br />
*Multiple teams often depend on one another to succeed.<br />
*No one person knows everything going on inside the organization.<br />
*Personal objectives that are directly and clearly connected to the broader goals of the company are more inspiring and imaginative.<br />
*Public information that everyone can see help make you feel you are toiling in a thriving environment with your manager’s approval.<br />
*Public goals and clear results:<br />
**encourage people to ask for resources; and<br />
**easily spot where you can support your colleagues;<br />
**force different types of thinking around how people ask for help from others and helps amplifying this type of dialog.<br />
*Airing things out releases anxiety and let’s people get creative—that’s when interesting things happen.<br />
*Stretched goals:<br />
**help you to be ambitious enough the push you beyond your limits; and<br />
**focuses conversations about what is truly needed to beat expectations;<br />
**encourages to {{p|question everything}}; and<br />
**forces {{p|questions that matter}} like:<br />
***“I’d have to completely solve this hard problem”; or<br />
***“I need to completely rethink how I’m addressing X or Y.”<br />
*Having clear objectives, especially those tied to developing your skills, are a key part of career development.<br />
*People love hitting their marks.<br />
*Key results that are always tied to money block seeing other, diverse objectives in the mix—it will make people play safe rather than being ambitious and entrepreneurial.<br />
*Regular updates and reviews of objectives and key results spur increased dialogue between employees, co-workers, managers, and leadership and allows recognition to be spread out over time, which tends to be more rewarding.<br />
*Self-inflicted objectives and goals are much more powerful than top-down goals dictated from higher organizational levels.<br />
<br />
{{okrs}}:<br />
*serve as a layer of communication that holds the company together;<br />
*are designed for accountability;<br />
*are enforced with scores;<br />
*elevates its game;<br />
*can become a part of the culture;<br />
*use the following structure:<br />
**high level objective;<br />
**a more detailed description of why that objective is important—a summary of how the objective aligns with the broader goals of both the person’s team and the company; and<br />
**three to five key results that will help them achieve that goal.<br />
*track results on a quantitative basis—key results are not general or subjective actions you plan to take, and should always include numbers to make it clear how much has been achieved. For example, if Mary’s objective is to improve her sales prospecting skills, one key result might be to spend two hours a week shadowing Jennifer, the team member who demonstrates the most prospecting success;<br />
*are something for people look at, every quarter, every week, every day—consistently setting goals turns goal-setting into a habit and changes how people think about their work and approach their everyday to-dos; it puts in place natural milestones that make you think about what you need to do next and aim high;<br />
*are stretched goals in order to be effective—achieving 70% of your goals is just about perfect for {{okrs}}—if you achieve 100% of your goals, you’re not trying hard enough (cf. Sun Tzu: bow tension);<br />
*are a tool for motivating and aligning people to work together by increasing transparency, accountability and empowerment;<br />
*make it easier than ever to keep people focused and collect feedback, inside and outside management meetings;<br />
*facilitate continual coaching of yourself and others and develops your whole ecosystem;<br />
|therefore full=Encourage people to spend time defining their own {{okrs}} and then to meet specifically with their managers to incorporate their feedback. Spend your time defining {{okrs}}, not measuring them. Look at {{okrs}} as a way to communicate so there’s clarity about the {{p|unity of purpose}}. Tweak and tune your {{okrs}} to be more about collaboration and less about action items. Publish them for everyone to see (next to your {{p|flow board}}. Figure out how to put {{okrs}} work best for you. ‘Retroprospect’ your {{okrs}} with a {{p|season beat}} and make it a part of your {{p|operations review}}. Hold people publicly accountable for failing to regularly update their {{okrs}}. Have 60% of your {{okrs}} defined by employees, not leadership.<br />
|new=Consider creating an {{p|impact map}} to discover and express the right {{okrs}}.<br />
<br />
Grading should be a simple exercise at every {{p|season beat}}, five minutes tops. Score an objective by averaging the individual key result scores underneath it. This is also why it’s so important to make those key results quantitatively measurable.<br />
<br />
'''Warning'''<br />
*Do not mix {{okrs}} and performance reviews; do not use it as a weapon against your employees in performance reviews.<br />
}}<br />
==Typical Progress Meeting==<br />
*Ask people to share their quick wins—one or two notable things they or their team has achieved since last time.<br />
*Ask people what progress has been made agains their {{okrs}}: <br />
**What are the areas that are still keeping you up at night?<br />
**Where do you need help?'<br />
**Everyone shares one or two things that are causing them the biggest concerns about hitting their {{okrs}}<br />
*Have the major concerns guides the meeting’s conversation in the right direction—because they’re always focused on removing roadblocks, they always feel like time well spent.<br />
<br />
Smashing Magazine:<br />
:Schedule deadlines as specific tasks, not the ends of phases. Rather than “Content will be completed by 4 April 2010,” state “Review the content over lunch on 4 April 2010.” This ties the deadline to an event at which results must be shown. Mini-deadlines tied to specific events are more powerful than general statements.<br />
<br />
==Sources==<br />
<br />
{{WebSourceListItem<br />
|url=https://link.medium.com/uw3MScjdA6<br />
|person=Ian Batterbee<br />
|site=Medium<br />
|title= Designing for motivation with the goal-gradient effect<br />
}}<br />
{{WebSourceListItem<br />
|url=https://felipecastro.com/en/blog/book-review-measure-what-matters/<br />
|site=Felipe Castro<br />
|title=Measure What Really Matters<br />
|about=Good, bad and ugly of the book with the same title<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@mcleanonline/4-key-lessons-ive-learned-about-okrs-3f4b902ae9f8<br />
|site=Medium<br />
|person=Richard McLean<br />
|title=4 key lessons I’ve learned about OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hackernoon.com/beyond-outcomes-over-outputs-6b2677044214<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Beyond “Outcomes Over Outputs”<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2018/05/how-vc-john-doerr-sets-and-achieves-goals<br />
|site=HBR<br />
|person=Daniel McGinn<br />
|title=How VC John Doerr Sets (and Achieves) Goals<br />
}}<br />
{{WebSourceListItem<br />
|url=https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/<br />
|site=re:Work<br />
|title=Guide: Set goals with OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=http://felipecastro.com/en/okr-tools/<br />
|site=Filipe Castro<br />
|title=OKR Tools<br />
}}<br />
{{WebSourceListItem<br />
|url=http://eleganthack.com/the-art-of-the-okr/<br />
|site=Eleganthack<br />
|title=The Art of the OKR<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/untangling-okrs-with-a-big-visual-board-6153afa12213<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Untangling OKRs with a Big, Visual Board<br />
}}<br />
{{WebSourceListItem<br />
|url=http://okrexamples.co/company-okr-examples<br />
|site=OKR Examples<br />
|title=Company OKR Examples<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/18-things-your-okrs-shouldnt-do-23c8b57a455f<br />
|site=Medium<br />
|person=John Cutler<br />
|title=18 Things Your OKRs Shouldn’t Do…<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dannorth.net/2017/05/01/applying-okrs/<br />
|site=Dan North & Associates<br />
|person=Dan North<br />
|title=Applying OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/startup-tools/okrs-5afdc298bc28<br />
|site=Medium<br />
|person=@niket<br />
|title=The Fundamentals » OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://docs.google.com/document/d/1OHpQOvZz76_10ebJP2AKvvXUF3H9yd6FC89F5jS4mks<br />
|site=Google Docs<br />
|person=@niket<br />
|title=Startup OKRs Template<br />
}}<br />
{{WebSourceListItem<br />
|url=http://firstround.com/review/How-to-Make-OKRs-Actually-Work-at-Your-Startup/<br />
|site=First Round<br />
|title=How to Make OKRs Actually Work at Your Startup<br />
}}<br />
{{WebSourceListItem<br />
|url=https://blog.weekdone.com/introduction-okr-objectives-key-results/<br />
|site=Weekdone<br />
|person=Jüri Kaljundi<br />
|title=Introduction to OKR – Objectives and Key Results<br />
}}<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/blog/okr-vs-kpi/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=OKR vs. KPI: How they compare and how they work together<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Metric_drives_behavior&diff=3020Metric drives behavior2020-03-17T10:37:56Z<p>Martien: /* Sources */ += Use Notion » 13 Essential Software Development Metrics to Ensure Quality</p>
<hr />
<div>{{tag|excellence}}<br />
----<br />
'''[https://seths.blog/2019/06/any-metric-you-can-buy-your-way-out-of/ Any metric you can buy your way out of…]'''<br />
<br />
Is probably not a useful metric to measure yourself by.<br />
<br />
If it’s important and you can spend money to fix it, by all means, go do that.<br />
<br />
But the helpful metrics are the ones where cash isn’t the solution.<br />
<br />
—Seth Godin<br />
----<br />
Metrics for team coaching. Always be thinking:<br />
#If we improve this, what might we degrade?<br />
#Improvement takes time, how will we know when impact begins.<br />
#How much good for this metric is enough or too much, what signs do we look for?<br />
:—Troy Magennis<br />
<br />
The first things I'd check to diagnose bad quality:<br />
#how much work in progress<br />
#what % of the tasks have deadlines<br />
#how big the tasks are; and <br />
#are there any hand-offs.<br />
From my experience, nothing hurts quality more than those four. —Dimitri Kraivanov<br />
<br />
5 Basic Metric Rules:<br />
#Respect individual safety.<br />
#Show trends.<br />
#Compare data in context.<br />
#Highlight the unusual.<br />
#Balance the focus—the four balancing pillars are usually:<br />
##Quality<br />
##Productivity<br />
##Predictability, and<br />
##Responsiveness. <br />
(@t_magennis @elabor8)<br />
<br />
<br />
Metrics are not a yard-stick to control and manage people but serve to bring transparency to the teams.<br />
<br />
[https://www.bbc.co.uk/news/amp/business-41291483 Ryanair to cancel 40-50 flights per day for six weeks] to meet their “punctuality” metric, rather than focusing on customer’s {{p|fitness for purpose}} criterion '''on-time arrival''' metric. Ryanair noticed that punctuality—a vanity metric—had fallen below 80% and that cancelling less than 2% of its flights—affecting up to 285,000 passengers—would help it hit its annual punctuality target of 90%.<br />
<br />
'''To do''': Add quotes on behavior and control from ''{{p|don’t just do something, stand there!}}''<br />
{{quote|Good metrics are enlightening and help us make better decisions.|Scott Ambler}}<br />
{{quote|The most powerful statement managers can make about what is important in the organisation lies in what they choose to measure.|John Seddon}}<br />
{{quote|It is difficult to detect improvements or reductions in productivity because we feel busy regardless of our output. That’s why measurement is important.|Kanban}}<br />
{{quote|Measurements aren't about achieving certainty. They are about reducing uncertainty|@AgileSteveSmith}}<br />
{{quote|The purpose of measurements is to motivate the parts to do what is good for the organization as a whole.|Eli Goldratt}}<br />
{{quote|Every metric is a vanity metric if you are not using it to drive behavior.|Bill Sesko}}<br />
{{quote|Metrics are people, too.|Eric Ries}}<br />
{{quote|It’s better to be roughly right than precisely wrong|Maynard Keynes}}<br />
{{quote|Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.|Albert Einstein}}<br />
{{quote|What gets measured is what gets done.|unknown}}<br />
{{quote|You can game any metric.|unknown}}<br />
{{quote|Don't measure anything unless the data helps you make a better decision or change your actions.|Seth Godin}}, via {{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
{{quote|If you're not prepared to change your diet or your workouts, don't get on the scale.|Seth Godin}}, via <br />
{{quote|Even noisy data is better than no data.|David J. Anderson}}<br />
{{quote|Data always trumps opinion.|David J. Anderson}}<br />
{{quote|Without data, assumptions fill the void.|Julia Wester}}<br />
{{quote|When benefits are not quantified at all, assume there aren’t any.|Tom DeMarco}}<br />
{{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
<br />
Meten leidt tot weten(?!). To measure leads to knowledge.<br />
<br />
From {{book|The Lean Startup|Eric Ries}}: Actionable Metrics are<br />
#Actionable<br />
#Accessible<br />
#Auditable<br />
<br />
Use '''behaviour-driven metrics'''—metrics that deal with people and their actions with the system, e.g.<br />
*downloading the product;<br />
*login into the product;<br />
*posting and sharing a picture; and<br />
*commenting on a picture.<br />
Sounds like {{p|user stories}}.<br />
<br />
Use {{usage|actionable behavioural metrics one-pager}} throughout the organization.<br />
<br />
'''METRICS''':<br />
:'''M'''easure '''E'''verything '''T'''hat '''R'''esults '''I'''n '''C'''ustomer '''S'''atisfaction<br />
<br />
Have a look at {{p|pirate metrics}}.<br />
<br />
In other words, '''metrics drive behavior''', possibly related to the [http://en.wikipedia.org/wiki/Observer_effect_(physics) Observer Effect].<br />
<br />
Therefore:<br />
*Secure that all metrics lead to customer delight and value creation, potentially boosting the {{p|net promoter score}}, either, directly or indirectly.<br />
*Pick and design your metrics with great care as they drive human behavior, and therefore that of the organization.<br />
*Use metrics to guide improvements that accelerate the organization or ecosystem as a whole, not to measure activities of people. This is, pick metrics that {{p|optimize the whole}} on multiple levels of scale or granularity, e.g. {{p|epic}}, {{p|feature}}, and {{p|story}} level.<br />
*Limit metrics to numbers that quantify a certain outcome or the quality of certain input that is key for the quality of an outcome.<br />
*Select two to three universal metrics that apply to the whole unit, division or all teams.<br />
*Use {{p|ockham's razor}} to measure only the necessary things.<br />
*Aim the metric to maximize value creation.<br />
*Capture the metric in {{p|planguage}} to quantify quality.<br />
*Keep your metric elegant, terse, to the point.<br />
<br />
The worst thing that van happen with metrics is that people start feeling beat up, which means that they will start hiding data. If the management does not understand the constraints because the teams concerns about getting beat up for not being on time, then you never know where to help or how move resources around. If teams see management as helping to move resources around and provide creative and helpful changes, the issues will be made visible early, and you can respond and adjust in reaI·time. The leads to a positive reinforcing cycle that is key to the the agile management approach. (Source: [http://www.amazon.com/Practical-Approach-Large-Scale-Agile-Development/dp/0321821726 A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)])<br />
<br />
*'''Metrics without goals are naked'''—Metrics should always give you a clue on where you are regarding your goals. So, find out where you are, how you measure that, and where you want to be. Set up a metric that tracks your progress.<br />
*'''Balanced Metrics'''—Many metrics only focus on operational excellence. This creates a biased view on reality and distorts and deforms the organization as a whole. Therefore, balance metrics across the following dimensions:<br />
*#Operational Excellence<br />
*#*Velocity<br />
*#*Burn rate<br />
*#*Predictability<br />
*#*Sustainability<br />
*#*Meeting deadlines<br />
*#*Stay within budget<br />
*#*Meet quality requirements<br />
*#*Cohesive set {{p|user stories}} in a {{p|sprint}}<br />
*#User Orientation<br />
*#*Availability<br />
*#*Performance<br />
*#*User satisfaction ({{p|net promoter score}} ([[NPS]]))<br />
*#Business Value<br />
*#*Business value per € development<br />
*#*Business value realization<br />
*#Future Orientation<br />
*#*Enthusiasm and motivation<br />
*#*{{p|happiness index}}<br />
*#*Educational opportunities<br />
*#*Vision on future development<br />
*#*Innovative governance<br />
**Have participants brainstorm on metrics and put each of them in the most appropriate category. Next, pick one or two from each catagory to create balance.<br />
**Consider using {{p|planguage}} to capture metrics in a solid, comprehensive and consistent way.<br />
<br />
==Vanity Metrics==<br />
The book {{book|The Lean Startup|Eric Ries}} defines so called [[vanity metrics]].<br />
<br />
==Useful Metrics==<br />
Donald Reinertsen, author of Managing the Design Factory states that a good, useful metric is:<br />
*'''Simple'''—The ideal metrics are self-generating in the sense that they are created without extra effort in the normal course of business.<br />
*'''Relevant'''—One test of relevance is whether the metrics focus on things that are actually controllable by the people being measured. Psychologists have found that when people think that they can control something they are more motivated to control it. Measuring people on things they can not control simply causes stress, dissatisfaction, and alienation. Also, metrics must be relevant towards the end goal.<br />
*'''Leading'''—Managers like leading indicators, and prefer an imperfect forecast of the future to a perfect report on the past. It is better to measure the size of a test queue than it is to measure the processing times of individual tests because test queue size is a leading indicator of future delays in test processing. Accountants like lagging indicators that can be measured very accurately, but these point to things that have past.<br />
*'''Self-generating'''—Metrics are created without extra effort in the normal course of business, as in spin-off of daily activities.<br />
<br />
All metrics can be leading or lagging relative to some other metric. The important question is whether you can describe a coherent relationship between them.<br />
<br />
==KPIs==<br />
{{author|David J. Anderson}} on KPIs: Measure what matters to customers! All KPIs should be recognizable to your customer!<br />
'''Fit for purpose''' service delivery KPIs:<br />
*lead time;<br />
*quality;<br />
*predictability;<br />
*conformance;<br />
*safety.<br />
<br />
KPIs:<br />
*help to give direction<br />
*are meaningful for everyone<br />
*focus on trends rather than absolute numbers<br />
*focus on quality (speed will follow)<br />
*drive improvements in the way of working<br />
*challenge everyone to improve performance<br />
*are tied to a strategic objective<br />
*contribute to vision and mission<br />
*provide neutral and objective information, not judgement<br />
*flow top down and bottom up<br />
*are concrete but not a target<br />
*have at least one bound<br />
*are leading indicators<br />
*gives insight in and answers the question “Are we heading in the right direction?” at strategic (company), tactical (unit) and operational (team) level;<br />
*are reflected in the various flow state admission criteria (e.g. Definition of Ready, Definition of Done).<br />
<br />
Good KPIs are:<br />
*accessible<br />
*transparent—visibile to everyone<br />
*simple<br />
*understandable<br />
*actionable at the lowest organizational levels (team, individual)<br />
<br />
KPIs '''DO NOT'''s:<br />
*'''Do not''' use KPIs to compare teams or units;<br />
*'''Do not''' use or design KPIs to judge;<br />
*'''Do not''' create KPIs that threaten or scare people;<br />
<br />
Potential KPI trends you may want to track:<br />
*{{p|ka-ching moment}}s—every time an item is put in production a point is scored; higher is better; trend should be upwards as team speeds up, gets gelled;<br />
*{{p|average lead time distribution}}:<br />
**average time between moment item is pulled into team and ka-ching moment; shorter is better; trend should be downwards;<br />
**number of outliers (should decrease)<br />
*{{p|throughput}}—running average of completed items per time period (week, month, quarter, year); as team speeds up, trend should follow upwards;<br />
*{{p|happiness index}}—drives speed improvements; higher is better; trend should be upwards;<br />
*{{p|due date performance}}:<br />
**For the most recent month and for the year to date;<br />
**Optional year-on-year (or 12 months ago);<br />
*{{p|flow efficiency}}:<br />
**sum of work time divided by sum of waiting time for all items<br />
**good indicator of the waste in the system;<br />
*{{p|defect rate}} (a.k.a. bugs):<br />
**Defects represent opportunity cost and affect the lead time and throughput of the system.<br />
**Report the number of escaped defects as a percentage against the total WIP and throughput.<br />
**Keeping the number of bugs between 0 and 20 is a good policy for most projects.<br />
**Key questions:<br />
***Why is the number of new defects increasing? Did you relax some QA policies?<br />
***How did the high level of bugs in week 20 affect cycle time?<br />
***What was the impact on the cumulative flow diagram when the number of bugs increased?<br />
***Over time, work to make the defect rate fall to close to zero.<br />
***less is better;<br />
***trend should be downwards;<br />
*{{p|blocked items}}:<br />
**Blocked items have serious long term effects on the systems.<br />
**A team’s ability to quickly solve issues says a lot about the team’s performance and effectiveness.<br />
**Blocked items should always be visible on the board.<br />
**Tracking the status over time is usually a good way of knowing whether the team is moving in the right direction.<br />
**less blockers is better; downward trend;<br />
*{{p|failure load}}:<br />
**Failure Load (amount of rework) is a good indicator that you are improving as a whole organization and thinking at a system level.<br />
**Failure load tracks how many work items you process because of earlier poor quality—how many work items are production defects or new features that have been requested through your customer-service organization because of poor usability or a failure to anticipate user needs properly. <br />
**Ideally, Failure Load should fall over time. <br />
**less rework is better; downward trend preferred;<br />
<br />
The {{p|operations review}} is a monthly feedback loop for a number of these metrics.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://blog.usenotion.com/13-essential-software-development-metrics-to-ensure-quality-219cfc264ed1<br />
|site=Use Notion<br />
|title=13 Essential Software Development Metrics to Ensure Quality<br />
}}<br />
{{WebSourceListItem<br />
|url=https://productcraft.com/perspectives/not-all-metrics-have-to-be-actionable-gasp/<br />
|site=Product Craft<br />
|person=René Rosendahl<br />
|title=Not All Metrics Have to Be Actionable (Gasp!)<br />
|kind=Tweet<br />
}}<br />
{{WebSourceListItem<br />
|url=https://t.co/O3XrQNe6nd<br />
|site=Twitter<br />
|person=Omer van Kloeten<br />
|title=Quantifying Quality<br />
|kind=Tweet<br />
}}<br />
{{WebSourceListItem<br />
|url=http://focusedobjective.com/wp-content/uploads/2014/09/The-Economic-Impact-of-Software-Development-Process-Choice-Cycle-time-Analysis-and-Monte-Carlo-Simulation-Results.pdf<br />
|site=Focused Objective<br />
|person=Troy Magennis<br />
|title=The Economic Impact of Software Development Process Choice—Cycle-time Analysis and Monte Carlo Simulation Results<br />
|kind=PDF<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.slideshare.net/FocusedObjective/agile-2014-software-moneyball-troy-magennis<br />
|site=SlideShare<br />
|person=Troy Magennis<br />
|title=Agile 2014 Software Moneyball<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/10/scrum-metrics-for-hyperproductive-teams.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Scrum Metrics for Hyperproductive Teams<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/11/happiness-metric-wave-of-future.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Happiness Metric - The Wave of the Future<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dl.dropbox.com/u/33524813/LeanRiskManagement%20(Anderson%20Key%20Note).pptx<br />
|site=Dropbox<br />
|person=David J. Anderson<br />
|title=Lean Risk Management—Options, Liquidity & Hedging Risk using Kanban Systems<br />
}}, about Liquidity, WIP, Lead Time, Cycle Time, Process Efficiency.<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/not-destroy-team-metrics<br />
|site=InfoQ<br />
|person=Sean McHugh<br />
|title=How To Not Destroy your Agile Team with Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.sixsigmatraining.org/introduction-to-six-sigma/gaming-the-metrics.html<br />
|site=Pyzdek Institute<br />
|person=Thomas Pyzdek<br />
|title=Gaming the Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://leadinganswers.typepad.com/leading_answers/2010/02/smart-metrics-slides.html<br />
|site=Leading Answers<br />
|person=Mike Griffiths<br />
|title=Smart Metrics Slides<br />
}}<br />
{{WebSourceListItem<br />
|url=http://martinfowler.com/articles/useOfMetrics.html<br />
|site=Martin Fowler<br />
|person=Martin Fowler<br />
|title=An Appropriate Use of Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://theitriskmanager.wordpress.com/2013/12/07/outcome-based-process-metrics-a-focus-on-time-to-value/<br />
|site=The Risk Manager<br />
|person=Chris Matts<br />
|title=Outcome based Process Metrics—A focus on Time to Value<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.agilealliance.org/files/8213/9819/0015/ActionableMetricsAtSiemensHealthServices.pdf<br />
|site=Agile Alliance<br />
|person=Daniel Vacanti, Bennet Vallet<br />
|title=Actionable Metrics at Siemens Health Services<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2016/04/numbers-and-the-magic-of-measuring-the-right-thing.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Numbers (and the magic of measuring the right thing)<br />
}}<br />
<br />
*http://www.slideshare.net/JuliaWester/metrics-and-coaching<br />
*https://mattphilip.wordpress.com/2015/01/12/improvement-metrics/</div>Martienhttp://pearllanguage.org/index.php?title=Metric_drives_behavior&diff=3019Metric drives behavior2019-11-21T18:03:52Z<p>Martien: += All metrics can be leading or lagging relative to some other metric. The important question is whether you can describe a coherent relationship between them.</p>
<hr />
<div>{{tag|excellence}}<br />
----<br />
'''[https://seths.blog/2019/06/any-metric-you-can-buy-your-way-out-of/ Any metric you can buy your way out of…]'''<br />
<br />
Is probably not a useful metric to measure yourself by.<br />
<br />
If it’s important and you can spend money to fix it, by all means, go do that.<br />
<br />
But the helpful metrics are the ones where cash isn’t the solution.<br />
<br />
—Seth Godin<br />
----<br />
Metrics for team coaching. Always be thinking:<br />
#If we improve this, what might we degrade?<br />
#Improvement takes time, how will we know when impact begins.<br />
#How much good for this metric is enough or too much, what signs do we look for?<br />
:—Troy Magennis<br />
<br />
The first things I'd check to diagnose bad quality:<br />
#how much work in progress<br />
#what % of the tasks have deadlines<br />
#how big the tasks are; and <br />
#are there any hand-offs.<br />
From my experience, nothing hurts quality more than those four. —Dimitri Kraivanov<br />
<br />
5 Basic Metric Rules:<br />
#Respect individual safety.<br />
#Show trends.<br />
#Compare data in context.<br />
#Highlight the unusual.<br />
#Balance the focus—the four balancing pillars are usually:<br />
##Quality<br />
##Productivity<br />
##Predictability, and<br />
##Responsiveness. <br />
(@t_magennis @elabor8)<br />
<br />
<br />
Metrics are not a yard-stick to control and manage people but serve to bring transparency to the teams.<br />
<br />
[https://www.bbc.co.uk/news/amp/business-41291483 Ryanair to cancel 40-50 flights per day for six weeks] to meet their “punctuality” metric, rather than focusing on customer’s {{p|fitness for purpose}} criterion '''on-time arrival''' metric. Ryanair noticed that punctuality—a vanity metric—had fallen below 80% and that cancelling less than 2% of its flights—affecting up to 285,000 passengers—would help it hit its annual punctuality target of 90%.<br />
<br />
'''To do''': Add quotes on behavior and control from ''{{p|don’t just do something, stand there!}}''<br />
{{quote|Good metrics are enlightening and help us make better decisions.|Scott Ambler}}<br />
{{quote|The most powerful statement managers can make about what is important in the organisation lies in what they choose to measure.|John Seddon}}<br />
{{quote|It is difficult to detect improvements or reductions in productivity because we feel busy regardless of our output. That’s why measurement is important.|Kanban}}<br />
{{quote|Measurements aren't about achieving certainty. They are about reducing uncertainty|@AgileSteveSmith}}<br />
{{quote|The purpose of measurements is to motivate the parts to do what is good for the organization as a whole.|Eli Goldratt}}<br />
{{quote|Every metric is a vanity metric if you are not using it to drive behavior.|Bill Sesko}}<br />
{{quote|Metrics are people, too.|Eric Ries}}<br />
{{quote|It’s better to be roughly right than precisely wrong|Maynard Keynes}}<br />
{{quote|Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.|Albert Einstein}}<br />
{{quote|What gets measured is what gets done.|unknown}}<br />
{{quote|You can game any metric.|unknown}}<br />
{{quote|Don't measure anything unless the data helps you make a better decision or change your actions.|Seth Godin}}, via {{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
{{quote|If you're not prepared to change your diet or your workouts, don't get on the scale.|Seth Godin}}, via <br />
{{quote|Even noisy data is better than no data.|David J. Anderson}}<br />
{{quote|Data always trumps opinion.|David J. Anderson}}<br />
{{quote|Without data, assumptions fill the void.|Julia Wester}}<br />
{{quote|When benefits are not quantified at all, assume there aren’t any.|Tom DeMarco}}<br />
{{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
<br />
Meten leidt tot weten(?!). To measure leads to knowledge.<br />
<br />
From {{book|The Lean Startup|Eric Ries}}: Actionable Metrics are<br />
#Actionable<br />
#Accessible<br />
#Auditable<br />
<br />
Use '''behaviour-driven metrics'''—metrics that deal with people and their actions with the system, e.g.<br />
*downloading the product;<br />
*login into the product;<br />
*posting and sharing a picture; and<br />
*commenting on a picture.<br />
Sounds like {{p|user stories}}.<br />
<br />
Use {{usage|actionable behavioural metrics one-pager}} throughout the organization.<br />
<br />
'''METRICS''':<br />
:'''M'''easure '''E'''verything '''T'''hat '''R'''esults '''I'''n '''C'''ustomer '''S'''atisfaction<br />
<br />
Have a look at {{p|pirate metrics}}.<br />
<br />
In other words, '''metrics drive behavior''', possibly related to the [http://en.wikipedia.org/wiki/Observer_effect_(physics) Observer Effect].<br />
<br />
Therefore:<br />
*Secure that all metrics lead to customer delight and value creation, potentially boosting the {{p|net promoter score}}, either, directly or indirectly.<br />
*Pick and design your metrics with great care as they drive human behavior, and therefore that of the organization.<br />
*Use metrics to guide improvements that accelerate the organization or ecosystem as a whole, not to measure activities of people. This is, pick metrics that {{p|optimize the whole}} on multiple levels of scale or granularity, e.g. {{p|epic}}, {{p|feature}}, and {{p|story}} level.<br />
*Limit metrics to numbers that quantify a certain outcome or the quality of certain input that is key for the quality of an outcome.<br />
*Select two to three universal metrics that apply to the whole unit, division or all teams.<br />
*Use {{p|ockham's razor}} to measure only the necessary things.<br />
*Aim the metric to maximize value creation.<br />
*Capture the metric in {{p|planguage}} to quantify quality.<br />
*Keep your metric elegant, terse, to the point.<br />
<br />
The worst thing that van happen with metrics is that people start feeling beat up, which means that they will start hiding data. If the management does not understand the constraints because the teams concerns about getting beat up for not being on time, then you never know where to help or how move resources around. If teams see management as helping to move resources around and provide creative and helpful changes, the issues will be made visible early, and you can respond and adjust in reaI·time. The leads to a positive reinforcing cycle that is key to the the agile management approach. (Source: [http://www.amazon.com/Practical-Approach-Large-Scale-Agile-Development/dp/0321821726 A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)])<br />
<br />
*'''Metrics without goals are naked'''—Metrics should always give you a clue on where you are regarding your goals. So, find out where you are, how you measure that, and where you want to be. Set up a metric that tracks your progress.<br />
*'''Balanced Metrics'''—Many metrics only focus on operational excellence. This creates a biased view on reality and distorts and deforms the organization as a whole. Therefore, balance metrics across the following dimensions:<br />
*#Operational Excellence<br />
*#*Velocity<br />
*#*Burn rate<br />
*#*Predictability<br />
*#*Sustainability<br />
*#*Meeting deadlines<br />
*#*Stay within budget<br />
*#*Meet quality requirements<br />
*#*Cohesive set {{p|user stories}} in a {{p|sprint}}<br />
*#User Orientation<br />
*#*Availability<br />
*#*Performance<br />
*#*User satisfaction ({{p|net promoter score}} ([[NPS]]))<br />
*#Business Value<br />
*#*Business value per € development<br />
*#*Business value realization<br />
*#Future Orientation<br />
*#*Enthusiasm and motivation<br />
*#*{{p|happiness index}}<br />
*#*Educational opportunities<br />
*#*Vision on future development<br />
*#*Innovative governance<br />
**Have participants brainstorm on metrics and put each of them in the most appropriate category. Next, pick one or two from each catagory to create balance.<br />
**Consider using {{p|planguage}} to capture metrics in a solid, comprehensive and consistent way.<br />
<br />
==Vanity Metrics==<br />
The book {{book|The Lean Startup|Eric Ries}} defines so called [[vanity metrics]].<br />
<br />
==Useful Metrics==<br />
Donald Reinertsen, author of Managing the Design Factory states that a good, useful metric is:<br />
*'''Simple'''—The ideal metrics are self-generating in the sense that they are created without extra effort in the normal course of business.<br />
*'''Relevant'''—One test of relevance is whether the metrics focus on things that are actually controllable by the people being measured. Psychologists have found that when people think that they can control something they are more motivated to control it. Measuring people on things they can not control simply causes stress, dissatisfaction, and alienation. Also, metrics must be relevant towards the end goal.<br />
*'''Leading'''—Managers like leading indicators, and prefer an imperfect forecast of the future to a perfect report on the past. It is better to measure the size of a test queue than it is to measure the processing times of individual tests because test queue size is a leading indicator of future delays in test processing. Accountants like lagging indicators that can be measured very accurately, but these point to things that have past.<br />
*'''Self-generating'''—Metrics are created without extra effort in the normal course of business, as in spin-off of daily activities.<br />
<br />
All metrics can be leading or lagging relative to some other metric. The important question is whether you can describe a coherent relationship between them.<br />
<br />
==KPIs==<br />
{{author|David J. Anderson}} on KPIs: Measure what matters to customers! All KPIs should be recognizable to your customer!<br />
'''Fit for purpose''' service delivery KPIs:<br />
*lead time;<br />
*quality;<br />
*predictability;<br />
*conformance;<br />
*safety.<br />
<br />
KPIs:<br />
*help to give direction<br />
*are meaningful for everyone<br />
*focus on trends rather than absolute numbers<br />
*focus on quality (speed will follow)<br />
*drive improvements in the way of working<br />
*challenge everyone to improve performance<br />
*are tied to a strategic objective<br />
*contribute to vision and mission<br />
*provide neutral and objective information, not judgement<br />
*flow top down and bottom up<br />
*are concrete but not a target<br />
*have at least one bound<br />
*are leading indicators<br />
*gives insight in and answers the question “Are we heading in the right direction?” at strategic (company), tactical (unit) and operational (team) level;<br />
*are reflected in the various flow state admission criteria (e.g. Definition of Ready, Definition of Done).<br />
<br />
Good KPIs are:<br />
*accessible<br />
*transparent—visibile to everyone<br />
*simple<br />
*understandable<br />
*actionable at the lowest organizational levels (team, individual)<br />
<br />
KPIs '''DO NOT'''s:<br />
*'''Do not''' use KPIs to compare teams or units;<br />
*'''Do not''' use or design KPIs to judge;<br />
*'''Do not''' create KPIs that threaten or scare people;<br />
<br />
Potential KPI trends you may want to track:<br />
*{{p|ka-ching moment}}s—every time an item is put in production a point is scored; higher is better; trend should be upwards as team speeds up, gets gelled;<br />
*{{p|average lead time distribution}}:<br />
**average time between moment item is pulled into team and ka-ching moment; shorter is better; trend should be downwards;<br />
**number of outliers (should decrease)<br />
*{{p|throughput}}—running average of completed items per time period (week, month, quarter, year); as team speeds up, trend should follow upwards;<br />
*{{p|happiness index}}—drives speed improvements; higher is better; trend should be upwards;<br />
*{{p|due date performance}}:<br />
**For the most recent month and for the year to date;<br />
**Optional year-on-year (or 12 months ago);<br />
*{{p|flow efficiency}}:<br />
**sum of work time divided by sum of waiting time for all items<br />
**good indicator of the waste in the system;<br />
*{{p|defect rate}} (a.k.a. bugs):<br />
**Defects represent opportunity cost and affect the lead time and throughput of the system.<br />
**Report the number of escaped defects as a percentage against the total WIP and throughput.<br />
**Keeping the number of bugs between 0 and 20 is a good policy for most projects.<br />
**Key questions:<br />
***Why is the number of new defects increasing? Did you relax some QA policies?<br />
***How did the high level of bugs in week 20 affect cycle time?<br />
***What was the impact on the cumulative flow diagram when the number of bugs increased?<br />
***Over time, work to make the defect rate fall to close to zero.<br />
***less is better;<br />
***trend should be downwards;<br />
*{{p|blocked items}}:<br />
**Blocked items have serious long term effects on the systems.<br />
**A team’s ability to quickly solve issues says a lot about the team’s performance and effectiveness.<br />
**Blocked items should always be visible on the board.<br />
**Tracking the status over time is usually a good way of knowing whether the team is moving in the right direction.<br />
**less blockers is better; downward trend;<br />
*{{p|failure load}}:<br />
**Failure Load (amount of rework) is a good indicator that you are improving as a whole organization and thinking at a system level.<br />
**Failure load tracks how many work items you process because of earlier poor quality—how many work items are production defects or new features that have been requested through your customer-service organization because of poor usability or a failure to anticipate user needs properly. <br />
**Ideally, Failure Load should fall over time. <br />
**less rework is better; downward trend preferred;<br />
<br />
The {{p|operations review}} is a monthly feedback loop for a number of these metrics.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://productcraft.com/perspectives/not-all-metrics-have-to-be-actionable-gasp/<br />
|site=Product Craft<br />
|person=René Rosendahl<br />
|title=Not All Metrics Have to Be Actionable (Gasp!)<br />
|kind=Tweet<br />
}}<br />
{{WebSourceListItem<br />
|url=https://t.co/O3XrQNe6nd<br />
|site=Twitter<br />
|person=Omer van Kloeten<br />
|title=Quantifying Quality<br />
|kind=Tweet<br />
}}<br />
{{WebSourceListItem<br />
|url=http://focusedobjective.com/wp-content/uploads/2014/09/The-Economic-Impact-of-Software-Development-Process-Choice-Cycle-time-Analysis-and-Monte-Carlo-Simulation-Results.pdf<br />
|site=Focused Objective<br />
|person=Troy Magennis<br />
|title=The Economic Impact of Software Development Process Choice—Cycle-time Analysis and Monte Carlo Simulation Results<br />
|kind=PDF<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.slideshare.net/FocusedObjective/agile-2014-software-moneyball-troy-magennis<br />
|site=SlideShare<br />
|person=Troy Magennis<br />
|title=Agile 2014 Software Moneyball<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/10/scrum-metrics-for-hyperproductive-teams.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Scrum Metrics for Hyperproductive Teams<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/11/happiness-metric-wave-of-future.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Happiness Metric - The Wave of the Future<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dl.dropbox.com/u/33524813/LeanRiskManagement%20(Anderson%20Key%20Note).pptx<br />
|site=Dropbox<br />
|person=David J. Anderson<br />
|title=Lean Risk Management—Options, Liquidity & Hedging Risk using Kanban Systems<br />
}}, about Liquidity, WIP, Lead Time, Cycle Time, Process Efficiency.<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/not-destroy-team-metrics<br />
|site=InfoQ<br />
|person=Sean McHugh<br />
|title=How To Not Destroy your Agile Team with Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.sixsigmatraining.org/introduction-to-six-sigma/gaming-the-metrics.html<br />
|site=Pyzdek Institute<br />
|person=Thomas Pyzdek<br />
|title=Gaming the Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://leadinganswers.typepad.com/leading_answers/2010/02/smart-metrics-slides.html<br />
|site=Leading Answers<br />
|person=Mike Griffiths<br />
|title=Smart Metrics Slides<br />
}}<br />
{{WebSourceListItem<br />
|url=http://martinfowler.com/articles/useOfMetrics.html<br />
|site=Martin Fowler<br />
|person=Martin Fowler<br />
|title=An Appropriate Use of Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://theitriskmanager.wordpress.com/2013/12/07/outcome-based-process-metrics-a-focus-on-time-to-value/<br />
|site=The Risk Manager<br />
|person=Chris Matts<br />
|title=Outcome based Process Metrics—A focus on Time to Value<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.agilealliance.org/files/8213/9819/0015/ActionableMetricsAtSiemensHealthServices.pdf<br />
|site=Agile Alliance<br />
|person=Daniel Vacanti, Bennet Vallet<br />
|title=Actionable Metrics at Siemens Health Services<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2016/04/numbers-and-the-magic-of-measuring-the-right-thing.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Numbers (and the magic of measuring the right thing)<br />
}}<br />
<br />
*http://www.slideshare.net/JuliaWester/metrics-and-coaching<br />
*https://mattphilip.wordpress.com/2015/01/12/improvement-metrics/</div>Martienhttp://pearllanguage.org/index.php?title=Persona_team&diff=3018Persona team2019-10-27T08:36:29Z<p>Martien: /* Sources */ += https://svpg.com/product-vs-feature-teams/</p>
<hr />
<div>{{tag|team}}<br />
==Sources==<br />
*http://featureteamprimer.org/feature_team_primer12.pdf<br />
*http://www.odd-e.com/material/2009/Agile2009/Agile2009_print.pdf<br />
*http://pareltaal.nl/Personateam<br />
*https://svpg.com/product-vs-feature-teams/</div>Martienhttp://pearllanguage.org/index.php?title=Metric_drives_behavior&diff=3017Metric drives behavior2019-10-27T08:33:07Z<p>Martien: /* Sources */ += Product Craft » René Rosendahl » Not All Metrics Have to Be Actionable (Gasp!)</p>
<hr />
<div>{{tag|excellence}}<br />
----<br />
'''[https://seths.blog/2019/06/any-metric-you-can-buy-your-way-out-of/ Any metric you can buy your way out of…]'''<br />
<br />
Is probably not a useful metric to measure yourself by.<br />
<br />
If it’s important and you can spend money to fix it, by all means, go do that.<br />
<br />
But the helpful metrics are the ones where cash isn’t the solution.<br />
<br />
—Seth Godin<br />
----<br />
Metrics for team coaching. Always be thinking:<br />
#If we improve this, what might we degrade?<br />
#Improvement takes time, how will we know when impact begins.<br />
#How much good for this metric is enough or too much, what signs do we look for?<br />
:—Troy Magennis<br />
<br />
The first things I'd check to diagnose bad quality:<br />
#how much work in progress<br />
#what % of the tasks have deadlines<br />
#how big the tasks are; and <br />
#are there any hand-offs.<br />
From my experience, nothing hurts quality more than those four. —Dimitri Kraivanov<br />
<br />
5 Basic Metric Rules:<br />
#Respect individual safety.<br />
#Show trends.<br />
#Compare data in context.<br />
#Highlight the unusual.<br />
#Balance the focus—the four balancing pillars are usually:<br />
##Quality<br />
##Productivity<br />
##Predictability, and<br />
##Responsiveness. <br />
(@t_magennis @elabor8)<br />
<br />
<br />
Metrics are not a yard-stick to control and manage people but serve to bring transparency to the teams.<br />
<br />
[https://www.bbc.co.uk/news/amp/business-41291483 Ryanair to cancel 40-50 flights per day for six weeks] to meet their “punctuality” metric, rather than focusing on customer’s {{p|fitness for purpose}} criterion '''on-time arrival''' metric. Ryanair noticed that punctuality—a vanity metric—had fallen below 80% and that cancelling less than 2% of its flights—affecting up to 285,000 passengers—would help it hit its annual punctuality target of 90%.<br />
<br />
'''To do''': Add quotes on behavior and control from ''{{p|don’t just do something, stand there!}}''<br />
{{quote|Good metrics are enlightening and help us make better decisions.|Scott Ambler}}<br />
{{quote|The most powerful statement managers can make about what is important in the organisation lies in what they choose to measure.|John Seddon}}<br />
{{quote|It is difficult to detect improvements or reductions in productivity because we feel busy regardless of our output. That’s why measurement is important.|Kanban}}<br />
{{quote|Measurements aren't about achieving certainty. They are about reducing uncertainty|@AgileSteveSmith}}<br />
{{quote|The purpose of measurements is to motivate the parts to do what is good for the organization as a whole.|Eli Goldratt}}<br />
{{quote|Every metric is a vanity metric if you are not using it to drive behavior.|Bill Sesko}}<br />
{{quote|Metrics are people, too.|Eric Ries}}<br />
{{quote|It’s better to be roughly right than precisely wrong|Maynard Keynes}}<br />
{{quote|Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.|Albert Einstein}}<br />
{{quote|What gets measured is what gets done.|unknown}}<br />
{{quote|You can game any metric.|unknown}}<br />
{{quote|Don't measure anything unless the data helps you make a better decision or change your actions.|Seth Godin}}, via {{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
{{quote|If you're not prepared to change your diet or your workouts, don't get on the scale.|Seth Godin}}, via <br />
{{quote|Even noisy data is better than no data.|David J. Anderson}}<br />
{{quote|Data always trumps opinion.|David J. Anderson}}<br />
{{quote|Without data, assumptions fill the void.|Julia Wester}}<br />
{{quote|When benefits are not quantified at all, assume there aren’t any.|Tom DeMarco}}<br />
{{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
<br />
Meten leidt tot weten(?!). To measure leads to knowledge.<br />
<br />
From {{book|The Lean Startup|Eric Ries}}: Actionable Metrics are<br />
#Actionable<br />
#Accessible<br />
#Auditable<br />
<br />
Use '''behaviour-driven metrics'''—metrics that deal with people and their actions with the system, e.g.<br />
*downloading the product;<br />
*login into the product;<br />
*posting and sharing a picture; and<br />
*commenting on a picture.<br />
Sounds like {{p|user stories}}.<br />
<br />
Use {{usage|actionable behavioural metrics one-pager}} throughout the organization.<br />
<br />
'''METRICS''':<br />
:'''M'''easure '''E'''verything '''T'''hat '''R'''esults '''I'''n '''C'''ustomer '''S'''atisfaction<br />
<br />
Have a look at {{p|pirate metrics}}.<br />
<br />
In other words, '''metrics drive behavior''', possibly related to the [http://en.wikipedia.org/wiki/Observer_effect_(physics) Observer Effect].<br />
<br />
Therefore:<br />
*Secure that all metrics lead to customer delight and value creation, potentially boosting the {{p|net promoter score}}, either, directly or indirectly.<br />
*Pick and design your metrics with great care as they drive human behavior, and therefore that of the organization.<br />
*Use metrics to guide improvements that accelerate the organization or ecosystem as a whole, not to measure activities of people. This is, pick metrics that {{p|optimize the whole}} on multiple levels of scale or granularity, e.g. {{p|epic}}, {{p|feature}}, and {{p|story}} level.<br />
*Limit metrics to numbers that quantify a certain outcome or the quality of certain input that is key for the quality of an outcome.<br />
*Select two to three universal metrics that apply to the whole unit, division or all teams.<br />
*Use {{p|ockham's razor}} to measure only the necessary things.<br />
*Aim the metric to maximize value creation.<br />
*Capture the metric in {{p|planguage}} to quantify quality.<br />
*Keep your metric elegant, terse, to the point.<br />
<br />
The worst thing that van happen with metrics is that people start feeling beat up, which means that they will start hiding data. If the management does not understand the constraints because the teams concerns about getting beat up for not being on time, then you never know where to help or how move resources around. If teams see management as helping to move resources around and provide creative and helpful changes, the issues will be made visible early, and you can respond and adjust in reaI·time. The leads to a positive reinforcing cycle that is key to the the agile management approach. (Source: [http://www.amazon.com/Practical-Approach-Large-Scale-Agile-Development/dp/0321821726 A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)])<br />
<br />
*'''Metrics without goals are naked'''—Metrics should always give you a clue on where you are regarding your goals. So, find out where you are, how you measure that, and where you want to be. Set up a metric that tracks your progress.<br />
*'''Balanced Metrics'''—Many metrics only focus on operational excellence. This creates a biased view on reality and distorts and deforms the organization as a whole. Therefore, balance metrics across the following dimensions:<br />
*#Operational Excellence<br />
*#*Velocity<br />
*#*Burn rate<br />
*#*Predictability<br />
*#*Sustainability<br />
*#*Meeting deadlines<br />
*#*Stay within budget<br />
*#*Meet quality requirements<br />
*#*Cohesive set {{p|user stories}} in a {{p|sprint}}<br />
*#User Orientation<br />
*#*Availability<br />
*#*Performance<br />
*#*User satisfaction ({{p|net promoter score}} ([[NPS]]))<br />
*#Business Value<br />
*#*Business value per € development<br />
*#*Business value realization<br />
*#Future Orientation<br />
*#*Enthusiasm and motivation<br />
*#*{{p|happiness index}}<br />
*#*Educational opportunities<br />
*#*Vision on future development<br />
*#*Innovative governance<br />
**Have participants brainstorm on metrics and put each of them in the most appropriate category. Next, pick one or two from each catagory to create balance.<br />
**Consider using {{p|planguage}} to capture metrics in a solid, comprehensive and consistent way.<br />
<br />
==Vanity Metrics==<br />
The book {{book|The Lean Startup|Eric Ries}} defines so called [[vanity metrics]].<br />
<br />
==Useful Metrics==<br />
Donald Reinertsen, author of Managing the Design Factory states that a good, useful metric is:<br />
*'''Simple'''—The ideal metrics are self-generating in the sense that they are created without extra effort in the normal course of business.<br />
*'''Relevant'''—One test of relevance is whether the metrics focus on things that are actually controllable by the people being measured. Psychologists have found that when people think that they can control something they are more motivated to control it. Measuring people on things they can not control simply causes stress, dissatisfaction, and alienation. Also, metrics must be relevant towards the end goal.<br />
*'''Leading'''—Managers like leading indicators, and prefer an imperfect forecast of the future to a perfect report on the past. It is better to measure the size of a test queue than it is to measure the processing times of individual tests because test queue size is a leading indicator of future delays in test processing. Accountants like lagging indicators that can be measured very accurately, but these point to things that have past.<br />
*'''Self-generating'''—Metrics are created without extra effort in the normal course of business, as in spin-off of daily activities.<br />
<br />
==KPIs==<br />
{{author|David J. Anderson}} on KPIs: Measure what matters to customers! All KPIs should be recognizable to your customer!<br />
'''Fit for purpose''' service delivery KPIs:<br />
*lead time;<br />
*quality;<br />
*predictability;<br />
*conformance;<br />
*safety.<br />
<br />
KPIs:<br />
*help to give direction<br />
*are meaningful for everyone<br />
*focus on trends rather than absolute numbers<br />
*focus on quality (speed will follow)<br />
*drive improvements in the way of working<br />
*challenge everyone to improve performance<br />
*are tied to a strategic objective<br />
*contribute to vision and mission<br />
*provide neutral and objective information, not judgement<br />
*flow top down and bottom up<br />
*are concrete but not a target<br />
*have at least one bound<br />
*are leading indicators<br />
*gives insight in and answers the question “Are we heading in the right direction?” at strategic (company), tactical (unit) and operational (team) level;<br />
*are reflected in the various flow state admission criteria (e.g. Definition of Ready, Definition of Done).<br />
<br />
Good KPIs are:<br />
*accessible<br />
*transparent—visibile to everyone<br />
*simple<br />
*understandable<br />
*actionable at the lowest organizational levels (team, individual)<br />
<br />
KPIs '''DO NOT'''s:<br />
*'''Do not''' use KPIs to compare teams or units;<br />
*'''Do not''' use or design KPIs to judge;<br />
*'''Do not''' create KPIs that threaten or scare people;<br />
<br />
Potential KPI trends you may want to track:<br />
*{{p|ka-ching moment}}s—every time an item is put in production a point is scored; higher is better; trend should be upwards as team speeds up, gets gelled;<br />
*{{p|average lead time distribution}}:<br />
**average time between moment item is pulled into team and ka-ching moment; shorter is better; trend should be downwards;<br />
**number of outliers (should decrease)<br />
*{{p|throughput}}—running average of completed items per time period (week, month, quarter, year); as team speeds up, trend should follow upwards;<br />
*{{p|happiness index}}—drives speed improvements; higher is better; trend should be upwards;<br />
*{{p|due date performance}}:<br />
**For the most recent month and for the year to date;<br />
**Optional year-on-year (or 12 months ago);<br />
*{{p|flow efficiency}}:<br />
**sum of work time divided by sum of waiting time for all items<br />
**good indicator of the waste in the system;<br />
*{{p|defect rate}} (a.k.a. bugs):<br />
**Defects represent opportunity cost and affect the lead time and throughput of the system.<br />
**Report the number of escaped defects as a percentage against the total WIP and throughput.<br />
**Keeping the number of bugs between 0 and 20 is a good policy for most projects.<br />
**Key questions:<br />
***Why is the number of new defects increasing? Did you relax some QA policies?<br />
***How did the high level of bugs in week 20 affect cycle time?<br />
***What was the impact on the cumulative flow diagram when the number of bugs increased?<br />
***Over time, work to make the defect rate fall to close to zero.<br />
***less is better;<br />
***trend should be downwards;<br />
*{{p|blocked items}}:<br />
**Blocked items have serious long term effects on the systems.<br />
**A team’s ability to quickly solve issues says a lot about the team’s performance and effectiveness.<br />
**Blocked items should always be visible on the board.<br />
**Tracking the status over time is usually a good way of knowing whether the team is moving in the right direction.<br />
**less blockers is better; downward trend;<br />
*{{p|failure load}}:<br />
**Failure Load (amount of rework) is a good indicator that you are improving as a whole organization and thinking at a system level.<br />
**Failure load tracks how many work items you process because of earlier poor quality—how many work items are production defects or new features that have been requested through your customer-service organization because of poor usability or a failure to anticipate user needs properly. <br />
**Ideally, Failure Load should fall over time. <br />
**less rework is better; downward trend preferred;<br />
<br />
The {{p|operations review}} is a monthly feedback loop for a number of these metrics.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://productcraft.com/perspectives/not-all-metrics-have-to-be-actionable-gasp/<br />
|site=Product Craft<br />
|person=René Rosendahl<br />
|title=Not All Metrics Have to Be Actionable (Gasp!)<br />
|kind=Tweet<br />
}}<br />
{{WebSourceListItem<br />
|url=https://t.co/O3XrQNe6nd<br />
|site=Twitter<br />
|person=Omer van Kloeten<br />
|title=Quantifying Quality<br />
|kind=Tweet<br />
}}<br />
{{WebSourceListItem<br />
|url=http://focusedobjective.com/wp-content/uploads/2014/09/The-Economic-Impact-of-Software-Development-Process-Choice-Cycle-time-Analysis-and-Monte-Carlo-Simulation-Results.pdf<br />
|site=Focused Objective<br />
|person=Troy Magennis<br />
|title=The Economic Impact of Software Development Process Choice—Cycle-time Analysis and Monte Carlo Simulation Results<br />
|kind=PDF<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.slideshare.net/FocusedObjective/agile-2014-software-moneyball-troy-magennis<br />
|site=SlideShare<br />
|person=Troy Magennis<br />
|title=Agile 2014 Software Moneyball<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/10/scrum-metrics-for-hyperproductive-teams.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Scrum Metrics for Hyperproductive Teams<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/11/happiness-metric-wave-of-future.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Happiness Metric - The Wave of the Future<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dl.dropbox.com/u/33524813/LeanRiskManagement%20(Anderson%20Key%20Note).pptx<br />
|site=Dropbox<br />
|person=David J. Anderson<br />
|title=Lean Risk Management—Options, Liquidity & Hedging Risk using Kanban Systems<br />
}}, about Liquidity, WIP, Lead Time, Cycle Time, Process Efficiency.<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/not-destroy-team-metrics<br />
|site=InfoQ<br />
|person=Sean McHugh<br />
|title=How To Not Destroy your Agile Team with Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.sixsigmatraining.org/introduction-to-six-sigma/gaming-the-metrics.html<br />
|site=Pyzdek Institute<br />
|person=Thomas Pyzdek<br />
|title=Gaming the Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://leadinganswers.typepad.com/leading_answers/2010/02/smart-metrics-slides.html<br />
|site=Leading Answers<br />
|person=Mike Griffiths<br />
|title=Smart Metrics Slides<br />
}}<br />
{{WebSourceListItem<br />
|url=http://martinfowler.com/articles/useOfMetrics.html<br />
|site=Martin Fowler<br />
|person=Martin Fowler<br />
|title=An Appropriate Use of Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://theitriskmanager.wordpress.com/2013/12/07/outcome-based-process-metrics-a-focus-on-time-to-value/<br />
|site=The Risk Manager<br />
|person=Chris Matts<br />
|title=Outcome based Process Metrics—A focus on Time to Value<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.agilealliance.org/files/8213/9819/0015/ActionableMetricsAtSiemensHealthServices.pdf<br />
|site=Agile Alliance<br />
|person=Daniel Vacanti, Bennet Vallet<br />
|title=Actionable Metrics at Siemens Health Services<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2016/04/numbers-and-the-magic-of-measuring-the-right-thing.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Numbers (and the magic of measuring the right thing)<br />
}}<br />
<br />
*http://www.slideshare.net/JuliaWester/metrics-and-coaching<br />
*https://mattphilip.wordpress.com/2015/01/12/improvement-metrics/</div>Martienhttp://pearllanguage.org/index.php?title=Wardley_map&diff=3016Wardley map2019-10-25T11:18:53Z<p>Martien: New link to video</p>
<hr />
<div>{{Oyster<br />
|goal=Make the right decisions on where and when to invest.<br />
|stage=Sparkle<br />
|context=a complex organisation in a complex, ever-evolving world.<br />
|wish=Picking the right investments and decide what to make, buy or outsource is a winning strategy.<br />
|so=Base your choices on a map that plots the value visibility against its evolutionary position.<br />
|image=Wardley-Map-Uber-Example.jpg{{!}}1152px<br />
|wish full=Picking the right investments and decide what to make, buy or outsource is a winning strategy.<br />
|background=There's no one-size-fits-all approach to business. Strategic frameworks can often be limiting, and what has worked well for one company may signal the beginning of the end for another. Avoid {{wikipedia|en|cargo cult}}.<br />
<br />
:[https://youtu.be/Gfq3ocmadZo iluli » Mike Lamb » Investing in innovation - How situational awareness can put your business on the map]<br />
|therefore full=Base your choices on a map that plots the value visibility against its evolutionary position.<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Planguage&diff=3015Planguage2019-09-06T11:19:30Z<p>Martien: -= result-planning.com</p>
<hr />
<div>{{author|Tom Gilb}} and [[author|Kai Gilb]]'s {{p|planguage}} allow you to express requirements is a precise, concise, coherent and complete way.<br />
<br />
==Sources==<br />
*http://www.methodsandtools.com/archive/archive.php?id=58<br />
*http://gilb.com/<br />
<br />
{{tag|quality}}</div>Martienhttp://pearllanguage.org/index.php?title=Planguage&diff=3014Planguage2019-09-06T11:18:45Z<p>Martien: -= clearspecs</p>
<hr />
<div>{{author|Tom Gilb}} and [[author|Kai Gilb]]'s {{p|planguage}} allow you to express requirements is a precise, concise, coherent and complete way.<br />
<br />
==Sources==<br />
*http://www.methodsandtools.com/archive/archive.php?id=58<br />
*http://www.result-planning.com/tiki-download_file.php?fileId=39<br />
*http://gilb.com/<br />
<br />
{{tag|quality}}</div>Martienhttp://pearllanguage.org/index.php?title=OKR&diff=3013OKR2019-09-01T13:16:33Z<p>Martien: += {{quote|The greater danger for most of us lies not in setting our aim too high and falling short, but in setting our aims too low and achieving our mark.|Michelangelo}}</p>
<hr />
<div>{{Oyster<br />
|goal=keep everyone moving forward as a team—aligned autonomy<br />
|stage=Sparkle<br />
|context=culture, productivity and alignment all in flux.<br />
|wish=Keep everyone moving forward as an aligned and autonomous team.<br />
|so=Co-create and publish objectives and key results on all levels in your organization.<br />
|image=OKR Best Practices.png{{!}}600px<br />
|prologue=To achieve great things, two things are needed: a plan and not quite enough time. —Leonard Bernstein<br />
|wish full=Keep everyone moving forward as a team in a world where culture, productivity and alignment are all in flux.<br />
|background={{quote|The greater danger for most of us lies not in setting our aim too high and falling short, but in setting our aims too low and achieving our mark.|Michelangelo}}<br />
<br />
==Forces==<br />
*{{p|metrics drive behavior}}<br />
*People hate corporate acronyms that mandate work more than just corporate acronyms.<br />
*Multiple teams often depend on one another to succeed.<br />
*No one person knows everything going on inside the organization.<br />
*Personal objectives that are directly and clearly connected to the broader goals of the company are more inspiring and imaginative.<br />
*Public information that everyone can see help make you feel you are toiling in a thriving environment with your manager’s approval.<br />
*Public goals and clear results:<br />
**encourage people to ask for resources; and<br />
**easily spot where you can support your colleagues;<br />
**force different types of thinking around how people ask for help from others and helps amplifying this type of dialog.<br />
*Airing things out releases anxiety and let’s people get creative—that’s when interesting things happen.<br />
*Stretched goals:<br />
**help you to be ambitious enough the push you beyond your limits; and<br />
**focuses conversations about what is truly needed to beat expectations;<br />
**encourages to {{p|question everything}}; and<br />
**forces {{p|questions that matter}} like:<br />
***“I’d have to completely solve this hard problem”; or<br />
***“I need to completely rethink how I’m addressing X or Y.”<br />
*Having clear objectives, especially those tied to developing your skills, are a key part of career development.<br />
*People love hitting their marks.<br />
*Key results that are always tied to money block seeing other, diverse objectives in the mix—it will make people play safe rather than being ambitious and entrepreneurial.<br />
*Regular updates and reviews of objectives and key results spur increased dialogue between employees, co-workers, managers, and leadership and allows recognition to be spread out over time, which tends to be more rewarding.<br />
*Self-inflicted objectives and goals are much more powerful than top-down goals dictated from higher organizational levels.<br />
<br />
{{okrs}}:<br />
*serve as a layer of communication that holds the company together;<br />
*are designed for accountability;<br />
*are enforced with scores;<br />
*elevates its game;<br />
*can become a part of the culture;<br />
*use the following structure:<br />
**high level objective;<br />
**a more detailed description of why that objective is important—a summary of how the objective aligns with the broader goals of both the person’s team and the company; and<br />
**three to five key results that will help them achieve that goal.<br />
*track results on a quantitative basis—key results are not general or subjective actions you plan to take, and should always include numbers to make it clear how much has been achieved. For example, if Mary’s objective is to improve her sales prospecting skills, one key result might be to spend two hours a week shadowing Jennifer, the team member who demonstrates the most prospecting success;<br />
*are something for people look at, every quarter, every week, every day—consistently setting goals turns goal-setting into a habit and changes how people think about their work and approach their everyday to-dos; it puts in place natural milestones that make you think about what you need to do next and aim high;<br />
*are stretched goals in order to be effective—achieving 70% of your goals is just about perfect for {{okrs}}—if you achieve 100% of your goals, you’re not trying hard enough (cf. Sun Tzu: bow tension);<br />
*are a tool for motivating and aligning people to work together by increasing transparency, accountability and empowerment;<br />
*make it easier than ever to keep people focused and collect feedback, inside and outside management meetings;<br />
*facilitate continual coaching of yourself and others and develops your whole ecosystem;<br />
|therefore full=Encourage people to spend time defining their own {{okrs}} and then to meet specifically with their managers to incorporate their feedback. Spend your time defining {{okrs}}, not measuring them. Look at {{okrs}} as a way to communicate so there’s clarity about the {{p|unity of purpose}}. Tweak and tune your {{okrs}} to be more about collaboration and less about action items. Publish them for everyone to see (next to your {{p|flow board}}. Figure out how to put {{okrs}} work best for you. ‘Retroprospect’ your {{okrs}} with a {{p|season beat}} and make it a part of your {{p|operations review}}. Hold people publicly accountable for failing to regularly update their {{okrs}}. Have 60% of your {{okrs}} defined by employees, not leadership.<br />
|new=Consider creating an {{p|impact map}} to discover and express the right {{okrs}}.<br />
<br />
Grading should be a simple exercise at every {{p|season beat}}, five minutes tops. Score an objective by averaging the individual key result scores underneath it. This is also why it’s so important to make those key results quantitatively measurable.<br />
<br />
'''Warning'''<br />
*Do not mix {{okrs}} and performance reviews; do not use it as a weapon against your employees in performance reviews.<br />
}}<br />
==Typical Progress Meeting==<br />
*Ask people to share their quick wins—one or two notable things they or their team has achieved since last time.<br />
*Ask people what progress has been made agains their {{okrs}}: <br />
**What are the areas that are still keeping you up at night?<br />
**Where do you need help?'<br />
**Everyone shares one or two things that are causing them the biggest concerns about hitting their {{okrs}}<br />
*Have the major concerns guides the meeting’s conversation in the right direction—because they’re always focused on removing roadblocks, they always feel like time well spent.<br />
<br />
Smashing Magazine:<br />
:Schedule deadlines as specific tasks, not the ends of phases. Rather than “Content will be completed by 4 April 2010,” state “Review the content over lunch on 4 April 2010.” This ties the deadline to an event at which results must be shown. Mini-deadlines tied to specific events are more powerful than general statements.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://felipecastro.com/en/blog/book-review-measure-what-matters/<br />
|site=Felipe Castro<br />
|title=Measure What Really Matters<br />
|about=Good, bad and ugly of the book with the same title<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@mcleanonline/4-key-lessons-ive-learned-about-okrs-3f4b902ae9f8<br />
|site=Medium<br />
|person=Richard McLean<br />
|title=4 key lessons I’ve learned about OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hackernoon.com/beyond-outcomes-over-outputs-6b2677044214<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Beyond “Outcomes Over Outputs”<br />
}}<br />
{{WebSourceListItem<br />
|url=https://hbr.org/2018/05/how-vc-john-doerr-sets-and-achieves-goals<br />
|site=HBR<br />
|person=Daniel McGinn<br />
|title=How VC John Doerr Sets (and Achieves) Goals<br />
}}<br />
{{WebSourceListItem<br />
|url=https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/<br />
|site=re:Work<br />
|title=Guide: Set goals with OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=http://felipecastro.com/en/okr-tools/<br />
|site=Filipe Castro<br />
|title=OKR Tools<br />
}}<br />
{{WebSourceListItem<br />
|url=http://eleganthack.com/the-art-of-the-okr/<br />
|site=Eleganthack<br />
|title=The Art of the OKR<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/untangling-okrs-with-a-big-visual-board-6153afa12213<br />
|site=Medium<br />
|person=John Cutler<br />
|title=Untangling OKRs with a Big, Visual Board<br />
}}<br />
{{WebSourceListItem<br />
|url=http://okrexamples.co/company-okr-examples<br />
|site=OKR Examples<br />
|title=Company OKR Examples<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/@johnpcutler/18-things-your-okrs-shouldnt-do-23c8b57a455f<br />
|site=Medium<br />
|person=John Cutler<br />
|title=18 Things Your OKRs Shouldn’t Do…<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dannorth.net/2017/05/01/applying-okrs/<br />
|site=Dan North & Associates<br />
|person=Dan North<br />
|title=Applying OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://medium.com/startup-tools/okrs-5afdc298bc28<br />
|site=Medium<br />
|person=@niket<br />
|title=The Fundamentals » OKRs<br />
}}<br />
{{WebSourceListItem<br />
|url=https://docs.google.com/document/d/1OHpQOvZz76_10ebJP2AKvvXUF3H9yd6FC89F5jS4mks<br />
|site=Google Docs<br />
|person=@niket<br />
|title=Startup OKRs Template<br />
}}<br />
{{WebSourceListItem<br />
|url=http://firstround.com/review/How-to-Make-OKRs-Actually-Work-at-Your-Startup/<br />
|site=First Round<br />
|title=How to Make OKRs Actually Work at Your Startup<br />
}}<br />
{{WebSourceListItem<br />
|url=https://blog.weekdone.com/introduction-okr-objectives-key-results/<br />
|site=Weekdone<br />
|person=Jüri Kaljundi<br />
|title=Introduction to OKR – Objectives and Key Results<br />
}}<br />
{{WebSourceListItem<br />
|url=https://www.perdoo.com/blog/okr-vs-kpi/<br />
|site=Perdoo<br />
|person=Henrik-Jan van der Pol<br />
|title=OKR vs. KPI: How they compare and how they work together<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Metric_drives_behavior&diff=3012Metric drives behavior2019-08-11T14:01:39Z<p>Martien: /* Sources */ += Omer van Kloeten » Quantifying Quality</p>
<hr />
<div>{{tag|excellence}}<br />
----<br />
'''[https://seths.blog/2019/06/any-metric-you-can-buy-your-way-out-of/ Any metric you can buy your way out of…]'''<br />
<br />
Is probably not a useful metric to measure yourself by.<br />
<br />
If it’s important and you can spend money to fix it, by all means, go do that.<br />
<br />
But the helpful metrics are the ones where cash isn’t the solution.<br />
<br />
—Seth Godin<br />
----<br />
Metrics for team coaching. Always be thinking:<br />
#If we improve this, what might we degrade?<br />
#Improvement takes time, how will we know when impact begins.<br />
#How much good for this metric is enough or too much, what signs do we look for?<br />
:—Troy Magennis<br />
<br />
The first things I'd check to diagnose bad quality:<br />
#how much work in progress<br />
#what % of the tasks have deadlines<br />
#how big the tasks are; and <br />
#are there any hand-offs.<br />
From my experience, nothing hurts quality more than those four. —Dimitri Kraivanov<br />
<br />
5 Basic Metric Rules:<br />
#Respect individual safety.<br />
#Show trends.<br />
#Compare data in context.<br />
#Highlight the unusual.<br />
#Balance the focus—the four balancing pillars are usually:<br />
##Quality<br />
##Productivity<br />
##Predictability, and<br />
##Responsiveness. <br />
(@t_magennis @elabor8)<br />
<br />
<br />
Metrics are not a yard-stick to control and manage people but serve to bring transparency to the teams.<br />
<br />
[https://www.bbc.co.uk/news/amp/business-41291483 Ryanair to cancel 40-50 flights per day for six weeks] to meet their “punctuality” metric, rather than focusing on customer’s {{p|fitness for purpose}} criterion '''on-time arrival''' metric. Ryanair noticed that punctuality—a vanity metric—had fallen below 80% and that cancelling less than 2% of its flights—affecting up to 285,000 passengers—would help it hit its annual punctuality target of 90%.<br />
<br />
'''To do''': Add quotes on behavior and control from ''{{p|don’t just do something, stand there!}}''<br />
{{quote|Good metrics are enlightening and help us make better decisions.|Scott Ambler}}<br />
{{quote|The most powerful statement managers can make about what is important in the organisation lies in what they choose to measure.|John Seddon}}<br />
{{quote|It is difficult to detect improvements or reductions in productivity because we feel busy regardless of our output. That’s why measurement is important.|Kanban}}<br />
{{quote|Measurements aren't about achieving certainty. They are about reducing uncertainty|@AgileSteveSmith}}<br />
{{quote|The purpose of measurements is to motivate the parts to do what is good for the organization as a whole.|Eli Goldratt}}<br />
{{quote|Every metric is a vanity metric if you are not using it to drive behavior.|Bill Sesko}}<br />
{{quote|Metrics are people, too.|Eric Ries}}<br />
{{quote|It’s better to be roughly right than precisely wrong|Maynard Keynes}}<br />
{{quote|Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.|Albert Einstein}}<br />
{{quote|What gets measured is what gets done.|unknown}}<br />
{{quote|You can game any metric.|unknown}}<br />
{{quote|Don't measure anything unless the data helps you make a better decision or change your actions.|Seth Godin}}, via {{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
{{quote|If you're not prepared to change your diet or your workouts, don't get on the scale.|Seth Godin}}, via <br />
{{quote|Even noisy data is better than no data.|David J. Anderson}}<br />
{{quote|Data always trumps opinion.|David J. Anderson}}<br />
{{quote|Without data, assumptions fill the void.|Julia Wester}}<br />
{{quote|When benefits are not quantified at all, assume there aren’t any.|Tom DeMarco}}<br />
{{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
<br />
Meten leidt tot weten(?!). To measure leads to knowledge.<br />
<br />
From {{book|The Lean Startup|Eric Ries}}: Actionable Metrics are<br />
#Actionable<br />
#Accessible<br />
#Auditable<br />
<br />
Use '''behaviour-driven metrics'''—metrics that deal with people and their actions with the system, e.g.<br />
*downloading the product;<br />
*login into the product;<br />
*posting and sharing a picture; and<br />
*commenting on a picture.<br />
Sounds like {{p|user stories}}.<br />
<br />
Use {{usage|actionable behavioural metrics one-pager}} throughout the organization.<br />
<br />
'''METRICS''':<br />
:'''M'''easure '''E'''verything '''T'''hat '''R'''esults '''I'''n '''C'''ustomer '''S'''atisfaction<br />
<br />
Have a look at {{p|pirate metrics}}.<br />
<br />
In other words, '''metrics drive behavior''', possibly related to the [http://en.wikipedia.org/wiki/Observer_effect_(physics) Observer Effect].<br />
<br />
Therefore:<br />
*Secure that all metrics lead to customer delight and value creation, potentially boosting the {{p|net promoter score}}, either, directly or indirectly.<br />
*Pick and design your metrics with great care as they drive human behavior, and therefore that of the organization.<br />
*Use metrics to guide improvements that accelerate the organization or ecosystem as a whole, not to measure activities of people. This is, pick metrics that {{p|optimize the whole}} on multiple levels of scale or granularity, e.g. {{p|epic}}, {{p|feature}}, and {{p|story}} level.<br />
*Limit metrics to numbers that quantify a certain outcome or the quality of certain input that is key for the quality of an outcome.<br />
*Select two to three universal metrics that apply to the whole unit, division or all teams.<br />
*Use {{p|ockham's razor}} to measure only the necessary things.<br />
*Aim the metric to maximize value creation.<br />
*Capture the metric in {{p|planguage}} to quantify quality.<br />
*Keep your metric elegant, terse, to the point.<br />
<br />
The worst thing that van happen with metrics is that people start feeling beat up, which means that they will start hiding data. If the management does not understand the constraints because the teams concerns about getting beat up for not being on time, then you never know where to help or how move resources around. If teams see management as helping to move resources around and provide creative and helpful changes, the issues will be made visible early, and you can respond and adjust in reaI·time. The leads to a positive reinforcing cycle that is key to the the agile management approach. (Source: [http://www.amazon.com/Practical-Approach-Large-Scale-Agile-Development/dp/0321821726 A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)])<br />
<br />
*'''Metrics without goals are naked'''—Metrics should always give you a clue on where you are regarding your goals. So, find out where you are, how you measure that, and where you want to be. Set up a metric that tracks your progress.<br />
*'''Balanced Metrics'''—Many metrics only focus on operational excellence. This creates a biased view on reality and distorts and deforms the organization as a whole. Therefore, balance metrics across the following dimensions:<br />
*#Operational Excellence<br />
*#*Velocity<br />
*#*Burn rate<br />
*#*Predictability<br />
*#*Sustainability<br />
*#*Meeting deadlines<br />
*#*Stay within budget<br />
*#*Meet quality requirements<br />
*#*Cohesive set {{p|user stories}} in a {{p|sprint}}<br />
*#User Orientation<br />
*#*Availability<br />
*#*Performance<br />
*#*User satisfaction ({{p|net promoter score}} ([[NPS]]))<br />
*#Business Value<br />
*#*Business value per € development<br />
*#*Business value realization<br />
*#Future Orientation<br />
*#*Enthusiasm and motivation<br />
*#*{{p|happiness index}}<br />
*#*Educational opportunities<br />
*#*Vision on future development<br />
*#*Innovative governance<br />
**Have participants brainstorm on metrics and put each of them in the most appropriate category. Next, pick one or two from each catagory to create balance.<br />
**Consider using {{p|planguage}} to capture metrics in a solid, comprehensive and consistent way.<br />
<br />
==Vanity Metrics==<br />
The book {{book|The Lean Startup|Eric Ries}} defines so called [[vanity metrics]].<br />
<br />
==Useful Metrics==<br />
Donald Reinertsen, author of Managing the Design Factory states that a good, useful metric is:<br />
*'''Simple'''—The ideal metrics are self-generating in the sense that they are created without extra effort in the normal course of business.<br />
*'''Relevant'''—One test of relevance is whether the metrics focus on things that are actually controllable by the people being measured. Psychologists have found that when people think that they can control something they are more motivated to control it. Measuring people on things they can not control simply causes stress, dissatisfaction, and alienation. Also, metrics must be relevant towards the end goal.<br />
*'''Leading'''—Managers like leading indicators, and prefer an imperfect forecast of the future to a perfect report on the past. It is better to measure the size of a test queue than it is to measure the processing times of individual tests because test queue size is a leading indicator of future delays in test processing. Accountants like lagging indicators that can be measured very accurately, but these point to things that have past.<br />
*'''Self-generating'''—Metrics are created without extra effort in the normal course of business, as in spin-off of daily activities.<br />
<br />
==KPIs==<br />
{{author|David J. Anderson}} on KPIs: Measure what matters to customers! All KPIs should be recognizable to your customer!<br />
'''Fit for purpose''' service delivery KPIs:<br />
*lead time;<br />
*quality;<br />
*predictability;<br />
*conformance;<br />
*safety.<br />
<br />
KPIs:<br />
*help to give direction<br />
*are meaningful for everyone<br />
*focus on trends rather than absolute numbers<br />
*focus on quality (speed will follow)<br />
*drive improvements in the way of working<br />
*challenge everyone to improve performance<br />
*are tied to a strategic objective<br />
*contribute to vision and mission<br />
*provide neutral and objective information, not judgement<br />
*flow top down and bottom up<br />
*are concrete but not a target<br />
*have at least one bound<br />
*are leading indicators<br />
*gives insight in and answers the question “Are we heading in the right direction?” at strategic (company), tactical (unit) and operational (team) level;<br />
*are reflected in the various flow state admission criteria (e.g. Definition of Ready, Definition of Done).<br />
<br />
Good KPIs are:<br />
*accessible<br />
*transparent—visibile to everyone<br />
*simple<br />
*understandable<br />
*actionable at the lowest organizational levels (team, individual)<br />
<br />
KPIs '''DO NOT'''s:<br />
*'''Do not''' use KPIs to compare teams or units;<br />
*'''Do not''' use or design KPIs to judge;<br />
*'''Do not''' create KPIs that threaten or scare people;<br />
<br />
Potential KPI trends you may want to track:<br />
*{{p|ka-ching moment}}s—every time an item is put in production a point is scored; higher is better; trend should be upwards as team speeds up, gets gelled;<br />
*{{p|average lead time distribution}}:<br />
**average time between moment item is pulled into team and ka-ching moment; shorter is better; trend should be downwards;<br />
**number of outliers (should decrease)<br />
*{{p|throughput}}—running average of completed items per time period (week, month, quarter, year); as team speeds up, trend should follow upwards;<br />
*{{p|happiness index}}—drives speed improvements; higher is better; trend should be upwards;<br />
*{{p|due date performance}}:<br />
**For the most recent month and for the year to date;<br />
**Optional year-on-year (or 12 months ago);<br />
*{{p|flow efficiency}}:<br />
**sum of work time divided by sum of waiting time for all items<br />
**good indicator of the waste in the system;<br />
*{{p|defect rate}} (a.k.a. bugs):<br />
**Defects represent opportunity cost and affect the lead time and throughput of the system.<br />
**Report the number of escaped defects as a percentage against the total WIP and throughput.<br />
**Keeping the number of bugs between 0 and 20 is a good policy for most projects.<br />
**Key questions:<br />
***Why is the number of new defects increasing? Did you relax some QA policies?<br />
***How did the high level of bugs in week 20 affect cycle time?<br />
***What was the impact on the cumulative flow diagram when the number of bugs increased?<br />
***Over time, work to make the defect rate fall to close to zero.<br />
***less is better;<br />
***trend should be downwards;<br />
*{{p|blocked items}}:<br />
**Blocked items have serious long term effects on the systems.<br />
**A team’s ability to quickly solve issues says a lot about the team’s performance and effectiveness.<br />
**Blocked items should always be visible on the board.<br />
**Tracking the status over time is usually a good way of knowing whether the team is moving in the right direction.<br />
**less blockers is better; downward trend;<br />
*{{p|failure load}}:<br />
**Failure Load (amount of rework) is a good indicator that you are improving as a whole organization and thinking at a system level.<br />
**Failure load tracks how many work items you process because of earlier poor quality—how many work items are production defects or new features that have been requested through your customer-service organization because of poor usability or a failure to anticipate user needs properly. <br />
**Ideally, Failure Load should fall over time. <br />
**less rework is better; downward trend preferred;<br />
<br />
The {{p|operations review}} is a monthly feedback loop for a number of these metrics.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=https://t.co/O3XrQNe6nd<br />
|site=Twitter<br />
|person=Omer van Kloeten<br />
|title=Quantifying Quality<br />
|kind=Tweet<br />
}}<br />
{{WebSourceListItem<br />
|url=http://focusedobjective.com/wp-content/uploads/2014/09/The-Economic-Impact-of-Software-Development-Process-Choice-Cycle-time-Analysis-and-Monte-Carlo-Simulation-Results.pdf<br />
|site=Focused Objective<br />
|person=Troy Magennis<br />
|title=The Economic Impact of Software Development Process Choice—Cycle-time Analysis and Monte Carlo Simulation Results<br />
|kind=PDF<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.slideshare.net/FocusedObjective/agile-2014-software-moneyball-troy-magennis<br />
|site=SlideShare<br />
|person=Troy Magennis<br />
|title=Agile 2014 Software Moneyball<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/10/scrum-metrics-for-hyperproductive-teams.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Scrum Metrics for Hyperproductive Teams<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/11/happiness-metric-wave-of-future.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Happiness Metric - The Wave of the Future<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dl.dropbox.com/u/33524813/LeanRiskManagement%20(Anderson%20Key%20Note).pptx<br />
|site=Dropbox<br />
|person=David J. Anderson<br />
|title=Lean Risk Management—Options, Liquidity & Hedging Risk using Kanban Systems<br />
}}, about Liquidity, WIP, Lead Time, Cycle Time, Process Efficiency.<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/not-destroy-team-metrics<br />
|site=InfoQ<br />
|person=Sean McHugh<br />
|title=How To Not Destroy your Agile Team with Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.sixsigmatraining.org/introduction-to-six-sigma/gaming-the-metrics.html<br />
|site=Pyzdek Institute<br />
|person=Thomas Pyzdek<br />
|title=Gaming the Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://leadinganswers.typepad.com/leading_answers/2010/02/smart-metrics-slides.html<br />
|site=Leading Answers<br />
|person=Mike Griffiths<br />
|title=Smart Metrics Slides<br />
}}<br />
{{WebSourceListItem<br />
|url=http://martinfowler.com/articles/useOfMetrics.html<br />
|site=Martin Fowler<br />
|person=Martin Fowler<br />
|title=An Appropriate Use of Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://theitriskmanager.wordpress.com/2013/12/07/outcome-based-process-metrics-a-focus-on-time-to-value/<br />
|site=The Risk Manager<br />
|person=Chris Matts<br />
|title=Outcome based Process Metrics—A focus on Time to Value<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.agilealliance.org/files/8213/9819/0015/ActionableMetricsAtSiemensHealthServices.pdf<br />
|site=Agile Alliance<br />
|person=Daniel Vacanti, Bennet Vallet<br />
|title=Actionable Metrics at Siemens Health Services<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2016/04/numbers-and-the-magic-of-measuring-the-right-thing.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Numbers (and the magic of measuring the right thing)<br />
}}<br />
<br />
*http://www.slideshare.net/JuliaWester/metrics-and-coaching<br />
*https://mattphilip.wordpress.com/2015/01/12/improvement-metrics/</div>Martienhttp://pearllanguage.org/index.php?title=Generative_images&diff=3011Generative images2019-07-21T08:14:33Z<p>Martien: Typo</p>
<hr />
<div>{{Oyster<br />
|goal=allure people to create openings for new, productive conversations about issues they care about<br />
|stage=Sparkle<br />
|theme=Don’t just do something<br />
|context=faced with a tough, complex challenge that people care about and you want to improve or break through.<br />
|wish=Drawing highly motivated people to explore new, unforeseen ways to break through an existing challenge brings out the best in all.<br />
|so=Attract people with an, often ambiguous and paradoxical, slogan that evokes an attractive, generative image to new, productive conversations, allowing many facets so people can leap into it into it in ways no one ever thought about before.<br />
|wish full=Drawing highly motivated people to explore new, unforeseen ways to break through an existing challenge brings out the best in all.<br />
|background=Compelling vision can lead:<br />
*people towards it; and<br />
*to big bets.<br />
<br />
Most visions create the illusion of certainty and fail.<br />
<br />
Compelling—to call on something people '''care''' about.<br />
<br />
{{quote|The task is not so much to see what no one has yet seen; but to think what nobody has yet thought, about that which everybody sees.|Erwin Schrödinger}}<br />
<br />
Donald Schön: “problem-setting”, how a problem gets initially defined, is more important than problem-solving to the creation of good policies. Decision-makers ought to think metaphorically about issues they face, and that they in fact already do, and that the images often rest upon tacit and pervasive common rhetoric—'''generative metaphors'''.<br />
<br />
{{p|generative images}} are:<br />
*'''fresh'''—unusual combination of words in this group, organisation, context;<br />
**may work in one context, may fail in another;<br />
**can often be found when ‘either/or’ is replaced by ‘both/and’:<br />
***“decentralised centralisation”;<br />
***“generalisation specialist”;<br />
*'''attractive'''—appealingly point to issues and/or futures people care about;<br />
*'''energetic'''—create openings for new, productive conversations; people want to come to these conversations;<br />
*'''generative'''—ambiguous, paradoxical slogans to allow people to imagine many different alternatives for action; has so many facets, people can leap into it in ways no one ever thought about it before; totally unique thoughts;<br />
*'''compelling'''—people care about it, feel the urge to contribute, act, take the lead.<br />
<br />
Examples of {{p|generative images}}:<br />
*'''sustainable development'''—brought environmentalists and business people together; generative image in many contexts, almost universal; still glows;<br />
*'''decentralised centralisation''';<br />
*'''exceptional customer arrival experiences''', rather than, “How do we get airline employees to identify and act on innovations that will make is stand out from our competitors?” —British Airways;<br />
**much more meaningful for frontline workers, bagage handling, on the planes, people handling tickets, etc.<br />
*'''stress free customer services''', rather than, “How do we get unionised employees from all parts of the supply chain to generate and act on ideas for increasing standardisation of work processes?”; boring!; they failed standardising for years; <br />
*'''uncompromised personal service'''—hotel chain<br />
|therefore full=Attract people with an, often ambiguous and paradoxical, slogan that evokes an attractive, generative image to new, productive conversations, allowing many facets so people can leap into it into it in ways no one ever thought about before.<br />
}}<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=http://media.aicommunity.net/2015/11/Generative-Image-by-Gervaise-Bushe-and-Jacob-Storch.pdf<br />
|site=European Appreciative Inquirey Community<br />
|person=Gervase R. Bushe, Jacob Storch<br />
|title=Generative Image: Sourcing Novelty<br />
}}<br />
{{WebSourceListItem<br />
|url=https://youtu.be/ukJBbjYo4ME<br />
|site=YouTube<br />
|person=Gervase Bushe<br />
|title=Generative Images<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Generative_images&diff=3010Generative images2019-07-20T11:47:19Z<p>Martien: Refactor</p>
<hr />
<div>{{Oyster<br />
|goal=allure people to create openings for new, productive conversations about issues they care about<br />
|stage=Sparkle<br />
|theme=Don’t just do something<br />
|context=faced with a tough, complex challenge that people care about and you want to improve of break through.<br />
|wish=Drawing highly motivated people to explore new, unforeseen ways to break through an existing challenge brings out the best in all.<br />
|so=Attract people with an, often ambiguous and paradoxical, slogan that evokes an attractive, generative image to new, productive conversations, allowing many facets so people can leap into it into it in ways no one ever thought about before.<br />
|wish full=Drawing highly motivated people to explore new, unforeseen ways to break through an existing challenge brings out the best in all.<br />
|background=Compelling vision can lead:<br />
*people towards it; and<br />
*to big bets.<br />
<br />
Most visions create the illusion of certainty and fail.<br />
<br />
Compelling—to call on something people '''care''' about.<br />
<br />
{{quote|The task is not so much to see what no one has yet seen; but to think what nobody has yet thought, about that which everybody sees.|Erwin Schrödinger}}<br />
<br />
Donald Schön: “problem-setting”, how a problem gets initially defined, is more important than problem-solving to the creation of good policies. Decision-makers ought to think metaphorically about issues they face, and that they in fact already do, and that the images often rest upon tacit and pervasive common rhetoric—'''generative metaphors'''.<br />
<br />
{{p|generative images}} are:<br />
*'''fresh'''—unusual combination of words in this group, organisation, context;<br />
**may work in one context, may fail in another;<br />
**can often be found when ‘either/or’ is replaced by ‘both/and’:<br />
***“decentralised centralisation”;<br />
***“generalisation specialist”;<br />
*'''attractive'''—appealingly point to issues and/or futures people care about;<br />
*'''energetic'''—create openings for new, productive conversations; people want to come to these conversations;<br />
*'''generative'''—ambiguous, paradoxical slogans to allow people to imagine many different alternatives for action; has so many facets, people can leap into it in ways no one ever thought about it before; totally unique thoughts;<br />
*'''compelling'''—people care about it, feel the urge to contribute, act, take the lead.<br />
<br />
Examples of {{p|generative images}}:<br />
*'''sustainable development'''—brought environmentalists and business people together; generative image in many contexts, almost universal; still glows;<br />
*'''decentralised centralisation''';<br />
*'''exceptional customer arrival experiences''', rather than, “How do we get airline employees to identify and act on innovations that will make is stand out from our competitors?” —British Airways;<br />
**much more meaningful for frontline workers, bagage handling, on the planes, people handling tickets, etc.<br />
*'''stress free customer services''', rather than, “How do we get unionised employees from all parts of the supply chain to generate and act on ideas for increasing standardisation of work processes?”; boring!; they failed standardising for years; <br />
*'''uncompromised personal service'''—hotel chain<br />
|therefore full=Attract people with an, often ambiguous and paradoxical, slogan that evokes an attractive, generative image to new, productive conversations, allowing many facets so people can leap into it into it in ways no one ever thought about before.<br />
}}<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=http://media.aicommunity.net/2015/11/Generative-Image-by-Gervaise-Bushe-and-Jacob-Storch.pdf<br />
|site=European Appreciative Inquirey Community<br />
|person=Gervase R. Bushe, Jacob Storch<br />
|title=Generative Image: Sourcing Novelty<br />
}}<br />
{{WebSourceListItem<br />
|url=https://youtu.be/ukJBbjYo4ME<br />
|site=YouTube<br />
|person=Gervase Bushe<br />
|title=Generative Images<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Generative_images&diff=3009Generative images2019-07-20T10:48:59Z<p>Martien: Sources++</p>
<hr />
<div>{{Oyster<br />
|goal=allure people to create openings for new, productive conversations about issues they care about<br />
|stage=Sparkle<br />
|theme=Don’t just do something<br />
|context=faced with a tough, complex challenge that people care about and you want to improve of break through.<br />
|wish=Drawing highly motivated people to explore new, unforeseen ways to break through an existing challenge brings out the best in all.<br />
|so=Attract people with an, often ambiguous and paradoxical, slogan that evokes an attractive, generative image to new, productive conversations, allowing many facets so people can leap into it into it in ways no one ever thought about before.<br />
|wish full=Drawing highly motivated people to explore new, unforeseen ways to break through an existing challenge brings out the best in all.<br />
|background={{quote|The task is...not so much to see what no one has yet seen; but to think what nobody has yet thought, about that which everybody sees.|Erwin Schrödinger}}<br />
<br />
Compelling vision can lead:<br />
*people towards it; and<br />
*to big bets.<br />
Most visions create the illusion of certainty and fail.<br />
Compelling—to call on something people '''care''' about.<br />
<br />
{{p|generative images}} are:<br />
*'''fresh'''—unusual combination of words in this group, organisation, context;<br />
**may work in one context, may fail in another;<br />
**can often be found when ‘either/or’ is replaced by ‘both/and’:<br />
***“decentralised centralisation”;<br />
***“generalisation specialist”;<br />
*'''attractive'''—appealingly point to issues and/or futures people care about;<br />
*'''energetic'''—create openings for new, productive conversations; people want to come to these conversations;<br />
*'''generative'''—ambiguous, paradoxical slogans to allow people to imagine many different alternatives for action; has so many facets, people can leap into it in ways no one ever thought about it before; totally unique thoughts;<br />
*'''compelling'''—people care about it, feel the urge to contribute, act, take the lead.<br />
<br />
Examples of {{p|genertative images}}:<br />
*'''sustainable development'''—brought environmentalists and business people together; generative image in many contexts, almost universal; still glows;<br />
*'''decentralised centralisation''';<br />
*'''exceptional customer arrival experiences''', rather than, “How do we get airline employees to identify and act on innovations that will make is stand out from our competitors?” —British Airways;<br />
**much more meaningful for frontline workers, bagage handling, on the planes, people handling tickets, etc.<br />
*'''stress free customer services''', rather than, “How do we get unionised employees from all parts of the supply chain to generate and act on ideas for increasing standardisation of work processes?”; boring!; they failed standardising for years; <br />
*'''uncompromised personal service'''—hotel chain<br />
<br />
Donald Schön: “problem-setting”, how a problem gets initially defined, is more important than problem-solving to the creation of good policies. Decision-makers ought to think metaphorically about issues they face, and that they in fact already do, and that the images often rest upon tacit and pervasive common rhetoric—'''generative metaphors'''.<br />
|therefore full=Attract people with an, often ambiguous and paradoxical, slogan that evokes an attractive, generative image to new, productive conversations, allowing many facets so people can leap into it into it in ways no one ever thought about before.<br />
}}<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=http://media.aicommunity.net/2015/11/Generative-Image-by-Gervaise-Bushe-and-Jacob-Storch.pdf<br />
|site=European Appreciative Inquirey Community<br />
|person=Gervase R. Bushe, Jacob Storch<br />
|title=Generative Image: Sourcing Novelty<br />
}}<br />
{{WebSourceListItem<br />
|url=https://youtu.be/ukJBbjYo4ME<br />
|site=YouTube<br />
|person=Gervase Bushe<br />
|title=Generative Images<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Generative_images&diff=3008Generative images2019-07-20T10:42:35Z<p>Martien: Zeroth version.</p>
<hr />
<div>{{Oyster<br />
|goal=allure people to create openings for new, productive conversations about issues they care about<br />
|stage=Sparkle<br />
|theme=Don’t just do something<br />
|context=faced with a tough, complex challenge that people care about and you want to improve of break through.<br />
|wish=Drawing highly motivated people to explore new, unforeseen ways to break through an existing challenge brings out the best in all.<br />
|so=Attract people with an, often ambiguous and paradoxical, slogan that evokes an attractive, generative image to new, productive conversations, allowing many facets so people can leap into it into it in ways no one ever thought about before.<br />
|wish full=Drawing highly motivated people to explore new, unforeseen ways to break through an existing challenge brings out the best in all.<br />
|background={{quote|The task is...not so much to see what no one has yet seen; but to think what nobody has yet thought, about that which everybody sees.|Erwin Schrödinger}}<br />
<br />
Compelling vision can lead:<br />
*people towards it; and<br />
*to big bets.<br />
Most visions create the illusion of certainty and fail.<br />
Compelling—to call on something people '''care''' about.<br />
<br />
{{p|generative images}} are:<br />
*'''fresh'''—unusual combination of words in this group, organisation, context;<br />
**may work in one context, may fail in another;<br />
**can often be found when ‘either/or’ is replaced by ‘both/and’:<br />
***“decentralised centralisation”;<br />
***“generalisation specialist”;<br />
*'''attractive'''—appealingly point to issues and/or futures people care about;<br />
*'''energetic'''—create openings for new, productive conversations; people want to come to these conversations;<br />
*'''generative'''—ambiguous, paradoxical slogans to allow people to imagine many different alternatives for action; has so many facets, people can leap into it in ways no one ever thought about it before; totally unique thoughts;<br />
*'''compelling'''—people care about it, feel the urge to contribute, act, take the lead.<br />
<br />
Examples of {{p|genertative images}}:<br />
*'''sustainable development'''—brought environmentalists and business people together; generative image in many contexts, almost universal; still glows;<br />
*'''decentralised centralisation''';<br />
*'''exceptional customer arrival experiences''', rather than, “How do we get airline employees to identify and act on innovations that will make is stand out from our competitors?” —British Airways;<br />
**much more meaningful for frontline workers, bagage handling, on the planes, people handling tickets, etc.<br />
*'''stress free customer services''', rather than, “How do we get unionised employees from all parts of the supply chain to generate and act on ideas for increasing standardisation of work processes?”; boring!; they failed standardising for years; <br />
*'''uncompromised personal service'''—hotel chain<br />
|therefore full=Attract people with an, often ambiguous and paradoxical, slogan that evokes an attractive, generative image to new, productive conversations, allowing many facets so people can leap into it into it in ways no one ever thought about before.<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Images_of_potential&diff=3007Images of potential2019-07-20T09:14:05Z<p>Martien: Zeroth version.</p>
<hr />
<div>{{Oyster<br />
|goal=innovatively, creatively and energetically improve the whole system<br />
|stage=Sparkle<br />
|theme=Don’t just do something<br />
|context=you have some tough and complex challenges to address and solve and have the {{p|whole system in the room}}.<br />
|wish=Energised people working on outcomes and healthy systems.<br />
|so=Ask questions like “What is the possibility here? So what? Who cares? Who is exited about the possibilities?”<br />
|wish full=Group problem solving can depress people when they focus on what’s wrong and how they can fix the problem. Energised people are more creative, outcome focused.<br />
|background=I watched Gervase Bushe's generative images video a few days ago, so I couldn't help to react to "images of potential" mentioned in this video, starting at 21:56: https://www.youtube.com/watch?v=gWpd1kRNxaQ<br />
<br />
> Ron came to an interesting conclusion, he concluded – in the mid 1950s – that group problem solving was depressing people, and he wanted to energise people. So he started experimenting with, what he called, images of potential. Instead of saying "What's wrong and how we fix it?", he began to ask the question "What is the possibility here, and who cares? Who's excited about new possibilities?"<br />
|therefore full=Ask questions like, “What is the possibility here, and who cares? Who's excited about new possibilities?”, rather than saying, “What's wrong and how we fix it?”<br />
}}<br />
https://www.youtube.com/watch?v=gWpd1kRNxaQ</div>Martienhttp://pearllanguage.org/index.php?title=Whole_system_in_the_room&diff=3006Whole system in the room2019-07-20T09:02:12Z<p>Martien: /* Six practices essential for improving whole systems */ += {{p|images of potential}}</p>
<hr />
<div>{{Oyster<br />
|goal=understand everyone’s stakes, faster decision-making, and greater personal responsibility<br />
|stage=Sparkle<br />
|theme=Jumpstart, Don’t just do something<br />
|context=you are to make an important and complex decision that affects many people across the organization.<br />
|wish=understand everyone’s stakes, faster decision-making, and greater personal responsibility<br />
|so=In each meeting, include all the relevant people who “ARE IN” .<br />
|wish full=You want to understand everyone’s stakes in order to make faster decisions and evoke greater personal responsibility.<br />
|background=Forces:<br />
*Growing aspirations for both systemic—rather than single-problem—solutions and for greater inclusion of people in using what they know.<br />
*No task is too complex if the right people can be brought in on it.<br />
*The nature of the whole cannot be understood fully by anyone unless all participate.<br />
*People cannot be expected to act responsibly without understanding the impact of what they do.<br />
*Having a “whole system” in the room opens doors no one has walked through before.<br />
<br />
Make “systems thinking” experiential rather than conceptual.<br />
|therefore full=Include all the relevant people who {{p|are in}} in each meeting.<br />
|new=When you can’t get the {{p|whole system in the room}}, the {{p|3 × 3 rule}} might be feasible. {{p|nemawashi}} can be another approach and lead or follow {{p|don’t just do something, stand there!}}.<br />
<br />
Once you’ve got the {{p|whole system in the room}}, you can explore the {{p|whole elephant}}. Make sure to {{p|relax}} while engaging.<br />
}}<br />
==Six practices essential for improving whole systems==<br />
#{{usage|are in}}—define the whole system in light of your goal and define who has formal authority? Resources? Expertise? Information? Need?<br />
#{{usage|match people to the task}}—make a note on your expected outcome (see {{p|kata}}); for each of those who {{p|are in}}, note the consequences of leaving them out.<br />
#{{usage|meeting length proportional to agenda}}—how much time do you need? Be honest. Be realistic. Rather than ‘meeting’, use words like:<br />
#*dialogue;<br />
#*action-oriented conversation; or<br />
#*gathering.<br />
#{{usage|time to express yourself}}—only then people can focus on positive experiences and energetically switch to action orientation.<br />
#{{usage|differentiate to integrate}}. You cannot integrate unless people know all the range of possibilities, so get it all out as early if you want to make progress. Think about when to as people to work alone, in small groups, or in the whole group.<br />
#{{usage|3 × 3 rule}}.<br />
#*Pick a problem or decision that involves more than one department or function.<br />
#*Get any two other functions that have a stake and/or three organization levels, preferable both. <br />
#*Pick a goal that is realistic for the time available.<br />
<br />
Also, {{usage|images of potential}}.<br />
<br />
==Sources==<br />
*{{djdsst}}<br />
*[https://youtu.be/gWpd1kRNxaQ YouTube » Marvin Weisboard » Getting the whole system in the room]</div>Martienhttp://pearllanguage.org/index.php?title=Whole_system_in_the_room&diff=3005Whole system in the room2019-07-20T08:59:59Z<p>Martien: /* Sources */ += YouTube » Marvin Weisboard » Getting the whole system in the room</p>
<hr />
<div>{{Oyster<br />
|goal=understand everyone’s stakes, faster decision-making, and greater personal responsibility<br />
|stage=Sparkle<br />
|theme=Jumpstart, Don’t just do something<br />
|context=you are to make an important and complex decision that affects many people across the organization.<br />
|wish=understand everyone’s stakes, faster decision-making, and greater personal responsibility<br />
|so=In each meeting, include all the relevant people who “ARE IN” .<br />
|wish full=You want to understand everyone’s stakes in order to make faster decisions and evoke greater personal responsibility.<br />
|background=Forces:<br />
*Growing aspirations for both systemic—rather than single-problem—solutions and for greater inclusion of people in using what they know.<br />
*No task is too complex if the right people can be brought in on it.<br />
*The nature of the whole cannot be understood fully by anyone unless all participate.<br />
*People cannot be expected to act responsibly without understanding the impact of what they do.<br />
*Having a “whole system” in the room opens doors no one has walked through before.<br />
<br />
Make “systems thinking” experiential rather than conceptual.<br />
|therefore full=Include all the relevant people who {{p|are in}} in each meeting.<br />
|new=When you can’t get the {{p|whole system in the room}}, the {{p|3 × 3 rule}} might be feasible. {{p|nemawashi}} can be another approach and lead or follow {{p|don’t just do something, stand there!}}.<br />
<br />
Once you’ve got the {{p|whole system in the room}}, you can explore the {{p|whole elephant}}. Make sure to {{p|relax}} while engaging.<br />
}}<br />
==Six practices essential for improving whole systems==<br />
#{{usage|are in}}—define the whole system in light of your goal and define who has formal authority? Resources? Expertise? Information? Need?<br />
#{{usage|match people to the task}}—make a note on your expected outcome (see {{p|kata}}); for each of those who {{p|are in}}, note the consequences of leaving them out.<br />
#{{usage|meeting length proportional to agenda}}—how much time do you need? Be honest. Be realistic. Rather than ‘meeting’, use words like:<br />
#*dialogue;<br />
#*action-oriented conversation; or<br />
#*gathering.<br />
#{{usage|time to express yourself}}—only then people can focus on positive experiences and energetically switch to action orientation.<br />
#{{usage|differentiate to integrate}}. You cannot integrate unless people know all the range of possibilities, so get it all out as early if you want to make progress. Think about when to as people to work alone, in small groups, or in the whole group.<br />
#{{usage|3 × 3 rule}}.<br />
#*Pick a problem or decision that involves more than one department or function.<br />
#*Get any two other functions that have a stake and/or three organization levels, preferable both. <br />
#*Pick a goal that is realistic for the time available.<br />
<br />
==Sources==<br />
*{{djdsst}}<br />
*[https://youtu.be/gWpd1kRNxaQ YouTube » Marvin Weisboard » Getting the whole system in the room]</div>Martienhttp://pearllanguage.org/index.php?title=Babushka_of_value&diff=3004Babushka of value2019-07-19T14:03:39Z<p>Martien: dependencies</p>
<hr />
<div>{{Oyster<br />
|goal=evolve your product as stacked layers of quality<br />
|stage=Sparkle<br />
|theme=Agile, Lean, Quality<br />
|context=product development, in the broadest sense.<br />
|wish=You want a sustainable, ever evolving flow of value creating activities.<br />
|so=Create and groom an ever evolving minimal set of quality filters in a value stream.<br />
|image=Russian Dolls.jpg<br />
|wish full=You want a sustainable, ever evolving flow of value creating activities. Flowing Products from Concept to Cash, a Value Stream Map Backbone.<br />
|background=Goals:<br />
*maximize flow<br />
*minimize transitions and boundaries—only introduce them when absolutely necessary<br />
*{{p|maximum cohesion, minimal coupling}} (and dependencies)<br />
<br />
Design Principles:<br />
*''done'' for upstream equals ''ready'' for downstream<br />
*downstream defines interface for upstream in collaboration with upstream<br />
|therefore full=Create and groom an ever evolving minimal set of quality filters in a value stream.<br />
|new=In short:<br />
:'''Fix the process, not the people'''.<br />
<br />
Each maturity level includes and transcends all previous levels, just like a babushka doll.<br />
}}<br />
[[File:Babushka_of_Value.png|thumb|link=http://pearllanguage.org/images/4/45/Babushka_of_Value.pdf]] '''PDF with example on the right.'''<br />
<br />
Forces:<br />
*{{p|flow to ready}}<br />
*{{p|sprint to done}}<br />
*''ready'' for downstream equals ''done'' for upstream<br />
<br />
Metaphore unto {{p|ready to build}} is the school system: Nursery School → Elementary School → High School → University.<br />
<br />
In the right conditions and within constraints, items develop, unfold, mature in every phase until they are ready for the next. Items ready for the ''next'' phase are ''done'' in the current.<br />
<br />
<br />
{|rules="rows"<br />
|-<br />
!<br />
!align="left"|<br />
Nursery School<br />
!align="left"|<br />
Elementary School<br />
!align="left"|<br />
Junior High School<br />
!align="left"|<br />
University<br />
!align="left"|<br />
Ready to Poker<br />
!align="left"|<br />
Read to Build<br />
!align="left"|<br />
Ready to Ship<br />
|-<br />
!align="right" valign="top"|<br />
Policy<br />
|valign="top"|<br />
*Any input: wild ideas, brainwaves, anything.<br />
|valign="top"|<br />
*Item matches product goals, as determined by {{po}}.<br />
|valign="top"|<br />
*Item matches release goals.<br />
|valign="top"|<br />
*Item is aligned with key stakeholders on features, functions and visuals.<br />
|valign="top"|<br />
*{{dor}}, except for {{p|planning poker}}.<br />
|valign="top"|<br />
*See {{dor}}.<br />
|valign="top"|<br />
{{p|ready to ship}}, a.k.a. {{dod}}.<br />
|-<br />
!align="right" valign="top"|<br />
Activities<br />
|valign="top"|<br />
*Collect and maybe categorize input.<br />
|valign="top"|<br />
*Analysts decompose.<br />
*User Experience Expert researches context, characteristics and criteria.<br />
*Business Analyst identifies business alignment needs.<br />
|valign="top"|<br />
*Elaborate item details.<br />
*Refine acceptance criteria to almost done.<br />
*Start UE pre-work (wireframes, visual mocks, story boards).<br />
*Review legal and compliance issues.<br />
|valign="top"|<br />
*Identify candidates for Release Planning and Sprint Planning.<br />
|valign="top"|<br />
*Estimate implementation effort.<br />
*Converse and converge on significant estimation gaps.<br />
|valign="top"|<br />
*Test design.<br />
*Technical design, development and implementation.<br />
*Integration.<br />
*Architectural spikes.<br />
*Technological spikes.<br />
|valign="top"|<br />
*Hardening.<br />
*Packaging.<br />
*Publishing.<br />
|}<br />
{{Source<br />
|author={{mvs}}<br />
|coder={{mvs}}<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=User_story&diff=3003User story2019-07-02T05:22:22Z<p>Martien: += “What can I get by …?”</p>
<hr />
<div>{{Oyster<br />
|goal=be crystal clear on what who wants and why so it can be build<br />
|stage=Sparkle<br />
|theme=Agile, Lean, Scrum, Product<br />
|background={{quote|The cost of a story includes providing the capability and maintaining a healthy codebase for future work.|Martin Fowler}}<br />
<br />
{{quote|If you can't write a user story in a tweet, it's too big.|@allenholub}}<br />
<br />
Ask, “What can I get by …?” rather than “When is it going to be done?” The first opens up a world of options, the second will constrict you into a commitment (and death walk). —Troy Magennis.<br />
|therefore full=Use the {{p|story splitter}} to make all {{p|user stories}} {{p|similar-sized items}}.<br />
}}<br />
===Story Template===<br />
{|rules="rows" cellpadding="10"<br />
|-<br />
|{{SubtleCellLabel|In order to}}<br />
|'''safely buy some ice cream and quench my thirst'''<br/>''value, benefit, outcome & behavioral '''change'''''<br />
|-<br />
|{{SubtleCellLabel|when}}<br />
|'''I am in the city'''<br/>''situation, context''<br />
|-<br />
|{{SubtleCellLabel|as a}}<br />
|'''relaxed, first time tourist here''',<br/>''(qualified) role''<br />
|-<br />
|{{SubtleCellLabel|I want to}}<br />
|'''withdraw cash'''<br/>''feature as verb sentence; potential entry in user manual''<br />
|-<br />
|{{SubtleCellLabel|unlike}}<br />
|'''carrying a thick wallet loaded with cash, prone to theft, making me worried'''.<br/>''contrast with current solution''<br />
|}<br />
Different from the “As a ''role'' I want to ''function'' so that I ''value''.”<br />
<br />
==Use a formal specification language==<br />
Leslie Lamport on Distributed Systems and Precise Thinking:<br />
{{quote|The benefit of using [a formal specification language] is that it teaches you to think rigorously, to think precisely, and the important point is the precise thinking. So what you need to avoid at all costs is any language that's all syntax and no semantics.|Leslie Lamport}}<br />
<br />
==Story==<br />
===Legend===<br />
{|rules="rows" cellpadding="10"<br />
|-<br />
!align="left"|color<br />
!align="left"|meaning<br />
|-<br />
!align="left"|'''{{color|black|black}}'''<br />
|To be implemented in the current variant of the {{p|user story}}.<br />
|-<br />
!align="left"|'''{{color|red|red}}'''<br />
|Issues that must be researched and resolved before you can start with implementation.<br />
|-<br />
!align="left"|'''{{color|grey|grey}}'''<br />
|Items that will '''not''' be implemented in the current variant of the {{p|user story}} (out of scope).<br />
|}<br />
<br />
===Verb-sentences, please===<br />
When composing the title of a {{p|user story}}, use '''verb-sentences''' and active language. The verbs are the actions and activities users can do with your product. The nouns are the objects or parts that make up your product.<br />
<br />
For example:<br />
*To '''send''' a message.<br />
*To '''delete''' a message.<br />
*To '''close''' a partnership.<br />
*To '''view''' a product’s location. ''(relationship between product and location)''<br />
<br />
===Context===<br />
''Describe the context or situation in which this story shows its value at best.''<br />
<br />
===Gist===<br />
''Describe the essence, the ‘gist’ of the {{p|user story}} in its context.''<br />
<br />
{{author|Gojko Adzic}} pro tip: “In order to…” should ideally be a behavioral '''change''', not just a behaviour, so it's observable and measurable.<br />
<br />
===Ready to Build===<br />
''Describe the user’s '''adventure as a narrative''', a story, until everyone can {{p|back brief}} the story crystal clear, lucid way. In short, make sure the {{p|user story}} is {{p|ready to build}}.''<br />
<br />
===Issues===<br />
''Issues that need to be resolved before the {{p|user story}} can be declared {{p|ready to build}}. Color open issues '''{{color|red|red}}'''. Color them '''{{color|black|black}}''' when resolved.''<br />
For example:<br />
*{{color|red|How many daily withdrawals are allowed?}}<br />
*What is the maximum amount someone can withdraw and on what does it depend?<br />
**Maximum '''daily''' withdrawal amount is minimum(''account balance'', ''credit limit'', ''cash in ATM'').<br />
*{{color|grey|Offer a loan when the withdrawal amount exceeds the account balance}}.<br />
<br />
===To do===<br />
''Describe what needs to be done to get (a path through) the story {{p|ready to build}}, especially to split them into {{p|similar-sized items}}.'' Consider using {{p|gherkin}} as a formal language to do so. Remember, the goal of a {{p|story}} is to have a good conversation<br />
<br />
===Seeing is believing===<br />
''Tersely describe in steps how the path through the {{p|user story}} will be demonstrated. Pay special attention to edge cases. Steps in '''{{color|grey|grey}}''' are excluded from the current revision of the story, and are used to illustrate what the complete story looks like.''<br />
<br />
===Design===<br />
''Describe the conceptual technical design of the story. Include any diagrams that clarify its implementation direction.''<br />
<br />
===Acceptance===<br />
''When appropriate, use {{p|specification by example}} and {{p|behavior-driven development}} in conduction with [[#Seeing is believing]] to obtain {{p|crystal clear acceptance criteria}}.''<br />
*See [[#Seeing is believing]].<br />
<br />
===Scope===<br />
''Explicitly specify what is in scope, and especially what is out of scope for this revision of the story.''<br />
*See [[#Seeing is believing]].<br />
====In scope====<br />
*{{color|red|To be discussed}}.<br />
====Out scope====<br />
*{{color|red|To be discussed}}.<br />
<br />
===Decisions===<br />
''List any decisions and their rationale.''<br />
*{{color|red|To be discussed}}.<br />
<br />
===Assumptions===<br />
''List any assumptions on which the story, its design and decisions is based.''<br />
*{{color|red|To be discussed}}.<br />
<br />
==Junk items==<br />
Junk can be items that are added while in a hurry. The need to be rewritten as good stories later to get them {{p|ready to build}}, but were initially just tossed into the bin so to remember. Others are things like “Upgrade Linux server” that could be rewritten as a story, but there is little benefit to do that. Also, items like that tend to be well understood and are often short-lived.<br />
<br />
A little bit of junk on your wishlist is totally fine, especially when it won’t be there long. <br />
<br />
<br />
==User out of sight==<br />
Sometimes, the functionality being described starts to get a little too distant from real users and writing user stories when real users are nowhere to be found feels artificial or even silly.<br />
<br />
Borrowing from {{p|feature driven development}}, you can write these stories remote from real users in this format:<br />
<br />
:''action'' '''the''' ''result'' ['''by'''|'''for'''|'''of'''|'''to'''] ''object''<br />
<br />
For example:<br />
*Estimate the closing price of stock<br />
*Generate a unique identifier for a transaction<br />
*Change the text displayed on a kiosk<br />
*Merge the data for duplicate transactions<br />
<br />
All verb-based sentences with at least one noun. Each noun represents an object in your system. Multiple nouns in a single sentence indicate a relationship between the objects. <br />
<br />
This can be a particularly good syntax when developing something like an Application Programming Interface (API) and object-oriented systems. It works equally well on other types of back-end functionality.<br />
<br />
==FDD==<br />
Also, check out {{p|feature driven development}}. It also uses verb-sentences and is well suited for object oriented development. See e-mail on June 2, 2015, from Mike Cohn, titled “Not Everything Needs to Be a User Story: Using FDD Features”.<br />
<br />
==Sources==<br />
<br />
*http://martinfowler.com/bliki/ConversationalStories.html<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
{{tag|story}}<br />
{{WebSourceListItem<br />
|url=http://www.betterprojects.net/2017/05/writing-better-user-stories.html<br />
|site=Better Projects<br />
|person=Craig Brown<br />
|title=Writing Better User Stories<br />
}}<br />
{{WebSourceListItem<br />
|url=http://dannorth.net/whats-in-a-story/<br />
|site=Dan North & Associates<br />
|person=Dan North<br />
|title=What’s in a story?<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.commoncraft.com/why-bathroom-sign-great-explanation<br />
|site=The Common Craft Blog<br />
|person=Lee LeFever<br />
|title=Why This Bathroom Sign Is a Great Explanation<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements<br />
|site=Mountain Goat Software<br />
|person=Mike Cohn<br />
|title=Advantages of User Stories for Requirements<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.boost.co.nz/blog/agile/user-stories/<br />
|site=Boost<br />
|title=User stories: a beginner’s guide<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.stellman-greene.com/2009/05/03/requirements-101-user-stories-vs-use-cases/<br />
|site=Stellman-Greene<br />
|person=Andrew Stellman<br />
|title=Requirements 101: User Stories vs. Use Cases<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2013/09/the-magic-of-a-spec.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=The magic of a spec<br />
|about=about the level of spec required<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blogs.hbr.org/2014/05/generating-data-on-what-customers-really-want/<br />
|site=HBR<br />
|person=Juan Pablo Vazquez Sampere<br />
|title=Generating Data on What Customers Really Want<br />
|about=about capturing {{p|a day in the life}} which in turn can be used to generate a whole bunch of {{p|user stories}} to fill a {{p|story map}}<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.mountaingoatsoftware.com/blog/4-reasons-to-include-developers-in-story-writing#When:14:00:50Z<br />
|site=Mountain Goat Software<br />
|person=Mike Cohn<br />
|title=4 Reasons to Include Developers in Story Writing<br />
}}<br />
{{WebSourceListItem<br />
|url=http://alanklement.blogspot.nl/2013/09/replacing-user-story-with-job-story.html<br />
|site=Alan Klement<br />
|person=Alan Klement<br />
|title=Focus On Causality, Skip Personas<br />
}}<br />
{{WebSourceListItem<br />
|url=http://alanklement.blogspot.nl/2013/09/replacing-user-story-with-job-story.html<br />
|site=Alan Klement<br />
|person=Alan Klement<br />
|title=Replacing The User Story With The Job Story<br />
}}<br />
{{WebSourceListItem<br />
|url=http://alanklement.blogspot.nl/2013/09/5-tips-for-writing-job-story.html<br />
|site=Alan Klement<br />
|person=Alan Klement<br />
|title=5 Tips For Writing A Job Story<br />
}}<br />
{{WebSourceListItem<br />
|url=http://insideintercom.io/the-dribbblisation-of-design/<br />
|site=Intercom<br />
|person=Paul Adams<br />
|title=The Dribbblisation Of Design<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/09/slicing-heuristic<br />
|site=InfoQ<br />
|person=Savita Pahuja<br />
|title=Empirical Measurement of Cycle Time by Slicing Heuristic<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blog.crisp.se/2014/09/25/david-evans/as-a-i-want-so-that-considered-harmful<br />
|site=Crisp<br />
|person=David Evans, Gojko Adzic<br />
|title=“As a, I want, So that” Considered Harmful<br />
|about=using more effective ways to capture a story<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/10/ser-lamport-interview<br />
|site=InfoQ<br />
|person=Sergio De Simone<br />
|title=Leslie Lamport on Distributed Systems and Precise Thinking<br />
|about=using formal language for requirements and coding<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Wardley_map&diff=3002Wardley map2019-06-30T15:43:49Z<p>Martien: ++consistency</p>
<hr />
<div>{{Oyster<br />
|goal=Make the right decisions on where and when to invest.<br />
|stage=Sparkle<br />
|context=a complex organisation in a complex, ever-evolving world.<br />
|wish=Picking the right investments and decide what to make, buy or outsource is a winning strategy.<br />
|so=Base your choices on a map that plots the value visibility against its evolutionary position.<br />
|image=Wardley-Map-Uber-Example.jpg{{!}}1152px<br />
|wish full=Picking the right investments and decide what to make, buy or outsource is a winning strategy.<br />
|background=There's no one-size-fits-all approach to business. Strategic frameworks can often be limiting, and what has worked well for one company may signal the beginning of the end for another. Avoid {{wikipedia|en|cargo cult}}.<br />
<br />
:[https://www.youtube.com/watch?v=Gfq3ocmadZo iluli » Mike Lamb » Investing in innovation - How situational awareness can put your business on the map]<br />
|therefore full=Base your choices on a map that plots the value visibility against its evolutionary position.<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Wardley_map&diff=3001Wardley map2019-06-30T15:42:46Z<p>Martien: --typos, += cargo cult</p>
<hr />
<div>{{Oyster<br />
|goal=Make the right decisions on where and when to invest.<br />
|stage=Sparkle<br />
|context=a complex organisation in a complex, ever-evolving world.<br />
|wish=Picking the right investments and decide what to make, buy or outsource is a winning strategy.<br />
|so=Base your choices on a map that plots the customer visibility again its evolutionary position.<br />
|image=Wardley-Map-Uber-Example.jpg{{!}}1152px<br />
|wish full=Picking the right investments and decide what to make, buy or outsource is a winning strategy.<br />
|background=There's no one-size-fits-all approach to business. Strategic frameworks can often be limiting, and what has worked well for one company may signal the beginning of the end for another. Avoid {{wikipedia|en|cargo cult}}.<br />
<br />
:[https://www.youtube.com/watch?v=Gfq3ocmadZo iluli » Mike Lamb » Investing in innovation - How situational awareness can put your business on the map]<br />
|therefore full=Base your choices on a map that plots the value visibility against its evolutionary position.<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Wardley_map&diff=3000Wardley map2019-06-30T15:37:22Z<p>Martien: Zeroth version.</p>
<hr />
<div>{{Oyster<br />
|goal=Make the right decisions on where and when to invest.<br />
|stage=Sparkle<br />
|context=A complex organisation in a complex, ever-evolving world.<br />
|wish=Pick the right investments and decide what to make, buy or outsource is a winning strategy.<br />
|so=Base your choices on a map that plots the customer visibility again its evolutionary position.<br />
|image=Wardley-Map-Uber-Example.jpg{{!}}1152px<br />
|wish full=Pick the right investments and decide what to make, buy or outsource is a winning strategy.<br />
|background=There's no one-size-fits-all approach to business. Strategic frameworks can often be limiting, and what has worked well for one company may signal the beginning of the end for another.<br />
<br />
:[https://www.youtube.com/watch?v=Gfq3ocmadZo iluli » Mike Lamb » Investing in innovation - How situational awareness can put your business on the map]<br />
|therefore full=Base your choices on a map that plots the customer visibility again its evolutionary position.<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=File:Wardley-Map-Uber-Example.jpg&diff=2999File:Wardley-Map-Uber-Example.jpg2019-06-30T15:33:50Z<p>Martien: </p>
<hr />
<div></div>Martienhttp://pearllanguage.org/index.php?title=Metric_drives_behavior&diff=2998Metric drives behavior2019-06-30T14:46:27Z<p>Martien: += Seth Godin » Any metric you can buy your way out of…</p>
<hr />
<div>{{tag|excellence}}<br />
----<br />
'''[https://seths.blog/2019/06/any-metric-you-can-buy-your-way-out-of/ Any metric you can buy your way out of…]'''<br />
<br />
Is probably not a useful metric to measure yourself by.<br />
<br />
If it’s important and you can spend money to fix it, by all means, go do that.<br />
<br />
But the helpful metrics are the ones where cash isn’t the solution.<br />
<br />
—Seth Godin<br />
----<br />
Metrics for team coaching. Always be thinking:<br />
#If we improve this, what might we degrade?<br />
#Improvement takes time, how will we know when impact begins.<br />
#How much good for this metric is enough or too much, what signs do we look for?<br />
:—Troy Magennis<br />
<br />
The first things I'd check to diagnose bad quality:<br />
#how much work in progress<br />
#what % of the tasks have deadlines<br />
#how big the tasks are; and <br />
#are there any hand-offs.<br />
From my experience, nothing hurts quality more than those four. —Dimitri Kraivanov<br />
<br />
5 Basic Metric Rules:<br />
#Respect individual safety.<br />
#Show trends.<br />
#Compare data in context.<br />
#Highlight the unusual.<br />
#Balance the focus—the four balancing pillars are usually:<br />
##Quality<br />
##Productivity<br />
##Predictability, and<br />
##Responsiveness. <br />
(@t_magennis @elabor8)<br />
<br />
<br />
Metrics are not a yard-stick to control and manage people but serve to bring transparency to the teams.<br />
<br />
[https://www.bbc.co.uk/news/amp/business-41291483 Ryanair to cancel 40-50 flights per day for six weeks] to meet their “punctuality” metric, rather than focusing on customer’s {{p|fitness for purpose}} criterion '''on-time arrival''' metric. Ryanair noticed that punctuality—a vanity metric—had fallen below 80% and that cancelling less than 2% of its flights—affecting up to 285,000 passengers—would help it hit its annual punctuality target of 90%.<br />
<br />
'''To do''': Add quotes on behavior and control from ''{{p|don’t just do something, stand there!}}''<br />
{{quote|Good metrics are enlightening and help us make better decisions.|Scott Ambler}}<br />
{{quote|The most powerful statement managers can make about what is important in the organisation lies in what they choose to measure.|John Seddon}}<br />
{{quote|It is difficult to detect improvements or reductions in productivity because we feel busy regardless of our output. That’s why measurement is important.|Kanban}}<br />
{{quote|Measurements aren't about achieving certainty. They are about reducing uncertainty|@AgileSteveSmith}}<br />
{{quote|The purpose of measurements is to motivate the parts to do what is good for the organization as a whole.|Eli Goldratt}}<br />
{{quote|Every metric is a vanity metric if you are not using it to drive behavior.|Bill Sesko}}<br />
{{quote|Metrics are people, too.|Eric Ries}}<br />
{{quote|It’s better to be roughly right than precisely wrong|Maynard Keynes}}<br />
{{quote|Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.|Albert Einstein}}<br />
{{quote|What gets measured is what gets done.|unknown}}<br />
{{quote|You can game any metric.|unknown}}<br />
{{quote|Don't measure anything unless the data helps you make a better decision or change your actions.|Seth Godin}}, via {{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
{{quote|If you're not prepared to change your diet or your workouts, don't get on the scale.|Seth Godin}}, via <br />
{{quote|Even noisy data is better than no data.|David J. Anderson}}<br />
{{quote|Data always trumps opinion.|David J. Anderson}}<br />
{{quote|Without data, assumptions fill the void.|Julia Wester}}<br />
{{quote|When benefits are not quantified at all, assume there aren’t any.|Tom DeMarco}}<br />
{{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
<br />
Meten leidt tot weten(?!). To measure leads to knowledge.<br />
<br />
From {{book|The Lean Startup|Eric Ries}}: Actionable Metrics are<br />
#Actionable<br />
#Accessible<br />
#Auditable<br />
<br />
Use '''behaviour-driven metrics'''—metrics that deal with people and their actions with the system, e.g.<br />
*downloading the product;<br />
*login into the product;<br />
*posting and sharing a picture; and<br />
*commenting on a picture.<br />
Sounds like {{p|user stories}}.<br />
<br />
Use {{usage|actionable behavioural metrics one-pager}} throughout the organization.<br />
<br />
'''METRICS''':<br />
:'''M'''easure '''E'''verything '''T'''hat '''R'''esults '''I'''n '''C'''ustomer '''S'''atisfaction<br />
<br />
Have a look at {{p|pirate metrics}}.<br />
<br />
In other words, '''metrics drive behavior''', possibly related to the [http://en.wikipedia.org/wiki/Observer_effect_(physics) Observer Effect].<br />
<br />
Therefore:<br />
*Secure that all metrics lead to customer delight and value creation, potentially boosting the {{p|net promoter score}}, either, directly or indirectly.<br />
*Pick and design your metrics with great care as they drive human behavior, and therefore that of the organization.<br />
*Use metrics to guide improvements that accelerate the organization or ecosystem as a whole, not to measure activities of people. This is, pick metrics that {{p|optimize the whole}} on multiple levels of scale or granularity, e.g. {{p|epic}}, {{p|feature}}, and {{p|story}} level.<br />
*Limit metrics to numbers that quantify a certain outcome or the quality of certain input that is key for the quality of an outcome.<br />
*Select two to three universal metrics that apply to the whole unit, division or all teams.<br />
*Use {{p|ockham's razor}} to measure only the necessary things.<br />
*Aim the metric to maximize value creation.<br />
*Capture the metric in {{p|planguage}} to quantify quality.<br />
*Keep your metric elegant, terse, to the point.<br />
<br />
The worst thing that van happen with metrics is that people start feeling beat up, which means that they will start hiding data. If the management does not understand the constraints because the teams concerns about getting beat up for not being on time, then you never know where to help or how move resources around. If teams see management as helping to move resources around and provide creative and helpful changes, the issues will be made visible early, and you can respond and adjust in reaI·time. The leads to a positive reinforcing cycle that is key to the the agile management approach. (Source: [http://www.amazon.com/Practical-Approach-Large-Scale-Agile-Development/dp/0321821726 A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)])<br />
<br />
*'''Metrics without goals are naked'''—Metrics should always give you a clue on where you are regarding your goals. So, find out where you are, how you measure that, and where you want to be. Set up a metric that tracks your progress.<br />
*'''Balanced Metrics'''—Many metrics only focus on operational excellence. This creates a biased view on reality and distorts and deforms the organization as a whole. Therefore, balance metrics across the following dimensions:<br />
*#Operational Excellence<br />
*#*Velocity<br />
*#*Burn rate<br />
*#*Predictability<br />
*#*Sustainability<br />
*#*Meeting deadlines<br />
*#*Stay within budget<br />
*#*Meet quality requirements<br />
*#*Cohesive set {{p|user stories}} in a {{p|sprint}}<br />
*#User Orientation<br />
*#*Availability<br />
*#*Performance<br />
*#*User satisfaction ({{p|net promoter score}} ([[NPS]]))<br />
*#Business Value<br />
*#*Business value per € development<br />
*#*Business value realization<br />
*#Future Orientation<br />
*#*Enthusiasm and motivation<br />
*#*{{p|happiness index}}<br />
*#*Educational opportunities<br />
*#*Vision on future development<br />
*#*Innovative governance<br />
**Have participants brainstorm on metrics and put each of them in the most appropriate category. Next, pick one or two from each catagory to create balance.<br />
**Consider using {{p|planguage}} to capture metrics in a solid, comprehensive and consistent way.<br />
<br />
==Vanity Metrics==<br />
The book {{book|The Lean Startup|Eric Ries}} defines so called [[vanity metrics]].<br />
<br />
==Useful Metrics==<br />
Donald Reinertsen, author of Managing the Design Factory states that a good, useful metric is:<br />
*'''Simple'''—The ideal metrics are self-generating in the sense that they are created without extra effort in the normal course of business.<br />
*'''Relevant'''—One test of relevance is whether the metrics focus on things that are actually controllable by the people being measured. Psychologists have found that when people think that they can control something they are more motivated to control it. Measuring people on things they can not control simply causes stress, dissatisfaction, and alienation. Also, metrics must be relevant towards the end goal.<br />
*'''Leading'''—Managers like leading indicators, and prefer an imperfect forecast of the future to a perfect report on the past. It is better to measure the size of a test queue than it is to measure the processing times of individual tests because test queue size is a leading indicator of future delays in test processing. Accountants like lagging indicators that can be measured very accurately, but these point to things that have past.<br />
*'''Self-generating'''—Metrics are created without extra effort in the normal course of business, as in spin-off of daily activities.<br />
<br />
==KPIs==<br />
{{author|David J. Anderson}} on KPIs: Measure what matters to customers! All KPIs should be recognizable to your customer!<br />
'''Fit for purpose''' service delivery KPIs:<br />
*lead time;<br />
*quality;<br />
*predictability;<br />
*conformance;<br />
*safety.<br />
<br />
KPIs:<br />
*help to give direction<br />
*are meaningful for everyone<br />
*focus on trends rather than absolute numbers<br />
*focus on quality (speed will follow)<br />
*drive improvements in the way of working<br />
*challenge everyone to improve performance<br />
*are tied to a strategic objective<br />
*contribute to vision and mission<br />
*provide neutral and objective information, not judgement<br />
*flow top down and bottom up<br />
*are concrete but not a target<br />
*have at least one bound<br />
*are leading indicators<br />
*gives insight in and answers the question “Are we heading in the right direction?” at strategic (company), tactical (unit) and operational (team) level;<br />
*are reflected in the various flow state admission criteria (e.g. Definition of Ready, Definition of Done).<br />
<br />
Good KPIs are:<br />
*accessible<br />
*transparent—visibile to everyone<br />
*simple<br />
*understandable<br />
*actionable at the lowest organizational levels (team, individual)<br />
<br />
KPIs '''DO NOT'''s:<br />
*'''Do not''' use KPIs to compare teams or units;<br />
*'''Do not''' use or design KPIs to judge;<br />
*'''Do not''' create KPIs that threaten or scare people;<br />
<br />
Potential KPI trends you may want to track:<br />
*{{p|ka-ching moment}}s—every time an item is put in production a point is scored; higher is better; trend should be upwards as team speeds up, gets gelled;<br />
*{{p|average lead time distribution}}:<br />
**average time between moment item is pulled into team and ka-ching moment; shorter is better; trend should be downwards;<br />
**number of outliers (should decrease)<br />
*{{p|throughput}}—running average of completed items per time period (week, month, quarter, year); as team speeds up, trend should follow upwards;<br />
*{{p|happiness index}}—drives speed improvements; higher is better; trend should be upwards;<br />
*{{p|due date performance}}:<br />
**For the most recent month and for the year to date;<br />
**Optional year-on-year (or 12 months ago);<br />
*{{p|flow efficiency}}:<br />
**sum of work time divided by sum of waiting time for all items<br />
**good indicator of the waste in the system;<br />
*{{p|defect rate}} (a.k.a. bugs):<br />
**Defects represent opportunity cost and affect the lead time and throughput of the system.<br />
**Report the number of escaped defects as a percentage against the total WIP and throughput.<br />
**Keeping the number of bugs between 0 and 20 is a good policy for most projects.<br />
**Key questions:<br />
***Why is the number of new defects increasing? Did you relax some QA policies?<br />
***How did the high level of bugs in week 20 affect cycle time?<br />
***What was the impact on the cumulative flow diagram when the number of bugs increased?<br />
***Over time, work to make the defect rate fall to close to zero.<br />
***less is better;<br />
***trend should be downwards;<br />
*{{p|blocked items}}:<br />
**Blocked items have serious long term effects on the systems.<br />
**A team’s ability to quickly solve issues says a lot about the team’s performance and effectiveness.<br />
**Blocked items should always be visible on the board.<br />
**Tracking the status over time is usually a good way of knowing whether the team is moving in the right direction.<br />
**less blockers is better; downward trend;<br />
*{{p|failure load}}:<br />
**Failure Load (amount of rework) is a good indicator that you are improving as a whole organization and thinking at a system level.<br />
**Failure load tracks how many work items you process because of earlier poor quality—how many work items are production defects or new features that have been requested through your customer-service organization because of poor usability or a failure to anticipate user needs properly. <br />
**Ideally, Failure Load should fall over time. <br />
**less rework is better; downward trend preferred;<br />
<br />
The {{p|operations review}} is a monthly feedback loop for a number of these metrics.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=http://focusedobjective.com/wp-content/uploads/2014/09/The-Economic-Impact-of-Software-Development-Process-Choice-Cycle-time-Analysis-and-Monte-Carlo-Simulation-Results.pdf<br />
|site=Focused Objective<br />
|person=Troy Magennis<br />
|title=The Economic Impact of Software Development Process Choice—Cycle-time Analysis and Monte Carlo Simulation Results<br />
|kind=PDF<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.slideshare.net/FocusedObjective/agile-2014-software-moneyball-troy-magennis<br />
|site=SlideShare<br />
|person=Troy Magennis<br />
|title=Agile 2014 Software Moneyball<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/10/scrum-metrics-for-hyperproductive-teams.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Scrum Metrics for Hyperproductive Teams<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/11/happiness-metric-wave-of-future.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Happiness Metric - The Wave of the Future<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dl.dropbox.com/u/33524813/LeanRiskManagement%20(Anderson%20Key%20Note).pptx<br />
|site=Dropbox<br />
|person=David J. Anderson<br />
|title=Lean Risk Management—Options, Liquidity & Hedging Risk using Kanban Systems<br />
}}, about Liquidity, WIP, Lead Time, Cycle Time, Process Efficiency.<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/not-destroy-team-metrics<br />
|site=InfoQ<br />
|person=Sean McHugh<br />
|title=How To Not Destroy your Agile Team with Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.sixsigmatraining.org/introduction-to-six-sigma/gaming-the-metrics.html<br />
|site=Pyzdek Institute<br />
|person=Thomas Pyzdek<br />
|title=Gaming the Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://leadinganswers.typepad.com/leading_answers/2010/02/smart-metrics-slides.html<br />
|site=Leading Answers<br />
|person=Mike Griffiths<br />
|title=Smart Metrics Slides<br />
}}<br />
{{WebSourceListItem<br />
|url=http://martinfowler.com/articles/useOfMetrics.html<br />
|site=Martin Fowler<br />
|person=Martin Fowler<br />
|title=An Appropriate Use of Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://theitriskmanager.wordpress.com/2013/12/07/outcome-based-process-metrics-a-focus-on-time-to-value/<br />
|site=The Risk Manager<br />
|person=Chris Matts<br />
|title=Outcome based Process Metrics—A focus on Time to Value<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.agilealliance.org/files/8213/9819/0015/ActionableMetricsAtSiemensHealthServices.pdf<br />
|site=Agile Alliance<br />
|person=Daniel Vacanti, Bennet Vallet<br />
|title=Actionable Metrics at Siemens Health Services<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2016/04/numbers-and-the-magic-of-measuring-the-right-thing.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Numbers (and the magic of measuring the right thing)<br />
}}<br />
<br />
*http://www.slideshare.net/JuliaWester/metrics-and-coaching<br />
*https://mattphilip.wordpress.com/2015/01/12/improvement-metrics/</div>Martienhttp://pearllanguage.org/index.php?title=User_story&diff=2997User story2019-06-30T07:31:37Z<p>Martien: /* Gist */ typo</p>
<hr />
<div>{{Oyster<br />
|goal=be crystal clear on what who wants and why so it can be build<br />
|stage=Sparkle<br />
|theme=Agile, Lean, Scrum, Product<br />
|background={{quote|The cost of a story includes providing the capability and maintaining a healthy codebase for future work.|Martin Fowler}}<br />
<br />
{{quote|If you can't write a user story in a tweet, it's too big.|@allenholub}}<br />
|therefore full=Use the {{p|story splitter}} to make all {{p|user stories}} {{p|similar-sized items}}.<br />
}}<br />
===Story Template===<br />
{|rules="rows" cellpadding="10"<br />
|-<br />
|{{SubtleCellLabel|In order to}}<br />
|'''safely buy some ice cream and quench my thirst'''<br/>''value, benefit, outcome & behavioral '''change'''''<br />
|-<br />
|{{SubtleCellLabel|when}}<br />
|'''I am in the city'''<br/>''situation, context''<br />
|-<br />
|{{SubtleCellLabel|as a}}<br />
|'''relaxed, first time tourist here''',<br/>''(qualified) role''<br />
|-<br />
|{{SubtleCellLabel|I want to}}<br />
|'''withdraw cash'''<br/>''feature as verb sentence; potential entry in user manual''<br />
|-<br />
|{{SubtleCellLabel|unlike}}<br />
|'''carrying a thick wallet loaded with cash, prone to theft, making me worried'''.<br/>''contrast with current solution''<br />
|}<br />
Different from the “As a ''role'' I want to ''function'' so that I ''value''.”<br />
<br />
==Use a formal specification language==<br />
Leslie Lamport on Distributed Systems and Precise Thinking:<br />
{{quote|The benefit of using [a formal specification language] is that it teaches you to think rigorously, to think precisely, and the important point is the precise thinking. So what you need to avoid at all costs is any language that's all syntax and no semantics.|Leslie Lamport}}<br />
<br />
==Story==<br />
===Legend===<br />
{|rules="rows" cellpadding="10"<br />
|-<br />
!align="left"|color<br />
!align="left"|meaning<br />
|-<br />
!align="left"|'''{{color|black|black}}'''<br />
|To be implemented in the current variant of the {{p|user story}}.<br />
|-<br />
!align="left"|'''{{color|red|red}}'''<br />
|Issues that must be researched and resolved before you can start with implementation.<br />
|-<br />
!align="left"|'''{{color|grey|grey}}'''<br />
|Items that will '''not''' be implemented in the current variant of the {{p|user story}} (out of scope).<br />
|}<br />
<br />
===Verb-sentences, please===<br />
When composing the title of a {{p|user story}}, use '''verb-sentences''' and active language. The verbs are the actions and activities users can do with your product. The nouns are the objects or parts that make up your product.<br />
<br />
For example:<br />
*To '''send''' a message.<br />
*To '''delete''' a message.<br />
*To '''close''' a partnership.<br />
*To '''view''' a product’s location. ''(relationship between product and location)''<br />
<br />
===Context===<br />
''Describe the context or situation in which this story shows its value at best.''<br />
<br />
===Gist===<br />
''Describe the essence, the ‘gist’ of the {{p|user story}} in its context.''<br />
<br />
{{author|Gojko Adzic}} pro tip: “In order to…” should ideally be a behavioral '''change''', not just a behaviour, so it's observable and measurable.<br />
<br />
===Ready to Build===<br />
''Describe the user’s '''adventure as a narrative''', a story, until everyone can {{p|back brief}} the story crystal clear, lucid way. In short, make sure the {{p|user story}} is {{p|ready to build}}.''<br />
<br />
===Issues===<br />
''Issues that need to be resolved before the {{p|user story}} can be declared {{p|ready to build}}. Color open issues '''{{color|red|red}}'''. Color them '''{{color|black|black}}''' when resolved.''<br />
For example:<br />
*{{color|red|How many daily withdrawals are allowed?}}<br />
*What is the maximum amount someone can withdraw and on what does it depend?<br />
**Maximum '''daily''' withdrawal amount is minimum(''account balance'', ''credit limit'', ''cash in ATM'').<br />
*{{color|grey|Offer a loan when the withdrawal amount exceeds the account balance}}.<br />
<br />
===To do===<br />
''Describe what needs to be done to get (a path through) the story {{p|ready to build}}, especially to split them into {{p|similar-sized items}}.'' Consider using {{p|gherkin}} as a formal language to do so. Remember, the goal of a {{p|story}} is to have a good conversation<br />
<br />
===Seeing is believing===<br />
''Tersely describe in steps how the path through the {{p|user story}} will be demonstrated. Pay special attention to edge cases. Steps in '''{{color|grey|grey}}''' are excluded from the current revision of the story, and are used to illustrate what the complete story looks like.''<br />
<br />
===Design===<br />
''Describe the conceptual technical design of the story. Include any diagrams that clarify its implementation direction.''<br />
<br />
===Acceptance===<br />
''When appropriate, use {{p|specification by example}} and {{p|behavior-driven development}} in conduction with [[#Seeing is believing]] to obtain {{p|crystal clear acceptance criteria}}.''<br />
*See [[#Seeing is believing]].<br />
<br />
===Scope===<br />
''Explicitly specify what is in scope, and especially what is out of scope for this revision of the story.''<br />
*See [[#Seeing is believing]].<br />
====In scope====<br />
*{{color|red|To be discussed}}.<br />
====Out scope====<br />
*{{color|red|To be discussed}}.<br />
<br />
===Decisions===<br />
''List any decisions and their rationale.''<br />
*{{color|red|To be discussed}}.<br />
<br />
===Assumptions===<br />
''List any assumptions on which the story, its design and decisions is based.''<br />
*{{color|red|To be discussed}}.<br />
<br />
==Junk items==<br />
Junk can be items that are added while in a hurry. The need to be rewritten as good stories later to get them {{p|ready to build}}, but were initially just tossed into the bin so to remember. Others are things like “Upgrade Linux server” that could be rewritten as a story, but there is little benefit to do that. Also, items like that tend to be well understood and are often short-lived.<br />
<br />
A little bit of junk on your wishlist is totally fine, especially when it won’t be there long. <br />
<br />
<br />
==User out of sight==<br />
Sometimes, the functionality being described starts to get a little too distant from real users and writing user stories when real users are nowhere to be found feels artificial or even silly.<br />
<br />
Borrowing from {{p|feature driven development}}, you can write these stories remote from real users in this format:<br />
<br />
:''action'' '''the''' ''result'' ['''by'''|'''for'''|'''of'''|'''to'''] ''object''<br />
<br />
For example:<br />
*Estimate the closing price of stock<br />
*Generate a unique identifier for a transaction<br />
*Change the text displayed on a kiosk<br />
*Merge the data for duplicate transactions<br />
<br />
All verb-based sentences with at least one noun. Each noun represents an object in your system. Multiple nouns in a single sentence indicate a relationship between the objects. <br />
<br />
This can be a particularly good syntax when developing something like an Application Programming Interface (API) and object-oriented systems. It works equally well on other types of back-end functionality.<br />
<br />
==FDD==<br />
Also, check out {{p|feature driven development}}. It also uses verb-sentences and is well suited for object oriented development. See e-mail on June 2, 2015, from Mike Cohn, titled “Not Everything Needs to Be a User Story: Using FDD Features”.<br />
<br />
==Sources==<br />
<br />
*http://martinfowler.com/bliki/ConversationalStories.html<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
{{tag|story}}<br />
{{WebSourceListItem<br />
|url=http://www.betterprojects.net/2017/05/writing-better-user-stories.html<br />
|site=Better Projects<br />
|person=Craig Brown<br />
|title=Writing Better User Stories<br />
}}<br />
{{WebSourceListItem<br />
|url=http://dannorth.net/whats-in-a-story/<br />
|site=Dan North & Associates<br />
|person=Dan North<br />
|title=What’s in a story?<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.commoncraft.com/why-bathroom-sign-great-explanation<br />
|site=The Common Craft Blog<br />
|person=Lee LeFever<br />
|title=Why This Bathroom Sign Is a Great Explanation<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements<br />
|site=Mountain Goat Software<br />
|person=Mike Cohn<br />
|title=Advantages of User Stories for Requirements<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.boost.co.nz/blog/agile/user-stories/<br />
|site=Boost<br />
|title=User stories: a beginner’s guide<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.stellman-greene.com/2009/05/03/requirements-101-user-stories-vs-use-cases/<br />
|site=Stellman-Greene<br />
|person=Andrew Stellman<br />
|title=Requirements 101: User Stories vs. Use Cases<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2013/09/the-magic-of-a-spec.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=The magic of a spec<br />
|about=about the level of spec required<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blogs.hbr.org/2014/05/generating-data-on-what-customers-really-want/<br />
|site=HBR<br />
|person=Juan Pablo Vazquez Sampere<br />
|title=Generating Data on What Customers Really Want<br />
|about=about capturing {{p|a day in the life}} which in turn can be used to generate a whole bunch of {{p|user stories}} to fill a {{p|story map}}<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.mountaingoatsoftware.com/blog/4-reasons-to-include-developers-in-story-writing#When:14:00:50Z<br />
|site=Mountain Goat Software<br />
|person=Mike Cohn<br />
|title=4 Reasons to Include Developers in Story Writing<br />
}}<br />
{{WebSourceListItem<br />
|url=http://alanklement.blogspot.nl/2013/09/replacing-user-story-with-job-story.html<br />
|site=Alan Klement<br />
|person=Alan Klement<br />
|title=Focus On Causality, Skip Personas<br />
}}<br />
{{WebSourceListItem<br />
|url=http://alanklement.blogspot.nl/2013/09/replacing-user-story-with-job-story.html<br />
|site=Alan Klement<br />
|person=Alan Klement<br />
|title=Replacing The User Story With The Job Story<br />
}}<br />
{{WebSourceListItem<br />
|url=http://alanklement.blogspot.nl/2013/09/5-tips-for-writing-job-story.html<br />
|site=Alan Klement<br />
|person=Alan Klement<br />
|title=5 Tips For Writing A Job Story<br />
}}<br />
{{WebSourceListItem<br />
|url=http://insideintercom.io/the-dribbblisation-of-design/<br />
|site=Intercom<br />
|person=Paul Adams<br />
|title=The Dribbblisation Of Design<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/09/slicing-heuristic<br />
|site=InfoQ<br />
|person=Savita Pahuja<br />
|title=Empirical Measurement of Cycle Time by Slicing Heuristic<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blog.crisp.se/2014/09/25/david-evans/as-a-i-want-so-that-considered-harmful<br />
|site=Crisp<br />
|person=David Evans, Gojko Adzic<br />
|title=“As a, I want, So that” Considered Harmful<br />
|about=using more effective ways to capture a story<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/10/ser-lamport-interview<br />
|site=InfoQ<br />
|person=Sergio De Simone<br />
|title=Leslie Lamport on Distributed Systems and Precise Thinking<br />
|about=using formal language for requirements and coding<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=User_story&diff=2996User story2019-06-30T07:29:26Z<p>Martien: += {{quote|If you can't write a user story in a tweet, it's too big.|@allenholub}}</p>
<hr />
<div>{{Oyster<br />
|goal=be crystal clear on what who wants and why so it can be build<br />
|stage=Sparkle<br />
|theme=Agile, Lean, Scrum, Product<br />
|background={{quote|The cost of a story includes providing the capability and maintaining a healthy codebase for future work.|Martin Fowler}}<br />
<br />
{{quote|If you can't write a user story in a tweet, it's too big.|@allenholub}}<br />
|therefore full=Use the {{p|story splitter}} to make all {{p|user stories}} {{p|similar-sized items}}.<br />
}}<br />
===Story Template===<br />
{|rules="rows" cellpadding="10"<br />
|-<br />
|{{SubtleCellLabel|In order to}}<br />
|'''safely buy some ice cream and quench my thirst'''<br/>''value, benefit, outcome & behavioral '''change'''''<br />
|-<br />
|{{SubtleCellLabel|when}}<br />
|'''I am in the city'''<br/>''situation, context''<br />
|-<br />
|{{SubtleCellLabel|as a}}<br />
|'''relaxed, first time tourist here''',<br/>''(qualified) role''<br />
|-<br />
|{{SubtleCellLabel|I want to}}<br />
|'''withdraw cash'''<br/>''feature as verb sentence; potential entry in user manual''<br />
|-<br />
|{{SubtleCellLabel|unlike}}<br />
|'''carrying a thick wallet loaded with cash, prone to theft, making me worried'''.<br/>''contrast with current solution''<br />
|}<br />
Different from the “As a ''role'' I want to ''function'' so that I ''value''.”<br />
<br />
==Use a formal specification language==<br />
Leslie Lamport on Distributed Systems and Precise Thinking:<br />
{{quote|The benefit of using [a formal specification language] is that it teaches you to think rigorously, to think precisely, and the important point is the precise thinking. So what you need to avoid at all costs is any language that's all syntax and no semantics.|Leslie Lamport}}<br />
<br />
==Story==<br />
===Legend===<br />
{|rules="rows" cellpadding="10"<br />
|-<br />
!align="left"|color<br />
!align="left"|meaning<br />
|-<br />
!align="left"|'''{{color|black|black}}'''<br />
|To be implemented in the current variant of the {{p|user story}}.<br />
|-<br />
!align="left"|'''{{color|red|red}}'''<br />
|Issues that must be researched and resolved before you can start with implementation.<br />
|-<br />
!align="left"|'''{{color|grey|grey}}'''<br />
|Items that will '''not''' be implemented in the current variant of the {{p|user story}} (out of scope).<br />
|}<br />
<br />
===Verb-sentences, please===<br />
When composing the title of a {{p|user story}}, use '''verb-sentences''' and active language. The verbs are the actions and activities users can do with your product. The nouns are the objects or parts that make up your product.<br />
<br />
For example:<br />
*To '''send''' a message.<br />
*To '''delete''' a message.<br />
*To '''close''' a partnership.<br />
*To '''view''' a product’s location. ''(relationship between product and location)''<br />
<br />
===Context===<br />
''Describe the context or situation in which this story shows its value at best.''<br />
<br />
===Gist===<br />
''Describe the essence, the ‘gist’ of the {{p|user story}} in its context.''<br />
<br />
{{author|Gojko Adzic}} pro tip: “In order to…” should ideally be a behavioral '''change''', not just a behaviour, so it's obserable and measurable.<br />
<br />
===Ready to Build===<br />
''Describe the user’s '''adventure as a narrative''', a story, until everyone can {{p|back brief}} the story crystal clear, lucid way. In short, make sure the {{p|user story}} is {{p|ready to build}}.''<br />
<br />
===Issues===<br />
''Issues that need to be resolved before the {{p|user story}} can be declared {{p|ready to build}}. Color open issues '''{{color|red|red}}'''. Color them '''{{color|black|black}}''' when resolved.''<br />
For example:<br />
*{{color|red|How many daily withdrawals are allowed?}}<br />
*What is the maximum amount someone can withdraw and on what does it depend?<br />
**Maximum '''daily''' withdrawal amount is minimum(''account balance'', ''credit limit'', ''cash in ATM'').<br />
*{{color|grey|Offer a loan when the withdrawal amount exceeds the account balance}}.<br />
<br />
===To do===<br />
''Describe what needs to be done to get (a path through) the story {{p|ready to build}}, especially to split them into {{p|similar-sized items}}.'' Consider using {{p|gherkin}} as a formal language to do so. Remember, the goal of a {{p|story}} is to have a good conversation<br />
<br />
===Seeing is believing===<br />
''Tersely describe in steps how the path through the {{p|user story}} will be demonstrated. Pay special attention to edge cases. Steps in '''{{color|grey|grey}}''' are excluded from the current revision of the story, and are used to illustrate what the complete story looks like.''<br />
<br />
===Design===<br />
''Describe the conceptual technical design of the story. Include any diagrams that clarify its implementation direction.''<br />
<br />
===Acceptance===<br />
''When appropriate, use {{p|specification by example}} and {{p|behavior-driven development}} in conduction with [[#Seeing is believing]] to obtain {{p|crystal clear acceptance criteria}}.''<br />
*See [[#Seeing is believing]].<br />
<br />
===Scope===<br />
''Explicitly specify what is in scope, and especially what is out of scope for this revision of the story.''<br />
*See [[#Seeing is believing]].<br />
====In scope====<br />
*{{color|red|To be discussed}}.<br />
====Out scope====<br />
*{{color|red|To be discussed}}.<br />
<br />
===Decisions===<br />
''List any decisions and their rationale.''<br />
*{{color|red|To be discussed}}.<br />
<br />
===Assumptions===<br />
''List any assumptions on which the story, its design and decisions is based.''<br />
*{{color|red|To be discussed}}.<br />
<br />
==Junk items==<br />
Junk can be items that are added while in a hurry. The need to be rewritten as good stories later to get them {{p|ready to build}}, but were initially just tossed into the bin so to remember. Others are things like “Upgrade Linux server” that could be rewritten as a story, but there is little benefit to do that. Also, items like that tend to be well understood and are often short-lived.<br />
<br />
A little bit of junk on your wishlist is totally fine, especially when it won’t be there long. <br />
<br />
<br />
==User out of sight==<br />
Sometimes, the functionality being described starts to get a little too distant from real users and writing user stories when real users are nowhere to be found feels artificial or even silly.<br />
<br />
Borrowing from {{p|feature driven development}}, you can write these stories remote from real users in this format:<br />
<br />
:''action'' '''the''' ''result'' ['''by'''|'''for'''|'''of'''|'''to'''] ''object''<br />
<br />
For example:<br />
*Estimate the closing price of stock<br />
*Generate a unique identifier for a transaction<br />
*Change the text displayed on a kiosk<br />
*Merge the data for duplicate transactions<br />
<br />
All verb-based sentences with at least one noun. Each noun represents an object in your system. Multiple nouns in a single sentence indicate a relationship between the objects. <br />
<br />
This can be a particularly good syntax when developing something like an Application Programming Interface (API) and object-oriented systems. It works equally well on other types of back-end functionality.<br />
<br />
==FDD==<br />
Also, check out {{p|feature driven development}}. It also uses verb-sentences and is well suited for object oriented development. See e-mail on June 2, 2015, from Mike Cohn, titled “Not Everything Needs to Be a User Story: Using FDD Features”.<br />
<br />
==Sources==<br />
<br />
*http://martinfowler.com/bliki/ConversationalStories.html<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
{{tag|story}}<br />
{{WebSourceListItem<br />
|url=http://www.betterprojects.net/2017/05/writing-better-user-stories.html<br />
|site=Better Projects<br />
|person=Craig Brown<br />
|title=Writing Better User Stories<br />
}}<br />
{{WebSourceListItem<br />
|url=http://dannorth.net/whats-in-a-story/<br />
|site=Dan North & Associates<br />
|person=Dan North<br />
|title=What’s in a story?<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.commoncraft.com/why-bathroom-sign-great-explanation<br />
|site=The Common Craft Blog<br />
|person=Lee LeFever<br />
|title=Why This Bathroom Sign Is a Great Explanation<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements<br />
|site=Mountain Goat Software<br />
|person=Mike Cohn<br />
|title=Advantages of User Stories for Requirements<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.boost.co.nz/blog/agile/user-stories/<br />
|site=Boost<br />
|title=User stories: a beginner’s guide<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.stellman-greene.com/2009/05/03/requirements-101-user-stories-vs-use-cases/<br />
|site=Stellman-Greene<br />
|person=Andrew Stellman<br />
|title=Requirements 101: User Stories vs. Use Cases<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2013/09/the-magic-of-a-spec.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=The magic of a spec<br />
|about=about the level of spec required<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blogs.hbr.org/2014/05/generating-data-on-what-customers-really-want/<br />
|site=HBR<br />
|person=Juan Pablo Vazquez Sampere<br />
|title=Generating Data on What Customers Really Want<br />
|about=about capturing {{p|a day in the life}} which in turn can be used to generate a whole bunch of {{p|user stories}} to fill a {{p|story map}}<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.mountaingoatsoftware.com/blog/4-reasons-to-include-developers-in-story-writing#When:14:00:50Z<br />
|site=Mountain Goat Software<br />
|person=Mike Cohn<br />
|title=4 Reasons to Include Developers in Story Writing<br />
}}<br />
{{WebSourceListItem<br />
|url=http://alanklement.blogspot.nl/2013/09/replacing-user-story-with-job-story.html<br />
|site=Alan Klement<br />
|person=Alan Klement<br />
|title=Focus On Causality, Skip Personas<br />
}}<br />
{{WebSourceListItem<br />
|url=http://alanklement.blogspot.nl/2013/09/replacing-user-story-with-job-story.html<br />
|site=Alan Klement<br />
|person=Alan Klement<br />
|title=Replacing The User Story With The Job Story<br />
}}<br />
{{WebSourceListItem<br />
|url=http://alanklement.blogspot.nl/2013/09/5-tips-for-writing-job-story.html<br />
|site=Alan Klement<br />
|person=Alan Klement<br />
|title=5 Tips For Writing A Job Story<br />
}}<br />
{{WebSourceListItem<br />
|url=http://insideintercom.io/the-dribbblisation-of-design/<br />
|site=Intercom<br />
|person=Paul Adams<br />
|title=The Dribbblisation Of Design<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/09/slicing-heuristic<br />
|site=InfoQ<br />
|person=Savita Pahuja<br />
|title=Empirical Measurement of Cycle Time by Slicing Heuristic<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blog.crisp.se/2014/09/25/david-evans/as-a-i-want-so-that-considered-harmful<br />
|site=Crisp<br />
|person=David Evans, Gojko Adzic<br />
|title=“As a, I want, So that” Considered Harmful<br />
|about=using more effective ways to capture a story<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/news/2014/10/ser-lamport-interview<br />
|site=InfoQ<br />
|person=Sergio De Simone<br />
|title=Leslie Lamport on Distributed Systems and Precise Thinking<br />
|about=using formal language for requirements and coding<br />
}}</div>Martienhttp://pearllanguage.org/index.php?title=Metric_drives_behavior&diff=2995Metric drives behavior2019-06-24T07:37:47Z<p>Martien: +Troy</p>
<hr />
<div>{{tag|excellence}}<br />
Metrics for team coaching. Always be thinking:<br />
#If we improve this, what might we degrade?<br />
#Improvement takes time, how will we know when impact begins.<br />
#How much good for this metric is enough or too much, what signs do we look for?<br />
:—Troy Magennis<br />
<br />
The first things I'd check to diagnose bad quality:<br />
#how much work in progress<br />
#what % of the tasks have deadlines<br />
#how big the tasks are; and <br />
#are there any hand-offs.<br />
From my experience, nothing hurts quality more than those four. —Dimitri Kraivanov<br />
<br />
5 Basic Metric Rules:<br />
#Respect individual safety.<br />
#Show trends.<br />
#Compare data in context.<br />
#Highlight the unusual.<br />
#Balance the focus—the four balancing pillars are usually:<br />
##Quality<br />
##Productivity<br />
##Predictability, and<br />
##Responsiveness. <br />
(@t_magennis @elabor8)<br />
<br />
<br />
Metrics are not a yard-stick to control and manage people but serve to bring transparency to the teams.<br />
<br />
[https://www.bbc.co.uk/news/amp/business-41291483 Ryanair to cancel 40-50 flights per day for six weeks] to meet their “punctuality” metric, rather than focusing on customer’s {{p|fitness for purpose}} criterion '''on-time arrival''' metric. Ryanair noticed that punctuality—a vanity metric—had fallen below 80% and that cancelling less than 2% of its flights—affecting up to 285,000 passengers—would help it hit its annual punctuality target of 90%.<br />
<br />
'''To do''': Add quotes on behavior and control from ''{{p|don’t just do something, stand there!}}''<br />
{{quote|Good metrics are enlightening and help us make better decisions.|Scott Ambler}}<br />
{{quote|The most powerful statement managers can make about what is important in the organisation lies in what they choose to measure.|John Seddon}}<br />
{{quote|It is difficult to detect improvements or reductions in productivity because we feel busy regardless of our output. That’s why measurement is important.|Kanban}}<br />
{{quote|Measurements aren't about achieving certainty. They are about reducing uncertainty|@AgileSteveSmith}}<br />
{{quote|The purpose of measurements is to motivate the parts to do what is good for the organization as a whole.|Eli Goldratt}}<br />
{{quote|Every metric is a vanity metric if you are not using it to drive behavior.|Bill Sesko}}<br />
{{quote|Metrics are people, too.|Eric Ries}}<br />
{{quote|It’s better to be roughly right than precisely wrong|Maynard Keynes}}<br />
{{quote|Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.|Albert Einstein}}<br />
{{quote|What gets measured is what gets done.|unknown}}<br />
{{quote|You can game any metric.|unknown}}<br />
{{quote|Don't measure anything unless the data helps you make a better decision or change your actions.|Seth Godin}}, via {{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
{{quote|If you're not prepared to change your diet or your workouts, don't get on the scale.|Seth Godin}}, via <br />
{{quote|Even noisy data is better than no data.|David J. Anderson}}<br />
{{quote|Data always trumps opinion.|David J. Anderson}}<br />
{{quote|Without data, assumptions fill the void.|Julia Wester}}<br />
{{quote|When benefits are not quantified at all, assume there aren’t any.|Tom DeMarco}}<br />
{{web|url=http://sethgodin.typepad.com/seths_blog/2014/08/analytics-without-action.html|site=Seth Godin|title=Analytics without action}}<br />
<br />
Meten leidt tot weten(?!). To measure leads to knowledge.<br />
<br />
From {{book|The Lean Startup|Eric Ries}}: Actionable Metrics are<br />
#Actionable<br />
#Accessible<br />
#Auditable<br />
<br />
Use '''behaviour-driven metrics'''—metrics that deal with people and their actions with the system, e.g.<br />
*downloading the product;<br />
*login into the product;<br />
*posting and sharing a picture; and<br />
*commenting on a picture.<br />
Sounds like {{p|user stories}}.<br />
<br />
Use {{usage|actionable behavioural metrics one-pager}} throughout the organization.<br />
<br />
'''METRICS''':<br />
:'''M'''easure '''E'''verything '''T'''hat '''R'''esults '''I'''n '''C'''ustomer '''S'''atisfaction<br />
<br />
Have a look at {{p|pirate metrics}}.<br />
<br />
In other words, '''metrics drive behavior''', possibly related to the [http://en.wikipedia.org/wiki/Observer_effect_(physics) Observer Effect].<br />
<br />
Therefore:<br />
*Secure that all metrics lead to customer delight and value creation, potentially boosting the {{p|net promoter score}}, either, directly or indirectly.<br />
*Pick and design your metrics with great care as they drive human behavior, and therefore that of the organization.<br />
*Use metrics to guide improvements that accelerate the organization or ecosystem as a whole, not to measure activities of people. This is, pick metrics that {{p|optimize the whole}} on multiple levels of scale or granularity, e.g. {{p|epic}}, {{p|feature}}, and {{p|story}} level.<br />
*Limit metrics to numbers that quantify a certain outcome or the quality of certain input that is key for the quality of an outcome.<br />
*Select two to three universal metrics that apply to the whole unit, division or all teams.<br />
*Use {{p|ockham's razor}} to measure only the necessary things.<br />
*Aim the metric to maximize value creation.<br />
*Capture the metric in {{p|planguage}} to quantify quality.<br />
*Keep your metric elegant, terse, to the point.<br />
<br />
The worst thing that van happen with metrics is that people start feeling beat up, which means that they will start hiding data. If the management does not understand the constraints because the teams concerns about getting beat up for not being on time, then you never know where to help or how move resources around. If teams see management as helping to move resources around and provide creative and helpful changes, the issues will be made visible early, and you can respond and adjust in reaI·time. The leads to a positive reinforcing cycle that is key to the the agile management approach. (Source: [http://www.amazon.com/Practical-Approach-Large-Scale-Agile-Development/dp/0321821726 A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)])<br />
<br />
*'''Metrics without goals are naked'''—Metrics should always give you a clue on where you are regarding your goals. So, find out where you are, how you measure that, and where you want to be. Set up a metric that tracks your progress.<br />
*'''Balanced Metrics'''—Many metrics only focus on operational excellence. This creates a biased view on reality and distorts and deforms the organization as a whole. Therefore, balance metrics across the following dimensions:<br />
*#Operational Excellence<br />
*#*Velocity<br />
*#*Burn rate<br />
*#*Predictability<br />
*#*Sustainability<br />
*#*Meeting deadlines<br />
*#*Stay within budget<br />
*#*Meet quality requirements<br />
*#*Cohesive set {{p|user stories}} in a {{p|sprint}}<br />
*#User Orientation<br />
*#*Availability<br />
*#*Performance<br />
*#*User satisfaction ({{p|net promoter score}} ([[NPS]]))<br />
*#Business Value<br />
*#*Business value per € development<br />
*#*Business value realization<br />
*#Future Orientation<br />
*#*Enthusiasm and motivation<br />
*#*{{p|happiness index}}<br />
*#*Educational opportunities<br />
*#*Vision on future development<br />
*#*Innovative governance<br />
**Have participants brainstorm on metrics and put each of them in the most appropriate category. Next, pick one or two from each catagory to create balance.<br />
**Consider using {{p|planguage}} to capture metrics in a solid, comprehensive and consistent way.<br />
<br />
==Vanity Metrics==<br />
The book {{book|The Lean Startup|Eric Ries}} defines so called [[vanity metrics]].<br />
<br />
==Useful Metrics==<br />
Donald Reinertsen, author of Managing the Design Factory states that a good, useful metric is:<br />
*'''Simple'''—The ideal metrics are self-generating in the sense that they are created without extra effort in the normal course of business.<br />
*'''Relevant'''—One test of relevance is whether the metrics focus on things that are actually controllable by the people being measured. Psychologists have found that when people think that they can control something they are more motivated to control it. Measuring people on things they can not control simply causes stress, dissatisfaction, and alienation. Also, metrics must be relevant towards the end goal.<br />
*'''Leading'''—Managers like leading indicators, and prefer an imperfect forecast of the future to a perfect report on the past. It is better to measure the size of a test queue than it is to measure the processing times of individual tests because test queue size is a leading indicator of future delays in test processing. Accountants like lagging indicators that can be measured very accurately, but these point to things that have past.<br />
*'''Self-generating'''—Metrics are created without extra effort in the normal course of business, as in spin-off of daily activities.<br />
<br />
==KPIs==<br />
{{author|David J. Anderson}} on KPIs: Measure what matters to customers! All KPIs should be recognizable to your customer!<br />
'''Fit for purpose''' service delivery KPIs:<br />
*lead time;<br />
*quality;<br />
*predictability;<br />
*conformance;<br />
*safety.<br />
<br />
KPIs:<br />
*help to give direction<br />
*are meaningful for everyone<br />
*focus on trends rather than absolute numbers<br />
*focus on quality (speed will follow)<br />
*drive improvements in the way of working<br />
*challenge everyone to improve performance<br />
*are tied to a strategic objective<br />
*contribute to vision and mission<br />
*provide neutral and objective information, not judgement<br />
*flow top down and bottom up<br />
*are concrete but not a target<br />
*have at least one bound<br />
*are leading indicators<br />
*gives insight in and answers the question “Are we heading in the right direction?” at strategic (company), tactical (unit) and operational (team) level;<br />
*are reflected in the various flow state admission criteria (e.g. Definition of Ready, Definition of Done).<br />
<br />
Good KPIs are:<br />
*accessible<br />
*transparent—visibile to everyone<br />
*simple<br />
*understandable<br />
*actionable at the lowest organizational levels (team, individual)<br />
<br />
KPIs '''DO NOT'''s:<br />
*'''Do not''' use KPIs to compare teams or units;<br />
*'''Do not''' use or design KPIs to judge;<br />
*'''Do not''' create KPIs that threaten or scare people;<br />
<br />
Potential KPI trends you may want to track:<br />
*{{p|ka-ching moment}}s—every time an item is put in production a point is scored; higher is better; trend should be upwards as team speeds up, gets gelled;<br />
*{{p|average lead time distribution}}:<br />
**average time between moment item is pulled into team and ka-ching moment; shorter is better; trend should be downwards;<br />
**number of outliers (should decrease)<br />
*{{p|throughput}}—running average of completed items per time period (week, month, quarter, year); as team speeds up, trend should follow upwards;<br />
*{{p|happiness index}}—drives speed improvements; higher is better; trend should be upwards;<br />
*{{p|due date performance}}:<br />
**For the most recent month and for the year to date;<br />
**Optional year-on-year (or 12 months ago);<br />
*{{p|flow efficiency}}:<br />
**sum of work time divided by sum of waiting time for all items<br />
**good indicator of the waste in the system;<br />
*{{p|defect rate}} (a.k.a. bugs):<br />
**Defects represent opportunity cost and affect the lead time and throughput of the system.<br />
**Report the number of escaped defects as a percentage against the total WIP and throughput.<br />
**Keeping the number of bugs between 0 and 20 is a good policy for most projects.<br />
**Key questions:<br />
***Why is the number of new defects increasing? Did you relax some QA policies?<br />
***How did the high level of bugs in week 20 affect cycle time?<br />
***What was the impact on the cumulative flow diagram when the number of bugs increased?<br />
***Over time, work to make the defect rate fall to close to zero.<br />
***less is better;<br />
***trend should be downwards;<br />
*{{p|blocked items}}:<br />
**Blocked items have serious long term effects on the systems.<br />
**A team’s ability to quickly solve issues says a lot about the team’s performance and effectiveness.<br />
**Blocked items should always be visible on the board.<br />
**Tracking the status over time is usually a good way of knowing whether the team is moving in the right direction.<br />
**less blockers is better; downward trend;<br />
*{{p|failure load}}:<br />
**Failure Load (amount of rework) is a good indicator that you are improving as a whole organization and thinking at a system level.<br />
**Failure load tracks how many work items you process because of earlier poor quality—how many work items are production defects or new features that have been requested through your customer-service organization because of poor usability or a failure to anticipate user needs properly. <br />
**Ideally, Failure Load should fall over time. <br />
**less rework is better; downward trend preferred;<br />
<br />
The {{p|operations review}} is a monthly feedback loop for a number of these metrics.<br />
<br />
==Sources==<br />
{{WebSourceListItem<br />
|url=http://focusedobjective.com/wp-content/uploads/2014/09/The-Economic-Impact-of-Software-Development-Process-Choice-Cycle-time-Analysis-and-Monte-Carlo-Simulation-Results.pdf<br />
|site=Focused Objective<br />
|person=Troy Magennis<br />
|title=The Economic Impact of Software Development Process Choice—Cycle-time Analysis and Monte Carlo Simulation Results<br />
|kind=PDF<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.slideshare.net/FocusedObjective/agile-2014-software-moneyball-troy-magennis<br />
|site=SlideShare<br />
|person=Troy Magennis<br />
|title=Agile 2014 Software Moneyball<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/10/scrum-metrics-for-hyperproductive-teams.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Scrum Metrics for Hyperproductive Teams<br />
}}<br />
{{WebSourceListItem<br />
|url=http://scrum.jeffsutherland.com/2010/11/happiness-metric-wave-of-future.html<br />
|site=Scrum Log Jeff Sutherland<br />
|person=Jeff Sutherland<br />
|title=Happiness Metric - The Wave of the Future<br />
}}<br />
{{WebSourceListItem<br />
|url=https://dl.dropbox.com/u/33524813/LeanRiskManagement%20(Anderson%20Key%20Note).pptx<br />
|site=Dropbox<br />
|person=David J. Anderson<br />
|title=Lean Risk Management—Options, Liquidity & Hedging Risk using Kanban Systems<br />
}}, about Liquidity, WIP, Lead Time, Cycle Time, Process Efficiency.<br />
{{WebSourceListItem<br />
|url=http://www.infoq.com/articles/not-destroy-team-metrics<br />
|site=InfoQ<br />
|person=Sean McHugh<br />
|title=How To Not Destroy your Agile Team with Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.sixsigmatraining.org/introduction-to-six-sigma/gaming-the-metrics.html<br />
|site=Pyzdek Institute<br />
|person=Thomas Pyzdek<br />
|title=Gaming the Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://leadinganswers.typepad.com/leading_answers/2010/02/smart-metrics-slides.html<br />
|site=Leading Answers<br />
|person=Mike Griffiths<br />
|title=Smart Metrics Slides<br />
}}<br />
{{WebSourceListItem<br />
|url=http://martinfowler.com/articles/useOfMetrics.html<br />
|site=Martin Fowler<br />
|person=Martin Fowler<br />
|title=An Appropriate Use of Metrics<br />
}}<br />
{{WebSourceListItem<br />
|url=http://theitriskmanager.wordpress.com/2013/12/07/outcome-based-process-metrics-a-focus-on-time-to-value/<br />
|site=The Risk Manager<br />
|person=Chris Matts<br />
|title=Outcome based Process Metrics—A focus on Time to Value<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.agilealliance.org/files/8213/9819/0015/ActionableMetricsAtSiemensHealthServices.pdf<br />
|site=Agile Alliance<br />
|person=Daniel Vacanti, Bennet Vallet<br />
|title=Actionable Metrics at Siemens Health Services<br />
}}<br />
{{WebSourceListItem<br />
|url=http://sethgodin.typepad.com/seths_blog/2016/04/numbers-and-the-magic-of-measuring-the-right-thing.html<br />
|site=Seth’s Blog<br />
|person=Seth Godin<br />
|title=Numbers (and the magic of measuring the right thing)<br />
}}<br />
<br />
*http://www.slideshare.net/JuliaWester/metrics-and-coaching<br />
*https://mattphilip.wordpress.com/2015/01/12/improvement-metrics/</div>Martienhttp://pearllanguage.org/index.php?title=Product_owner&diff=2994Product owner2019-06-11T08:05:39Z<p>Martien: /* Sultans of Swing */ }}</p>
<hr />
<div>{{Oyster<br />
|goal=have passion and vision develop products that people want to buy<br />
|stage=Germ<br />
|theme=Agile, Scrum, Product<br />
}}<br />
{{tag|product owner}}<br />
{{tag|role}}<br />
<br />
Product ownership as it is often interpreted requires a polymath, since a {{p|product owner}} is:<br />
*'''Entrepreneur'''<br />
*Business Expert<br />
*Product Manager<br />
*Internal Customer Representative<br />
*Technology Expert<br />
*User Experience Expert<br />
*Subject Matter Expert<br />
*Designer<br />
*Communicator<br />
*Decision Maker<br />
<br />
Effective real-world {{p|product owner}}s collaborate with their {{p|development team}}s to do most of this. But how does it work?<br />
<br />
The {{p|product owner}} is a conduit between the client's needs and the crew able to fulfilling them.<br />
<br />
When the work is simply too much for a single {{p|product owner}}, split it up between a {{p|strategic product owner}} and {{p|tactical product owner}}. Sometimes, these roles are named {{p|chief product owner}} and {{p|product owner}}.<br />
<br />
==Key Succes Factors==<br />
For success, a {{p|product owner}} must be:<br />
#'''Passionate'''—Obsessed with delighting users and customers, the {{p|product owner}} sparks enthusiasm in everyone, creating a yearning for the sea that builds great ships.<br />
#'''Empowered'''—Able to make decisions, guide and push back on stakeholders. Delays in decision making slow down the team.<br />
#'''Qualified'''—Experienced in the product domain, the development technology, process and practices, and core personal skills.<br />
#'''Available'''—Able to work with the {{p|development team}}s quickly, or customer to understand needs. When split across multiple initiatives, you are unable to fully focus.<br />
<br />
==Product Owner Crew==<br />
A {{p|product owner}} represents many constituents with a single voice. Busy {{p|product owner}}s need not—and should not—act alone. Often, a {{p|product owner}} assembles a {{p|product owner crew}} that includes roles that might assist like:<br />
*'''{{p|agile business analyst}}s''' help to define business needs and elaborate them for the rest of the Team.<br />
*'''{{p|agile architect}}s''' help to secure the product's structural cohesion, consistency and completeness.<br />
*'''Developers''' provide available execution paths and describe their respective costs and benefits.<br />
*'''User Experience Experts''' and marketing resources help to elicit and explain end user needs and desires.<br />
<br />
==Sultans of Swing==<br />
As one of the {{p|three amigos}}, the {{p|product owner}} is a member of the {{p|sultans of swing}}. <br />
<br />
Pushing for delivery can be just as lonely as leading a team. By working so closely together with both a {{p|flow master}} and an {{p|agile coach}} you gain a multitude of benefits. One of the most important ones is focus, it allows you to focus on delivery of enhancements to the products you are responsible for because you know that the other two equally important aspects of team leadership are covered by the other to amigos.<br />
<br />
Mystifying incidents of the past such as for example a sudden lack of commitment by an engineer for some time became a lot clearer with the added information from the {{p|agile coach}} on the personal situation of that engineer. The {{p|agile coach}} opens up entirely new ways of handling typical issues with the team. (Source: [[DevOps @ Spotify]])<br />
<br />
The second most important benefit I see is the typical thorny problem of avoiding (or repaying) technical debt. An open discussion between people representing the different interests involved makes it easier to approach this problem. Otherwise, it's just an internal debate in a single person's head.<br />
<br />
==Daily Scrum==<br />
As {{p|product owner}}, your primary goals during the {{p|daily scrum}} include:<br />
*'''Listening!'''—This is your clearest window into detailed progress.<br />
*'''Addressing Team Issues''' that fall within your sphere of influence.<br />
*'''Gauge Visual Clues''' on the {{p|scrum wall}} like a flatliner on the {{p|burndown chart}}.<br />
*'''Providing your own status and issues''', where appropriate.<br />
<br />
==Product Owner Excellence==<br />
As {{p|product owner}}…<br />
{|rules="none"<br />
|-<br />
|align="right" valign="top" width="100pt"|<span style="color:{{pearlblue}};">'''You ought to'''</span><br />
|'''Own, elaborate and communicate the {{p|product vision}}'''<br />
:…business representatives best understand the business needs. It is next to impossible for teams to rely on their initial understanding of the domain.<br />
|-<br />
|<br />
|'''Drive {{p|collaborative product discovery}}'''<br />
:…A {{p|broad, deep and cross}} product ownership team plans and facilitates product discovery. Business stakeholders, users, subject matter experts, and the development team participate in various activities of the discovery.<br />
|-<br />
|<br />
|'''Garden a comprehensive {{p|story map}}'''<br />
:…the {{p|collaborative product discovery}} results in a solid {{p|story map}} that in turn is skimmed and flows into the {{p|product backlog}}.<br />
|-<br />
|<br />
|'''Formulate the {{p|unity of purpose}}'''<br />
:…many teams have rocky beginnings as people struggle to work together.Team members may come from different backgrounds, with different experiences. Therefore, the {{p|product owner}} ought to instill a common {{p|product vision}} and {{p|unity of purpose}} in all members of the team.<br />
|-<br />
|<br />
|'''Limit yourself to tell ''what'' needs to be done.'''<br />
:…the team excels in mastery in their profession. You only have to tell them what needs to be done in order to get the best out of them—they know how. Of course, also tell them ''why'', ''for whom'', and ''when'' you need ''what''.<br />
|-<br />
|<br />
|'''Explain ''why'' it needs to be done.'''<br />
:…understanding how each feature fulfills a need and creates value enables the team to discover utility and meaning in what they do.<br />
|-<br />
|<br />
|'''Order {{pbi}}s according to market and user value.'''<br />
:…features are not all of equal priority, and their value is not always obvious up front. Features ordered primarily by ease of delivery may reduce the return on investment.<br />
|-<br />
|<br />
|'''Choose what and when to release.'''<br />
:…feature sets can be delivered whenever they are ready, rather than only at the end of the project, facilitating incremental funding, providing incremental ROI and yielding valuable feedback.<br />
|-<br />
|<br />
|'''Create and garden {{p|vibrant persona}}s.'''<br />
:…achieve seamless alignment between {{p|vibrant persona}}s and {{p|scenarios define outcome}} by making sure that a relevant {{p|vibrant persona}} exists and is used for each user who you target. Use your {{p|vibrant persona}}s to make quick and wise design choices.<br />
|-<br />
|<br />
|'''Prepare and refine {{p|user storie}}s until they are {{p|ready to build}}.'''<br />
:…{{p|user stories}} that meet invest criteria joined with an evolving {{p|ready to build}} lead to a comprehensive, yet flexible, {{p|product backlog}} that feeds the {{p|development team}} into flow.<br />
|-<br />
|<br />
|'''Groom the {{p|product backlog}} based on feedback and changing conditions.'''<br />
:…initial requirements are often far from perfect and change constantly and may not cover every need or even be needed. Feedback can inform conscientious product tuning rather than being ignored or addressed reactively.<br />
|-<br />
|<br />
|'''Keep a short, iterative, sustainable, and predictable design cycle.'''<br />
:…{{p|scrum}}’s short 2–4 week {{p|sprint}}s are ideally suited to create a predictable and sustainable development rhythm, a cadence that may eventually become the pulse for the organization as a whole, for your market, even. Walk shoulder to shoulder with your {{p|scrum master}} to do so. Consider establishing a {{p|season beat}}.<br />
|-<br />
|<br />
|'''Perform acceptance tests to meet the criteria of {{p|ready to ship}}.'''<br />
:…ensure that stakeholders understand that the outcome of a {{p|sprint}} is not a finished product, yet make sure to get everyone’s consent on what’s considered done. Evolve that definition.<br />
|-<br />
|align="right" valign="top"|<span style="color:{{pearlblue}};">'''You ought not to'''</span><br />
|'''Manage the work of others'''<br />
:…your job is to create a product that works as advertised and that people want to buy.The team creating it is an autonomous, purposeful lean machine of masters in their profession. Feed them with purpose. Do not (micro) manage them.<br />
|-<br />
|<br />
|'''Tell anyone ''how'' to do their job.'''<br />
:…the team implementing your product vision displays mastery in their activities, knowledge, and skills. Let them work out how it’s done while you feed them with {{p|product vision}} and ''what'' needs to be done.<br />
|-<br />
|<br />
|'''Create your product in a vacuum.'''<br />
:…your work is interwoven with the work of every other team and is part of a larger whole. Involve cross-functional teams in your reviews and retrospectives. Keep an open mind and foster new ideas.<br />
|-<br />
|<br />
|'''Lose sight of the purpose behind your product.'''<br />
:…in agile settings, scope varies, so let {{p|scenarios define outcome}} to drive the required applications, features, user roles, dependencies in a collaborative workflow.<br />
|-<br />
|align="right" valign="top"|<span style="color:{{pearlblue}};">'''You should'''</span><br />
|'''Identify key moments to present your results.'''<br />
:...starting with {{p|storyboard scenarios}}, demonstrate the evolving product at the end of each {{p|sprint}} during the {{p|sprint review meeting}}, soliciting feedback from key stakeholders. Keep everyone excited and interested. Decide on how the feedback will be reflected in the {{p|product backlog}}. Demo or die!<br />
|-<br />
|<br />
|'''Involve interaction design appropriately.'''<br />
:…design the product around your users by professionals who master the art of interaction design and usability. Engineers excel in engineering, not in usability.<br />
|-<br />
|<br />
|'''Leverage and archive existing prototypes.'''<br />
:…to use ideas and/or other results from earlier efforts, keep them around. Explore efforts—like market research—of others in the same area. It may speed up development.<br />
|-<br />
|<br />
|'''Perform regular {{p|usability test}}s.'''<br />
:…regular and affordable {{p|usability test}}s where the whole team watches someone use your product are often eye-opening. Observe… Do they get it? Can they find their way around? Expect head slappers, shocks, inspiration, and passion. Brace yourself, yet do not panic.<br />
|-<br />
|align="right" valign="top"|<span style="color:{{pearlblue}};">'''You should not'''</span><br />
|'''Solicit feedback from too wide an audience.'''<br />
:…pleasing everyone with your work is impossible. In fact, you should not even try. It wastes the time of your best clients and annoys our staff. Please some less to please others a bit more. Ask for forgiveness for focussing on those customers we’re trying to delight.<br />
|-<br />
|<br />
|'''Drown in detail.'''<br />
:…perfect is the enemy of good enough.There are times later in development where you can determine detailed information or where it becomes the visual specification for the final product. Focus on relevant potentially shippable product and candid feedback instead.<br />
|}<br />
<br />
==15 things a professional Product Owner does==<br />
A professional Product Owner<br />
*is an entrepreneur—a value maximizer & optimizer;<br />
*sets a solid vision to help the team keep laser sharped focus and direction that helps with incremental progress;<br />
*1 product == 1 {{p|product backlog}} == 1 {{p|product owner}}. Having one {{p|product owner}} for the product helps with the clarity & focus, ensures quick decision making, and single person accountability for the success of the product;<br />
*validates the idea of frequent releases of the product increment to market to gain real customer insights;<br />
*has the final say on the order of the {{p|product backlog}}. The PSPO orders the items in the {{p|product backlog}} by keeping the value of the items, the dependencies between items and the dependencies on the other products in mind;<br />
*ensures that most valuable functionality is generated all times;<br />
*accounts for the Return on Investment and Total Cost of Ownership before a feature is built;<br />
*ensures that all work done originates from the single {{p|product backlog}}—a single source of truth;<br />
*uses metrics like time to market (cycle time / lead time), percentage of the functionality in the released product used by the customers, and overall customer satisfaction to determine the value of the product being delivered;<br />
*is accountable for interacting and engaging with the stakeholders;<br />
*comes to the {{p|sprint planning meeting}} with a clear business objective in mind and works with the {{p|build crew}} to craft a {{p|sprint goal}} based upon the forecast;<br />
*is accountable for regular and timely {{p|product backlog refinement}}, yet may delegate the work to the {{p|build crew}};<br />
*is the only one who can abnormally terminate the {{p|sprint}} in case the {{p|sprint goal}} becomes obsolete.<br />
*is just one person and not a committee;<br />
*builds trust by closely working with {{p|build crew}}, and happy to delegate the work of writing {{p|user stories}} and {{p|product backlog items}} to the {{p|build crew}}.<br />
<br />
==Videos==<br />
==Sources==<br />
*https://blog.scrum.org/15-things-professional-scrum-product-owner-pspo-actually/<br />
{{WebSourceListItem<br />
|url=http://blog.ted.com/2013/01/06/david-kelley-of-ideo-talks-design-thinking-on-60-minutes/<br />
|site=TED<br />
|person=Kate Torgovnick May<br />
|title=David Kelley of IDEO talks “design thinking” on 60 Minutes<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.youtube.com/watch?v=aXQ2lO3ieBA<br />
|site=YouTube<br />
|title=The Pentagon Wars » Bradley Fighting Vehicle Evolution<br />
}}<br />
{{WebSourceListItem<br />
|url=http://youtu.be/iur-noEd4eA<br />
|site=YouTube<br />
|title=The Pentagon Wars » Trailer<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.youtube.com/watch?v=502ILHjX9EE<br />
|site=YouTube<br />
|person=Henrik Kniberg<br />
|title=Agile Product Ownership in a Nutshell<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.pragmaticmarketing.com/publications/topics/09/the-mythical-product-owner-1<br />
|site=Pragmatic Marketing<br />
|person=Andre Kaminski<br />
|title=The Mythical Product Owner<br />
}}<br />
{{WebSourceListItem<br />
|url=http://kasperowski.com/2010/11/my-product-owner-will-kick-ass.html<br />
|site=Richard Kasperowski<br />
|title=My Product Owner will kick ass<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.smashingmagazine.com/2014/09/17/why-companies-need-full-time-product-managers/<br />
|site=Smashing Magazine<br />
|person=Rian van der Merwe<br />
|title=Why Companies Need Full-Time Product Managers (And What They Do All Day) » What is a product manager?<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.smashingmagazine.com/2014/09/17/why-companies-need-full-time-product-managers/2/<br />
|site=Smashing Magazine<br />
|person=Rian van der Merwe<br />
|title=Why Companies Need Full-Time Product Managers (And What They Do All Day) » Characteristics Of A Good Product Manager<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.smashingmagazine.com/2014/09/17/why-companies-need-full-time-product-managers/3/<br />
|site=Smashing Magazine<br />
|person=Rian van der Merwe<br />
|title=Why Companies Need Full-Time Product Managers (And What They Do All Day) » In Fairness<br />
}}<br />
{{WebSourceListItem<br />
|url=http://zenhabits.net/unknowing/<br />
|site=Zen Habits<br />
|person=Leo Babauta<br />
|title=The Not Knowing Path of Being an Entrepreneur<br />
|about=Entrepreneurship<br />
}}<br />
{{WebSourceListItem<br />
|url=http://www.beyondrequirements.com/po_blogs_newsletters/<br />
|site=Beyond Requirements<br />
|person=Kent McDonald<br />
|title=Product Ownership Blogs and Newsletters<br />
}}<br />
{{WebSourceListItem<br />
|url=http://blog.scrum.org/the-18-characteristics-of-a-great-product-owner/<br />
|site=Scrum.prg<br />
|person=Barry Overeem<br />
|title=The 18 Characteristics of a Great Product Owner<br />
}}<br />
{{WebSourceListItem<br />
|url=https://www.scrumalliance.org/employer-resources/7-skills-you-need-to-be-a-great-product-owner<br />
|site=Scrum Alliance<br />
|person=Lowell Lindstrom<br />
|title=7 Skills You Need to Be a Great Product Owner<br />
}}<br />
{{WebSourceListItem<br />
|url=https://www.infoq.com/articles/book-review-product-mastery<br />
|site=InfoQ<br />
|person=Geoff Watts<br />
|title=Book Q&A on Product Mastery<br />
}}</div>Martien