January 24th, 2011
Understanding Being Agile
I’m currently developing a new Web platform for the company I work for, and for many many reasons decided to build with Ruby on Rails and a local Web software development shop. You might question the fact that I’m building back-end software vs. using an open source project — suffice to say, the business goals are such that I decided that it was worth it to build. I (probably rightly) question that decision every day, but so far, the answer still always comes up “build”.
One of the most difficult concepts for me to translate is the notion of “agile” development. Most people I’m dealing with are old-school RFP-types who want the entire project spec’d and priced. (Honestly, it’s a new concept for me, too, but I’ve taken the time to read up on agile development and contracts.)
One of the core tenets of agile development is admitting that specs are useless because software changes and evolves. This seems pretty self-evident, and yet we’re still talking about it. If software didn’t change, then why all the patches, updates and releases we see every day? Microsoft seems pretty confident that Word needs a new release every few years — while thousands of users rebel and decide to move to simpler word-processing alternatives. Even with super predictive powers informing your RFP, it’s not unreasonable to think that you’re going to be off-target after six months of development.
Of course, when it’s said that you can’t accurately spec a software project, I immediately think that I must be doing something wrong — I’m smart, there must be a way to get really really close, right? But there’s a more important way to define “change” than errors in your calculations of scope or something missing in your list of features.
We all want users to enjoy our software, so we have them test it. Testing gives us small course corrections and helps users feel more vested in the project, but I think more importantly, it can reveal where you’ve fundamentally misunderstood what users are doing. I suppose there’s cases where you can simply nail it, where you’ve got the user dead-to-rights and can build the perfect solution to their problem. But probably not many.
We did some testing the other day, which required our testers to play around with a form for inputting data. With one tester, it seemed like the form was working. It helped organize a lot of data and actually provided some nice shortcuts. It wasn’t perfect, but I felt like we were on the right track.
The second tester was a different story. She was perfectly reasonable and accommodating, but it was clear to all of us that she didn’t see clear value in using the form.
Why? Because we’d designed the form to help organize a complex set of data. It worked great with the first tester, where organizing was the prime concern. But our second tester wasn’t organizing data, she was writing.
If you’d written down a description for this feature, 100% of the time, you’d get a solution designed for organizing data. But when you realize she’s “writing,” it makes perfect sense. It’s not that she’s an outlying case, a finicky user, it’s that we subtly mischaracterized what she was doing.
So, it’s not really a question of understanding what a user’s doing, it’s understanding what they think they’re doing. And that’s a question you’re going to need a lot of user testing to answer.
Luckily, because the testing came so early, we can easily adjust. Many of the features that will help create a more “writerly” environment are already planned but not yet implemented. So, we’re still basically on track, but with some very valuable new insights to inform our work.
I think that’s probably as goood a reason as any to be “agile”.
