The first day on a project is always a long one. No matter how hard one tries, there is always just so much to catch up on and learn in order to feel somewhat comfortable with the topic/software/process.

This morning I was up at 4 AM, out of the house by 5, and in a brand new office on the other side of the state by 8, only to be thrown into a gauntlet of jargon, processes, relationships, and individuals. I’m surprised to find that I really enjoy this situation. I get really excited when I look at what people have been working on, and I revel in the act of playing catch up. Sure, it’s pretty stressful since the clients and my peers expect me to catch up quick and deliver in a very short time period, but there’s something nice about delivering quickly and getting out, at least to me.

Of course, in a few weeks I should check in to see if I’m still happy with the fast pace. For now, I’ll just keep trying to catch up…

Hey ThoughtWorkers,

So at TWU we learned about a ton of different ways to test software: Unit Tests, Functional Testing, GUI Testing, etc. Here’s my question:

What’s the point of a tested tool that the user (or perhaps customer, if you prefer) finds difficult to actually use? What about Usability Testing? How about testing to see if your deliverables meet the problems found during analysis? Where do these kinds of testing come in?

Sincerely,

Josh

I know, I know. You’re all going to scold me, I’m sure. I haven’t blogged in a while, and you, my ever-patient readership have become quite used to me not spewing out any of the drivel that you’re used to seeing on my weblog. I’ll try to do better. I really will.

The past few weeks have been intense. Last week, the 5th week of ThoughtWorks University, the Analyst team had a number of late nights. We carried out a ThoughtWorks Quickstart, a short and intense period of analysis. I think these generally take a few weeks or perhaps a month, but we only had one week. We created over 40 stories, with detailed narratives, as well as awesome lo-fi and mid-fi prototypes. Of course, we also carried out some Usability, which solidified a lot of our ideas and interface designs. All in all, our “customers” (who were really just a few of our trainers) seemed happy with our results and we were hurdled into a frenzied development week that has been taking place over the past few days.

Development has been CRAZY! It turns out that we completely overestimated our velocity when we created our high-level release plan. We kind of knew this when we set out on the week, but I don’t think we realized the resulting implications of such an overestimation. Having to tell a client that you’re behind schedule, and then having to do it again the next day (and then again the next day) is just plain ol’ tough. Even if the “customer” is really just a trainer who’s posing as an unhappy client.

Still, the learning experience has been great. Tomorrow we’ll hopefully have some sort of release, then we’ll graduate from TWU. What a journey. So fast, and so educational, in oh-so-many ways. What a journey…

When I came to ThoughtWorks University a little less than a month ago, I set as my main goal the task of discovering what kinds of User Centered Design practices were occuring at ThoughtWorks, and how I could help progress those tasks. After two blazingly fast weeks of class, I’ve learned a lot, hopefully taught a little, and have come to this point surprisingly impressed at the user-centric ideas that shine through in the lessons here at TW, and possibly in Agile Development in general.

Many of the analysis techniques in use here align closely with a number of standard HCI practices. For example, last week we were taught a lesson about how to best gain knowledge about the organization, business process, and/or needs of the client. The lesson reminded me so much of Contextual Design, an analysis and design methodology that has been around the HCI field since the early-1990s, which makes it quite ancient in the field. I was completely staggered to learn that the lesson was not based on CD, and even more surprised to learn that the trainer had not heard of it at all.

Further lessons have discussed External Cognition (pdf link), process modeling, and interview techniques that would make most HCI-designers proud. We’ve also learned about how to incorporate Personas and Scenarios into our analysis work. Not to mention the fact that user stories, which guide the development of specific software functionality, are based directly on user needs (as mentioned earlier).

The fact that these practices are built directly into the system is uplifting for an Interaction Designer like myself. Now, I take it as part of my responsibility to point out when these known techniques are used, teach people their formal names, and discover how we can further leverage their strengths, while being aware of their weaknesses. Of course, it’s also important to add new tools to the TW toolkit, which I plan on doing.

So far, though, I am impressed by the User Centricity of the processes here at ThoughtWorks. Score one for the users.

As noted in my first agile worry, I am often scared that features of a given piece of software will be built based on reasons other than user needs. Yesterday I learned that story cards are, indeed, quite user centered.

The format we learned for creating a card is as follows:

As a [ person ]
I’d like to [ action ]
so that [ reason for action ]

This card is used as a discussion piece with clients, and is eventually used by developers to create particular functionality.

What excites me most about these story cards is the fact that right at the start, a person is identified for whom the functionality is important. This means that one cannot simply create a story for a feature that is “cool,” nor one that is simply unneeded. Also, the cards are to be specific, so the user cannot simply be some general party involved, such as “customer,” “client,” “computer user,” etc. User needs are heeded in a feature-by-feature manner, so the people who will eventually use the software simply cannot be ignored.

Now, there are still a number of ways in which a particular piece of software can veer from user-centredness. A bad interface to a set of features, for example, will make all other attempts at user centered design moot. Also, simply because the features of a piece of software have user needs in mind, the package of features may be counter to this spirit. Among other things I hope to learn at TWU is how to apply standard User Experience Design principles to Agile Methods so that the process and product are excellent for the builders and users of software, respectively. Hopefully what I will learn in the coming weeks (not to mention months and years) will help contribute to the growing knowledge in these combined fields.

For the moment, I am excited about agile…keep it comin’.