English to English Translations

Back when I was in Little Rock, there were a few mixups with the local language that I just didn't know how to process. Asking the questions landed us all on the same page. It's from this that I've created a table of English-to-English translations.

Phrase	Meaning
y'ort'a	you ought to
y'all	you or you all

Our current San Francisco team includes an Australian and an Englishman. The phrases they've brought to light for me in two weeks are top notch.

A rather incomplete list of things that mean this is bad

• This is a bit how's your father
• This is a bit pants
• This is a bit ass about face

Proposal

Finally, I'm throwing my own entry in the ring: cabbage. For my money, there's nothing more subtle in its badness than cabbage.

This is [a bit] cabbage.

Project 2

Way back in September, I took a 1x2 plane that touched down in Little Rock. The flight itself was delightfully uneventful — those tiny planes get to skip the \heartfelt\ update from Jeff Smisek "and [his] 80,000 coworkers".

After landing, all 30 of us aboard the plane shuffled out of most-delightfully-sized airport I've seen, but not before I checked in to gate 11, of course — this airport isn't going to mayor itself!

I've come to expect personality, conversation, and, well, danger out of late-night airport cab runs. Little Rock's James, just entering his 53rd year, gleefully delivered on 2 of 3, albeit silently for far too long as I dug deeper and deeper into the details of my destination.

James	Where to?
Me	The DoubleTree
	*awkward pausation*
Me	...in Little Rock
	*no response or movement*
Me	...downtown
	*continued awkward pausation*
Me	...on Markham Street
James	MmmHmmm. I should hope so. Only one we got.

I could tell early this place was going to be memorable.

NOTE While sarcasm has recently gotten a font, it isn't available everywhere, hence \heartfelt\

TIP Interested in my battle for the mayorship of the Little Rock Airport Burger King? Follow me on Foursquare

Project 1 Lessons [Retrospective Lead]

Progress on our project hasn't quite been at the pace we would have preferred, though time has certainly flown by. In fact, our speed of feature development was one of the hot topics at this retrospective — the first retrospective lead by the fearless team of Chris and myself.

Overview

Briefly, a retrospective is a look back at the previous cycle of work. There are several methods to go about it, but we're always trying to answer certain questions:

1. What went well?
2. What didn't go well?
3. What's puzzling?

We started our retro in the same fashion as any other: a thorough reading of the prime directive.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Concrete Implementation

After covering our progress on action items from the last retro, it was time to jump into reflecting on our newly-completed iteration. We chose the rather standard format of placing stickies on a whiteboard. Everyone had roughly seven minutes to put as many thoughts as they could capture into their respective categories.

Our retrospective process is fairly democratic. We first want to make sure all the thoughts are captured on the board. Second, we group those thoughts into broader topics. Finally, we give everyone three votes to spend anywhere they like.

• one cannot vote against a topic
• one may spend all three votes in the same place

Discussion generally revolves around the things we can improve. Our retrospective was no different. We dutifully captured input and action items for next time, as well as recording owners for those action items (with group consensus, of course!). Oh David Allen, where would we be without you?

Velocity Check

Sometimes it's necessary to devote time to specific areas of concern before they become problems. The final piece of our retrospective was a section devoted to velocity, or the pace our team is completing features.

On the suggestion of a teammate, the visual we chose for this was a boat. Very similar to the exercise that preceded it, thoughts of things that made us go faster were near the engine of the boat. Ideas for what exactly has been slowing us down were placed near the anchor.

Perhaps unsurprisingly, virtually all of what we discovered here was covered in some form or another during the previous portion of the retrospective.

Takeaways

All in all, it was a pretty successful retro for the team, as well as for Chris and I. We did a many things well and received some helpful feedback on areas to improve, namely:

• Timebox discussions and activities
• Minimize open-ended questions

Both points lead to the overall goal of having concise and effective retrospectives.

Project Fact Our iterations are two weeks long

Comedy Quote "No no, my vote was voting against!"

Project 1 Lessons: Part 1

It's amazing how fast weeks go by on a project.

It feels like just yesterday I found out I was headed to California for my first project. Suddenly a month has passed and we've cruised through one-and-a-half iterations. A few general lessons have been learned along the way that I'll surely be applying in the future.

Be Uniquely Identifiable

I made an attempt early on in the project to go by SG Hill. This was a new venture in person that didn't quite pan out for a number of reasons. The need for a name other than Steve was obvious and pressing. As is so often the case, I have a teammate named Steve. Ultimately the problem has been solved with the kind of class and style only software developers could pull off.

I'm now new Steve(); whilst my elder teammate has become known as Steve.Instance();

Learn Over Lunch

One of the great things about bringing together so many people of different backgrounds and experience levels is the knowledge transfer that could potentially happen. Getting it to actually happen requires some effort. Three weeks ago we made the effort to have lunch in the office one day a week for a little thing we're calling Lunch & Learn.

The response to L&L has been better than anticipated, and we've covered some varying topics so far over pizza and sandwiches.

1. ASP.NET MVC - Testable software designs
2. Feature Toggling (nToggle) - turning features of software on and off from a switch in the codebase
3. Automated Functional Testing - Automated testing of web applications through a browser with Selenium

Perhaps the biggest benefit to giving these presentations over lunch is not the new ideas being shown, but the discussions generated around them from the questions being asked.

Quote of the Day as said in a Russian accent "Pizza without beer? This is...crime"

What Does My Agile Project Look Like?

When catching up with people many questions tend to revolve around my working situation. Curiosities including

• Do you have an office?
• Do you have a cubicle?
• How many people do you work with?

Ideal Workspaces

Pioneers of Agile software development tend to not believe in partitioning people off into different sections of a workspace. The big change from traditional techniques is that development needs to be more of a social, collaborative effort throughout the entire development lifecycle.

When we put people into different rooms, or even put up walls between them, they're less likely to talk to each other and know what is going on between them. This leads to a pain point much later on when we need to integrate the code of several developers. The solution is to have people in an open area and constantly talking as questions and ideas emerge. We all sit at a table with our computers, where it's very easy to yell out a massive design change or ask a question.

"We've just implemented flashscope, so no one should be attaching error messages to models anymore. Take a look at the HomeController for how to use it."

Realistic Workspaces

Part of the project in Los Angeles is Agile Coaching. This of course implies that the workspaces aren't currently set up ideally. We have a team room that fits about half the developers and the other half utilize cubicles in the adjacent room. It unsurprisingly presents some challenges, most problematic of which is easily the higher barriers to conversation.

We combat this in various ways, such as having a second 5-minute meeting (or stand-up meeting) midway through the day. Fortunately for us, we have just another week until we move into a team room large enough for us all.

Team Size

The development team I'm on is comrpised of four TWers and four client developers. Team sizes vary based on the scope of the project and finding that sweetspot isn't always an easy task. This probably goes without saying for every field, but there isn't a direct, linear relationship between people on a project and the amount of work that gets done. With software development, a team that is too large will have people stepping all over each others toes and will subsequently spend more time merging code than writing code.

The grads of my TWU class in Chicago are all on, or headed to, projects with two members to 54 members.

From Bollywood to Hollywood

"The grass sure isn't growing under your feet."

Perhaps one of my favorite remarks so far by a fellow ThoughtWorker upon meeting me. I was lucky in that just two days after being hired I was off to India. By the time I got back I was already staffed on a project. Now that my first week on a billable project is wrapping up, it feels relevant to announce that this developer has had the great fortune of spending just four days on the beach.

I'd love nothing more than to report the amazing weather my first week in Los Angeles has been. I seem to have brought the rain with me in my well-packed Space Bags^®, though. Can you believe a week's worth of clothes fit into these?

I can dutifully report the view from our office. On the days when it wasn't raining, I was able to snap a few pics from indoors. I wouldn't say LA feels anything like Chicago. It's much more like a giant suburb than a city, with relatively few towering buildings.

Still, there is a skyline of sorts. Hopefully we'll make it out of the office in the next few weeks to enjoy some of it!

But What About the Actual University?

It's hard to believe, but we're already halfway done with our adventure to India, and through 27 updates I've yet to say much at all about what we're doing.

Note TWU is split between [roughly] 25 developers (devs), 10 quality analysts (QAs), and one business analyst (BA). Our trainers are from these backgrounds and more.

Week 1: All Together

We had a fairly normal 40-hour week to start things off. From 9-5 each day we had four sessions covering things that were common to all of our roles -- such as company history, diversity, software delivery model, and a micro-project with a simulated customer. Our customer needed an exotic animal built from LEGO^®. It was one of several sessions designed to get the devs, QAs, and BAs working together in a project-like setting. My biased opinion is our team came up with a pretty great animal, baby, and gated-enclosure.

We do a thing with sessions here called Open Spaces. Open Spaces are basically a blank timeslot where the sessions are proposed and led by the participants. Any number of concurrent sessions can be going, and there are four guiding principles that most every event would be better off to adhere to.

1. Whoever comes is the right people
2. Whenever it starts is the right time
3. Whatever happens is the only thing that could have
4. When it's over, it's over

One of our assignments before arriving in Bangalore was to take an existing project and make it better. I was curious to see the variety in solutions, so I proposed a session on walking through how we solved it. We had four presenters, including myself, who had approaches varying from elegantly simple to enterprise-caliber extensibility.

Week 2: Split

For the second week we split the teams in half. The developers were off to learn things about coding, whilst the analysts presumably had sessions tailored to analysis.

There was much debate before we got here over which language to use: Java or the powerful, syntactically beautiful and lovable Ruby. Ruby really is great. I'd highly encourage everyone, especially non-programmers, to give it a try at tryruby.org.

Eventually the call was made for Java. We had sessions ranging from setting up IntelliJ, a development environment that makes working with Java easier, to pair programming and practicing test-driven development.

The Open Space session I proposed for this week had far less traffic. In fact, only one trainer and I were interested in the topic of Behavior-Driven Development (BDD). BDD is essentially a way to describe tests for programs in plain English. That's really the beauty of this flexible time -- everyone can find something they're interested in. We went over examples of the BDD tool Cucumber for about an hour. I've just begun introducing this style of testing in the project I'm doing for my last semester of school. Certainly more on that project in the future.

Example Cucumber Test

Feature: Manage Stores
  In order to associate receipts with stores
  As a user
  I want to create and manage stores

  Scenario: Register new store
    Given I am on the new store page
    When I fill in "Name" with "Chipotle"
    And I press "Create"
    Then I should see "Chipotle"

Poorly-hidden subtext: I miss Chipotle a little bit.

Week 3: Project Begins

The most exciting part of University has definitely begun: we're going to spend four weeks working on an actual internal project for the company!

This is where we get to code actual functionality into a system. We're also getting to familiarize ourselves with all the cool tools ThoughtWorks Studios has released in the past few years. We use Go for Continuous Integration and Mingle for Project Management. Both of these tools, and the concepts behind them, have evolved out of the pain points of the old way of engineering software.

Integrating code is always a pain, but it's an absolute nightmare if you wait until the end of a project to start integrating the pieces that every developer has been working on. With continuous integration, we integrate dozens of times a day and our automated tests ensure everything is working correctly. The end result is a better product with more consistent and predictable delivery.

Mingle is tailored for agile projects. In agile development, we break up functionality into stories. We estimate the stories for difficulty with points and use those estimations to plan how much we will get done in an iteration. In our case, an iteration is one week -- this is quite important; we're never planning too far in advance because requirements tend to change. The number of points we actually complete in an iteration is called our velocity. Mingle makes it super easy to track velocity, deal with ever-changing requirements, and support an agile team.

Most of this week has been familiarizing ourselves with the existing codebase, tools, and getting more and more experience pairing with our peers.

Sushmitha and I after pairing on the first day of the project.

bonus Word on the street is I'm a pretty fun pair.