- Convened by Agile Coach finding it hard to coach teams on technical practices (TDD, pairing, etc.) which he understands theoretically, but without the hands-on technical cred that someone with a technical background would have.
- Mike Bowler described a game using Lego to demonstrate the cost of technical debt.
- See full description on his site: http://www.gargoylesoftware.com/ex/technical_debt. Please send him feedback if you try his games!
- Highlights value of "clean as you go" coding.
- Sometimes illuminates danger of overpreparing, trying to foresee every future problem.
- Very powerful to include management, who can experience pain of tech debt hands-on.
- People walk away knowing, "When I took the time to clean my code along the way, I went faster."
- Important note: when Mike has run this in the past with some participants and some observers, he found that the light bulb did not go off for observers. Get everyone participating in this one!
- We spent a bunch of time discussing a messy kitchen as a metaphor for tech debt:
- The longer you avoiding cleaning up, the more painful it is to do.
- When you don't clean as you go, your efficiency is undermined by losing access to key resources (counter space, sink, specific utensils that are dirty).
- Group noted the important distinction between (a) what is needed to recover from ignoring tech debt and (b) what is needed to prevent taking on new tech debt.
- Llewelyn Falco described an activity he's used with teams:
- Look through code with team and find paragraphs--blocks of code the seem to go together.
- Ask team to extract those as a method and rename (available as keyboard shortcut in most IDEs).
- If team doesn't know what it does, call the method iDontKnow. Explore/discuss/refactor until you know clearly what it does, and rename appropriately.
- One good question for seeking out bad methods: ask team, "What method do you fear?"
- Llewelyn also discussed the value of code complexity metrics. One place he has found them especially helpful is in reporting to management what might otherwise show no visible effect: e.g., deleting an unnecessary 10% of a code base may yield no immediate apparent benefit, but clearly simplifies future development/maintenance.
- On simplicity: Mike Bowler described game: throw Lego out on a table and ask people to build a person and a house, then discuss:
- How much more simply they could have gone. Couldn't a single block represent a person?
- What assumptions underpin their move to build a representative person?
- If they were to build a simpler house/person, would that make things easier/harder in the future?
- Mike also discussed an even simpler exercise: completely clear the space in front of you on table. Say, "This is the perfect program. Why?" Discuss that it is free, has no bugs, no TD. Talk about what happens when you begin to code. Talk about how to keep as close as possible to that ideal state. How small can you make it?
- Someone said "a good coder is a lazy coder".
- General notes about coaching teams to try new technical practices:
- One person talked about experiences with people saying they don't want to do TDD when they haven't tried it. His response was to tell teams "We are here to learn how to ride a bike, not to discuss the merits of biking relative to walking. Once you know how to bike, we can have that discussion."
- Someone brought up sculpting clay vs. marble to highlight the mindset shift required of people who are not used to working in certain ways. If you talk to someone who has always sculpted in marble about techniques you use in clay, their habits of working in marble will make working in clay conceptually challenging. For example, they in marble you can't decide after the fact to add an arm on a torso, while in clay you can.
- Other links/exercises mentioned:
- Ping pong pairing: http://c2.com/cgi/wiki?PairProgrammingPingPongPattern
- Pairing game - "Evil pair variation": write code that passes the test, but doesn't do what it should. Forces you to think about how your tests can be gamed.
- Gilded Rose kata - (Search web for this exercise available in various languages.)
- Cyberdojo.kom - gives you katas with environment to play
- koans - little unit tests that work but fail, you fix code to make them work. They come in series of increasing complexity.
- Code Retreats - Amos King talked about these. Go somewhere--preferably offsite--and spend a day, a weekend, on a fun project. Use it as a chance to try things, practice skills, compare different solutions to the same problem. (I believe this site summarizes the same thing Amos was discussing: http://coderetreat.org/).
Thursday, May 28, 2015
Tuesday, May 19, 2015
We had 25 participants and we broke into 3 teams and played 3 minute Improv warm-ups games from: http://teamfirstdevelopment.com
We had a really good time together.
I gave out our flier and a handout on related to training the games. The flier is here: http://www.teamfirstdevelopment.com/wp-content/uploads/2014/06/team-first-flier-final.pdf
The handout is a Word doc. Email email@example.com and I'll send it to you. I can do a 1-4 hour workshop if you are interested.
Monday, May 18, 2015
In this session, about ten of us went outside on a glorious warm spring day to explore three different ways to take your team for a walk:
1. Docent-style visit to a destination: I had explored the area around the conference location on my own the day before to find an interesting piece of public art nearby, then did some internet research to gather some basic facts about it. I chose the 2010 sculpture Ring Stone by the Chinese artist Cai Guo-Qiang.
When we gathered at the MIT Sloan School entrance to view the sculpture, I told the team what I'd learned, then led a brief discussion about it. This particular piece with this particular group inspired speculation about what would happen in the future when the trees growing through the granite links of the giant chain got bigger, and about whether the links of granite had sufficient tensile strength to hold up the full length of the chain if suspended from one link. There was also discussion of the significance of the numbers 12 (links) and 7 (trees) in Eastern and Western cultures.
This type of walk can be completed in 30 minutes. It can provide a team with knowledge and a shared experience, a break from being indoors, a sense of connection with the wider physical land and world where they work, and can inspire creativity.
2. VTS-inspired discussion of sculpture in nature: Visual Thinking Strategies (VTS) is a carefully designed and powerful method of facilitating a conversation about a piece of art. It was developed over decades by the museum curator community. It has moved into K-12 education (e.g. see Philip Yenawine's book Visual Thinking Strategies) as well as commercial enterprises and non-profit organizations (e.g. see the work of Hailey Group). It is very synergistic with Agile practices.
We gathered around Henry Moore's Sculpture Reclining Figure (working model for Lincoln Center sculpture), spent a few minutes in silence, then the participants experienced a facilitated discussion using the carefully crafted VTS questions ("What's going on in this sculpture and place?" "What do you see that makes you say that?" "What more can we find?"). Without any expert to dole out official interpretations, within 10-15 minutes the group was able to move from seeing fun dinosaurs and a diving whale, to observations about specific bones (vertebrae, shoulders, hips, knees) and geologic formations, to alternative connections between the two pieces, and then to deeper observations about a human form seeming to emerge or "push out" or "ooze" out of ancient structures, about evolution and breaks over time, and about connections between ancient and modern forms. A key turning point in the 15-minute conversation came when a 10-year old participant noticed a tiny face on top of the "neck". Towards the end of the conversation, one participant found the piece on the Internet and noted that the bigger version of this piece in Lincoln Center was set in a reflecting pool.
This type of walk can be completed in 30-45 minutes. Especially when repeated over time, it can provide a team with heightened observation and listening skills, improved critical thinking, an appreciation of the importance of soliciting and connecting different perspectives, and a common experience of absorbing new information as an ensemble. It meshes well with the mindset of an Agile Retrospective, and with a culture of ensuring every voice is heard. Formal training in VTS is available.
3. Walk with Focus: Inspired by a description of a design community event at VergeNYC, I distributed a different "focus card" to each participant with a suggestion on what to focus on during the walk back to the conference location at One Memorial Drive.
Towards the end of our walk along a breezy Charles River full of sailboats and kayaks, we compared observations. One participant had turned it into a game of guessing how many different surfaces we walked on, supplying photographs of all 14 (!). Another tuned into the difference between bird song and manmade sound. Another found himself thinking about how much cleaner the "dirty water" of the Charles River is now. Examples of what might be on a focus card include: "WATER: Where is the nearest whiter? What does the surface look like? What does rain fall on? Where does the rain go?" or "SOUND: What can you hear? Try closing your eyes…How does sound change your perception of a space?" or "TOUCH/SKIN: What can you feel? Find interesting textures."
This type of walk can be completed in 20-30 minutes. Giving each person's mind a focus area can be a playful way to understand the benefits and drawbacks of intense focus as an individual vs. as a group.
It was a fun hour outside on a fine day, with participants coming and going as "guinea pigs" in these experiments. Like "wanna play a game?", "let's go for a walk" often meets with a positive response. One participant thought it would be useful to use focus cards and the VTS questions in combination as a substitute for the docent-style tours of his open workplace. As museum curators and K-12 educators have learned, while the docent-style mini-lecture can be interesting, engagement and retention is much greater when participants are part of a conversation rather than just listening. I also think that when teams do this together, they get stronger.
Logistically, it's important to be prepared for the weather (it was quite hot on the first stop when we weren't in the shade), to have a clear meeting place ("the stairs" was ambiguous), and to provide the route (so people could catch up). Explicitly suggesting early that it's best not to look at the title of public art would have been helpful. Explicitly suggesting sun glasses or a hat would have been good, too.
Personally, it was very satisfying to see people connecting more with the land around them in this small way. Nature and artists have a lot to teach us -- getting ourselves to pay attention is the challenge, and simply taking a walk helps with that. Many thanks to those who joined us!
Sunday, May 17, 2015
6 players + 1 convener (Cheryl) convened to experiment with open-source getKanban v2.0.
H & K played their own board with standard rules starting from Day 10 to about Day 12 before moving on to other sessions.
Cheryl worked through the basic rules and "played" the scripted Day 9 with 3 folks who missed both of yesterday's sessions and wanted an introduction. We discussed WIP limits, creating a pull system, and the impact of the starting queues on cycle time. They took the URL to download the open-source game kit and then moved on to other sessions.
Stuart worked through a complete game experiment on his own and finished through Day 21 before lunch. He wrote up a summary of his game choices and outcomes:
Used Cheryl's "potential subscribers minus cycle time == actual subscribers" rule.
Start: set aside two testers, instead of one, and played with only one tester.
2 devs per day rotated into Test, with 1 dev (a different person each day, because morale) remaining in Dev.
Day 12: changed the WIP limit in the Ready column from 6 to 3.
Day 13: ignored "Carlos".
Day 15: changed the other WIP limits to Design 2, Dev 3, Test 2.
Day 17: hired the extra tester, bringing total testers to 2.
Day 18: by this point the board looked good - light overall WIP and clear queues.
Day 20: just missed delivering the F2 trade show story so didn't get the 25 subscribers.
Day 21: cycle time reached a 3-6 day range (down from 8-10 at start).
Final gross revenue: $8,600.
Cheryl is most impressed that even with half as many testers, the outcome of the game was not much different from a typical game! Swarming Test to knock down the queue and reducing WIP to keep it from re-forming had the same impact on overall cycle time. Total throughput/revenue was affected by the lack of tester, but cycle time was able to be reduced just as effectively. Very cool finding!
Richard stopped by to talk about his and Renee's idea about removing columns on the game board. We haven't playtested it yet.
A group of passionate people (photos attached) got together to talk about the assignment of full time resouces to the team but... and the but was captured as the list of issues they have (photo attached) as well as some of the solutions they've seen and used.
This session was useful to me, as I got some good tips for future solutions. Others express similar thoughts. The session lasted for about 50 minutes.
Topic: Full Time But ...
Moderated by: Harvey Lindauer, Agile Coach
Monday, May 11, 2015
To make this the best Agile Games Open Space ever, session conveners are publishing their notes at AgileGames.OpenSpaceProceedings.com. To publish your session's notes, follow these steps:
- Compose a new email message with your notes.
- Address your email To: firstname.lastname@example.org.
- Use the Subject line to give your session notes a title, for example: Subject: Emotional Check In Game
- Snap photos of your flip chart, games session, or anything else, and attach them to your message, or type your notes into the message body.
- Tap Send, and your email will be published as session notes at AgileGames.OpenSpaceProceedings.com.