Make a F.O.C.O.L. Point!
•Télécharger en tant que PPTX, PDF•
0 j'aime•350 vues
Have you ever wondered whether your retrospective format was actually effective at fueling learning and improvement? Are you ready to try something different? "FOCOL Point" is Idea Flow Learning Framework's 5-step learning and improvement protocol. It works great for software improvement, but it also works for team reflection, personal reflection, or mentorship. Rather than searching for answers, a FOCOL Point is all about finding the right questions. Once I walk through the protocol as a group, we'll make a FOCOL Point together! First, we'll identify the biggest software problems faced by the audience using the "flashstorming" technique. Then we'll focus on the top problems of the group and start digging into the details by walking through a group-adapted version of the stop and think protocol: 1. **Focus**: What's the journey we're trying to understand? 2. **Observe**: What patterns do we see? (for all journey pattern types) 3. **Conclude**: What obstacles seem to be causing the pain? 4. **Optimize**: How could we have avoided the obstacles? 5. **Learn**: What questions should we ask ourselves in the future? Amplify your learning by reflecting more productively on your own or with your team! You can immediately apply this technique on your own projects.
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (18)
Similaire à Make a F.O.C.O.L. Point!
Similaire à Make a F.O.C.O.L. Point! (20)
Plus de Arty Starr
Plus de Arty Starr (9)
Dernier
Dernier (20)
Make a F.O.C.O.L. Point!
- 1. CTO, New Iron, Austin, TX Janelle Klein ©2015 New Iron Group Make a FOCOL Point! Creation Date: 11/24/2015
- 2. What is this talk about? Make a F.O.C.O.L Point! (IFLF’s Reflection Protocol) FOCOL Point Team Retrospective The Process of Mastery
- 3. Why should I care?
- 4. Sprint Retrospective Have you ever wondered: “Are we really learning?”
- 5. Playing the Flute MeMy Skills
- 6. Playing the Flute MeMy Skills
- 7. Private Lessons MeMy Skills My Teacher NO! That’s Wrong!!
- 8. Private Lessons MeMy Skills My Teacher NO! That’s Wrong!!
- 9. Observations from Mastering the Flute Focus on the stuff you’re not good at. The objective with any lesson is to suck less. We can’t fix problems we can’t see. We can’t fix problems we don’t understand. To make improvements permanent, we have to make the changes a habit. (practice)
- 10. Why aren’t we learning? Practice isn’t enough. Thinking about improvements only works to an extent. My Skills Me Desire isn’t enough.
- 11. How do we design a process for mastery?
- 12. Mastery isn’t a Goal. It’s a Process.
- 13. Mastery isn’t a Destination. It’s a Direction.
- 14. Mastery isn’t the Quality of the Car. It’s the Quality of the Steering.
- 15. Mastery isn’t the Data File. It’s the Program that generates data files.
- 16. Mastery isn’t the Quality of the Outcome. It’s the Quality of Decisions.
- 17. The Process of Mastery Systematically Optimize Decisions
- 18. Target - The direction we’re trying to go… The Process of Mastery
- 19. Output - The pain signal we’re trying to improve The Process of Mastery
- 20. Input - The constraints that limit our short-term choices… The Process of Mastery
- 21. 1. Visibility - See the pain 1. Visibility 1. Visibility The Process of Mastery
- 22. 1. Clarity 2. Clarity 2. Clarity - Explain what’s causing the pain The Process of Mastery
- 23. 3. Awareness 3. Awareness - Learn to avoid the pain The Process of Mastery
- 24. Focus on the biggest pain… Minimize Pain The Process of Mastery
- 25. Systematically Optimize Decisions The Process of Mastery
- 26. Three Stages of Mastery Visibility Clarity Awareness
- 27. We can’t fix a problem that we don’t see. Visibility See the pain
- 28. Our level of understanding is constrained by the diversity of patterns in our vocabulary. Clarity Explain what’s causing the pain
- 29. Awareness Learn to avoid the pain The quality of our decisions is limited by our ability to recognize the risks in the moment.
- 30. Three Stages of Mastery Visibility Clarity Awareness See Explain Predict
- 31. Mastery is Knowledge Expansion Iterate - What type of learning do I need most?
- 32. Now Let’s Zoom Out! Mastery is a process of additive learning.
- 33. The Scientific Method Creating an explicit model makes our beliefs testable. (An additive learning strategy)
- 34. Decision-Making Model Little Pain Big Pain Trade-off decisions
- 35. Imagine your brain is a decision-making engine written in code. Breakpoint Stop and Think!
- 36. Imagine your brain is a decision-making engine written in code. Breakpoint Stop and Think!
- 37. What’s a Decision Principle? 1. How do I evaluate my situation? 2. What should I optimize for? Answers Two Questions
- 38. The Haystack Principle “Optimize for small manageable haystacks.” “If I decide to skip the unit tests, how will that affect my haystack size?” Lots of unvalidated changes Easier to find the needle.
- 39. The Checklist Manifesto Atul Gawande Running Lean Ash Maurya + Use strategy experiments to test your beliefs.
- 40. 14:230:00 I want to avoid this… Thinking Checklist Is my current approach likely to cause a big haystack? Situation: start of subtask Let’s Make a Checklist! “What question could I ask my future self to recognize similar risks in the future?” “In what situation would I ask the question?”
- 41. 0:00 Stop and Think: Is my current approach likely to cause a big haystack? Predict: Small haystack Strategy Experiments
- 42. 18:120:00 Stop and Think: Is my current approach likely to cause a big haystack? Predict: Small haystack False Prediction Strategy Experiments
- 43. 18:120:00 Stop and Think: Is my current approach likely to cause a big haystack? False Prediction Strategy Experiments High-Risk Situations 1. Unraveling sweater 2. Integration-heavy change 3. High state variation 4. Minimum scope is big Q: Is my current approach likely to cause a big haystack? Start of Subtask
- 44. Strategy Types (“do”) 1. DependencyAnalysis 2. IncrementalIntegrationTest 3. DataDrivenTest 4. IsolateHardToTestCode Situation Types (“see”) 1. UnravelingSweater 2. HeavyIntegrationLogic 3. HighStateVariation 4. CoupledExternalDependencies Haystack Decisions Codify What Works DoSee
- 45. Best Practices are Backwards We don’t encounter solutions, we encounter problems. Do See We need a new data structure!!
- 46. The Scientific Method Creating an explicit model makes our beliefs testable. (An additive learning strategy) Visibility Process Modeling Process Experimentation Process
- 47. The Scientific Method Creating an explicit model makes our beliefs testable. (An additive learning strategy) Visibility Process Modeling Process Experimentation Process FOCOL Point happens here!
- 48. Learn Focus Observe ConcludeOptimize Make a FOCOL Point! (The Mastery Spiral) Back to Experiments
- 50. Learn Focus Observe ConcludeOptimize Focus - What’s the needle we’re trying to move? Make a FOCOL Point! (The Mastery Spiral) Pain Type Focus = Scope + Direction
- 51. Journey Beginning Ending Think about the Experience as a Problem-Solving Journey
- 52. = Solution Strategy The Problem-Solving Journey
- 53. = Solution Strategy Choose a general strategy The Problem-Solving Journey
- 54. = Solution Strategy Understand the system The Problem-Solving Journey
- 55. = Solution Strategy Code & work out the kinks The Problem-Solving Journey
- 56. = Solution Strategy Back to the drawing board The Problem-Solving Journey
- 57. Journey Beginning Ending Focus = Scope + Direction How could I have reduced <this pain type> in <this experience>?
- 58. The type of pain we experience depends on where the disruptions are in the journey
- 59. The Ten Pains of Software Development (Needles) Troubleshooting Learning Rework
- 60. Design-Fit Pain - When the new feature doesn’t fit well into the existing design. The Ten Pains of Software Development (Needles)
- 61. Requirements Pain - Bad assumptions about what functionality to build The Ten Pains of Software Development (Needles)
- 62. Collaboration Pain - Challenges collaborating with other developers on the team. The Ten Pains of Software Development (Needles)
- 63. Modeling Pain - When it’s difficult to build a conceptual model of the existing software. The Ten Pains of Software Development (Needles)
- 64. Cognitive Pain - Challenges with complexity and intense thinking The Ten Pains of Software Development (Needles)
- 65. Alarm Pain - Challenges with false alarms and test maintenance The Ten Pains of Software Development (Needles)
- 66. Experiment Pain - Challenges with getting feedback by running experiments The Ten Pains of Software Development (Needles)
- 67. Execution Pain - When changing the code is highly mistake-prone The Ten Pains of Software Development (Needles)
- 68. An amplifying effect on other problems The Ten Pains of Software Development (Needles)
- 69. Journey Beginning Ending Will Need a Guinea Pig. Focus on One Experience at a time.
- 70. Learn ConcludeOptimize Observe - What patterns do we see? Focus Observe Make a FOCOL Point! (The Mastery Spiral)
- 71. Circle Leader Focus Member Inquisitor Observation Questions Mastery Circle (Based on Action Learning) Observe - What patterns do we see?
- 72. Learn Optimize Conclude - What major factors caused the pain? Focus Observe Conclude Make a FOCOL Point! (The Mastery Spiral)
- 73. What were the biggest obstacles on the journey? Constraints Difficulties Bad Strategies Uncertainty
- 74. Journey Constraints What were the biggest obstacles on the journey?
- 75. Difficulties Journey What were the biggest obstacles on the journey?
- 76. Journey Bad Strategy What were the biggest obstacles on the journey?
- 77. Journey Good Strategy What were the biggest obstacles on the journey?
- 78. Journey Uncertainty What were the biggest obstacles on the journey?
- 79. Circle Leader Focus Member Inquisitor Inquisitors state additive conclusions. Mastery Circle (Based on Action Learning) Conclude - What major factors caused the pain? Focus Member is last.
- 80. Learn Optimize Optimize - What strategies could have reduced the pain? Focus Observe Conclude Make a FOCOL Point! (The Mastery Spiral)
- 81. Journey Good Strategy What strategies could have reduced the pain?
- 82. Circle Leader Focus Member Inquisitor Mastery Circle (Based on Action Learning) Focus Member is last. Inquisitors state additive strategies. Optimize - What strategies could have reduced the pain?
- 83. Learn Learn - What questions should we add to the field guide? Focus Observe ConcludeOptimize Make a FOCOL Point! (The Mastery Spiral)
- 84. Journey Field Guide What questions should we add to the field guide? Situational Checklists
- 85. Circle Leader Focus Member Inquisitor Mastery Circle (Based on Action Learning) Focus Member is last. Inquisitors state additive questions. Learn - What questions should we add to the field guide?
- 86. Learn Focus Observe ConcludeOptimize Make a FOCOL Point! (The Mastery Spiral) Back to Experiments
- 87. Troubleshooting Learning Rework What are the TOP THREE pains on your project?
- 88. Think of an EXPERIENCE where you learned about the pain. Journey Beginning Ending
- 89. Journey Beginning Ending We need a Guinea Pig. Focus on One Experience
- 90. Journey Beginning Ending Focus = Scope + Direction How could I have reduced <this pain type> in <this experience>?
- 91. Learn Focus Observe ConcludeOptimize Let’s Make a FOCOL Point!
- 92. Open Mastery 2016 We Believe in Peer Mentorship! Yay!
- 93. Individuals Free Membership Companies Paid Membership Open Mastery Guild Membership
- 94. IFM Tools Anonymized data Developers Learning Together! IFM Tools IFM Tools IFM Tools IFM Tools IFM Tools Community Focus Integrated #HashTag Glossary
- 95. IFM Tools IFM Tools IFM Tools IFM Tools IFM Tools IFM Tools Idea Flow Analytics PlatformPrivate data Companies Learning Together! Revenue from membership fees to fund core development
- 96. @janellekz Open Mastery 2016 Join us! @openmastery janelle@newiron.com Thank you! Free e-book if you sign up before publish day! (Jan 2016) Tweet about #ideaflow! IFM Tools available at: github.com/ideaflow/tools
Notes de l'éditeur
- Hi Everyone, I’m Janelle Klein, from Austin, TX. Been a developer for 15 years, then did consulting for a while, and now I’m CTO of a software-niche recruiting company that specializes in technical assessment and mentorship. The project I’ve been working on over the last several years has been to figure out how to codify and teach the art of our craft. So while it might seem a little weird to work for a recruiting company, technical assessment and mentorship really go hand in hand, that in order to teach a skill, we have to be able to correctly diagnose the concepts that are missing. It’s like troubleshooting people’s brains. Brains are really cool.
- So what’s this talk about — the art of better. It doesn’t get more abstract than this. So I’m going to take this abstract fuzzy notion of better that we don’t even have words to describe, and I’m going to break it down into concrete conceptual models, strategies, and things we can actually measure. The philosophy behind my mentorship technique, and my book.
- So let’s talk about mentorship. I have kind of a weird job. I work at software-niche recruiting company that specializes in technical interviews… I found myself teaching “this guy”
- And that if we just keep trying harder to be more best practice like, our problems will go away.
- So let’s talk about mentorship. I have kind of a weird job. I work at software-niche recruiting company that specializes in technical interviews… I found myself teaching “this guy”
- And that if we just keep trying harder to be more best practice like, our problems will go away.
- And that if we just keep trying harder to be more best practice like, our problems will go away.
- And that if we just keep trying harder to be more best practice like, our problems will go away.
- And that if we just keep trying harder to be more best practice like, our problems will go away.
- And that if we just keep trying harder to be more best practice like, our problems will go away.
- See the pain
- Rework Risk is driven by the likelihood... Things like... bad assumptions about the architecture or design or bad assumptions about customer requirements. The longer we delay before making corrections, the greater the rework.
- It’s not good or bad, it just is.
- It’s not good or bad, it just is.
- It’s not good or bad, it just is.
- Rework Risk is driven by the likelihood... Things like... bad assumptions about the architecture or design or bad assumptions about customer requirements. The longer we delay before making corrections, the greater the rework.
- Think about the scope of your knowledge as three concentric circles. Each circle limits the growth of the circles immediately inside it. When we’re trying to expand our knowledge, we can’t understand what we don’t see. We can’t be aware of what we don’t understand. Visibility constrains Clarity constrains Awareness. To expand our knowledge, we have to [] focus on breaking the most limiting constraint.
- Rework Risk is driven by the likelihood... Things like... bad assumptions about the architecture or design or bad assumptions about customer requirements. The longer we delay before making corrections, the greater the rework.
- Rework Risk is driven by the likelihood... Things like... bad assumptions about the architecture or design or bad assumptions about customer requirements. The longer we delay before making corrections, the greater the rework.
- But that wasn’t enough either… despite those things, he was still struggling.
- We optimize for execution time, even when the time spent on human cycles can completely dwarf the execution time. Why do you think that is?
- Used thinking checklists to codify a decision-making process… let me show you what I mean.
- Focus on one decision principle until you have it down.
- It’s not that best practices are bad, or wrong, they’re just backwards.
- The problem-solving process in software development looks like this. [pause]
- First, we evaluate possible alternatives and decide on a general strategy.
- Next, we scan through the code to build a conceptual model of how it works and figure out how the pieces will fit together.
- Then we enter this feedback loop phase -- [slow] we write a little code, validate that it works, and then we keep refining the details of our strategy.
- Sometimes we discover our strategy’s not gonna work -- and we have to go back to the drawing board to find an alternative.
- Then we have lack of familiarity and disruption pain... these are a little different than the others, because they have an amplifying effect on other problems.
- [read] [pause] For example... [] when there’s problems evaluating alternatives
- Only a handful of things that cause excessive troubleshooting time.
- [read]
- [read]
- [read]
- [read]
- [read]
- [read]
- [read]
- [read]
- Then we have lack of familiarity and disruption pain... these are a little different than the others, because they have an amplifying effect on other problems.
- Then we have lack of familiarity and disruption pain... these are a little different than the others, because they have an amplifying effect on other problems.
- ©2014 New Iron Group Such that we can learn from eachother, build on our existing knowledge, make new discoveries and drive the industry forward
- Then you start recognizing the patterns, “aha! this is one of those situations, or… I should keep on eye on that.” If there’s one thing that will accelerate your learning faster than anything else, it’s this. Need to also mention Open Mastery Online. People in the Mentorship program we’re going to build a statical process control system for software development.
- Then you start recognizing the patterns, “aha! this is one of those situations, or… I should keep on eye on that.” If there’s one thing that will accelerate your learning faster than anything else, it’s this. Need to also mention Open Mastery Online. People in the Mentorship program we’re going to build a statical process control system for software development.
- Then you start recognizing the patterns, “aha! this is one of those situations, or… I should keep on eye on that.” If there’s one thing that will accelerate your learning faster than anything else, it’s this. Need to also mention Open Mastery Online. People in the Mentorship program we’re going to build a statical process control system for software development.
- Then you start recognizing the patterns, “aha! this is one of those situations, or… I should keep on eye on that.” If there’s one thing that will accelerate your learning faster than anything else, it’s this. Need to also mention Open Mastery Online. People in the Mentorship program we’re going to build a statical process control system for software development.
- Then you start recognizing the patterns, “aha! this is one of those situations, or… I should keep on eye on that.” If there’s one thing that will accelerate your learning faster than anything else, it’s this. Need to also mention Open Mastery Online. People in the Mentorship program we’re going to build a statical process control system for software development.
- Then you start recognizing the patterns, “aha! this is one of those situations, or… I should keep on eye on that.” If there’s one thing that will accelerate your learning faster than anything else, it’s this. Need to also mention Open Mastery Online. People in the Mentorship program we’re going to build a statical process control system for software development.
- ©2014 New Iron Group Such that we can learn from eachother, build on our existing knowledge, make new discoveries and drive the industry forward
- Then you start recognizing the patterns, “aha! this is one of those situations, or… I should keep on eye on that.” If there’s one thing that will accelerate your learning faster than anything else, it’s this. Need to also mention Open Mastery Online. People in the Mentorship program we’re going to build a statical process control system for software development.
- ©2014 New Iron Group Such that we can learn from eachother, build on our existing knowledge, make new discoveries and drive the industry forward
- Then you start recognizing the patterns, “aha! this is one of those situations, or… I should keep on eye on that.” If there’s one thing that will accelerate your learning faster than anything else, it’s this. Need to also mention Open Mastery Online. People in the Mentorship program we’re going to build a statical process control system for software development.
- ©2014 New Iron Group Such that we can learn from eachother, build on our existing knowledge, make new discoveries and drive the industry forward
- Then we have lack of familiarity and disruption pain... these are a little different than the others, because they have an amplifying effect on other problems.
- Then we have lack of familiarity and disruption pain... these are a little different than the others, because they have an amplifying effect on other problems.
- Then we have lack of familiarity and disruption pain... these are a little different than the others, because they have an amplifying effect on other problems.
- Then we have lack of familiarity and disruption pain... these are a little different than the others, because they have an amplifying effect on other problems.
- Iterative clarify then implement “better”
- Iterative clarify then implement “better”
- Iterative clarify then implement “better”
- Creation Date: 9/13/2015