It's All a Matter of Perspective

Apparently, Eryn's braid issue with the dog could have been so much worse.

"Brancheau, 40, was rubbing Tilikum from a poolside platform when the 12,000-pound creature reached up, grabbed her ponytail in its mouth and dragged her underwater. Trainers rushed to help but could not save her."

http://news.yahoo.com/s/ap/20100225/ap_on_re_us/us_seaworld_death

Random Pictures of Eryn

For the folks and in-laws...

Eryn at the Valentine's Day (actually, the day before) Daddy/Daughter Dance. She LOVED the fairy wings and wore them later during the week. She HATED the random name-selection event at the beginning where you drew a heart out of a box and it had a fairy name on it. Her name was "Fairy Sweet Autumn Breeze" in case you ever really want to annoy her. We had fun - decorated cookies, decorated hearts, decorated the flower she got. She was excited about getting a blue flower, until someone else walked off with it, so this is the replacement in the picture. She won another later, so she walked away with two which made her happy. We also danced...a lot. I liked everyone singing along to Ring of Fire. I wasn't so impressed with the Grease medley.

Ring Mountain. Being silly with a glass of water.

Happy ice cream grin.

Poker Advice for Kyle's Dad

Kyle...did you know that according to St. Paul city law it's illegal to sell, barter, or give away baby chicks unless you're dealing in lots of 12? This would really screw up your Dad's baby chicks and brandy poker game unless the minimum bid was 12 chicks. We should keep that in mind in case we're playing poker at Dan'l's house again sometime soon.

And my sister should take note. I assume there are equivalent laws across the river in Minneapolis, and if she's intent on raising Urban Chickens, she better buy them in batches of 12. And once again, I include a law pertaining to the trapping of any animals, including squirrels. Just in case she's still up to her squirrel-related shenanigans.

Chapter 197. Sale of Baby Chicks

Sec. 197.01. Prohibition.

No person, firm or corporation in the City of Saint Paul shall sell or offer for sale, barter or give away baby chicks, less than one (1) month in age, in lots of less than twelve (12) in number.

(Code 1956, § 330.01)

Trapping-related:

Sec. 196.01. Trapping prohibited.

Except as may be otherwise provided in this chapter, it shall be unlawful to set traps or engage in trapping in the City of Saint Paul.

(Code 1956, § 323A.01)

Self Art

Eryn made a self-portrait at school. Pretty cool.

But what surprised me is that Klund was on the wall as well.

Winter Geocaching

I try to do a little bit of winter geocaching every year, despite that it's difficult because you can't be sure the cache is above the snow line, and it's freaking cold. Two weekends ago I went out with The Boss and looked for a few in the area. We did surprisingly well, finding three caches.

The best part about winter geocaching is that sometimes it's incredibly beautiful hiking around the woods while the trees are covered in snow.

A cool cache, just because it was tricky to find despite being so obvious.

I hope no one can figure out where the cache is after we were there.

A difficult cache just because it required us to pretend we were Galapagos Island finches to get the cache out of the hidey hole.

Elizabeth Bacon's Sundial Model

Elizabeth Bacon's Sundial Model:
My department recently (trending to not-so-recently) had a realignment. It would be more accurate to call it a reorganization. Reporting lines shifted en masse, so that's obviously what it was. The goal was to facilitate Agile development and how we interact with other teams in a vertical manner. While we had distinct objectives in mind, optimizing to Agile and vertical development are rather esoteric statements, and it's difficult to see how the realignment achieves this end without concrete examples. Here's one example, and how it ties to some theory. For the vertical development objective, our goal in reorganizing was to break down some of the specialization - what you see in Elizabeth Bacon's sundial model above as generally the bigger the company, the more those skills become defined as distinct roles (in our case it was code domains, not UX domains) - and code throughout the stack, bringing individuals with a breadth of experience to bear on technical questions so that design and architecture are as much a part of our daily work as development.

The issue with specialization, at least one of the issues, is that there is a premium, salary- and benefit-wise, paid by large companies for developers in order to hire people who willingly deal with an overabundance of process, don't mind the extensive roster of roles (role specialization, or at least the lack of generalization) that interferes with personal ownership, and flourish despite not working directly with customers. The premium isn't for the best developers (although that is a goal for any development team), but for developers who fit a set of criteria. Those criteria can be characterized as broken from some perspectives, particularly the Agile perspective, despite that they fit company needs. The flip side of this "corporate tax" is the idea of "golden handcuffs". It's a two-way street. While big companies shop for best of breed developers who still fit within their box. Best of breed developers who fit within the large corporate box shop for those companies to ensure stability, a premium on their salary, and a low-impact, mobility pressure valve that doesn't always come with a small shop.

Relating this to Alan Cooper's presentation, we can conjecture an interesting correlation between big company hiring practices, specialization, and offshoring. If the hiring goal is fulfill the above constraints, then the appeal of offshoring is, in part, that the company feels this developer persona can be offshored. What is headed abroad in many cases is not the job of a self-empowered, iterative, design-capable, agile knowledge worker - a craftsperson - but an extremely specialized, heavily process-focused, non-customer-informed, placeholder.

That seems harsh. As though I'm disparaging both onshore and offshore resources for large companies. But far from it. Large companies have specialization. They have process. They lack customer contact at certain levels. And to thrive in that environment is a skill, or set of skills, as is the reverse. And if we look at ShuHaRi, we realize that some of this work takes place in the lowest level of knowledge. But it serves as building blocks for moving to higher levels of knowledge and understanding. Onshore or offshore, the move toward craftsmanship (being a craftsperson) is inevitable in an educated base of developers. Consider the focus applied to process by new offshore groups. Then consider how, over time, the process evolves into something more. The natural progression, so it would seem, is to rise above the traditional big company premium restrictions. Moving the premium offshore simply delays an evolutionary change in how software is constructed or pushes the premium from offshore group to offshore group until the very last developer is empowered (a good place to argue Friedman's World is Flat).

The good news is there is space for the process-focused developer who is moving toward being a craftsperson, and for the developer who has already moved past that stage and is a craftsperson. It requires the former to allow the latter to stretch. But you have to acknowledge that you're the latter and put yourself in a structure that enables non-process focused, customer-oriented, iterative, generalized (ownership-focused) development. That might be Agile (in the strictest sense). Or it might be an organization rebuilt around the idea that these are positive goals to achieve and developers should be proactively enabled to drive at those ideals. Our department has started a journey toward Agile, and has come down strongly on restructuring to empower developers. We know we have a team of craftspeople and we're striving to allow them to actualize that reality despite, or perhaps by building upon the strengths of, the corporate tax.

Found It!

I think I found Eryn's painting. Bald guy in the background. Just to the left, two up (from the top of his pate). Kattycorner lower left from the silver plate. That would be Eryn's painting. Click it to get a little closer.

Foot in the Door 4 - Pooteewheet's Painting

Found it, although not in person. We were worried it might be a bit crowded the first week. They used this photo on the front of the Weekend Life section of the St. Paul Pioneer Press. My father-in-law's painting is immediately below the CC in the circle in the lower right corner. Pooteewheet's (my wife's) painting is five rows to the left and about two up (red painting with black, below the white and blue painting that looks like a piece of the sky). I'm still looking for Eryn's Black Sun with Gray Rays.

The Dangers of Extraneous Income

I should clarify. For my grandmother, this isn't extraneous income. She spent so many years working on the farm to make a living, that this just sort of allows her to enjoy her last decade (or so) without worries. Both my grandmother and my (deceased) Grandpa Harry have oil wells on what I believe is the same oil field in the MonDak area. Apparently they recently discovered a second oil field underneath the first one. For some reason, that immediately reminded me of Mr. Burns' slant oil company.

Ellen, being threatened by the oil well.

John being threatened. I'm pleased they're not wearing matching outfits. And that he got rid of that rat tail thing he used to wear when he thought he was haute couture Tucson so it's not hanging over his shoulder.

The Magicians

Mean Mr. Mustard (he no longer gets a link, because he no longer blogs) mentioned that he was reading The Magicians. I ordered it from the Dakota County library and read it over the long weekend. Excellent. It's Harry Potter, but de-bowdlerized. The teenagers are so angsty it hurts, and exacerbate it with drugs, alcohol and magic. The idea that magic is just another substance that teenagers use to escape is woven through the book, but so is the idea that it's incredibly difficult and seldom used because of the complexity. At least until the end/climax when things start to really get wild. Add a bit of Chronicles of Narnia gone scary, and you've got the idea. The only thing that I didn't enjoy was the ending, but that's just my dystopic tendencies showing through. If a book has a dark tone, I want it to end on a dark tone. Or at least a darker tone than you might get if there's a glimmer of hope.

Some of my favorite bits that don't give the plot away.

Grossman's reference to The Phantom Tollbooth. I've never heard another author mention it, and Eryn and I were just finishing up the book when I started The Magicians. If you have a kid, don't read them The Magicians. But definitely read them The Phantom Tollbooth. The story of a kid in search of the princesses Rhyme and Reason with the dog Tock is a a classic. I had to explain something new about language or numbers to Eryn every few pages, much to her delight.

This piece: "'Are you kidding? That guy was a mystery wrapped in an enigma and crudely stapled to a ticking fucking time bomb. He was either going to hit somebody or start a blog. To tell you the truth I'm kind of glad he hit you." (107).

My Stallions Are UNSTOPPABLE!

I have a new URL to NodToNothing!

http://5z8.info/toosexyfortv.mov_t6s4z_white-power-rides-upon-stallions-unstoppable

Please...click away! (via Shady URL)

LARP

Live Avatar Role Playing. Thanks to the Na'vi of Hometree, Wisconsin.

Lena's Got My Back

According to one of the advertisements in the back of the City Pages for Asian Massage in Bloomington, with every ten visits I get a free Swedish Massage! Wouldn't I want a free Asian massage if that's why I'd been there the first ten times? Does an Asian give the Swedish massage, or do they switch to some Nordeast transplanted farm girl from Owatonna area? But, better a free Swedish massage than whatever a "fantasy shower" is...that just sounds nasty. Like a bunch of masseuses involved in urolagnia.

Art Adventures

Eryn cheerfully volunteered to do a lot of the setup around my next Art Adventures project today. She was taking the many brown lunchbags I purchased and drawing elk hides on either side of them. Having an assistant is the best. She even made a demonstration illustrated hide for me to use with the classes.

This is the orientation they give us before each art adventure tour of the MIA

This is My Seventh Two-Headed Animal So Far...

I mentioned Eryn (and Pooteewheet, and my father-in-law) has a piece at Foot in the Door 4 at the MIA. A short video on some of the submissions:

Pigman?

I'm at a loss. This was in my context ads in Facebook. What does the pigchild have to do with debt relief? Are they telling me if I have all the medical bills associated with having a pig baby they can help me with my problems? Wouldn't I make enough money to help with raising my pig baby just by taking him/her on Oprah and the like?

I suspect this is just to catch my eye. I guess it worked.

Real World Agile User Experience Design - Jeff Patton (Part III)

I covered the first six patterns Jeff Patton says user experience designers picked up from Agile in Part II. Here we'll cover the last seven.

7. Schedule continuous user research in a separate track from development. You can picture this as an intersection of a few of the previous patterns: cultivating your user pool, chunking the design, and use parallel track development. The goal is to smooth out the design process so that it is stable and flowing into and out of development without being dependent on stages or waiting for a piece of functionality to complete. If developers decide, or their schedule dictates, when user research occurs, the natural breakpoints create a stop/start feel to design that interrupts the agile velocity (pacing) all groups should experience.

8. Leverage time with users for multiple activities - avoid thrashing your users by scheduling distinct meetings for distinct activities regardless of the time involved. Again, aim for creating a sense of continuous pace by having multiple goals for users to consider, including looking forward and backward as well as working within the current iteration.

9. Use RITE to iterate the UI (design) before development. Rapid Iterative Testing and Evaluation evaluates testing at the end of each day or after each participant, making changes to the interface almost immediately (if you need more information about RITE, this is a good slide show).

10. Design and prototype at the lowest fidelity possible. we've talked about the ease of use and portability of whiteboards before. Low fidelity means doing your design on a whiteboard as well, or some other easily portable, easily modifiable medium. Don't get carried away with using the latest tool, only to be trapped spending excessive time converting. From the tool to Visio. From Visio to Powerpoint. From Powerpoint to the wiki. Ad naseum. We've all done it. Instead, start simple and take a picture. Avoid formatting as an occupational time sink.

11. Treat the prototype as the specification. If you think you have a hard time with this, I suggest spending some time in my group at work (migration) and you'll realize there's a group more antithetical to this viewpoint than your own. But even within my group, we see places where this approach makes a certain amount of sense. Some of our projects are particularly heavy on design and proof of concept, and the POC drives subsequent development. It's not that simple, and invariably we find ourselves tracking backward to recreate the necessary documents and fit within the approved process flow - part of the tax of a large company - but the POC or prototype is still the heart of the project, and when we revisit requirements and design, it's that prototype we reexamine to determine the outflow.

12. Designer-developers iterate visual design outside the development timebox. Don't feel constrained to always finish up all cycles in all spaces simultaneously. After all, slavish devotion to aligning deadlines, despite the actual temp of productivity, is more characteristic of waterfall than Agile. Visual design is necessarily going to overlap development iterations as it captures the results of refactoring and attempts to anticipate new UI direction based on refinement of personas, interviews with customers, and reaction to new functionality (and customer feedback on that functionality).

13. Become a design facilitator. Patton's baker's dozen is rounded out with a bit of advice that applies to the previous twelve points. Learn some of the core skills of Agile: socialize, share, collaborate. Learn to communicate and increase communication touchpoints so that interactions are driving the betterment of your project. Patton offered some sayings/quotes to remember to keep that collaborative focus:

• "Design is not an artifact. It is a process."
• "Design is something that is done. It is not a role."
• and my favorite... "Design by community is not design by committee." (Leisa Reichert)

Future

Minnesotans...behold! (and anyone on the northeastern coast)...

Heart of the Beast

Eryn's school - the first graders - had a puppet show at the end of last week after working with the Heart of the Beast puppet folks. There were shadow puppets. Puppets on sticks. And masks. Eryn wore a bear mask. We thought she looked a bit like Scooby Doo.

From some of the dance.

Black Sun with Gray Rays

Eryn submitted a piece of art to Foot in the Door 4 at the Minneapolis Institute of Arts. She called it Black Sun With Gray Rays. It looks very official.

Kente Cloths

"First Grade Kente Cloths. Students learned about Ghana and the art of making Kente Cloths. Kente is an Asanti ceremonial cloth that is hand-woven on a loom. Four-inch strips are sewn together into larger pieces of cloth. Kente cloth comes in various colors, sizes, and designs and is worn during very important social and religious occasions. First graders imitated this art form by painting strips and gluing them down."

Eryn near the wall of Kente cloths.

Her Kente cloth. See if you can pick it out in the montage above.

Review Like a Pirate!

I can't remember who I got this from. I think it was Boing Boing. But then again, maybe not. I'll have to check my blogroll more carefully in the morning. But I modified it to suit my mood lately.

Collision

From the Arizona Star, "Collision". That's my father in the article below, restricting traffic after a van ran over him and his motorcycle yesterday. The collision cracked his helmet and totaled his motorcycle. The driver (who just pulled out of a gas station without looking or pausing - that doesn't seem to be uncommon in Tucson and wider Arizona) didn't have insurance (and reportedly this isn't his first accident without insurance). Fortunately, my father sounds to be ok. But their recent total is, a.) house robbed, b.) truck (a big pickup, for pulling the trailer, boat, motorcycle) pilfered, c.) motorcycle totaled by uninsured motorist. Nothing like having all your property screwed with at once.

A two-vehicle collision involving a motorcycle and a minivan has restricted eastbound traffic on Arizona 86 at Three Points, officials with the Department of Public Safety said.

The collision occurred just after 5 p.m. on Arizona 86 at the Arizona 286 Junction.

The motorcyclist is thought not to have sustained serious injuries because he was walking around after the incident, DPS spokesman Officer Robert Lee Bailey said.

Rating as a Team

(My reviewer says I shouldn't xb this one. It seems harmless, but I think I'm going to listen to the advice and give it an xb so I can find it in conjunction with similar posts, but not actually cross-blog it. I pushed enough buttons this week that I should take a breather. So here's a story about annual reviews. Not necessarily about my company, but about something I've seen at big companies, having worked at a few).

If you're reading this for some Agile insight, I have to ask you to bear with me until nearer the end. It's a very roundabout dig into how I feel about a topic that's at odds with Agile based on some recent experiences. But it's a good dig, the kind that, if you work for a big company, they're not always comfortable with you addressing. So it needs to be addressed, because you have to work all the harder at a large company with significant inertia to change behaviors.

Every year or, more accurately, twice a year, we do reviews at my corporation. I've had direct reports on and off for several years now, which necessitates doing reviews, and I've always been asked to do plenty of non-direct report reviews because I have a reputation for putting some thought into them. Fortunately, I'm running a little lower than my heyday of twenty plus, but with a bevy of direct reports (up 700%), I'm sure to have more this year. What I try to get into a review is not just my impressions from the year, but a reevaluation of my own impressions, trying to ensure a.) I haven't told myself a story about someone that's coloring my perception. I try to give everyone a clean slate in the sense that I throw away the narrative I tell myself about them and let them recast their narrative for the next year. Part of each review is identifying the story that was built up over the year and what was concrete and what was interpolation. In some respects, I try to build a counter story for the next year, so they have to work at dispelling a positive impression I've put together, actively working to dissuade me of their innate need to succeed. And b.) that I haven't internalized someone else's story for the same reason. I find that to be even more important, as stories about employees are rife in a company with 5000+ individuals at a site, and they tend to stick for longer than you'd suspect. One of the most important things in working toward being a manager was to identify the stories being bandied about in regards to me and actively work to offset the negative ones. If you haven't picked up enough of my personality in previous blog posts, the bigs ones were 1.) not promoting myself enough because I wasn't interested in getting ahead (make noise, even if you're not interested in a job or an opportunity, you have to explain your perception of why it's not the right move), 2.) not being an advocate of "up or out" (I'm still not, but it's mandatory I have a story to explain my own version of up or out and how it fits into the corporate strategy), 3.) not looking like I feel entitled to promotion (this fits in with, I know better how to manage my career than those who are trying to manage it for me...it's an incredibly fine line, and there was a lot of misperception initially, much of it my own doing - see #1).

That would seem to be a post in its own right. But it's just the opening.

This year, I heard one of these stories being shopped around. A recursive review story if you like, because the story is "X is an easy rater." I'm instantly suspicious whenever I hear the same story coming from multiple managers, unless I've been the one to put the story out there in the first place. If someone is regurgitating my story, I see it as an opportunity to refine my message. If it's a story I'm unfamiliar with, I suspect someone else of pushing an agenda. To the best of my knowledge, there's no fact or statistics behind this particular story. It's just being adopted as gospel because it's convenient. I've argued the flip side in manager meetings with a variety of "tools", as my last manager referred to that set of skills. A bit of displacement: our rating system seems to be tougher overall this year. Manager A used to rate most of his team particularly high. If he had still been here, we'd have been 10% higher overall. We're lower than we should have expected. This leads to discussion and some humor, with full knowledge that it was statistically accurate that up to 60% of Manager A's team(s) used to get in the top 20-30% of ratings.

Wait a while, then add the confusion tool when meeting with other leads and managers, using it to extend the narrative and reinforce it beyond the initial review meeting. "But perhaps Manager A used to rate his team(s) so high because they were together so much and really brought each other up as a team." The inevitable follows, "But we still need to evaluate the individual against the whole. Is Q1 really more qualified than Q2? Did they produce the same amount of work? Did they make the most of their individual opportunities? Why are they where they're at after all this time?"

It's at that point that I drag in the whole ethos of the department, "Didn't we change our organization so that we'd take the focus off the individual and put it on the team? Isn't our new direction centered on verticals and Agile? Shouldn't we be rewarding teams that exemplify what we're organizing toward?"

Loop it back to the initial discussion. The initial story. "That reminds me of X's team. They were criticized earlier in the year for their lack of ownership Not as individuals, but as a team."

There's a bit of dissembling from the whomever I'm talking to, which I'm counting on. I immediately move to offset with, "It was my director who called them on it. We had a lot of discussions around ownership and that team and how to remedy the problem. I was in the followup and review meetings to discuss what was done well and what was not. Individuals were mentioned, but the concern was with the whole team and how to change the communal attitude."

I'm not saying Director R would be easy on ratings. I know better. But Director R would be looking at whether ownership improved with that team this year and how that was servicing the wider department. That improvement might be credited to the lead. But the team improvement would be the crux of any investigation. Director R wouldn't be as concerned with the ratings. They were secondary to Director R's goal of better teams, better ownership, and better communication. So I ask myself, is their ownership better? Is their team better?And the answer is, almost to a person. They've changed one of their internal stories and followed through on living it at work. It's almost too bad we carved them up with the reorg, as they seem indicative of what we're trying to capture going forward. Ownership. Team focus. Reinforcing each other. Living or dying as a team. There are exceptions. But our own rating system works against really calling out the poorest players, pushing everyone toward a central bell that is more than a standard deviation wide on each side. 75-80+% fall into the middle. Reviews don't recognize the individual. And they don't recognize the team. If our reorg was truly focused on Agile, it should strengthen, should reinforce, those internal connections that are hinted at by teams with elevated ratings, that indicate Agile teams where there's a desire not to let down your coworkers, even if the individual review process weakens what we're trying to create.

Can you mentally scrap our review system? Instead, picture what teams you would reward for working well together, despite the restrictions and roadblocks that are there, that we're attempting to eliminate. Are they the same teams the highest rated individuals are on this year, or are there teams that produced without star players? Maybe X's team, even if you don't know them well enough, falls into that paradigm. Maybe X believes that of them.

And here we get to a big slice of the issue. Malcolm Gladwell says in Blink that we adjust to our explanations. We adjust to our stories. And if our stories are about rating the individual, and not rating the team, then that's where we put our focus. And the biggest issue is that our vocabulary, how we cast and perceive how we talk about something, is limited to a shared vision. In this case, the individual, not the team. Gladwell talks about "jam idiots". People who know that something is wrong, but can't talk about it, because they don't have the vocabulary to explain why it is wrong. In the case of reviewing jam, you don't know to talk about taste, texture, berriness. In the case of reviews, you don't know that "team" is a possible category. Experts have a vocabulary. If your'e not an Agile expert, team is not necessarily an intrinsic part of your vocabulary.

We file patents as a team. We produce as a team. We work as teams. We review as individuals. If our goal, our drive, is to create high-quality teams of craftspeople who work well together, then the vocabulary has to change. The review process has to change. And the courage to address that process has to change. It can't be something that even higher level leaders are afraid to address in print. There has to be a better way. And there has to be a better story. About the team. Not about the individual.

Minnedemo

Friday night I went to Minnedemo with Erik. I've been a couple of times and space is always tight. This time it looked like there might be fewer people in the Intermedia Arts building. However, we straggled a bit getting a last beer, and the next thing we know, the place is full back to the edges of the bleachers in the standing room only area. Looking back over our shoulders at empty space, we wandered back into the entry way where there was a wall projection, assuming Minnedemo would display there. After ten minutes, we realized it just wasn't going to happen.

This was the first time Minndemo had an annex, so we bailed, figuring paying for a few beers was a small price for watching on a screen that was actually displaying something. When we got to the bar, there were about eight to ten other people (more much later)...and an open bar. Comfortable chairs. A sofa if you wanted it. Appetizers. Sake nuts (Developer: "Are they called sake nuts because they're dipped in sake?" Waitress: "Um....no. They just go well with sake."). (Free) Surly Furious and an offer for a sake martini we passed on because of the volume of Surly Furious. And a large screen playing the event that was easy to hear and that you could talk to the developer next to you over without being rude. Best Minnedemo ever.

Here's the whole event, courtesy of Tech.MN, although you have to pay for your own Surly. I thought PedalBrain and MinuteBids were both intriguing.

Peeing on the Waterfall

One of the developers at work, on my recommendation, wrote an article for my work blog called, "Peeing on the Waterfall" about how Waterfall is a misinterpretation of something that was originally intended to be more iterative. It's surprising how much concern you have to put into a title like that, thinking about whether it matters for job longevity.

I might have said "no" if I had dropped that search into Google before approving the title, as the primary hits were:

• Someone actually peeing in a waterfall on MySpace.
• Lengthy stories about peeing in waterfall displays.
• And, most disturbing, the Urban Dictionary page related to Vagina Waterfalls. I quote from the section on Yiddish Waterfalls:

While a woman is peeing in the toilet you attempt to pee through her legs into the toilet. Of course this is nearly impossible thus you end up peeing on her urinating vagina thus causing a waterfall. Not typically done for wierd sexual pleasure. Only in the case that you both have to go and the house only has one head.

Oh shit there's only one bathroom at this fucking party !!! I guess we'll just have to Yiddish waterfall babe.

Really? This is something that needs a title/description? Just to be entirely above board, I once peed in the same porta-potty as a woman at a George Thorogood concert, but no Yiddish Waterfalls were involved, just a pleasant discussion about the concert, what we'd each been drinking, and pleasant introductions.

Advanced Squad Leader

Kyle and I used to play a lot of Squad Leader. Not Advanced Squad Leader, which involves this enormous binder of rules of such intricacy that it make the publishing systems at my company look tame, but regular old first-generation Squad Leader that came in a book case box and a dozen subsequent book case boxes as expansions. I remember our excitement when two different times, at Riverplace and at the Mall in Monticello, we found expansions priced to sell at just a few dollars each. The great part about Squad Leader was that if you had ten copies of one expansion, you could still string all the hex-based boards together into an enormous playing area. So when they were cheap, you had the opportunity to add real estate to your play area.

Which we did. We had whole weekends where Kyle, Goon (Erik, who know has an Eastern Orthodox name), and I moved little cardboard squares around several dozen boards spanning a significant portion of my apartment floor near the University of Minnesota while drinking beer and shooting the shit. It made for some memorable times. Like when we played for almost 72 hours, and the whole game involved ganging up on whoever had to take a bathroom break. Eventually it devolved into me in the mountains rushing in and trying to split them up where they had bunkered down in the city, and then them pushing me out and back up into the mountains, all the while trading hardware (machine guns, et al). Or the time we finally used tanks, and Kyle blew up one of my tanks, the joy evident on his face, only to have my tanks come around a corner and tip the game the other direction. And then there was the yelling, which introduced us to the girls on the other side of the wall. One of whom Goon dated, and another - a student at Aveda - who cut my hair for several years.

Sure...we could have been chasing women (and perhaps we were, given we were talking to them through the wall). But two of the most attractive women I knew from college (my wife aside) were seriously into war games and Russian military history. You don't get that kind of variety after you enter the real world, so it skews your idea of what's normal and acceptable behavior. If they think playing war games is fun, you just take it at face value.

Kyle and I have tried several times over the years to recapture a bit of that fun, but the Advanced Squad Leader rules are daunting. The attacker/defender fire and movement phases alone take some in depth study and practice, and many days it seems as though it's just easier to settle on some f*ing Eurogame. But once again, ASL calls. I can hear the small gun fire (or maybe that me getting offed with my .2 kill rate in Call of Duty on the Wii) and the rumble of the tanks. It's probably my fault for suggesting a game of Axis and Allies at our last gaming day. That's a gateway drug. Advanced Squad Leader is the heroin to A&A marijuana. Fortunately, the internet has occurred since we last really played, and there seem to be a few good tutorials out there to get us going.

At the moment, I'm reading this one at BoardGameGeek which uses a more lyrical approach to the rules (no 1.2.1.1.b, references 1.1.0.3.c) and jogs my memory of all the things we kept trying to remember and couldn't (oh yeah, cowering). I'm hoping it's a good place to start, and you know I'm optimistic as even these simple tutorials are over 24 pages per section. So a basic introduction is 160 or so pages, which gives you an idea of the complexity of the outlined rules system.

• Tutorial 1 - Basic Phases
• An ASLSK Tutorial (Part 2) - Support Weapons - http://www.boardgamegeek.com/thread/166941
• An ASLSK Tutorial (Part 3) - Infantry in Battle - http://www.boardgamegeek.com/thread/169542
• An ASLSK Tutorial (Part 4) - Ordnance and the To Hit Process - http://www.boardgamegeek.com/thread/177157
• An ASLSK Tutorial (Part 5) - Tanks - http://www.boardgamegeek.com/thread/361467
• Explanation of ROF (and Defensive Fire) - http://www.boardgamegeek.com/thread/88350
• Explanation of the Rout Phase - http://www.boardgamegeek.com/thread/122340

Real World Agile User Experience Design - Jeff Patton (Part II)

So what are User Experience designers learning from Agile now that the methodology has left its impact? Patton identifies thirteen patterns:

1. Drive: usability practitioners as part of the product team or as product owners. This is a good thing, but be careful about backseat driving.
2. Research modeling and design up front - this should happen, but only just enough. As (Alan) Cooper stated, there almost needs to be a Sprint Zero (0) or Iteration Zero (0) where product discovery can happen.
3. Chunk your design work - design work should, when possible, be handled in manageable chunks. We've all heard of sprints to investigate and dig into unknown (un-estimateable) pieces of functionality, but some digs can be too big to achieve in an iteration, particularly without an evolved basis for design decisions (understanding your decisions provides a context for future decisions...makes sense). It's important to know, Patton says, what's a napkin and what's higher level when it comes to design. To ensure these decisions can be evaluated accurately and chunked appropriately, some work can be done in advance (here we start to cross paths with Alan Cooper once again): a.) pragmatic personas can be developed, evolving from lightweight personas, usability sketches, and provisional personas; b.) backlogs can evolve into story maps and task analysis grids. Patton recommends The New Backlog is a Map as an evolutionary step; c.) start your usability investigations for Agile-centered design early, using tools like Sketchbook Pro (product). To give this point some relevance, think of internal projects, even Agile ones, that seemed to lose their way architecturally for a time. A lot of drift is expected in Agile, but it should be controlled drift, not the kind that comes from a loss of vision leading to meeting bloat and a feeling like the rudder has slipped the hand. A solid design should allow informed decision making and course correction rather than directionless floating in some Sargasso Sea.
4. Use parallel track development to work ahead and follow behind. What the product owner team is working on should apply to the previous, current, and upcoming iterations. Design and coded features should be passing back and forth between them and the development team.
5. Buy design time with complex engineering stories. Play a balancing game. Look in the story map and determine which stories are heavy on design and which are heavy on development. try to level by pushing lightweight design with heavy development to the front of an iteration (or even the whole project) to give developers something to do while they heavy design stories are researched. this plays hand-in-hand with chunking your design work so you know how the chunks fit on either side of your fulcrum.
6. Cultivate a pool of users for continuous user validation. Having to find new users each time a piece of functionality is considered can be a drain on a project and can delay design decisions. Identifying responsive users, ensuring a pool large enough to cover gaps (vacations, et al), and building a relationship and sense of pace with them results in more nimble design decisions.

Real World Agile User Experience Design - Jeff Patton (Part I)

I listened to Jeff Patton at Code Freeze 2010. He comes more from the user experience side than (Alan) Cooper, and he presented on the integration of design into day-to-day work. His core idea is that Agile, in eliminating the old BDUF (Big Design Up Front - I like BUFD, it sounds more like "buffed", implying some sort of dim, Jersey Shore, over-muscled, guy, which I can correlate to the slowness and excess of process often associated with Waterfall. By the way, you can get your own Jersey Shore nickname here. Mine is "Tan Jovi") process, has fundamentally altered how design is accomplished. Newer User Experience and Interaction experts are increasingly relying on lighter, more collaborative, practices that make design part of a holistic project approach.

Patton says that this history can be broken down into four parts. 1.) How User Experience (UX) was. 2.) How Agile wrecked everything. 3.) How User Experience design is in an Agile context. And 4.) What's next.

How User Experience/Interaction Design was...

Design followed an isolated phase model. That is, design was a separate precursor to other work, done by a designer or Business Analyst or business representative up front. It was characterized by fewer people, less collaboration, and more specialization. The emphasis was on information gathering, documentation, completeness, defensibility, and culpability. We all know the model or some variation on the model. Business needs >> user needs >> model the users >> high level design >> detail design >> specification >> develop software >> test (test, test, test...test, test, test) >> release >> maintenance.

The isolation of phases was obvious in the language gap (or syntactical overlap - choose your poison) between design and development and, later, between legacy design words and Agile vocabulary. Consider the difference between old school design and Agile when it comes to phrases and words like design, iteration (Agile builds it, Design sketches it), customer (Agile focuses on user story providers, Design focuses on the person who buys the product), user story (Agile focuses on what someone wants built, and Design focuses on a profile of a user), test-driven, and a "small bit of software" (Agile means "built in a few days". Design/UX means "something that seems small as a piece of user functionality. There's a enormous gap when you give that some study). The result when Agile, with its holistic, iterative, design/development/testing entered the scene, was to provoke in UX designers what Craig Villamor referred to as the five phases: denial, anger, bargaining, depression, acceptance.