“Welcome to the team, Pat,” said Kim, smiling at the recent graduate. “Let me show you around. As I said during the interview, we’re an XP shop. You may find that things are a little different here than you learned in school.”
“I’m eager to get started,” said Pat. “I took a software engineering course in school, and they taught us about the software development lifecycle. That made a lot of sense. There was a bit about XP, but it sounded like it was mostly about working in pairs and writing tests first. Is that right?”
“Not exactly,” said Kim. “We do use pair programming, and we do write tests first, but there’s much more to XP than that. Why don’t you ask me some questions? I’ll explain how XP is different than what you learned.”
Pat thought for a moment. “Well, one thing I know from my course is that all development methods use the software development lifecycle: analysis, design, coding, and testing [see Figure 3-1]. Which phase are you in right now? Analysis? Design? Or is it coding or testing?”
“Yes!” Kim grinned. She couldn’t help a bit of showmanship.
“I don’t understand. Which is it?”
“All of them. We’re working on analysis, design, coding, and testing. Simultaneously. Oh, and we deploy the software every week, too.”
Pat looked confused. Was she pulling his leg?
Kim laughed. “You’ll see! Let me show you around.
“This is our team room. As you can see, we all sit together in one big workspace. This helps us collaborate more effectively.”
Kim led Pat over to a big whiteboard where a man stood frowning at dozens of index cards. “Brian, I’d like you to meet Pat, our new programmer. Brian is our product manager. What are you working on right now?”
“I’m trying to figure out how we should modify our release plan based on the feedback from the user meeting last week. Our users love what we’ve done so far, but they also have some really good suggestions. I’m trying to decide if their suggestions are worth postponing the feature we were planning to start next week. Our success has made us visible throughout the company, so requests are starting to flood in. I need to figure out how to keep us on track without alienating too many people.”
“Sounds tough,” Kim said. “So, would you say that you’re working on requirements, then?”
“I’m working on making our stakeholders happy,” Brian shrugged, turning back to the whiteboard.
“Don’t mind him,” Kim whispered to Pat as they walked away. “He’s under a lot of pressure right now. This whole project was his idea. It’s already saved the company two and a half million dollars, but now there’s some political stuff going on. Luckily, we programmers don’t have to worry about that. Brian and Rachel take care of it—Rachel’s our project manager.”
“Wait... I thought Brian was the project manager?”
“No, Brian is the product manager. He’s in charge of deciding what we build, with the help of stakeholders and other team members, of course. Rachel is the project manager—she helps things run smoothly. She helps management understand what we’re doing and gets us what we need, like when she convinced Facilities to tear down the cubicle walls and give us this nice open workspace.
“Let me introduce you to some more members of the team,” Kim continued, leading Pat over to two people sitting at a workstation. “This is Mary and Jeff. Mary is a mechanical engineer. She normally works in manufacturing, but we asked her to join us as an on-site customer for this project so she can help us understand the issues they face on the floor. Jeff is one of our testers. He’s particularly good at finding holes in requirements. Guys, this is Pat, our new programmer.”
Pat nodded hello. “I think I recognize what you’re doing. That looks like a requirements document.”
“Sort of,” Jeff replied. “These are our customer tests for this iteration. They help us know if the software’s doing what it’s supposed to.”
“Customer tests?” Pat asked.
Mary spoke up. “They’re really examples. This particular set focuses on placement of inventory in the warehouse. We want the most frequently used inventory to be the easiest to access, but there are other concerns as well. We’re putting in examples of different selections of inventory and how they should be stored.”
“You can see how things are progressing,” Jeff continued. “Here, I’ll test these examples.” He pressed a button on the keyboard, and a copy of the document popped up on the screen. Some sections of the document were green. Others were red.
“You can see that the early examples are green—that means the programmers have those working. These later ones are red because they cover special cases that the programmers haven’t coded yet. And this one here is brand-new. Mary realized there were some edge cases we hadn’t properly considered. You can see that some of these cases are actually OK—they’re green—but some of them need more work. We’re about to tell the programmers about them.”
“Actually, you can go ahead and do that, Jeff,” said Mary, as they heard a muffled curse from the area of the whiteboard. “It sounds like Brian could use my help with the release plan. Nice to meet you, Pat.”
“Come on,” said Jeff. “Kim and I will introduce you to the other programmers.”
“Sure,” said Pat. “But first—this document you were working on. Is it a requirements document or a test document?”
“Both,” Jeff said, with a twinkle in his eye. “And neither. It’s a way to make sure that we get the hard stuff right. Does it really matter what we call it?”
“You seem pretty casual about this,” Pat said. “I did an internship last year and nobody at that company could even think about coding until the requirements and design plans were signed off. And here you are, adding features and revising your requirements right in the middle of coding!”
“It’s just crazy enough to work,” said Jeff.
“In other words,” Kim added, “we used to have formal process gates and signoffs, too. We used to spend days arguing in meetings about the smallest details in our documents. Now, we focus on doing the right things right, not on what documents we’ve signed off. It takes a lot less work. Because we work on everything together, from requirements to delivery, we make fewer mistakes and can figure out problems much more easily.”
“Things were different for me,” Jeff added. “I haven’t been here as long as Kim. In my last company, we didn’t have any structure at all. People just did what they felt was right. That worked OK when we were starting out, but after a few years we started having terrible problems with quality. We were always under the gun to meet deadlines, and we were constantly running into surprises that prevented us from releasing on time. Here, although we’re still able to do what we think is right, there’s enough structure for everyone to understand what’s going on and make constant progress.”
“It’s made our life easier,” Kim said enthusiastically. “We get a lot more done...”
“...and it’s higher quality,” Jeff finished. “You’ve got to watch out for Kim—she’ll never stop raving about how great it is to work together.” He grinned. “She’s right, you know. It is. Now let’s go tell the other programmers about the new examples Mary and I added.”