« February 2009 | Main | April 2009 »
Chris led three sessions at PCamp the day before we left for the Scrum Gatheirng: Agile 101, the ever-popular Agile Learning Games, and a new session with Ainsley Nies called "PM Principles, Values and Practices," a World Cafe session that delved into ways for PMs to apply the Agile Manifesto to their roles and areas of expertise.( I stayed home with a sore throat, bleh.)
This was Chris' first time running a World Cafe session, and it sounds like we'll be using that format more in future. The World Cafe website looks like it was designed by someone wearing a Che t-shirt and crunching loudly on GORP--so to spare you the kumbayaa lingo, I'll summarize the process:
I can see this working well when all groups consider the same topic, too, as it's interesting to see the variation in people's answers on a single question.
As promised to the participants, is the slide deck from Agile 101 session. Also posted on the PCamp Wiki. Enjoy!
And if you want to learn how to build Agile learning games, Chris and Elisabeth Hendrickson will be teaching a class in Portland May 1st.
Yesterday Chris and Elisabeth Hendrickson led a day-long dress rehearsal for a class called Creating Agile Games for Coaches & Consultants. The idea for the course grew out of various experiences: Chris has led sessions on Agile learning games at several conferences, and they've always been hugely successful, and Elisabeth has taught learning games, and held "game days" for coaches at her Quality Tree Software offices in Pleasanton. She's also done a lot of work deconstructing games, and building a set of principles and processes for how to create or adapt them to target specific learning objectives, as well as amassing an amazing array of boards, markers, spinners, dice and the like.
The day began when David Chilcott walked into the room and wrote on a flip chart: "Do not think that you will necessarily be aware of your own enlightenment." Which proved true more than once.
At the beginning of the session, one of our 14 testers asked, "How would you like to receive feedback, in the moment, after the fact, verbally, in writing?" To which we said, "Yes, please." I mostly lurked throughout the day, taking copious notes so that we might capture the goodness and update our program and class materials for when we offer the class fer real in Portland on May 1st.
To kick things off, Chris and Elisabeth discussed various game elements like chance, choice, turns, roles, winning, etc., and how to select elements to match different learning objectives. Then they laid out a basic set of steps and broke everyone into teams. Most of the day was spent devising games, while Chris and Elisabeth floated from group to group, jiggling them when they got stuck somewhere, but trying to stay out of the way of the creative process. Some phases ran long, and others we didn't get to, and we learned a lot from that about how better to calibrate the day.
We've always found dress rehearsals immensely helpful in developing classes, and this time was no exception.The opportunity to have an iteration 0 helped us immensely in shaping the future class. Going in, Chris and I were a bit worried that we didn't have enough structure mapped out, while Elisabeth, who has taught a similar class before, was more sanguine. We were wrong and she was right; starting with the minimum necessary framework was absolutely the right approach. I commented to Chris as we were packing out, "We learned where we needed more and where we needed less, and with more structure and planning--we would have learned where we needed more and where we needed less."
The same pattern emerged in the four groups collaborating on building learning games: The more talking a group engaged in, the less progress they made. The groups that shifted to a trial and error approach and started playing and iterating made more progress sooner. A group working on a game illustrating the value of TDD got bogged down in too much up-front planning. Rob Myers, a well-known TDD advocate, summed it up neatly, observing dryly, "We've spent half the day to arrive at the realization that test-driven development works!"
Over the years, I've grown to take more pleasure in being proven wrong more than I do in being right, as it means I've learned something new. I think Agile values and practices speak to me because they encourage that mindset, and I observed the same at work in the group of stellar minds who honored us with their presence.
Jeffrey Fredrick observed that learning games are quite fundamentally different from recreational games, which are most often about winning and losing.
Jeff McKenna remarked that it was hard to remember to think like a participant and not like a coach, but that one had to step out of the coaching role and think like a player in order to do the work of designing a game. He also questioned the term "game," suggesting that much of what was being created could better be described as "simulations," which speaks to Jeff's point about the characteristics of learning game objectives.
Three of the four teams ended with finished games: a poker-based card game, a game with dice and story cards, and a kinesthetic game where people went on a kind of treasure hunt for balloons. The fourth group worked on a complex game-in-progress Cesar Idrovo brought with him to the workshop, and they had some good ahas around that. Some groups built their success slowly and steadily, while others made progress in big, sudden leaps.
In all, the level of engagement was extraordinarily high, which is remarkable considering that game design appears to be composed of 90% frustration and 10% exhileration. "You need to bring in lunch when you run this workshop instead of having a break," Steve Bockman said, "We just wanted to keep working on our game without disruption."
Many thanks to everyone else who turned up, including Mack Adams, Daniel Bols, Peter Dean, Don DeCosta, Rich Gierak, Ed Kraay, Craig Sakowitz and Joanna Zweig.
We've turned on registration for the May 1st workshop in Portland. And ff all goes well with Chris and Elisabeth's submission, you'll be able to catch an abbreviated three hour version at Agile 2009.
The first thing I laid eyes on this a.m. was a hilarious tweet from Jose Ramon Calzada, a Mexican software developer: "Agile is like
teen sex: Everyone wants to do it, many say they're doing it, only some
actually are, and very few are doing it right."
Seeing that Calzada had as yet only one follower on twitter (he now has at least two), I visited his blog and ended up reading all about what disappointed him about his Computer Science degree: "Unfortunately, college ended up being, mostly, a dreadful experience.
It became clear to me that what I thought was a degree in Computer
Science was actually a mutant hybrid between Software Engineering and
Project Administration gone wrong." His college sought to turn out "People who will code for a while, out of need, but whose real purpose
in life is management. Our future wasn’t that of a software developer,
we were supposed to run consulting firms and manage multi-million
dollar contracts, writing code was below us."
What Calzada is getting at is, I think, a tremendous fallacy that lies at the root of the entire problem with software development models like Waterfall: the category error that treats the writing of code as a low-level mechanical process, rather than an ideational one, a matter of mere execution rather than creation.
A category error, as described by the philosopher Gilbert Ryle, occurs when you group something with the wrong class of phenomena. Ryle coined the concept of category error to refute Cartesian Dualism, whose error, according to Ryle, lies in the presumption that mind and body are "terms of the same logical type." The same idea is taught on Sesame Street to the tune of "one of these things is not like the other." In the set "cat, dog, bird, conclusion," the inclusion of "conclusion" is a category error.
Another common example of a category error is "library, dorm, commons, university." The inclusion of university on a par with the buildings in which the university is located on the physical plane is a category error. The university is more than a physical place, it is an institution, which includes both physical and ideational components. A university is founded and built on a physical plane, but it is embodied and inhabited on a notional plane.
The category error in software is to treat is to treat software like a building, and not like a university. The academic environment Calzada describes makes a category error when it perscribes the writing of code as a low-level manufacturing function belonging to the execution phase of an explicit process. This presupposes that code is rote, that design and process are separate, but even more critically, it presupposes that software is a building.
What would the process look like if we decided to treat software like a university instead of like a building? We'd need buildings, professors, students, a curriculum, something called school spirit, and of course a little bit of teen sex. Sounds a bit like an Agile project!
Yesterday I signed on to Jurgen Appelo's Complex Manifesto for Software Development, a document whose first principle is "Every problem has multiple solutions" and whose last principle is "It is impossible to predict the best solution." The Complexity Manifesto posits that the path to agility lies
not in the observance of a set of reductive, fundamentalist "thou shalt" and "thou shalt not"
commandments, but in the cultivation of mastery and discipline in all their complex glory.
I'm reminded of a big "aha" moment I had while reading sports writer John Feinstein's excellent book on golf, A Good Walk Spoiled. Golf is such a difficult game to master that even the great players are never actually good at it--they just suck less than everyone else. Feinstein wrote of one PGA Tour player who spent a year trying to improve his swing--it had to be taken apart and painfully put right, and during that process he was worse than useless, but then through some magical background process involving muscle memory, mathematics and emotional release, it all came together one day and he experienced an enormous gain.
My point (and I do have one) is that while there is joy in perceived simplicity, such as an easy, disciplined golf swing, or a smooth agile process, simplicity of that order is not achieved through reductivism and rule-making; it is hard-won through discipline and mastery. I was talking to Chris about this earlier, and he added that what sets agile apart is the thoughtfulness baked into its structure as a set of values and principles rather than a set of rules. "Rule based systems lend themselves to misinterpretation, misapplication and gaming," he said, "while systems based on values and principles empower individual choice and responsibility and lead to simple, elegant and appropriate solutions."
Appelo asks us to practice agility as an art, to enculturate our organizations with a set of sustainaable values, principles and practices that, once mastered, inform our actions from within. What he cautions against is the tendency to be reductive rather than expansive, to fret too much over what is and isn't agile, rather than focusing on growth and experimentation.
My own fear is that too much reductivist thinking too early in the development of the agile movement could lead to self-limiting rigidity, insularity and irrelevance before agility has even had a chance to mature and flourish. The Complexity Manifesto swings the dialogue back in a more generative direction. As Appelo says, "we must recognize that it is human to prefer simple solutions, but also that the world is more complex than we think."
