Agile Learning Labs

Agile Open Northwest - Agile Learning Games Part 1

I'm enjoying Agile Open Northwest. I hosted a session on agile learning games, in which we played three games:

• The Ball Passing Game
• Knot That!
• Arranging the Deck Chairs

I ran the session at 1:00 PM on Tuesday, and there was enough demand for a re-run session today. Each time we had about 25 participants. Here is a description of how to run the first game we played:

The Ball Passing Game (A.K.A. The Ballpoint Game)

Supplies

Balls
I use tennis balls, but anything similar can work. I did this once (now twice!) with paper cups and it worked just fine. Have at least as many balls as there are participants; more is better.

Bin
A bin, bucket, or bag to hold the balls (We used a chair for the cups). It should be easy to put balls in and get them out in a hurry. If it makes some noise when a ball goes in, all the better.

Timer
You will want a timer that can be set for 2 minutes. You want an alarm that will sound. In this is not available, then use a volunteer to track the time and announce when exactly 2 minutes have past.

Process

Arrange the group in a circle. Explain to them that their task is to 'process' as many balls as possible. A ball is considered processed when it has been removed from the bin, held by each participant at least once, and returned to the bin.

Any given ball can be processed an arbitrary number of times, that is, the total number of balls processed is not limited to the number of balls there are. Once a ball has been returned to the bin, it may then be removed from the bin and processed again.

Note: Multiple balls can be in process at the same time. The facilitator may choose to 'forget' to mention this fact until the group asks, or may simply state it at the outset.

The constraints

Participants may not pass the ball to the person next to them. A ball that hits the ground is returned to the bin and does not count. The balls must be held directly in the hand, they may not be in any type of container.

Ask the team to estimate how many balls they will be able to process in 2 minutes. Give them only a minute or so to finalize their estimate. Record it.

Give them 2 minutes, or so, to decide how they will process the balls. Let them know that they can move around, do almost anything, so long as they stay within the given constraints.

Once they have a plan, have them process balls for 2 minutes. Count how many are successfully processed, and how many are dropped. Ask them if they can improve, and give them a few minutes to decide how they might improve their process. Once they have a new process, ask for a new estimate and record it. Have them process balls for 2 minutes again. Record the number of balls processed and dropped.

Repeat this one or two more times. Try to end with a very successful run. That is, if the 3rd run went well, stop there. If not, give them one more chance to do better.

What exactly is agile design? Or better yet, what could it be?

Chris just published an article on InfoQ called Refactoring is Not A Substitute for Design about the debate over what role design plays in agile development. The worry is that agile processes shortchange the very principles of good design, because so much of agile happens at the granular level while design is seen as a macro-level activity. But is that the case? Here is the bit that I consider Chris' main point:

Big Design Up Front is not design; it is just one way to accomplish design. Agile practitioners tend to prefer a different approach, in which the current design emerges in response to the actual functionality being supported. The design reacts and adapts to the needs of the system, which itself is constantly evolving and adapting to the needs of the customers.

Chris addresses a common misconception, that foregoing up front design in favor of an agile process is tantamount to no design at all. Yes, yes, agile is anarchistic, the sky is falling, and kids these days listen to the darnedest music, we know, we know.

It strikes me that this type of sea-change has all happened before:

When the first impressionist painters broke the rules by dispensing with classical rendering and embracing naturalistic forms and gestures, a great many people refused to call it "art." But in hindsight, we now recognize the equal level of artistry involved in making art that departed from classical norms. Just because Van Gogh didn't block and draw on the canvas with charcoal before he took up his palette knife didn't mean he lacked an eye for shape, perspective and line: in fact, art students now are taught that "You must know the rules by heart in order to break them."  The expectation now is that artists will be able to break the rules, and thus they are now expected to know these things at the cellular level.

I predict that we'll look back on this change in our attitudes toward design and software in much the same way--we'll think of the curious olden days when developers were seen as code monkeys wrenching on software that someone else designed. By engaging developers in all aspects of coding, and including design and test, agile actually seeks to elevate design and function to a higher level of importance, to where it's part of everyday practice for everyone who writes code.

In Portland for Agile Open Northwest? Join us for coffee!

Chris and I are in Portland for Agile Open Northwest, which starts tomorrow. We would love to see any agile folks who might care to join us tonight at Ristretto Roasters from 5-7 pm for the world's best cup of coffee, hand roasted by my brother, Din, and the world's best chocolate chip cookie, hand baked by his wife, Nancy.

Ristretto Roasters

3808 N Williams Ave

Portland, OR 97213

503.288.8667

Is Agile a Culture?

Is Agile a culture or a process?

That's the question Jeff Patton is asking on AgileProductDesign.com. It's a question I've also been thinking about, ever since Chris and I shared a deep dish pizza at Patxi's in Palo Alto last week with Pat Reed, supreme mistress of the IT universe at the Gap.

What Pat has accomplished in terms of furthering agile adoption, and the thinking she's put into the hows and whys, is fairly stunning. She has a psych degree, too, which inclines her to always circle back to the human side of why we do the things we do--and she said, in effect, that the biggest stumbling block of all wasn't the teaching (or even the accounting) but enculturation--the transition to an agile culture.

In his post, Patton goes on to say that on one level "culture is process," and uses the example of what it means culturally to be an American--work hard, go to college, get a good job, have 2.5 kids, etc. Our culture, he says, is comprised of these processes,  which we then adopt or rebel against. The point, he says, isn't that we do all of these things, but that as members of the culture that holds them as values, we always return to measure ourselves against them.

Here is where it gets interesting for those of us who teach agile:

We must teach process, but if we try to teach this stuff as pure process--put tab a in slot b--we might get perfect adoption in the short term, but in the long run, once people revert to their human state, this system will break down. I hear a lot of "one true way-ism" around agile, statements like, "Well, if you're not doing XYZ, then it isn't agile, period!" But how useful is this? Is agile an object, a commodity to be refined to a state of purity in order to "burn clean," or is it a culture, in which we hope to live our professional lives with room to grow, fail and define ourselves, for ourselves?

In agile, we have a manifesto, some best practices, a few schools of thought, and even, as Patton adds, some myths and heroes. But if it is to be inhabitable as a culture, then it is vital that we use it as a framework to measure, test and strengthen ourselves against, rather than as a set of acceptance tests to pass.

To use an analogy: as human beings, we absorb much of our culture from our parents. And we accomplish this in any number of ways: by immitating them, honoring them, emulating them, and by rebelling, rejecting and defining ourselves against them. We draw strength from their guidance, and we strengthen ourselves by resisting them. Agile needs to be robust enough that we can treat it this way without breaking it.

In short, we aren't the parents here, but the children: we don't need to adopt agile; agile needs to adopt us. Only then will it be a true culture.

Agile 2009 is... agile!

Chris and I have spent a fair portion of the past week preparing session proposals for the Agile 2009 conference in Chicago. So far we're submitted five, and have several more in the pipeline, so I've gotten to know my way aorund the submission process...

...and am increasingly impressed with the system that the organizers have designed to plan this conference, and in particular the innovative interface web producer Rachel Davies has put together. What she's done here is one of the first really useful applications of social networking to business, if I'm not mistaken. From now on, when people ask me "What's the big deal about social networking--I mean, what's it good for?" I will point them to this site, which is the best example I've seen of the kind of purpose-driven, large-scale collaborative effort that social networking can accomplish, once we start to think outside of the MyFace/SpaceBook box.

Usually, geek conferences have paleolithic websites that barely function. This in itself is not surprising: architects always live in ugly houses, dog trainers have ill-behaved pets, and software engineers make clunky, stupid websites. But the Agile 2009 conference's website is a functional, form-ful thing of beauty, and the submission process it serves is actually (drumroll...) agile!

How is that? First, it is a self-organizing process, in that anyone can register and submit proposals, which are then open to comments from other registrants, and reviews from a slate of official reviewers and producers. Then it's inspect-and-adapt time: as would-be presenters receive feedback, they may then iterate their proposals up to the deadline.

It's a massive enterprise: Each of the 17 stages has two producers (ie, product owners) who will ultimately choose the program from among the submissions--not a small thing to volunteer for, as there are, as of this writing, just under 1000 of them, and we're a week or more away from the closing date. According to Conference Chair Joanna Rothman, the conference itself will have up to 20 simultaneous sessions going at a time (down from last year's 37, which Rothmann acknowledges was simply overwhelming to attendees, and demoralizing for presenters).

It's exciting and instructive to watch the comments and reviews accrue to our submissions. So far the only slam dunk is a session on Creating Agile Learning Games that Chris is co-presenting with Elisabeth Hendrickson, principal of Quality Tree Software, who is, to put it mildly, a pistol. When I first read Elisabeth's write-up, I thought, what kind of person wouldn't want to go to this? To judge from the comments so far, the answer is: only people who hate puppies and chocolate, ie, no-one. Our Agile 101 proposal is faring well, too, with one reviewer praising its "detail and clarity," which does help me justify my existence as TMI's publications editor (whew).

We've also proposed What Makes Agile Teams Succeed (or Fail)? and its counterpart, What Makes Distributed Agile Teams Succeed (or Fail)?, as well as The Agile Game, our spin on the XP Game (we are all about the fun and games at TMI). You will have to register to see the sessions, but it's easy and well worth the trouble, even if just to poke around--but why not propose a session? And by all means, we welcome comments on any of our proposals!

So far the session I'd most like to see hasn't been proposed yet: that would be Rachel Davies giving an experience report on how she designed and built the confererence website....

Fly SD West and get a free upgrade!

We've heard plenty of anecdotal evidence suggesting that tech companies are limiting travel to conferences as part of their cost-cutting measures, and as a result, conference registrations appear to be down. It seems to me that this is a false economy; training your people to be better at their jobs is probably the best approach to increasing productivity per capita in lean times, and the networking that takes place benefits everyone and puts your company in the marketplace of ideas. I say, you're either in or out of the boat, and if you're in, there's no point to having just one oar in the water, because that will make you spin in circles the harder you paddle. I used to teach sailing, so I am in fact an authority on these matters.

Never fear, SD West, which will be happening right here in Santa Clara March 9-13, is offering free upgrades that will allow you and your favorite comptroller the opportunity to be penny-wise but not pound-stoopid:

Register for an All Access for the cost of a VIP Pass. The All Access Pass is the only pass that includes full access to both SD West and Mobile Connect.

Register for a VIP Pass for the cost of a Conference Pass. The VIP Pass includes full access to SDWest.

That's a smokin' deal, especially as Chris will be leading a workshop on the musical topic of Why Do Agile Projects Succeed (or Fail)? that you'd be remiss to miss.

Register for your upgrade here, using discount code 9WUP.