1. Board of directors Henrik Kniberg Agile/Lean coach www.crisp.se Kanban and Scrum Making the most of both Agile 2010, Orlando August 12, 2010 henrik.kniberg@crisp.se +46 70 4925284 Copyright notice These slides are licensed under Creative Commons. Feel free to use these slides & pictures as you wish, as long as you leave my name and the Crisp logo somewhere. For licensing details see: http://creativecommons.org/licenses/by/3. 0/ http://creativecommons.org/licenses/by/3. 0/ All slides available at: http://www.crisp.se/henrik.kniberg/

2. 2 Purpose of this presentation To clarify Kanban and Scrum by comparing them...so you can figure out how these may come to use in your context. Henrik Kniberg 2

3. 3 Kanban Henrik Kniberg 3 Scrum Veteran Read Seen Tried Use Your knowledge?

4. 4 Scrum in a nutshell Henrik Kniberg 4

5. 5 Scrum in a nutshell Henrik Kniberg 5 January April Split your organization Split your product Split time Optimize business value Optimize process $ $$$ Large group spending a long time building a huge thing Small team spending a little time building a small thing... but integrating regularly to see the whole

6. 6 Process is continuously improving Have Definition of Done (DoD) DoD achievable within each iteration Team respects DoD The bottom line Delivering working, tested software every 4 weeks or less Delivering what the business needs most Demo happens after every sprint Shows working, tested software Feedback received from stakeholders & PO Retrospective happens after every sprint Results in concrete improvement proposals Some proposals actually get implemented Whole team + PO participates Team has a sprint backlog Highly visible Updated daily Owned exclusively by the team Have sprint planning meetings PO participates Whole team participates Results in a sprint plan Whole team believes plan is achievable PO satisfied with priorities PO brings up-to-date PBL Iteration length 4 weeks or less Always end on time Team not disrupted or controlled by outsiders Timeboxed iterations PO has a product backlog (PBL) Top items are prioritized by business value Top items are estimated PO understands purpose of all backlog items Top items in PBL small enough to fit in a sprint Estimates written by the team Clearly defined product owner (PO) PO is empowered to prioritize PO has knowledge to prioritize PO has direct contact with team PO has direct contact with stakeholders PO speaks with one voice (in case PO is a team) Team members sit together If you achieve these you can ignore the rest of the checklist. Your process is fine. These are central to Scrum. Without these you probably shouldn’t call it Scrum. Core Scrum PO has product vision that is in sync with PBL PBL and product vision is highly visible Everyone on the team participates in estimating PO available when team is estimating Team members not locked into specific roles Team has all skills needed to bring backlog items to Done Team has a Scrum Master (SM) Whole team knows top 1-3 impediments SM has strategy for how to fix top impediment SM focusing on removing impediments Escalated to management when team can’t solve Velocity is measured Velocity only includes items that are Done PO uses velocity for release planning Team has a sprint burndown chart PBL items are broken into tasks within a sprint Estimates for ongoing tasks are updated daily Highly visible Updated daily PO participates at least a few times per week All items in sprint plan have an estimate SM sits with the team Daily Scrum is every day, same time & place Sprint tasks are estimated Estimate relative size (story points) rather than time Max 15 minutes Each team member knows what the others are doing Most of these will usually be needed, but not always all of them. Experiment! Recommended but not always necessary Daily Scrum happens Whole team participates Problems & impediments are surfaced You have a Chief Product Owner (if many POs) Dependent teams do Scrum of Scrums Dependent teams integrate within each sprint Scaling Having fun! High energy level. Overtime work is rare and happens voluntarily Discussing, criticizing, and experimenting with the process Positive indicators Scrum Checklist http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17) the unofficial Henrik Kniberg PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done Team usually delivers what they committed to Leading indicators of a good Scrum implementation. These are pretty fundamental to any Scrum scaling effort. Max 9 people per team Iterations that are doomed to fail are terminated early

7. 7 Kanban in a nutshell Henrik Kniberg 7

8. 8 Which team needs most improvement? Henrik Kniberg 8 Team 1Team 2 Todo Doing Done this week orem ipsum dolor sit amet, co nse ctetur Avg lead time: days 3 Todo Doing Done this week orem ipsum dolor sit amet, co nse ctetur Avg lead time: days 20 orem ipsum dolor sit amet, co nse ctetur Russel Ackoff Managers who don’t know how to measure what they want settle for wanting what they can measure

9. 9 Kanban @ Imperial Palace Gardens Henrik Kniberg 9

10. 10 Kanban Signaling system Visual Limited in supply Henrik Kniberg 10 看板 ”Visual Card”

11. 11 Kanban in your wallet Henrik Kniberg 11 Darn. Forgot to limit.

12. 12 SupplierBuyer Kanban @ Toyota Henrik Kniberg 12 ReceiveConsumeDetachShipAllocateManufacture Taiichi Ohno Father of the Toyota Production System The tool used to operate the [Toyota Production] system is kanban. Adapted from Kiro Harada’s slide

13. 13 Kanban in SW development Henrik Kniberg Backlog Dev Done orem ipsum dolor sit amet, co nse ctetur UAT Deploy 5 3 2 3 FLOW Avg lead time: days 12 orem ipsum dolor sit amet, co nse ctetur Visualize the workflow Limit WIP (work in progress) Measure & optimize flow Explicit policies (definition of Done, WIP limits, etc) Pioneered by David Anderson in 2004

14. 14 Kanban example Board shared by 2 teams (16 people in total) Henrik Kniberg 14

15. 15 Compare for understanding, not judgement Henrik Kniberg 15

16. 16 Henrik Kniberg 16 Pair programming Product Owner role Physical tools Process tools a.k.a. ”organizational patterns” Thinking tools a.k.a. ”mindsets” or ”philosophies” Lean Agile Toolkits a.k.a. ”frameworks” Scrum XP Visualize the workflow Kanban Systems Thinking Theory of Constraints RUP Tool ”anything used as a means of accomplishing a task or purpose.” - dictionary.com

17. 17 More prescriptive More adaptive Compare for understanding, not judgement Henrik Kniberg 17 XP (13) Scrum (9) Kanban (3) Do Whatever (0) RUP (120+) Architecture Reviewer Business Designer Business-Model Reviewer Business-Process Analyst Capsule Designer Change Control Manager Code Reviewer Configuration Manager Course Developer Database Designer Deployment Manager Design Reviewer Designer Graphic Artist Implementer Integrator Process Engineer Project Manager Project Reviewer Requirements Reviewer Requirements Specifier Software Architect Stakeholder System Administrator System Analyst Technical Writer Test Analyst Test Designer Test Manager Tester Tool Specialist User-Interface Designer Architectural analysis Assess Viability of architectural proof-of-concept Capsule design Class design Construct architectural proof-of- concept Database design Describe distribution Describe the run-time architecture Design test packages and classes Develop design guidelines Develop programming guidelines Identify design elements Identify design mechanisms Incorporate design elements Prioritize use cases Review the architecture Review the design Structure the implementation model Subsystem design Use-case analysis Use-case design Analysis model Architectural proof-of-concept Bill of materials Business architecture document Business case Business glossary Business modeling guidelines Business object model Business rules Business use case Whole team Coding standard TDD Collective ownership Customer tests Pair programming Refactoring Planning game Continuous integration Simple design Sustainable pace Metaphor Small releases Scrum Master Product Owner Team Sprint planning meeting Daily Scrum Sprint review Product backlogt Sprint backlog BUrndown chart Visualize the workflow Limit WIP Measure and optimize lead time Miyamoto Musashi 17 th century samurai Do not develop an attachment to any one weapon or any one school of fighting Business use case realization Business use-case model Business vision Change request Configuration audit findings Configuration management plan Data model Deployment model Deployment plan Design guidelines Design model Development case Development-organization assessment End-user support mateirla Glossary Implementation model Installation artifacts Integration build plan Issues list Iteration assessment Iteration plan Manual styleguide Programming guidelines Quality assurance plan Reference architecture Release notes Requirements attributes Requirements management plan Review record Risk list Risk management plan Software architecture document Software development plan Software requirements specification Stakeholder requests Status assessment Supplementary business specification Supplementary specification Target organization assessment Test automation architecture Test cases Test environment configuration Test evaluation summary Test guidelines Test ideas list Test interface specification Test plan Test suite Tool guidelines Training materials Use case model Use case package Use-case modeling guidelines Use-case realization Use-case storyboard User-interface guidelines User-interface prototype Vision Work order Workload analysis model

18. 18 Lean & Agile process toolkits Henrik Kniberg 18 Kanban Scrum XP Values & Principles Lean, Agile, Theory of Constraints, Systems Thinking, etc Other lean tools (Value Stream Mapping, Root Cause Analysis, etc)

19. 19 Henrik Kniberg 19 Any tool can be misused The old tool was better! Don’t blame the tool!

20. 20 Why limit WIP? (work in progress) Henrik Kniberg 20

21. 21 Setup Henrik Kniberg 21 Dave Lisa Bob Eric Maria 1 Developer 4 – 6 customers Multitasking name game

22. 22 Round 1: Ordering process Henrik Kniberg 22 JEFF 28 1 2 3 Multitasking name game DeveloperCustomer Jeff Log delivery time Deliver Order

23. 23 Round 1: Development process Henrik Kniberg 23 DAVE LIS BOB ERI MAR Never keep a customer waiting Start early = Finish early Policy Dave Lisa Bob Eric Maria Multitasking name game 28

24. 24 Round 2 – Development process Henrik Kniberg 24 DAVE LIS Limit WIP (work in process) Current limit = 1 customer at a time Policy Dave Lisa Bob Eric Maria A Multitasking name game

25. 25 Round 2: Ordering process Henrik Kniberg 25 1 2 3 Multitasking name game Developer Customer Jeff Log delivery time Calc project length Deliver product Log start time Submit order 5 5 JEFF 5 15 10 0 Request order

26. 26 Typical results Henrik Kniberg 26 Multitasking name game

27. 27 Henrik Kniberg 27 Focusing on starting stuff rather than finishing Not limiting WIP Focusing on keep people busy (fear of slack) Accepting the “reason” & solving the symptom instead of the problem Bail water Water in boat Hole in boat Fix hole Causes of unnecessary multitasking

28. 28 Kanban & Scrum Real-life example Henrik Kniberg 28

29. 29 Case study Sam Concept pres. Lisa assigns resources Graphics design Sound design Dev Integr. & deploy 2d1m 4h 6m 8 Game backlog 1w6m 15 Design-ready games 12 Production-ready games 1m3w3m (1m+2m) 3w2h1d 3 m value added time 25 m cycle time = 12% Process cycle efficiency

30. 30 Limit work to capacity Henrik Kniberg 30 Input: 3 customers / hour Output capacity: 2 customers / hour

31. 31 Case study Henrik Kniberg 31 Sam Concept pres. Lisa assigns resources Graphics design Sound design Dev Integr. & deploy 2d1m 4h 6m 8 Game backlog 1w6m 15 Design-ready games 12 Production-ready games 1m3w3m (1m+2m) 3w2h1d Cross-functional game team 3-4 m cycle time = 6-8x faster Game team (graphics, sound, dev, integrate) 3-4 months 3 m value added time 25 m cycle time = 12% Process cycle efficiency

32. 32 Case study – Key points Speeding up product development is usually a matter of improving the process rather than adding people. Value stream mapping is a great tool for spotting bottlenecks Push scheduling + too much WIP (work in progress) is usually the root cause Scrum & Kanban = two good approaches to fix this Beware suboptimization! Henrik Kniberg 32 ”Hey, let’s do Scrum here! Maybe we can cut OUR time in half!” w2w1w4w3w6w5w8w7 ”Cross-functional teams are no good, that will make OUR work take longer!” Sam Concept pres. Lisa assigns resources Graphics design Sound design Dev Integr. & deploy 2d1m 4h 6m1w6m 1m3w3m (1m+2m) 3w2h1d 8 15 12

33. 33 Operations / support team Typical evolution to Scrum/Kanban combo Henrik Kniberg 33 Feature team 1 Feature team 2 Feature team 2 Feature team 1 Feature team 2 Feature team 2 Scrum Operations / support team Feature team 1 Feature team 2 Feature team 2 Scrum Kanban Scrum step 1Scrum step 2Scrum + Kanban

34. 34 One day in Kanban land Henrik Kniberg 34

35. 35 ”One day in Kanban land” Henrik Kniberg 35 http://blog.crisp.se/henrikkniberg/tags/kanban/

36. 36 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 1 – one piece flow Henrik Kniberg 36 B C A D E F G H I J L K M

37. 37 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 1 – one piece flow Henrik Kniberg 37 B C A D E F G H I J L K M

38. 38 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 1 – one piece flow Henrik Kniberg 38 B C A D E F G H I J L K M

39. 39 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 1 – one piece flow Henrik Kniberg 39 B CA D E F G H I J L K M

40. 40 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 1 – one piece flow. Henrik Kniberg 40 B CA D E F G H I J L K M

41. 41 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 2 – Deployment problem Henrik Kniberg 41 B C A D E F G H I J L K M PO

42. 42 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 2 – Deployment problem Henrik Kniberg 42 B C A D E F G H I J L K M PO

43. 43 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 2 – Deployment problem Henrik Kniberg 43 B CA D E F G H I J L K M PO

44. 44 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 2 – Deployment problem Henrik Kniberg 44 B CA D E F G H I J L K M PO

45. 45 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 2 – Deployment problem Henrik Kniberg 45 B CA D F G H I J L K M !? E PO

46. 46 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 2 – Deployment problem Henrik Kniberg 46 B C A D E F G H I J L K M !? PO

47. 47 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 2 – Deployment problem Henrik Kniberg 47 B C A D E F G H I J L K M PO

48. 48 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 2 – Deployment problem Henrik Kniberg 48 B A D E F G H I J L K M C PO

49. 49 Next Dev Done Backlog 3 2 In production :o) Ongoing Scenario 2 – Deployment problem Henrik Kniberg 49 B AD E F G H I J L K M C PO

50. 50 Evolve your process Henrik Kniberg 50

51. 51 Kanban & Scrum are empirical Henrik Kniberg 51 Many small teamsFew large teams Low WIP limitsHigh WIP limits Few workflow statesMany workflow states No iterationsLong iterations Little planningLots of planning Capacity (aka velocity) Lead time (aka cycle time).... etc... Quality (defect rate, etc) Predictability (SLA fulfillment, etc) Kanban is more configurable Great! More options!Oh no, more decisions!

52. 2009-08-29 orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl 2009-09-01 orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl 2009-09-02 orem ipsum dolor sit amet, nse ctetur adi pis elit nisl AnalysisDevelopment Acceptance ProdNext Definition of Done: Customer accepted Ready for production Ongoing Done Definition of Done: Code clean & checked in on trunk Integrated & regression tested Running on UAT environment Ongoing DoneOngoingDone Definition of Done: Goal is clear First tasks defined Story split (if necessary) 2 3 3 2 Feature / story = completed = blocked = who is doing this right now 2009-08-202009-09-30 (description) Panicfeatures (should be swarmed and kept moving. Interrupt other work and break WIP limits as necessary) Priority features Hard deadline features (only if deadline is at risk) Oldest features 2009-09-03 ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl 2009-09-02 orem ipsum dolor sit amet, co nse 2009-08-27 orem ipsum dolor sit amet, ctetur adi pis cing elit nisl 2009-08-27 orem ipsum dolor sit amet, adi pis cing elit nisl 2009-08-20 orem olor sit amet, co nse ctetur adi pis cing elit nisl 2009-08-30 orem ipsum dolor sit amet, co adi pis cing elit nisl 2009-09-08 2009-08-20 orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl 2009-08-25 2009-08-22 orem ipsum dolor sit amet, co 2009-08-25 orem ipsum dolor sit ctetur adi pis cing elit nisl Task / defect Hard deadline (if applicable) Date when added to board orem ipsum dolor sit amet, co nse ctetur (description) Why (description) Who is analyzing / testing right now = priority = panic What to pull first xxxx kjd dj d xxx Kanban kick-start example Henrik Kniberg www.crisp.se/kanban/example version 1.2 2009-11-16 (description) orem ipsum dolor sit amet, co nse ctetur 2009-08-26 orem adi pis cing elit nisl orem ipsum dolor sit amet, co nse ctetur =task=defect

53. 53 Kanban evolution example 53 April 7 April 23 Henrik Kniberg

54. 54 Optimizing the WIP limit Henrik Kniberg 54 To do Doing Done orem ipsum dolor sit amet, co nse ctetur 1 Too low WIP limit To do Doing orem ipsum dolor sit amet, co nse ctetur Done orem ipsum dolor sit amet, co nse ctetur 2 Just Right WIP limit To do Doing orem ipsum dolor sit amet, co nse ctetur Done orem ipsum dolor sit amet, co nse ctetur 5 Too high WIP limit orem ipsum dolor sit amet, co nse ctetur Zzzzzzzzz orem ipsum dolor sit amet, co nse ctetur People often idle Slow flow (end-to-end) People sometimes idle (slack) People sometimes idle (slack) Fast flow Tasks rarely idle Slow flow Tasks often idle Lack of wall space... People never idle

55. 55 Evolve your own unique board! Henrik Kniberg 55 Some of these photos courtesy of David Anderson, Mattias Skarin, and various other people

56. 56 Kanban compared to Scrum Henrik Kniberg 56

57. 57 Scrum prescribes roles, Kanban doesn’t Henrik Kniberg 57 PO SM Product owner Team Scrum Master

58. 58 Scrum prescribes timeboxed iterations Scrum team Henrik Kniberg week 1week 2week 3week 4week 5week 6week 7week 8 Sprint 1 Plan & commit Review (release?) Kanban team 1 Kanban team 2 week 1week 2week 3week 4week 5week 6week 7week 8 Planning cadence (2w) Sprint 2 Retrospective Release cadence (1w) Retrospectives (4w) Kanban team 3 week 1week 2week 3week 4week 5week 6week 7week 8 Planning (on demand) Release (on demand) Retrospectives (4w)

59. 59 Scrum backlog items must fit in a sprint Henrik Kniberg 59 Sprint 1Sprint 2Sprint 3Sprint 4 Long running task Scrum Kanban WIP limit = 3

60. 60 Both limit WIP, but in different ways Henrik Kniberg 60 To doOngoing Done :o) B C A D FLOW To doOngoing Done :o) B C A D FLOW 2 Scrum board Kanban board WIP limited per unit of time (iteration) WIP limited per workflow state

61. 61 Scrum discourages change in mid-iteration Henrik Kniberg 61 To doOngoing Done :o) B C A D FLOW To doOngoing Done :o) B CA D FLOW 2 Scrum Kanban 2 PO I’d like to have E! Wait until next sprint! Wait until a To Do slot becomes available! Or swap out C or D! Policies

62. 62 Scrum board is reset between each iteration Henrik Kniberg 62 Scrum First day of sprintMid-sprintLast day of sprint Kanban Any day

63. 63 Scrum prescribes cross-functional teams Kanban supports both specialists & generalists Henrik Kniberg 63 Backlog Design orem ipsum dolor sit amet, co nse ctetur Fold Tape orem ipsum dolor sit amet, co nse ctetur TrimDraw 3221 4 3 orem ipsum dolor sit amet, co nse ctetur Scrum team Cross-functional team Kanban team 1 Kanban team 2

64. 64 Scrum prescribes estimation and velocity Henrik Kniberg 64 Sprint 1Sprint 2Sprint 3 Likely velocity: 8 per sprint (sustainable pace?) 2 23 12 311221 112 V= 8V= 7V= 9

65. 65 Estimation is flexible in both Kanban & Scrum Tasks Features Henrik Kniberg 65 1. Don’t estimate features. Just count them. 2. Estimate features in t-shirt size 1. Skip tasks 2. Don’t estimate tasks. Just count them. 3. Estimate tasks in days 1d 2d 0.5d 4. Estimate tasks in hours 12h 8h 4h S M L Hours? Days? Weeks? S M L 3. Estimate features in story points 1 sp 2 sp 5 sp 4. Estimate features in ideal man-days 1d1d 3d3d 6d6d ”Typical” Kanban ”Typical” Scrum

66. 66 Both allow working on multiple products simultaneously (if you must…) Henrik Kniberg 66 Green Product Green team Yellow Product Yellow team All products Cross-product team Scrum example 1 Scrum example 2Scrum example 3 All products Kanban example 1 Kanban example 2 Color-coded tasks Color-coded swimlanes

67. 67 Minor differences Henrik Kniberg 67

68. 68 Minor difference: Scrum prescribes daily meetings Henrik Kniberg 68... but many Kanban teams do that anyway.

69. 69 Minor difference: Scrum prescribes a prioritized product backlog Scrum: Product backlog must exist Changes to product backlog take effect next sprint (not current sprint) Product backlog must be sorted by “business value” Henrik Kniberg 69 Kanban: Product backlog is optional Changes to product backlog take effect as soon as capacity becomes available Any prioritization scheme can be used. For example: Take any item Always take the top item Always take the oldest item 20% on maintainance items, 80% on new features Split capacity evenly between product A and product B Always take red items first Policies

70. 70 Henrik Kniberg 70 Backlog Dev orem ipsum dolor sit amet, co nse ctetur Test orem ipsum dolor sit amet, co nse ctetur Day 4 Prod Common alternative in Kanban: Cumulative flow diagram Minor difference: In Scrum, burndown charts are prescribed

71. 71 Final points Henrik Kniberg 71

72. 72 Kanban & Scrum Comparison summary Both are Lean and Agile Both based on pull scheduling Both limit WIP Both use transparency to drive process improvement Both focus on delivering releasable software early and often Both are based on self-organizing teams Both require breaking the work into pieces In both cases the release plan is continuously optimized based on empirical data (velocity / lead time) Henrik Kniberg 72 ScrumKanban Timeboxed iterations prescribed.Timeboxed iterations optional. Team commits to a specific amount of work for this iteration. Commitment optional. Uses Velocity as default metric for planning and process improvement. Uses Lead time as default metric for planning and process improvement. Cross-functional teams prescribed. Cross-functional teams optional. Specialist teams allowed. Items broken down so they can be completed within 1 sprint. No particular item size is prescribed. Burndown chart prescribed No particular type of diagram is prescribed WIP limited indirectly (per sprint) WIP limited directly (per workflow state) Estimation prescribedEstimation optional Cannot add items to ongoing iteration. Can add new items whenever capacity is available A sprint backlog is owned by one specific team A kanban board may be shared by multiple teams or individuals Prescribes 3 roles (PO/SM/Team)Doesn’t prescribe any roles A Scrum board is reset between each sprint A kanban board is persistent Prescribes a prioritized product backlog Prioritization is optional. Differences http://www.infoq.com/minibooks/kanban-scrum-minibook Similarities

73. 73 Free download http://www.infoq.com/minibooks/kanban-scrum-minibook Henrik Kniberg 73

74. 74 Don’t be dogmatic Henrik Kniberg 74 Go away! Don’t talk to us! We’re in a Sprint. Come back in 3 weeks. Though Shalt Limit WIP

75. 75 Essential skills needed regardless of process Henrik Kniberg 75 Software craftsmanship Splitting the system into useful pieces Retrospectives As a buyer I want to save my shopping cart so that I can continue shopping later

76. 76 Take-away points Henrik Kniberg 76 1.Know your goal Hint: Agile/Lean/Kanban/Scrum isn’t it. 2.Never blame the tool Tools don’t fail or succeed. People do. There is no such thing as a good or bad tool. Only good or bad decisions about when, where, how, and why to use which tool. 3.Don’t limit yourself to one tool Broaden yourself Compare for understanding, not judgement. 4.Experiment & enjoy the ride Don’t worry about getting it right from start – you won’t The important thing is not your process. The important thing is your process for improving your process

77. 77 Perfection is a direction, not a place Henrik Kniberg