At the risk of writing a giant post that’s hard to get through, I’m going to outline a few of the choice spots in each of the talks I attended and a few connections I made over the course of last week.

The Gaylord Texan:  Quite the resort, you feel like you’re on an island b/c everything is enclosed under a glass roof.  It’s really a nice resort with many amenities some more notable ones were the 4K sq. ft. health center that was open from 5:00-23:00 each night.  Most places have one, but this one was huge and had a wide variety of gear, treadmills, etc. to fit any workout into.  Most of the guest facing staff wore smiles most of the time, but the convention folks for whatever reason didn’t.  Think of an ant farm, that’s how we spread out over the convention space each day for 9 hours, we were everywhere and they still manage to feed us, and see to our needs over the week.  I’d go back on my own dime some time if the opportunity presented itself, a very comfortable place to be sure.

Agile 2012:: The Conference

I was excited to have the opportunity to attend my second Agile conference, the first in 2010 at home here in Orlando.  And this one didn’t disappoint in any way, this community is very much alive and well, and kicking!  Every session I attended I was either paired with another person for the workshop portions, or a member of five or more session attendees to solve a problem.  I really enjoy this aspect of the community and conference b/c it reinforces the notion of working together immediately.  In our case it was five or so minutes after we all sat down at a table and introduced ourselves.  All of the folks I interacted with was easy to talk to and had great questions about what was going on where I worked and this reciprocated over the course of the week in all of my sessions.  The conversations and connections with other members in this community was/is stellar, everyone is willing to help solve problems in different contexts, you just have to take the time to sit down and let it happen.

Software-Craftsmanship:: Simple Design Applied : Removing Duplication and Naming

Removing Duplication:: We looked through some really “troubling” code the speaker had encountered and had to realize what its intent was.  After no less than three minutes of trailing back and forth through the code (in pairs) the two of us realized the code was trying to build a calendar for a client-side drop-down, and this example was server-side code written in Java so it was easy for me to follow along after we figured out what the intent was.  The point the speaker made was about code commonality and variability.  Most of the common (duplicate) code in the code sample could be refactored into smaller reusable chunks, but first you have to detect the commonality in the code.  Next, we identified the variability in the code.  Some of the variability was introduced b/c of the types of arguments being passed to the methods; some of it b/c of a group of if/else code echoing the arrow-head anti-pattern making the code harder to change b/c of variability.

Naming:: Stroop Effect, as in Blue Red Black.  The test was to understand how quickly you could understand what color the text was referring to, not the color of the text itself. This translated into what should we be naming the different objects and members in those objects as we go along.  The rule is to name for less cryptic names, and more meaningful names.  I’m probably for too liberal with character naming but I did realize there’s a happy medium in the length and meaning of the names we choose for things.  A few of the general guidelines: the name is

1) pronounceable

2) avoids encodings and member prefixes

3) suggest why it exists

4) suggests how it should be used

5) what it does

6) easily searchable in the code base

So the punchline is when you’re crafting code think about the names you’re going to apply.  The names of things don’t have to be elegant, just appropriate.  And for variability, check-in on the variability if you see more coming out of your design, it just needs to be easy to spot.  Make the commonality easy to detect as well – for the consumer and the developer who has to look at your code 12 months from now.  The refactored code was much easier to read, understand, and potentially maintain.  The side effect was there were more methods, not a huge reduction in the amount of code, but the class’ intent was more understood with simpler design applied.

Collaboration & Communication:: Improving Collaboration and Communication through Improvisation

The notion here was to learn how to listen, as one Greek teacher stated, “we have two ears and one mouth”, so we should be listening twice as much as we are speaking.  Here’s a few of the games we all participated in: First Letter, Last Letter; Alliterate Adjective; Three Things in Common; Answer Man; Quick Draw; and we ended the session with “Group Juggle”.  The few that stuck out was Answer Man, Three Things in Common, and Group Juggle.

Answer Man went like this.  Three people at a time from the session would stand in front of the room and be “Answer Man”, someone you could ask any question.  The trick was the three people had to construct the answer in sentence form one-word-at-a-time.  The other two people helping to construct the sentence had no idea what word the third was going to say.  As the sentence continued to grow more context came out and then helped them finish the sentence.  Some questions were never answered though, the words would build a trail of words that couldn’t find an ending.  The point was hear was was being said, not what you wanted to hear the next person say.  It’s not as easy as it sounds, and proved a great point.

Three Things In Common went like this.  It was a basic interview to find three things you and the other person you were paired with had in common.  I was paired with someone from the midwest and another from Germany – this took time, longer than I expected.  And the three things could be obvious, that had to reflect something going on outside the conference closer to our real lives, and closer to home.   The notion here is to be patient until you get the information you both can agree on, not something that’s not quite fact.

Group Juggle went like this.  The speaker split the room into two groups of 30 or so people.  We went out into the hallway and formed to circles.  Each circle was going to toss a rubber ball to a random person across from them until everyone had caught and thrown the ball once.  We started with one and ended up with four going at once.  The fifth ball we were all juggling had to go in reverse while the other four were getting tossed in the regular order.  Many of us dropped at least one, or became confused because we took our eye off the ball being thrown at us b/c we were watching how the rest of the team was doing.  The rubber balls represented tasks we juggle on a team, and handing them off to one another.  The point was that some folks would wait until the catcher was ready, and some didn’t.  Other folks would verbally ask if they were ready for the toss, others were on automatic and just threw, caught, and reset to catch and throw the next thing coming at them.  Again, we’re all working with people  we met an hour earlier and don’t understand how they “catch and throw” tasks.  Its probably a good idea to iron this out when you, or a new member, joins your team.

Just before we wrapped with Group Juggle, we had a discussion about the “Five Dysfunctions of a Team”, here’s the graphic

Layers aren’t isolated, but part of another problem a layer or two above it.  Looking at other bloggers take on this graphic my mileage is going to vary but I’ll try to convey the key points the speaker was conveying.

If the top three are failing, there may be “no-conflict”, meaning everyone is agreeing with everything w/o sharing opinions.  Conflict can have a few different meanings in this context, “no-conflict” such as eye-rolling and silent disagreement as examples.  Or conflict can be rude, nasty, put-down behaviors.  By simply agreeing to disagree or working through the conflict you can get to the next layer commitment and start working there.  Working up through the next two layers once you get to, and succeed at the “Results” layer, all egos have left the room.  I’ll probably read Pencione’s book at some point but it will probably be before I begin working on a larger Agile team with a common goal, most of the what the speaker shared was enough to get the main ideas across about working through the layers and realizing the interpersonal pieces that aren’t working well across the team.

Tuesday’s Keynote:: Scaling up Excellence. Mindsets, Decisions, and Principles: Bob Sutton

Wow, this guy was amazing and the first time I heard him speak.  My leader picked him out of the conference as one to listen to, and so I listened and wrote as fast as I could, you can only write so fast to capture all of the nuggets flying off the stage, hopefully they taped this and will share it post-conference sometime.  Here’s a few points from his session:

Scaling from few to many:

• At FaceBook,
  • not just sharing the mindset, but practicing and living it, not by what we tell them to do; it’s clearly apparent what it is and how they need to perform
  • make one little change, one after another
  • Six-week boot camp for new members
    • Do chores for other groups working inside 12-13 short projects
    • the job (where they fit in) is determined at the end of the six weeks
    • touch the metal, understand the code base, move fast, and break things
• At Starbucks
  • How to water down the Starbucks experience…
    • Remove the tangible experiences from the stores, specifically the smell of and grinding coffee in front of the customers, something customers remembered most but that aspect was removed later to make room for the bagged version of the brand
• More vs. Better
  • Voltage loss is induced sometimes when an organization scales out, some things get lost in translation as the scaling occurs and the same results aren’t being achieved at scale because the localized plan to achieve the same results at scale are communicated, received, or interpreted correctly.
  • Voltage loss may not be bad, 1/2 as much better may be twice better than the way it was
  • Catholicism vs. Buddhism (replication vs. localization)
    • Replication Trap: Home Depot opened 12 stores in China and introduced their Do-It-Yourself culture to a Do-It-For-Me culture – they’ve closed 7 of the 12 stores so far
• Link Hot Causes to Cool Solutions (might be my favorite part of the talk)
  • When folks are really riled up about something, they’re probably thinking very, very hard about the problem
  • Offer them a cool solution that gives them somewhere to channel their energy.
  • The Watermelon Offensive: a large university wanted all undergrad students to wear bicycle helmets around campus but none were interested while almost all graduate students did.  The safety group decided to host the watermelon offensive.  The group had bikes laying all over a field with what appeared to be riders attached to the bikes with a smashed watermelon near where the head would be.  At that moment they offered the helmet at $7, less than half of what one would have originally cost them, and it worked for most that attended.

Software Craftsmanship::Deliberate Practice – becoming a better programmer: Alex Aitken

The rule is to become an expert you need 10K hours (five years of full time work) of deliberate practice, that’s a long time.  The thought that hit me was if I’ve spent 10K hours on anything besides breathing, maybe so, I hope so anyway.  Deliberate practice is how to pull this closer to being an expert at any level, or just moving yourself forward.

In this session we did a FizzBuzz Randori where we used test driven development to solve FizzBuzz in two minute pairing sessions.  Afterwards we did a mini-retrospective to see what we learned through the course of the randori…

1. taking smaller coding steps through the process produced more dialog for each pair
2. learn to (re)name code members where and when appropriate
3. try something, fail, throw it away

This was just one randori, YMMV where you live and code with your friends/peers, but the observations are for-real.  Things you can take away with you to prop your code better than you did the day before.

The speaker also discussed Coding Calisthenics that he uses, he proposed not trying to use all of them, but trying to work them into his code incrementally helped him craft his code a different way some times and think of other ways to solve a problem.  Here are the nine rules he uses for exercise:

1. Use only one level of indentation per method
2. Don’t use the else keyword
3. Wrap all primitives and strings
4. Use only one dot per line
5. Don’t abbreviate
6. Keep all entities small
7. Don’t use any classes with more than two instance variables
8. Use first-class collections
9. Don’t use any getters/setters/properties

This was probably my favorite SC session because it was more real-life to what I’ve experienced in some of the dojos I’ve participated in here at home.

I’ll wrap this post here, there’s a lot more to recall and remember but I hope you’ve got the idea that for the heavy price tag the conference carries, it totally changes the way you think about projects, collaboration, succeeding, code-crafting, and connecting with the folks you just met and may never meet again.  It’s all good.