1. You are sponsoring one of the stages at Agile 2010. Do you want to tell us a little bit about it?
Quality Tree Software is very happy to be sponsoring the Team-Room Agile Stage. It fits very well with our new Agilistry Studio in Pleasanton, California, which is a practice base for Agile Software Development and the Team-Room on its own.
Agile Up To Here was a hand-picked collection of folks. Allen Cooper, the author of About Face and The Inmates Are Running the Asylum was our product owner and Jeff Patton came out to do story mapping with all of us and with Allen. John Bock came and was there for exploratory testing on an Agile project and we had Pat Maddox and Matthew Barcomb and Katrina Owen and a bunch of other people. We built an application in the space of a week, doing dials to 11 extreme programming practices.
We paired all the time, we had all automated units test because we were doing TDD all the time, we had all automated regression tests because we were doing ATTD all the time. We did continuous integration obviously and continuous deploys. From the time I checked in code with my pair to the time that we could see it live on our staging web site it was less than 5 min. It was so much fun, it was so cool. We also got to see all these roles, got to play together nicely in an Agile context.
3. Any great learnings that came out of it?
For me, one of the biggest surprises was how even with a room of incredible people it can still become chaotic when we’re all trying to do something together very quickly. There came a point on Wednesday morning (we started on Monday and ended on Friday) where Allen kind of said "I won’t answer any more questions as the product owner until we have stepped back and done some of the design work that I know that I can do well." That formed a good break for us to take a step back and to allow him to focus on what he wanted the solution to look like and to also force the team to stop just keep continuing.
And I realized that that would be a really good and powerful thing for people to be able to do in a professional context because there was no revenue tied to our outcome. It was all about experiencing this week as opposed to driving to revenue or meeting customer demands. We didn’t have the same kind of time pressures. Although at the time I resisted taking that step back, in retrospect it was a very powerful and important thing and it’s something that I wish that more teams had felt like they could do in the real world, even where they’re experiencing tremendous schedule pressures. Stop - thinking is important! Who knew?
The AAFTT is a funded program of the Agile Alliance and the chair of that program is Jenita Andrea and I help organize. I refer myself and Jenita’s minion, but it was really her vision to establish the program. The mission of the program is to advance the state of the art and the state of the practice around Agile friendly functional testing tools. And examples of these would be FitNesse, Fit, Concordian, Cucumber, Twist, Robot Framework. These are tools that help facilitate collaboration between the different roles on an Agile project, so that we can express expectations in English and they can still be executed automatically so we get essentially executable specifications.
The mission of the program is to move the state of the tools forward, to help facilitate moving the state of the tools forward, to support this collaboration. The way we do that is all through community building. We are not funded so that we can then give money to a bunch of developers to develop a tool. Instead, we host events to bring together the people who are creating these tools and the people who are using these tools so that we can all learn from each other, share ideas. I’d like to think that we are maybe partly responsible for the ratcheting that we’ve seen in the feature sets in these tools, so now you can do tables in Cucumber and you can do prose in FitNesse.
There are just so many new capabilities being added to these tools and we’re not taking credit for that. We hope that some of the community building that we’ve done has helped with that.
5. Yesterday’s session: What was the focus of that?
Yesterday’s session was a community of practice retrospective that Rachel Davies led, so the first part of the day up until lunch we spent doing retrospective activities. We built a timeline of relevant events for both the individuals in the room and also for the community as a whole and the industry as a whole from about 2000 all the way up to looking forward a little bit towards what’s planned, coming up in 2011 and so forth. We did small group work where we created posters of what we’ve seen happen with both the things that are the pains of acceptance test driven development and the pleasures, so we got a lot of good meat out in the room about people’s experiences with this.
Then, in the afternoon, we were able to take that shared basis of understanding forward into the smaller open space-like sessions where we talked about topics related to the stuff that came out in the morning and how to address that and move things forward.
6. What are some of the key things that came out of that, some of the key learnings?
For me, it wasn’t a key learning that came out of it; for me what came out of it was seeing the passion in the community. At the very end Rachel had us do a sort of a commitment exercise - what is each of us in the room willing to commit to do to help move the state of the practice forward and to help the community. We had pages, multiple flipchart pages of things that people signed up to do. So, we’ve got somebody who signed up to create the Wiki that we’re going to put some additional information on.
We’ve got people who are committed to soliciting information from a wider community about how people are using the tools and around vocabulary related to the tools. For me, what came out of it was seeing this community that is relatively young and this community has just galvanized around this. It’s very cool.
7. What are some of the challenges facing the functional testing tools movement?
One of the things that I’m seeing is the tools are now reaching a level of maturity where they really are beginning to fulfill their promise to allow us to do things we always needed to do. Now that the tools can support us, it’s not surprising that we are noticing that the hardest part is the fluffy human stuff - getting everybody to the table. When you talk about having a tool that allows you to collaboratively specify the behavior of the system, getting everybody to the table to collaborate becomes the hard part.
So you typically see a situation where you’ve got the BAs over here and they say "We’re just going to write the requirements and we’ll hand them to you when we’re done". Or you’ve got the developers saying "Oh, you go write the requirements and the tests and you tell us when you’re done." We don’t always see that everyone in the organization is excited about coming together and doing this work as a group, as a team. That was a lot of what we ended up talking about yesterday; it was related to how to get people to all be willing to take the time to collaborate, to articulate expectations together, to be precise, to drive it down to concrete examples and expectations.
That’s the hard part now. The tools have their quirks still, but they are really getting there and now we’ve got the human side of it. Helping organizations get traction isn’t as easy as it sounds. You have to pull everybody together and they don’t necessarily think that they should all be participating in this process.
8. But isn’t that why we’re Agile?
Yes. That’s very much so. It’s exciting that the tools can help facilitate that now in a way that they couldn’t, say six or seven years ago. And now we get to work on the hard problem related to the humans. Before the tools couldn’t even support us even if we got everybody to the table the tool were quite there unless you were a very rare a group of folks with a high tolerance for quirks.
Absolutely. There is now such a wide array of tools. There is at this point I would say probably a tool to fit just about any context you might find yourself in. It’s not restricted to just Java. There are tools that could be in any technical context and the maturity of the tools is high enough that I would feel very confident running all of my enterprise class tests on any of the tools that I mentioned.
I mentioned a Wiki. The Wiki is not there yet and one of the things that’s been a little frustrating for everyone is figuring out how to capture the information about what tools are there, because there is new tools coming up every day. We have a mailing list, a Yahoo Group the AA-FTT group. It’s on Yahoo Groups and we’re a very open community, happy to have anybody join us as long as they are interested in Agile friendly functional testing tools and their application in software projects. On that group we have a spreadsheet.
One of the features of Yahoo Groups is that you can have a spreadsheet database-like thing. We’ve got a list there - we’re not going to pretend it’s all the tools, but lots of the tools. Mark Levison has been instrumental in getting that out there. So, that’s our first step. The next step is going to be taking that information and putting it into a more accessible form. But all of this is of course community-driven so, like I said, we may be a funded program of the Agile Alliance, but that funding is to help catalyze the discussions in the community as opposed to funding information production.
11. And the relationships with tool builders and vendors?
Very good. We’ve had lots of the tool creators come to our workshop-ing sessions. Aslak Hellesoy [creator of Cucumber] came last year, wasn’t able to come this year. We’ve had representatives from ThoughtWorks come; we’ve had, I believe, most of the tool creators come to our workshops at some point or another. So, it’s an excellent relationship with all of the tool builders and it’s so much fun to watch them talk together and get ideas from each other.