I had planned liveblog the Agile2009 sessions I attended, but ran into a couple roadblocks*. You can see the Agile2009 sessions I DID blog. Also, Jackson Fox went ahead and wrote a great recap from a UX perspective. It might be more interesting for me to talk about how well I accomplished my goals for attending.
I had three goals for attending Agile2009:
- Learn methods, tools, and best practices for improving my user experience (UX) research and design,
- Help my department to adopt Agile practices in order to respond to increasingly demanding projects and shorter deadlines, and
- Learn ways to more effectively team with colleagues in other parts of our organization to develop and deliver outstanding UX on our enterprise tools.
I was a blend of several of the conference personas: obviously Deanna the UI Designer, but I also felt some affinity for Carlos the Internal Coach, Peter the Programmer, Alex the Architect and David the Developer, even Tara the Tester.
Agile UX Research and Design
I’ve already blogged about some of the UX sessions I attended. I would say that there were two broad categories of UX sessions (at least, that I attended): Agile UX methods and processes (guerilla user research, persona development, task analysis grids or storyboards) and experience reports (how do we do UX on an agile time schedule, with an agile development team). The method and process talks were very high level — almost introductory, and I felt didn’t really have enough time to get into any kind of real discussion on how to really use these UX methods in real life, anymore than reading about the techniques on the web . I did appreciate the 3 hr tutorials from Jeff Patton on Personas and Mike Cohn on User Stories. Coming out of those, I felt like I got a bit of ‘meat,’ which I could chew on — they gave a good framework for how to think about using these tools, instead of just a technique.
From the experience reports, the main message I got was, “here’s what sort of worked for us…we had to be agile and learn, and this is what happened in our shop…good luck with yours.” I had a hard time seeing how some of these were generalizable, or how I might use some of the lessons learned. Clearly, everyone is feeling the time pressure for faster deliverables within Scrum sprits. This means that UX practicioners have to be UX generalists: skilled in visual design, info architecture, interaction design, even development. I think the best takeaway was just networking with the people giving and attending the sessions, and finding a community of people I could talk to about approaches I’m thinking about taking.
I was a bit saddened and disillusioned at the perceptible distance between the UX and Agile Development community. The developers are still saying, “I’ve gotta get this code feature out the door, I’ll let you know when I need to talk to a designer), and the UX people are still asking, “how do I get the working respect and integration with the development team.” One concrete example of this: Todd Warfel and others did a set of three sessions on the whole ‘Agile UX process: Performing User Research, Distilling and Communicating Research Results (mainly via personas, and finally developing wireframes. I noted that the user research sesssion was sparsely attended and almost solely by UX people, the session on personas had a few more, and the session on wireframing was jam-packed. I think this is another example of developers trying to see how to get straight to the design, even though designers know there’s a process involved in getting to the design. Not sure how this dichotomy will play out. I don’t think anyone does yet.
Overall, definitely a positive experience, though. I was really impressed with the LiveAid stage…several UX designers did some agileux methods (guerilla user research, personas, wireframes), then teamed with several agile developers at the conference to create an iPhone app for a non-profit: http://www.manoamano.org. In addition to raising nearly $5000 for the charity at the closing banquet, the exercise of doing UX research and design, development and shipping a live app in 3 days was inspiring.
Agile in our Department
At my company the webteam is undergoing a bit of an evolution, where are roles are changing from simply maintaining the public static websites to designing and developing some mission-critical web applications. Our internal clients are asking our team to provide new (to our company) types of online interactivity and functionality, and the demand for us to be a mini-IT department are increasing. What agile tools/options should we look at in order to keep with the demand and still deliver outstanding webapps?
One way I think we can improve is to better integrate unit testing, acceptance testing and continuous integration into our team workflow. I went to a couple talks on CI – I think mostly by CI software vendors.
I went to a couple agile coaching sessions to get a sense for how to ramp up teams, and get people started doing things an ‘agile way.’ I was impressed by some of the coaching start up team strategies shared Lyssa Adkins. The session on user stories from Mike Cohn was again a great example of how to collect/gather/uncover requirements. In the OpenJam, I poked my head in on some people review Kanban project management.
One takeaway here is that ‘agile software development’ is more of a mindset change. It’s a set of principles, from which several methods, tools, and best practices have been developed. But as warned on numerous occasions, just adopting some or all of the methods without understanding the principles often leads to poor results. I think the key here is to focus on the core principles, and adopt the set of practices that make sense for your team wherever they’re at. I like the idea of the Scrum style — setting a sprint timebox for a delivery of something of business value, and then meeting afterwards for a retrospecting and planning of the next sprint. I’m planning on experimenting with a WIP board for a short sprint on a project this week.
Another takeaway is that, at the end of the day, all these agile documentation and project management methods and tools (user stories, personas, work in progress boards, pair programming, Scrum, Kanban, Blitz Planning) aren’t really rocket science. They all center around creating externalized, shared visualizations of the problem and solution spaces. The goal, it seems, is to extract the implicit knowledged wrapped up in each team members’ head as simply as possible, put them in a shared accessible place as simply as possible. This allows the whole team to see the whole picture, and allows communication and ideas to flow as quickly as possible. That’s why agile emphasizes small, co-located teams over large distributed teams — fewer barriers to communication. That’s why agile emphasizes user stories on index cards, simple personas, and face to face communication over documentation — its easier to exchange ideas and information, to re-arrange and update the knowledge-base. Agile emphasizes working code as documentation because the working code is a clear concrete thing that the entire team can gather around and say, “yes, this is right” or “no, it should be some other way.”
Agile in our Enterprise
I’m going to hold this for a future blog post…this one is long enough as it is.
Other Conference Observations
- I thought I’d be hearing lots of people at this conference saying, “do it in Rails” or “Django” or <name your new-fangled web framework>; I was surprised at all the java and .NET technical talks.
- I loved the Musick Masti sessions over lunches and at night. I got to go down a jam on a sax they had there, as well as play various percussion and other instruments. That was a lot of fun. That seemed to be a theme the conference organizers were going for…things should be fun! The Monday night social/networking event was a good example — various wiis and other games were strewn about the vendor hall providing opportunities to interact with other people through games.
- SO…MUCH…SWAG. Wow…I brought home almost a whole suitcase full of free books, balls, silly putty, race cars, planning poker cards, t-shirts.
* 1) dodgy conference wi-fi access. You’d think ubiquitous wi-fi access would be a given at a techy-geek conference like this. It was great in the Open Jam area where people could congregate and talk about whatever, but it wasn’t as good elsewhere, 2) my Airport wireless card has been giving out for the last few weeks, and finally died at the conference. Luckily, the Chicago Apple Store is not far from the conference venue — they sent it in and fixed it for free, even though my AppleCare expired in April (I love Apple’s customer service, and the fact they know that I’m pro