In this interview, principal consultant and Agile Artisans founder, Jared Richardson, explains how misunderstanding requirements can cause major issues within an organization. He covers why team members need to communicate, how big projects are often mishandled, and the value of agile.
Josiah Renaudin: Today I'm joined by Jared Richardson, a principal consultant and a member of the core team at Agile Artisans. Jared, thank you very much for speaking with us.
Jared Richardson: Thanks for having me here today, Josiah. I appreciate it.
Josiah Renaudin: All right, well, first could you tell me just a bit about your experience in the industry?
Jared Richardson: Sold my first program back in 1991, still in college at the time. Been bouncing between consulting and full time work ever since. I tell people I'm fortunate enough to get paid to tinker with software or tinker with teams. I was fortunate enough to get in on the agile movement fairly early. I'm the second public signatory, dumb luck but I'll take it.
One of the guys called me and said, "Hey, this thing's live, you got to hit the website and sign in," so that was fortunate, to get in this movement at the right time. Before that I was involved with some of the object-oriented direction of the 90s, came out of the small talk industry, spent some time in Java, more recently Ruby, Ruby on Rails and process consulting.
Josiah Renaudin: Now, your STARWEST tutorial, titled, "Take a Test Drive, Acceptance Test-Driven Development" digs into the value of acceptance tests. Could you talk a bit more about how misunderstanding requirements can lead to mistrust within the organization?
Jared Richardson: Oh gosh, this is the biggest area. Beyond trust, managers want to hear about money, right? You want to talk about wasted money, wasted trust, wasted relationships. Someone takes text written in English, or whatever country you happen to be from, but I'm from America, so, you take something written in English, and I really want it to be right.
So I'll give it to some person who's inexperienced, new to the company, have them write it up. If I really cared, I'd hire a lawyer at $250 an hour, then I'd pay another lawyer $350 to prove it didn't mean what you said it meant … but I'm going to take a requirement, I'm going to take something I want to come out of software and try to encode it in prose, which is horribly inexact, inefficient.
I then give it to somebody with a different background. I'm business oriented and I'm writing requirements, maybe I'm customer facing, maybe I'm in sales. I'm going to hand that over to somebody with a technical background. They're then going to implement what they thought I wanted, in prose, they're going to translate it into some kind of programming language, machine language, machine code. Then I'm going to give it to someone in QA who doesn't speak code, nor business, nor customer, they're going to reinterpret the requirements again and then I'm going to have three sides where the business owner, the requirement writer says, "You idiot, you're a bad developer, you didn't give me what I wanted."
The developer says, "I wrote exactly what you wanted, you're an idiot for not recognizing that all my months of work were well spent," and this QA guy's over on the side going, "You're both idiots, it means the other …" So you have three sides of a coin, if you will, everyone's fighting over their interpretation being the right one, the requirements owner has spent, or committed, the company's money, so their ego is now involved, so they doggone-it has to be right. So the developer just spent three, four, six months of their lives coding it up, now my ego is involved, now I have to be right. QA's trying to show values, save the company money, I'm the last line of defense, so I have to be right.
This is a big waste of money, I now think you're a liar, you think I'm a liar, I think you're an idiot, you think that we're both idiots. How's that for a long answer to a short question? Instead of investing all that money, and then having the inevitable, I'll call it a discussion, it's usually an argument, but instead of having that discussion after we've spent all that money creating the product, if we go with a test-first approach, especially an acceptance test driven approach, we can get that golden triad, as Ken Pew likes to call it. The business owner, the requirement writer, the developer and the tester in a room, and have that discussion before we write the code.
If we're going to have the discussion, and I'm going to misunderstand you and you're going to misunderstand me, let's have that first, and secondly let's move it out of prose, because what's our classical solution? If an eight-page word document didn't describe the feature, then I probably need a twenty five-page word document, right? Let's make the water clear by throwing more mud in it. Let's move out of prose and go to something that's binary. Let's go to a test that can be run and read. I guess that's the two-pronged answer there.