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.
Josiah Renaudin: Kind of branching off of that, we were just talking about misunderstandings. It's really vital to understand business needs before starting any sort of project. What do you see as the best method for actually getting a firm grip on what it is you're creating and how best to direct its development?
Jared Richardson: Oh, wow. A lot of people don't like the single wringable neck these days because it's too often used to indicate a scapegoat, but I do like having the idea of a responsible party. Scrum calls it the “product owner.” Somebody who's responsible for gathering the requirements, bringing it together, and educating and sharing with the team and if there's an area that a developer or tester doesn't understand, the PO can either try to clarify, or put them in touch with the right customer, the right sales person, the right executive.
In order to get a handle on it you have to have a channel for that communication to flow neatly and cleanly. You need to build up some tribal knowledge within the company and the product owner is a pretty good direction for that to take.
Josiah Renaudin: How can we transform requirements into stories, and how does that give them real business value?
Jared Richardson: One of the things, actually the key thing, we'll be covering in the half-day tutorial in Anaheim, is a bit about converting the text into, almost a spreadsheet. A grid, if you will, of these three inputs, result in this output. These seven inputs result in that output.
It makes a lot of sense when you start with a text document that can be misunderstood. The developers are going to have to boil it down to that level of clarity. If A, then B, then C. No, sorry. If A and B and C, then D. They're going to do it. The question is whether or not you're going to convert it into a format that the business owner can understand, or whether you're going to wait and let them look at the software when you're done, and, again, call the team an idiot, they didn't understand.
Start with your text, translate it into a grid, and that grid can trivially be turned into a story, into a cucumber story, into a J unit test, into whatever format you want, because that spreadsheet with the seven variables, the seven inputs and the one result, forces you to decompose the text into manageable scenarios. It forces you into really analyzing and understanding what the inputs are and how A affects B and B affects C.
Josiah Renaudin: Yeah, and you just mentioned manageable scenarios, you were talking about breaking things down. I've run into a lot of situations, in my short career, where people see a large project, they see something big and they get overwhelmed, instead of breaking it down they try to tackle it all at once. Do you think we decompose larger requirement stories as often as we should? Have you seen testers and developers trying to tackle a big project without really breaking it down into smaller parts first?
Jared Richardson: I have a graphic on my wall in my office, I think it's from the Standish Group, where it shows success and failure rates for large projects. At one year, for a one-year project the failure rate is 25 percent, for two years it's 50, three years 75, and at four years your project is statistically guaranteed to fail.
We know that the larger the project, the higher the failure rate. The bigger we try to tackle at once, it’s the old, "I'm so busy driving I don't have time to stop for directions." I realize I have a lot of work, I feel overwhelmed, so I immediately start cutting corners. I don't try to decompose things into smaller, manageable chunks, it's a “shut up and code” situation and I have that T-shirt by the way, I love that, “shut up and code.”
Josiah Renaudin: I like that, too.
Jared Richardson: I'm not going to plan, I'm not going to write tests. I'm going to work hard, I'm going to work and I'm going to slave, and no-one's going to question your dedication to the company, but we're going to question how intelligently you're working. Right, you're working hard, but dumb. To bring in the old overdone management maxim, "Work smarter not harder." People absolutely will try to tackle too much work at the time and the end result is a really big chunk of spaghetti code instead of smaller manageable modules.
Gosh, I told you I would rabbit trail a bit, but the whole concept behind almost every principle and practice in agile software development is a feedback loop. I want to code the minimum possible and show it to somebody. We're talking about acceptance test driven, it's about getting those requirements into something that my business owner can understand. If I can’t demo that for you for six months, my odds of success have plummeted.
I instead want to code up something very small, just enough to show you the workflow, and have something for you every two weeks, at the outside every month, but I want to work as little as possible, and have something that I can run. And that one thing would force a lot of teams to slow down enough, that they would … you're going to waste some time, you're going to waste some money, especially on a research or an R&D-oriented project, but we want to minimize that.
We want to code as little as possible, let the customer, the PO, the business owner, see it, and realize we're headed in the wrong direction and turn the steering wheel, adjust our aim, until we're minimizing the risk, we're minimizing the expenses, and we're maximizing the amount of time that the team is coding the correct product.
Josiah Renaudin: When you talk about stopping and checking the code more often than every six months, doing it monthly, or bi-weekly, or something to that nature, does that make the development process move a lot slower? I know the goal is to create cleaner code, to make sure that these bugs and issues don't happen later, but, can it be difficult to try to convince a manager that you need to do this, you need to spend the extra money testing it and the extra time testing it, in order to create a better product?
Jared Richardson: It depends on whether or not the manager has been around long enough to recognize that we don’t ship lines of code, we ship the right features. I can take my entire team and have them work overtime for a year, and I can turn out more code and more features than the team that works for six months, but works a week and runs a demo, works a week, runs a demo. At the end of the six months I guarantee you the team that spent half the time coding will have the right product.
The team that spends a year coding, not likely. It's going to be gold plated, it's going to enterprise ready, it's going to be cloud enabled, and it's going to do really cool things the customer doesn't need or want. It does slow you down in terms of writing lines of code per minute, but it speeds you up on getting working software out the door, and at the end of the day that's the metric we need to be looking at. The problem we run into, sorry, another opportunity for me to rabbit trail.
Josiah Renaudin: No problem at all.
Jared Richardson: The problem we run into in software is, primarily, the work is done in our heads. Your manager who may not have a software background doesn't know how to manage that. They don't know how to ensure that the company's getting the bang for the buck, they don't know how to ensure that they're doing their job and managing you.
So a manager, or a drowning person, a drowning man or a drowning woman is going to grab onto anything around, including the lifeguard, and drown them. So, you put someone in this situation, they feel like they're drowning, they're stressed, and they see lines of code. Man, that's a metric I can measure, that's something I can count, what are they going to do? They're going to grab onto it with all their might and drown you and the rest of the developers and testers and take the product down with the ship.
We need to give them something else to measure, so that they can do their job. If we can move away from lines of code, which is a horrible, horrible metric, and move towards working acceptance tests. So maybe I get with my PO and we write a series of acceptance tests that say, "This shows this scenario works," and I can say we wrote 174 acceptance tests, thirty-two are working and have been demoed and of what's been demoed five have to be reworked because the customer doesn't like the workflow, but I don't really care how many lines of code it took. I care how many of the features work. That's my long answer to your short question.
Josiah Renaudin: You've been working in this industry since 1991. What principles and methodologies do you know today, that would have really been invaluable during the early ‘90s?
Jared Richardson: Oh gosh, the early ‘90s. In the early ‘90s, C and C++ were hot. Java wasn't born until, what, ‘96? Ruby came around in ‘95. We were focused on object orientation. The iterative nature that came with the lightweight methodologies, extreme programming, Scrum, Crystal from Alistair Cockburn, the rapid feedback, the short iterations, is what came out, from my point of view, the most important thing that came out of the agile movement … the write a little and get the feedback. Whether you're going to do it with test first, acceptance-test driven. Whether you're going to do it with weekly by weekly demos. The shorter iterations of work is the thing we could have used earlier.
Josiah Renaudin: I don't want to expose all of your talk, I want to save some surprises for Anaheim in October, but, more than anything, what message do you want the attendees of your tutorial in October to walk away with?
Jared Richardson: What I want them to leave with is a requirement, in order to save the company money, to keep your developers on the right track, to keep your testers validating the right thing … a requirement's got to be binary, it's got to be black and white. It can't be fuzzy. If it's fuzzy and there's room for interpretation, the odds are that feature will get delegated to some kid straight out of college. He's going to make the interpretation, he's going to make the call, and code it up in what he thinks is the right way, when the requirement was written by a twenty-year business veteran who has a completely different point of view.
If you don't clarify what you want in the requirements, and make them black and white, which you cannot do in prose, or lawyers would be much more efficient and much more affordable. You can't do it in prose, if you can make the requirements black and white, and you can do it before you spend money writing code, then you're going to have a more efficient organization, you're going to have less rework, you're going to have fewer schedule surprises, you're going to minimize the risk and increase, might I even say maximize, your chances for shipping the project on time and under budget.
Josiah Renaudin: Fantastic, I really do appreciate your time, once again, Jared, and I'm really looking forward to hearing more from you at STARWEST this year.
Jared Richardson: I'm looking forward to seeing you there as well, Josiah, thank you for your time.
Josiah Renaudin: Thank you.
Principal consultant and a member of the core team at Agile Artisans, Jared Richardson works with other software craftsmen to build excellent custom software. He sold his first software program in 1991 and has been immersed in software ever since. Jared has authored and coauthored a number of books, including the best selling Ship It! A Practical Guide to Successful Software Projects and Career 2.0: Take Control of Your Life. He is a frequent speaker at software conferences and a thought leader in agile. Jared lives with his wife and children in North Carolina where they recently, quite by accident, became backyard chicken farmers. He's on the web at AgileArtisans.com.
