forked from coreyhaines/coderetreat-web
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathfacilitation.html
83 lines (80 loc) · 5.31 KB
/
facilitation.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
---
layout: default
page_name: facilitation
---
<h1>Facilitation</h1>
<p>
The facilitator is an essential part of coderetreat. Responsibilities include introducing the day (see <a href="http://vimeo.com/18955165">my introductory video</a> for an example), guiding pairs through each session, leading inter-session retrospectives and the closing circle. This page outlines what the structure of the day should look like, as well as tips for effective facilitation. I've also written a blog post on <a href="http://blog.coderetreat.com/on-the-role-of-the-coderetreat-facilitator">the role of the coderetreat facilitator</a>.
</p>
<h2>Structure</h2>
<p>Coderetreat has an established, time-tested format that is optimized for focused practice.
<ul>
<li>Problem: <a href="/gol.html">Conway's Game of Life</a></li>
<li>Length of Session: 45 minutes</li>
<li>Duration: 8.30am to 5 or 6pm</li>
<li>Pair-programming is necessary, as the knowledge transfer contained in that activity is essential to the practice</li>
<li>Prefer using Test-Driven Development (TDD)</li>
<li>After each session, pairs should be swapped</li>
<li>After each session, code must be deleted, not put in a branch, not stashed, just deleted with no trace left</li>
</ul>
</p>
<h2>The Day</h2>
<p>
The coderetreat day consists of 5-6 sessions, each session's learnings building upon previous sessions. The morning focuses on becoming comfortable with the problem domain, breaking old habits and beginning focused self-discovery. The afternoon pushes the envelope by challenging pairs to stretch their skills and understanding of abstractions, modular design and test-driven development.
</p>
<p>
With most groups, the focus should be on the fundamentals of software development and modular design, primarily the <a href="http://c2.com/cgi/wiki?XpSimplicityRules">4 rules of simple design</a>. Spend the day practicing these concepts, rather than pushing into new learnings.
</p>
<p>
Below is a rough outline for the day.
</p>
<ul>
<li>8 - 8.45am : arrival, coffee/breakfast</li>
<li>8.45 - 9am : welcome, introductions, explanation of the problem</li>
<li>9 - 9.45am : Session #1</li>
<li>9.45 - 10am : retrospective, break</li>
<li>10 - 10.45am : Session #2</li>
<li>10.45 - 11am : retrospective, break</li>
<li>11 - 11.45am : Session #3</li>
<li>11.45 - 12pm : retrospective, break</li>
<li>12 - 1.30pm : lunch, socializing</li>
<li>1.30 - 2.15pm : Session #4</li>
<li>2.15 - 2.30pm : retrospective, break</li>
<li>2.30 - 3.15pm : Session #5</li>
<li>3.15 - 3.30pm : retrospective, break</li>
<li>3.30 - 4.15pm : Session #6</li>
<li>4.15 - 4.30pm : retrospective, break</li>
<li>4.30 - 5pm : Closing circle</li>
</ul>
<h2>Suggestions for session topics</h2>
<p>Over time, based on experience observing pairs through the sessions, a facilitator will learn to stretch beyond these suggestions. For the first few opportunites, a facilitator can use the ideas below to guide them.</p>
<h3>Sessions 1</h3>
<p>Allow pairs to get a feel for the problem domain. Not everyone has seen Conway's Game of Life before, so this session will allow them to wrap their head around the task. After the first session, it can sometimes be useful to discuss the idea of deleting the code. Some people might have a bit of resistance to the idea. Gently explain that those are the rules.</p>
<h3>Session 2</h3>
<p>Discuss appropriate data structures around the problem. Is an array the right way to hold the cells? Introduce the idea of primitive obsession.</p>
<h3>Session 3</h3>
<p>Suggest that teams begin to stretch themselves. Discuss polymorphism as a better solution than boolean flags. Further reinforce the avoidance of primitive obsession. Push heavy exploration of abstractions.</p>
<h3>Lunch</h3>
<p>Lunch should be long. Participants should have the opportunity to socialize and discuss the morning.</p>
<h3>Session 4, 5, 6</h3>
<p>Explain to teams that the afternoon is about going past any self-imposed limits. Below are some constraints that can be introduced, chosen based on the experience of the individual pairs.
<ul>
<li>No if statements</li>
<li>No loops</li>
<li>Small Methods (<5 lines, 1-line?)</li>
<li>No language primitives</li>
<li>TDD As If You Meant It</li>
</ul>
</p>
<h3>The Closing Circle</h3>
<p>It is important to get together at the end of the day and reflect. The standard way if to have a closing circle where everyone answers 3 questions. Depending on the size of the group, you'll want to emphasize brevity. With 20-30 people, it can potentially take a while.</p>
<h3>The Three Questions</h3>
<ul>
<li>What, if anything, did you learn today?</li>
<li>What, if anything, surprised you today?</li>
<li>What, if anything, will you do differently in the future?</li>
</ul>
<h2>Whatever Language You Want!</h2>
<p>
The ideas presented and practiced in coderetreat are applicable to any object-oriented language. To this end, it is suggested that coderetreats are explicitly multi-lingual. While coderetreat is not a day to learn a new language, it is perfectly acceptable for someone to work in a language they are not familiar with. The facilitator should stress that at least one member of the pair should have a working environment. After all, 45 minutes goes by quickly, and it is a waste to spend the majority of the time getting a development environment raised up.
</p>