Quardev Monthly, May 2010
In this issue:
Agile Up to Here - an experience report
By Jon Bach, Manager for Corporate Intellect, Quardev, Inc.
If you haven't heard the term "Agilistry," don't worry, it's not a hip new development methodology to learn, but you may be hearing more about it.
Agilistry is the name for a training space in Pleasanton, CA, opened by Agile luminary and long-time software development consultant Elisabeth Hendrickson. Known for her immersive and practical software development exercises, Elisabeth has opened a space for software professionals to learn the "true spirit of Agile software development."
(Open space at Agilistry)
Last week, I had a chance to see if her studio was indeed a place where "Agile software development professionals come to sharpen their saws and practice their craft" as her site claims.
I've known Elisabeth since 2000 when she came to Satisfice, the company (and training space) my brother created in 1999. He created it to give testers a chance to practice their craft. Ten years later (and partly inspired by her experience at Satisfice) she has turned the tables and invited me to see it in action. Actually, I was just one of 11 guests summoned to Pleasanton to see what she had in mind for her workshop idea called "Agile Up to Here" (search #au2h on Twitter for threads).
As Manager for Corporate Intellect here at Quardev, part of my job is to put myself in places that maximize my ability to learn new things about software so we can stay competitive. Principles and practices related to Agile Development are things that continue to emerge for us on more and more projects we are asked to bid on.
When she invited me, my main concern was what value I would add to an Agile workshop. In my experience, Agile was about programmers doing all of the testing and I'm not a programmer. Also, Agile proponents always seem to imply that there are no defined roles for testers because developers did all testing through unit and acceptance tests.
I expressed this concern to Elisabeth and she was adamant. "Not only is exploratory testing part of Agile, it is a crucial component of it. You are required to be here." That made me feel better. I trusted Elisabeth because she had demonstrated that although a very fervent fan of Agile, she hadn't lost her passion for testing.
I'm not a newbie to Agile, but there are tons of people who know a lot more about it than me. Sure, I'm familiar with the Agile Manifesto and know about story cards, backlogs, refactoring, sprints, Scrumboards, big visible charts, Test-Driven Design. I was also a stage producer at the Agile2008 Conference in Toronto, hosting the "Questioning Agile" track, and I have worked as a test manager on projects that used facets of Agile.
At Agilistry last week, I was first to arrive (a bag of Seattle coffee in hand to brew for the crew) and found Elisabeth setting up. There were 8 pairing stations, a big rolling whiteboard, index cards of every color everywhere, a few small couches to sit, a monitor on the wall for the Hudson integration system to advertise its results, a small fridge and sink area, a printer, a wireless network... and that was about it. A pleasant space in Pleasanton, not over-complicated, but resembling what the Agile conventions suggested - no cubes, no walls, maximized for pairing, transparency, and communication.
(Matt Barcomb, Pat, and me learning how Pat can write homophone acceptance tests at the speed of light.)
Leading up to the workshop there had been a wiki for us to get to know each other, bios and expectations, a Twitter hashtag (#au2h), that kind of thing, but as people arrived, it wasn't clear to me what our mission was.
We had our first stand-up - introductions. Everybody was a programmer except for me. Just as I had thought, I was sure I was going to be made obsolete, but I trusted what Elisabeth told me. That I was a required component. That I would add value by being there.
(Alan leading a team stand-up)
Alan Cooper from Cooper Interaction Design and author of The Inmates Are Running the Aslyum and About Face told us the mission: He was a word nut. For years he had collected homophones - words that sound alike but are spelled differently and mean different things (e.g. ere, air, and heir). He had a Website that listed some of his collection, but a lot of it was tucked away on his hard drive. Furthermore, his site was old - vintage 1997, Web .5 (not even 1.0) and the list was hardcoded HTML.
As Product Owner, his main objective for us was "Get me out of 1997!"
He didn't elaborate more than telling us what homophones were, but he did make enough of an introduction for me to get the gist that we would be building a site for him from scratch in these 5 days. I love challenges like that, especially when they are authentic - a real problem for a real person. Abstraction lessons can be fun, too, but I'd much rather provide value to some person.
Part facilitator, part host, and part programmer, Elisabeth put on her facilitator hat and announced that she would need some help configuring the machines. In seconds, she got two of the programmer-types to volunteer - Pat Maddox and BJ Clark helped her configure the pairing stations with the tools we needed: Hudson CI, GitHub, Rspec, Ruby on Rails, and Cucumber.
(Programmers BJ Clark and Pat Maddox)
Jeff Patton, an independent consultant and Agile coach, was also in attendance and emerged as a natural ScrumMaster, suggesting that the rest of us meet with Alan to get an idea of the kinds of things we wanted to see in a new site.
(Jeff Patton and Alan Cooper)
And just like that, with no fanfare or specific direction than that, we broke from our huddle, much like a team taking the field.
It felt weird. No specs, no design docs, no budget, no buy-in, no high-level meetings, no executives, no paperwork to fill out. Just go and DO. So as Jeff Patton took the lead to interview Alan Cooper about his ideas for a new site, Dale Emery, Matt Barcomb, Katrina Owen, and I gathered around to listen.
Two hours later, the machines were set up and my group was done talking with Alan - we had enough to get an idea of what he wanted and the board was full of Backlog.
(The rolling whiteboard with stories for the backlog)
Storyboard
The standup we had after that was simple. After a quick status report, Alan did a brief chalk talk on design, then we set to work, picking the few stories that we'd do the rest of that day - no bickering, no dissension, no turmoil. It just flowed. There was no confusion, no chaos, no tension. It reminded me from that scene in Apollo 13, where the ground crew had to build a filter out of spare parts. Yes, there was urgency and energy around the mission, but there was no clumsiness. People worked together and all they had to do was say or suggest something and a natural affinity formed for people who agreed. For those that wanted to do something different, they did and found someone to pair with.
(Elisabeth, Alan, me (in hat), and Matt)
What struck me when I paired with Elisabeth that doing TDD was akin to hacking. She would write code and then tests around that code and the tests would fail. That was a good thing, she said. Then she did something that looked to me like hacking - trial and error fixing so that the tests worked. She admitted when she was stuck or didn't know how to do something and she'd just ask the other pair next to her for advice or look it up online or in the API help docs and a solution would emerge. I rolled my eyes at one point because this was just hacking. She was trying different things, not knowing if they would work. That was TDD?!? Come on, really?!?
When I questioned Elisabeth about this, she said something that instantly hit me.
Yes, experimentation is ok with TDD, but it's not just trying anything, it's thoughtful experimentation. In one phrase, Elisabeth caught me judging TDD in the same way people attack exploratory testing as just reckless "banging on the keys." There was a method to her trials and I didn't see it because I didn't understand - I didn't know what to look for. Much in the same way test managers and execs aren't hip to the language of skills and tactics that testers use when they explore - things like modeling, conjecturing, observing, branching, backtracking, questioning - these words describe what many people walking by would call "playing around," but when the right language is used to describe what exploration really is, it's more apt to be understood and taken seriously.
(Elisabeth, working out code)
Another thing I chided Elisabeth on was how she found a bug and fixed it in about 30 seconds. That part was cool. But then she took 30 minutes to write TDD tests around it! I thought that was a waste of effort. The bug was found and fixed, why waste all that time writing a regression fix for such a little thing?!? Then she explained it to me, it's not just regression, but the process of creating the test that's important. The lessons learned in building that test may come in handy later.
Again, I felt sheepish. Sometimes I go down a rat hole with a test and it may seem like a waste of time to a stakeholder. But it was what I learned from that "wasteful" test that stays with me. That seemed to me to be a big part of Agile development - learning. In fact, I was surprised (happily so) to know that when developers do a spate of programming in this trial-and-error way, they call it a learning "spike." I liked that. I have a word for it, too, called a "session," but I didn't have a word for a smaller period of time, so "spike" is what I can borrow from them.
(Dale Emery, BJ, and Kat Owen)
The first three days, I did not feel that the site or any of its functions were ready for me to test. That is, I did not feel that I would have added value by testing what was there. The components were simple, they worked, and to test it in the ways I had in mind did not seem to suit anyone, even me. The risk was low and it was still under construction anyway.
But by Wednesday, enough of the pieces were coming together where I felt it would be worth it to the team to see what could be wrong with it.
(Work-in-progress board (kanban))
(Me, pairing with Matt on a session)
(Pat and me testing how homophone sets are presented)
When I found a bug, I wrote it on a red card and put it on the board.
When developers finished a story, they would ring a bell and everyone would want to know what was implemented. And we all had fun in this studio environment.
Most importantly, in 5 days, we turned this old, 1997 site:
http://www.cooper.com/alan/homonym_list.html
Into this:
"You just have to try it for yourself," is one of those conversation-ender statements. It's usually said when the person trying to persuade you of something has given up on you. But if you dismiss the freight you might feel when someone says that to you and decide to actually take them up on their invitation, it might be a profound experience. That statement can be invitational.
After what I went through at #ua2h, I was honored to have been invited. I wanted the chance to see if Elisabeth's studio was indeed a place where "Agile software development professionals come to sharpen their saws and practice their craft" as her site claims. And the experience did not disappoint me one bit. Remember that Alan Cooper was the Product Owner (in role and in deed), so to learn his thoughts of this experience, read his blog here: http://www.cooper.com/journal/2010/05/agile_up_to_here.html.