In this interview, Aaron Sanders explains why testing your assumptions can be the most important step of the development process. He digs into how he got his start in the industry, why team chemistry is critical, and the most common misunderstanding that plagues groups.
Josiah Renaudin: Today I’m joined by Aaron Sanders, an agile coach. He’ll be leading the presentation “Before You Test Your Systems, Test Your Assumptions” at this year’s STARWEST event. Aaron, thank you very much for joining us today.
Aaron Sanders: You’re welcome.
Josiah Renaudin: First off, can you tell us just a bit about your experience in the industry?
Aaron Sanders: Well, I really started working with computers back before I was even a teenager, since both my parents were involved in the industry. I wrote my first basic program at that time, but in high school I decided computers really weren’t all that cool and gave them up and gave gaming up and didn’t find it again until college when I moved to San Francisco and the place was just all abuzz about the Internet.
A friend of mine told me the secret about that [the Internet] is everything you want to know about the Internet is on it, and with him and some other people built my first website around snowboarding. We were going to have resort information and interviews and videos and all sorts of stuff like that and put it together and pitched it.
A lot of people on the snowboarding industry just didn’t seem to understand why they should be on the Internet.
While that fell apart, I realized that I could begin to make a living as a contractor building sites and started to do that for the Hewlett Packard Scanjet site, and that led on to some other things, such as working at Oracle for a while, where I really got a lot of professional development in all the technologies they were using at the time, such as PL/SQL and Java. They also had a really robust process where I would write a whole bunch of requirements and they never seemed to see the light of day.
I put Easter eggs in them, “Read this and I’ll buy you lunch.” Nobody ever came by. That really started me thinking about there’s got to be a better way to do this. That was end of the ‘90s into beginning of the 2000s and I started attending software process improvement groups and found agile was still working on contract.
I think the thing about that is no matter what that person is doing that’s contracting you, you’re supposed to come in, understand their problem, understand the language it’s written in, and just jump right in. Really, right there, [you] have to be somewhat flexible and adaptable and learn the different syntaxes of languages and that sort of thing.
I did start to seek out places that were more agile-related and eventually became an extreme programmer doing the test-driven development and all of that kind of stuff and really loving it and deciding that this is something that I wanted to help other people that were interested in to do.
Now, over about the last six years or so I’ve been an agile coach. One of the nice things about being an agile coach or being an XP developer is it’s really true, technology and business, working together daily, you get to see each other’s work. Because of that, I became a lot more aware of other positions and business and user experience and product management and started to see some other tools that could help improve the situation.
Josiah Renaudin: Now, a lot of your discussion that will be happening October is about having a shared understanding among different members of a team. How often do you see developers, testers, and users actually have this shared understanding of a system?
Aaron Sanders: Well, it’s when they’re able to work together. It is really what helps that shared understanding daily, if possible. Now, at least with the developers and testers, with the users you might see them every week or two. Yet that’s how we keep that tacit knowledge going and understand… what is our mutual purpose, why are we building the thing that we’re building?
Josiah Renaudin: What types of assumptions about systems often lead to a disastrous team situation?
Aaron Sanders: The types of assumptions tend to, from what I have seen and as I’ve worked as a developer, come from the requirements themselves. It seems to be no matter what we write down or even maybe put some flows together with, there’s just a lot of ambiguity and uncertainty left up to the person reading that thing to figure out what’s really meant there or making a decision of what they feel is the best approach for a certain feature, function, specification, whatever.
Josiah Renaudin: What do you see as more important to a project’s actual success; team chemistry or technical savvy? Would you rather work with a team of individualistic technical geniuses or team players with a much more basic technical know-how?
Aaron Sanders: I think it’s really important that a team has that chemistry and has that mutual purpose. If we know our goal and where we’re going together as a team, we can also overcome some of those differences or conflicts and approaches and personalities and work together better.
I would say that then it’s about being a team player. If you don’t have enough skill, though, that’s a place where it’s really easy for somebody with high skill to come in and take over. They are maybe hired because the organization sees the team is not really having the right kinds of skills.
Really, I would prefer some sort of diversity, where we have a diverse set of skills and experience that we can work together and play to the strengths of each other. Then that way it’s really hard for some expert to come in, get hired, and take over.
Josiah Renaudin: Do you think a team can actually properly function if, let’s say, like you said, a technical genius comes in and kind of takes over? Can a team work in concert with someone so commanding over the group?
Aaron Sanders: Well, usually not as well or not for some time until that person really finds their place and understands. A situation like that will change the team. It will change the dynamics of a team and it will usually change the team membership as well.
Josiah Renaudin: Absolutely. Have you found a common misunderstanding that just about every team deals with, or is each group really different?
Aaron Sanders: Well, that common misunderstanding I think is about the requirements. What really has led me into agile coaching is trying to understand where does this stuff come from. Even as a software developer and as a consultant contractor, when people tell me to do this, say, well, what’s the problem; what’s going on; can you help me see why I should be doing this?
I think that common misunderstanding can start really early in inception or origination of a project or an idea or some sort of task being handed out.
Josiah Renaudin: Yeah. I think a lot of your point of this talk is that we worry about testing a system, testing a product, before we really test the team and our assumptions about that team. Kind of in summation, why don’t we test our assumptions as a team as often as we should?
Aaron Sanders: We don’t even know what assumptions we’re making, how to find them, and figure out how to test if they’re valid.
Josiah Renaudin: Absolutely. Now, just to kind of close … I don’t want to give away all of your discussion before October rolls around. Do you have anything in particular you’d like to tell testers before they attend your presentation at STARWEST?
Aaron Sanders: Be prepared to get involved and participate. It won’t just be a lecture.
Josiah Renaudin: It was very nice talking to you. I appreciate your time. I’m looking forward to actually meeting you in person in Anaheim.
Aaron Sanders: Likewise. Thank you very much.
Through training and coaching, Aaron Sanders helps organizations design collaborative systems. Aaron owes the effectiveness of his work to practice spanning more than two decades in technological and interpersonal disciplines. He believes that his work as a Certified Scrum Trainer introduces all the initial concepts, while the full impact on the learners is usually felt days later. Coaching allows him to sense when a situation requires attention and leads to faster concept integration. Since there’s always room for improvement, Aaron finds that pairing with others helps him improve his skills and increase the customer’s benefit. Check out Aaron’s work at aaron.sanders.name.
