Agile Learning Labs

Ruby on Rails for Beginning Brain Surgeons

By Hillary Johnson

I've been teaching myself Ruby on Rails of late, and as such am getting a good dose, right here in the Learning Lab, of what it's like to learn something new at the ripe old age of 45. I'd say half our clientele is my age, so this is especially useful data.

I started, of course, by struggling through all manner of introductory texts and video tutorials, and I finally re-learned something I'd always known: When you undertake to aquire a skill, any skill, it's not necessarily a good idea to start with an "introductory" text. Why is that?

Your average introductory text says things like, "All you have to do is put tab a into slot b--but be extra careful while short-tacking not to overhaul the sheet or you'll be late flopping the genny and end up in irons." Whaaa? (If you'd taken sailing lessons from me years ago, you might have suffered such advice) The problem with "introductions" is that they're always authored by experts whose expertise does not extend to explaining things. So you get dumbed down instructions with no rationale, often using opaque lingo. They're always bizarrely over- and under- pitched. If you want to learn from the experts, read what they write for each other.

Pick up a text aimed at the "expert" level, and suddenly you find yourself eavesdropping on the real thing, and if you listen patiently, you can learn why something works, which for me is the only way to remember how to do it.
I finally got a sense of the why and how of Rails reading the first chapter of Obie Fernandez's The Rails Way--which a lot of people warn beginners not to attempt. This after several frustrating attempts at self-education through primers and introductions that left me feeling like Ben Stiller in Tropic Thunder when Robert Downey Jr. clued him in about how it's never a good strategy to go "full retard."

Similarly "above my head" are Ryan Bates' Railscasts. I learn maybe 10% of what he's saying each time I watch one, but they're so dense that 10% is quite a lot.

We've talked and thought a lot about the problem of teaching to all levels here in the Lab, and part of the reason Chris has evolved his teaching style to rely on exercises and simulations over lectures is that every level of participant gets something out of the interactive experience, while lecutre material is always either over the student's head, under it--or more commonly, both.

Postscript:

The title of this post is a bit of an homage to one of my favorite texts, Baseball for Brain Surgeons by Tim McCarver, a book that conveys utterly the mystery of baseball by delving fearlessly and lucidly into the mechanical and dramatic intricacies of the sport. The reading of it is punctuated by ahhh!s and ohhh!s and tingly now-I-get-it!s.

Story Sizing: A better start than planning poker

By Chris Sims

I've helped several teams adopt the practice of planning poker. It's a good and useful practice, but it’s about as beginner-friendly as Badugi.

The problem is that planning poker is a lot about numbers: “Is this feature a '5' an '8' or maybe a ‘13’?” New teams have no reference for what these values mean, and it leads to confusion. As they try to figure out 'how big' a story point is, teams frequently give in to the temptation to map a story point to some unit of time. I've heard: “Let's have our 'story points' be the same as days!” or “How many hours should a 3 point story take to complete?”

So what are story points, if not units of time? They are units of work. We count them and size them precisely because we don't know how long it takes to complete a point's worth of work until we have history and data that we can measure. This measured rate is referred to as the team's velocity.

Here is a super-useful technique for bootstrapping the sizing process. Steve Bockman taught me this approach, and I have used it with new teams ever since:

Start with a pile of stories, each written on an index card or sticky note. Have the team identify one story that is of roughly “average” size, not one of the biggest stories, nor one of the smallest.

Now find a wall that’s long enough to line all of the stories up from left to right in a single row. Take the “average” story and stick it on the wall, right in the middle. Pick up a second story—any one will do—and if it’s bigger, stick it to the right side, and if it’s smaller, stick it to the left. Keep doing this with each story, swapping them around and putting them in size order, until you’ve got them lined up like the Von Trapp Family Singers, smallest to largest.

This process usually involves some interesting discussions, and stories will tend to move about until the team is happy with the ordering. Sometimes you’ll identify a story that needs to be broken down into smaller stories, or find one that must be rewritten in order to be sized. All of this discussion is valuable; the team is learning and sharing important information. Still, in order to keep the process moving along, stop the discussion as soon as you’ve decided on a story’s rank. It's time to pick up another story card and find its place on the wall. It really helps to have someone acting as facilitator, to keep the process moving. Yes, you can hire me. ;-)

Once the stories are ordered, start at the far left and ask: “Is this the smallest story we’re realistically going to encounter?” If the answer is yes, mark that story as a 'one'; its size (or estimate) is one story point. When I’m facilitating this exercise, I start walking down the wall and have the team stop me when I reach a story that seems about twice the size of our one-point story. I stick a vertical stripe of blue tape just before it, to mark off where the one-point bucket ends and the two-point bucket begins. Similarly, I get the team to identify where the three-point stories start (they are three times as big as our smallest story), and so on.

I like to use Fibonacci numbers for story sizes, because they grow at about the same rate at which we humans can perceive meaningful changes in magnitude. Using this sequence, you can divide the rest of your wall into buckets of stories sized: 1, 2, 3, 5, 8, 13, and so on.

This approach to story sizing gets a team up-and-running. You won't get bogged down in philosophical discussions about the meaning of a 'story point', or whether or not a story point has a Buddha nature. It's expedient, engaging, and yes, even fun.

Try it out, and let me know how it works for you.

Cheers,

Chris