June 16, 2012
Team Dojo & Team CraftsmanshipBefore I say anything else, a big thank you to Clive Evans and Tony Denyer for all their help running the Team Dojo workshop at SC2012. It's not really possible to run it alone, especially if you're also organising the conference and running around sticking a video camera in people's faces, so their expert facilitation and technical guidance made it possible for me to have my cake and eat it.
Now, to the Team Dojo itself.
I run a two-day training workshop on collaborative design, where teams (often made up of people who've never met) have to design and implement a piece of software to manage a community video library.
It's my favourite workshop to run, because I think it stretches muscles that my other courses don't reach. To a larger extent, I feel team disciplines have been overlooked by the craftsmanship movement. It's not just about individual programmers creating great code, but also about how individual programmers, working together, can produce great software.
The SEI felt it important enough that they created both a Personal Software Process and a Team Software Process. I see, too, that we have Personal Craftsmanship and Team Craftsmanship.
Being the fiend that I am, I decided to try and condense this 2-day workshop into 2 hours. Because, well, I can. Chairman's previlege.
I won't bore you with the details of the exercise, but here's a short summary:
Participants form into teams and try to build software that comprises five user stories, with a bunch of acceptance tests that they must demonstrate their software passing through some kind of user interface to a 3rd party, who gives them points for every test they pass. They have, minus explanations and the scoring, about 90 minutes to deliver from a standing start.
The conference had a computer science theme, so I built a couple of interesting CS-type problems into the requirements (PageRank and Breadth-first Search), and - being doubly fiendish - did very little to explain them.
(To see all the requirements, acceptance tests and explanatory material, goto http://www.codemanship.co.uk/teamdojo )
Some aspects of the problem deliberately mirrored the problems they might face in the workshop, just for jolly. They were asked to build a social network for programmers, and the ultimate goal was to be able to select any skill and find the strongest team in the network, calculated as a function of the "kudos" (or PageRank, in reality) of programmers in the team, the number of degrees of separation between them, and their strength with that particular skill.
If only they'd had the software before the workshop started!
We asked them to write their top 3 programming languages on stickers and display them prominently on their chests, so everyboldy could see what each potential team members strongest languages were.
The SC crowd's pretty diverse. When you wander among the sessions, you see all sorts of languages being used - everything from Ruby to Python via Haskell and F#. Interesting, then, that we ended up with either Java or C# teams. They are the "business english" of programming languages, perhaps.
My initial expectation was that we'd get some really strong teams that stand out from the rest, and I had high expectations for some of the teams that formed, knowing the people on them.
To my surprise, when we totted up the final scores, almost all the teams ended up with the same number of points. A couple didn't quite manage to get any acceptance tests passing, and one team did marginally better than the rest, but the scores clustered very closely indeed.
A reminder to me that a strong team is not necessarily just a plural of "strong developer". There are undoubtedly team disciplines. One participant mentioned that he'd lost considerable time when a team colleague broke the build, for example.
The most important team discipline I've observed over the years is the ability to make decisions together. In particular, the ability to decide on a high-level plan and how all the pieces should fit together. That's not usually rocket science, that's "people science". A tam that can effectively collaborate seems to do just as well, if not better, than a team made up of star programmers. Of course, a team of star programmers who can work like a well-oiled machine together would wipe the floor with the rest.
Watching the conference video footage back, I noted the repeated use of the term "shaving yaks", as teams in the Team Dojo, and participants in other workshops, reported time lost to getting their environment sorted out.
Now, just as programming isn't about typing, issues like source control, build automation, test automation and so on aren't about the tools and the technology. But there's a lot of faffing and fiddling required, and that's what eats up our time.
Ideally, Eclipse, IntelliJ, Visual Studio etc would just have a button for it - a One-Click team development environment, if you like. Instead, what we have - for our sins - is a hidgepodge of disparate, clunky and user-unfriendly compromises in this space. Tool devs, get your act together - we're dying out here!
But, tooling aside, things like SCM and build automation revealed themselves in this workshop as areas we probably all need to work on. Even with the clunky tools, setting up a team environment should still only take a few minutes. I'm just as guilty as most. I don't think I've ever sat down and thought "I should practice setting up builds and CI".
Finally, to the feasability of the exercise itself. Can it really be done by a team in 90 minutes? I believe it can. When you actually get down to the individual user stories, they amount to code of comparable complexity to, say, the roman numerals converter. Given another hour, I suspect many teams would have passed a majority of the acceptance tests. Indeed, some participants told me they were "this close" to completing at least one more user story when I heartlessly called "time" on them.
And so, to the point of it all.
When I first try a code kata, it can take me 2-3 times as long to complete than it might tale me after a bit of practice. I suspect if the same teams were asked to do the exercise again, they'd score significantly higher. After 3-4 attempts, I believe most would be able to complete it and get top marks in under 90 minutes.
Would there be value in such repetition? I think there would. A lot of the time wasted seemed to be down to factors outside of the problem itself. By honing these skills, there'd be much more time to actually come up with solutions. We could test this theory by varying the problem in each attempt, so the skills being worked on would largely be these team disciplines.
Of course, there's only one way to find out for sure...
Posted 1 year ago on June 16, 2012