A Journeyman Visit with Getty Images

A while back I posted about taking a journey of discovery through the Seattle tech scene. My goal was one of discovery and to some degree imitate the success of people I admire. I wasn't quite sure what I was doing, but youthful exuberance pushed me on through. I posted to the local ALT.NET and the global Software Craftsmanship mailing lists.

I received a lot of positive feedback and well wishes but sadly not a whole lot of offers that I could act on locally. While I would love to travel to Chicago, India or the UK, real life makes that prohibitively difficult in the short term. To add insult to injury, it seemed most of my local developer friends were of the opinion that I would never get approval from human resources departments or corporate bureaucracies to even enter buildings let alone view and touch source code.

That all changed when I got an email from Michael Ibarra from Getty Images. Getty is a well known, highly successful local company. Chances are if you see an image on television news or in Wired or in any of thousands of publications, that image was handled in some way by Getty Images.

I have a secret history with Getty. Way back at the beginning of my tech career here in Seattle, I worked for a outsourced tech support company called Keane doing technical support calls for Adobe Photoshop. As anyone who has done it before can tell you technical support is a soul sucking pit of despair kind of job. But it is how a large amount of if technical people get our foot in the door in the late 90's. You suffered through the endless calls suggesting trying to reboot the machine because you knew that after you put your time in better jobs would be waiting.

Everybody at Keane had an escape route planned. For some people that route was Microsoft or Adobe or moving back to where ever they came from and flipping burgers, but for me that escape route was Getty Images. At the time, I was just getting into this web thing and image optimization for web delivery. Getty at the time still did distribution through giant CD compilations (they may still do that, but I suspect the vast majority of their sales are online now). I even went so far as to interview there once before the I got caught up in the .com bubble madness and left Seattle for Olympia.

Needless to say, I was pumped when I got Michael's message about working with him for a day at Getty. Seriously, my Mercury App statuses for the day were all happy pandas. We made some quick arrangements and early this December, I was making the pilgrimage to Fremont giddy as a school girl.

The trek up to Fremont via public transit navigating by iPhone, Google maps and OneBusAway was a nice way to contemplate the day. A quick brisk walk over the Fremont bridge and a cup of joe at Pete's and I was ready to rock for the day. Sadly, I was on the backend of a wicked cold and the Dayquil I took to get out of bed had me pretty jittery as well.

I met up with Michael right outside the Getty building and we headed in. Getty is a very mature Agile shop with a solid rigorous process in place. The team that Mike is apart of is split into two scrum teams; Axis of Awesome and Walrus. I didn't get the story on Walrus, but Axis of Awesome is a great team name. Each team is composed of roughly six members and the teams seemed to be composed of one lead, a couple developers and a couple of quality assurance people. The teams are arranged in an open seating plan with each group arranged in little pods of desks that face each other with no privacy or cube walls to facilitate open communication.

The team dynamic was interesting on team Walrus as one of the QA folks filled the role of scrum master and their QA folks actively write automated tests using Selenium. I talked over the QA role on the team with the scrum master (sorry forgot your name) to find out how much power QA had at the table to ensure quality. A lot of shops view QA as an after thought with no real authority or power to prevent disaster. Scrum master guy assured me that quality was a major role in the development process and that really showed during the day I was there.

An interesting experience related to QA's role in Getty's development process popped up while Mike and I trolled though their backlog to find a task to work on. Sadly, the day we picked for me to come visit was at the end of the sprint cycle and all the current tasks had pretty much been wrapped up and they had plans to deploy that day. Anyway, Mike and I browsed through their backlog looking for an item to work on. Getty uses Rally Software for project management and it is a core part of their process. Getty seemed to make much better use of Rally, than we do of Jira w/Green Hopper but I think I prefer Jira's simple board display to the busy task list in Rally.

Once we decided on a task to work on, Mike fired up notepad and called over the scrum master QA guy and they started a little dance they called "done whens". Basically, they discussed the ticket and documented acceptance criteria for when this task would be sufficiently done by the developer and ready for a QA person to review.

The format looked something like this:

Done When:

• I can log into the site and view order options for the Foo collections.
• I can place an order for images in the Foo collections.

The final list consisted of about six criteria. The criteria were then sent via email to the product owner, who sat a room away for review. The intent was for the PO to review and agree that the team had understood the story. Once that was complete, Mike added each of the criteria as subtasks of the story we had selected to work on. This is a far more formal process than what we use on my team, but I think it gives the team several points in the process for open communication and forces unclear stories right out in the open. It seemed like it might be cumbersome at times, but I liked the in person communication that it seemed to formalize in the team. Even in an agile team it is far to easy to take your little task and go hide at your desk working on it, I bet this process makes that pretty difficult to accomplish.

During the corse of the day, I happened to notice an unusual board on the wall that caught my attention. The board was laid out with two axis labeled Bang & Buck was titled Technical Debt. Sticky notes were laid out on the board describing bits of friction in their environment that they would like to address. The notes were arranged on the board so that tasks that had a high degree of value (Bang) to the application were high on the up down axis and relative level of difficulty (Buck) on the left right axis with the far right being very difficult. A band encapsulated the sweet spot balanced between cost and difficulty.

[](http://dl.dropboxusercontent.com/u/3596778/blog/2010/12/img_06 66-full.jpg)
I thought this was absolutely brilliant and became quite obsessed with it for a while asking lots of questions. Sadly, it seems like the idea was not meeting much success with the Getty teams. While the board gave great visibility into the friction the team was having to deal with every day, they had not found an effective way to incorporate the work into their regular scrum development process. New features and customer concerns always put the tech debt board on the back burner, like in most shops. So, it sat on the wall as a beacon of developer pain and that was about it. But I still feel its a great way to make developer pain visible to everyone involved and the Getty team is ahead of the curve on that.

We took a break around noon to go have lunch at a local dog friendly pub that had a really amazing chicken sandwich. The team and I had some great discussions over pints. I sadly was coming down from my caffeine, Dayquil and adrenaline rush and started to feel my cold creeping back in. So when we made our way back to the office and the team had to go off to a internal meeting, I took the opportunity to make my exit and start my two hour trek back to Olympia.

I really enjoyed my time with Mike and his teams at Getty and look forward to making a return visit. The team seemed engaged and full of talented people working interesting problems. That is fun to watch. For myself, I learned that my exuberance for making a craftsmanship journey is not enough, I need to plan better what I am going to accomplish when I visit a place like Getty. I think this visit was valuable, but if I had come in with a plan of what I wanted to take away it could have been more productive I think. Mike and I really didn't know what we were getting ourselves into, but I appreciate his offer to help me figure it out and his invitation to come back and give it another shot.

Any other journeymen out there trying this? What are your goals when you enter a work place with only a workday to discover some insight about the development process? Is it worth trying to add some structure to the visit, or should I simply go with the flow and see where it leads? Cory & Liam, do you have suggestions?