Scott Ambler gave a great workshop yesterday on agile modeling. Agile? Modeling? Yep, you read that right. However, with agile, the emphasis of the models is to think about how the system should be developed, rather than to document how we’re going to develop it. Once you’ve modeled far enough that you know how to develop the system – don’t write about it, go develop it! He made a wonderful comment that I applauded:

“Architects who don’t write code are only qualified to fetch coffee for those of us that do.”

But, my favorite part of this session was where we each broke into groups to work through 3 development projects – each following a different process: Traditional, Mini-Waterfall (I can only hope by this he didn’t mean poor, misunderstood RUP), and, of course, Agile.

So, project 1 is Traditional. He has us each pick a role (stakeholder, analyst, designer, developer, tester). Analyst gets 1 minute to get the requirements from the stakeholder who then hands the designer and developer the specs. Designer and developer have 1 minute to develop what turns out to be a birthday card for dear old grandma, turning 84 this year, and then turn over to tester. Tester has 1 minute to compare against spec, gives us defects, and we have 1 minute to fix. Our team’s designer has an unnervingly hard time with this one, becoming visibly stressed out as Scott barks out “30 seconds left! 15! Okay, STOP!” Finally, stakeholder ranks us on how well we did. Let’s just call this one bad, very bad. A few teams actually got negative numbers.

Okay, round 2 and this time its mini-waterfalls. Now, analyst gathers requirements in 30 seconds, designer/developer develop, tester tests. Rinse, lather, repeat mini-waterfall 2 more times. It’s very chaotic and hectic , Scott screaming down over us the entire time, stomping his feet for extra emphasis. We barely have enough time to even understand the requirements (a wedding announcement, only, well, not quite – it’s actually a civil union — it mustn’t actually include the word “wedding,” and it must include a poem , but… apparently not an offensive one (our team got points off for “there once was a man from nantucket…”)), much less get them implemented. At end, stakeholders add up their rankings and we’ve done a little better then the last time, but only just barely.

And now, finally, round 3 and we’re on agile. This time, forget handing things over the wall from one discipline to the next. This time we have 2 minutes to work together as a team, which includes our stakeholder, to develop a card. This one thanking the SD Best Practices conference organizer for a great conference. Well, this card is by far our best one – we actually have time to breath and communicate and so we can come up with some cool details to add and even get them implemented – pictures, borders, a list of what we enjoyed about the conference, personal signatures of attendees. Stakeholder is involved every step of the way helping us understand what will improve it. Needless to say, ratings come in and all of the teams scores spike. Much happier customers.

So, what was interesting here is that we actually got less time to work on each subsequent project (from traditional to mini-waterfalls to agile) and yet, each subsequent project was more successful. Our team’s designer — you remember, the one who had such an adverse reaction to the traditional project — makes what I thought was the most insightful comment of the class (well, okay, maybe 2nd to the coffee fetching architect one):

“The agile project felt less rushed. It was more fun and relaxed”

And it was. We were laughing and having fun and innovating. Scott talked a lot about how our traditional software  development processes have been about how the academics think we should work, rather than how we really do think and work. The agile project definitely felt like it jived with the creative process.