Craig Smith

Facilitating a Successful Developer Day

When an executive manager approached me a few weeks ago with the idea of running a developer day with one of his Java development teams, I jumped at the opportunity. The idea was simple: emulate the success of Google 20% time and the Atlassian Fedex day to improve the collaboration and skills of a bunch of developers.

Research

I started out with some research and found the following excellent resources:

• Atlassian on what is a Fedex day
• Mike Cannon-Brookes on Fedex days
• Dan Pink mentioning Fedex days and Google 20% time at TED:

• Atlassian Summit presentation on Fedex days, some of the key points from this presentation were: a million dollar gamble, 20 percent of development time, needs to be related to Atlassian product, business, or open source products used, every project needs support after 5 days (3 engineers) or 3 weeks (founder), scheduling hard, easier on large teams, tends to be small fundamental things that bug people
• Atlassian Summit presentation on some of the innovations (greatest hits) from Fedex Day
• Some good pictures and commentary from Atlassian fedex day, including the clock!
• Good overview of hackathons
• Bug Squash (these were also mentioned in Becoming Agile)
• Inter-Sprint Breaks
• Mike Cannon-Brookes at JAOO on Atlassian

The Running Sheet

It was decided (in hindsight, a fantastic decision) to hold the day in a neutral venue away from the usual office in a training room environment. The pre-requisites equipment-wise were at least one machine per two attendees (we ended up with two high-spec developer machines and a bunch of laptops), network access, a projector and the usual agile materials of post-it notes and pens. A supply of snacks and drinks was also available to give it a “start-up” feel.

As we had two days and wanted to also allow for some presentations and discussions, the run of the days ended up as follows:

Day 1

9.00am: Standup Introductions (All), why are we here, team building exercise (paper folding exercise)

Give each member of the group an A4 piece of paper, the facilitator needs one too. Have them close their eyes. The facilitator issues the instructions and follows them as well. No questions are allowed.

1. Fold the paper in half.
2. Rip offf a corner
3. Fold the paper in half
4. Rip off a corner
5. Fold the paper in half
6. Rip off a corner

The group can now open their eyes and find that there are many different shapes of paper. The debrief covers the need for two way communication and that the different perceptions of the people caused the many different designs. If time permits the group can be put in pairs. Have the pairs sit back to back and repeat the exercise using two way communications and find that the patterns come out closer

10.00am: Presentation (Agile Tools & Maturity)

11.00am: Brainstorm / Retrospective: What would make this a better team -> how can we make a difference in 24 (8) hours

The idea was to review the good and not so good of the team and help determine the issues the team would like to tackle.

12.30pm: Iteration 0 / Planning / Lunch

2.00pm: Iteration 1

Including a quick planning session

3.30pm: Iteration 2

Including a quick retrospective and planning session

Day 2

9.00am: Standup

Overview of highlight of yesterday and what planned to do today.

9.30am: Iteration 3

Including a quick retrospective and planning session

10.30am Iteration 4

Including a quick retrospective and planning session

12.30pm: Developer Practices discussion / lunch

Based on the development practices prescribed on the Donkey open source project.

1.30pm: Iteration 5

Including a quick retrospective and planning session to ensure ready for the 3pm demo

3.00pm: Demo Showcase

4.00pm: Closing Statements and circle

The Outcome

Well, it turned out better than I could have imagined! Iteration 0 everybody turned a bunch of PC’s in boxes and chairs and tables into 5 distinct teams. Story walls went up, planning started and the software required was downloaded (or people remotely accessed their work machines). Pair programming naturally happened (the limited number of machines helped this) and teams supported other teams when they ran into problems or needed assistance.

The 5 teams focussed either on stuff they wanted to learn or things they wanted to achieve to help their everyday work. The projects attempted roughly consisted of:

• a mobile web application using the Play framework
• investigation into using JMX for application monitoring
• automating WebSphere environment creation with JACL / Jython scripts
• scripting legacy mainframe account creation for testing purposes
• performance testing using JMeter and The Grinder

The morale was high at the end of the two days, everybody clearly learnt something and the developers were asking when the next event was. Success!