The Myth of No Documentation in Scrum Projects
This chapter is from the book
This chapter is from the book
This chapter is from the book
We’ve all heard the common myth, Agile means no documentation. While other agile fallacies exist, this is a big one, and it could not be farther from the truth. Good agile teams are disciplined about their documentation but are also deliberate about how much they do and when. In this chapter’s story we find a duo struggling to explain that while they won’t be fully documenting everything up front, they will actually be more fully documenting the entire project from beginning to end.
The Story
”Hey, you two,” said Ashley, stopping Carter and Noel in the hallway as they passed by her office. “I’ve been sensing some resistance from you two over the initial project documentation. I need it by next Friday for project sign off, OK?” Ashley looked back at her computer and began typing again, clearly expecting a quick answer.
Carter and Noel looked at each other then back at their manager Ashley before replying. They had known this conversation was coming but didn’t realize they’d be accosted in the hallway by an obviously harried Ashley when it did.
“Listen, we can document everything up front like you ask” Noel began as she and Carter moved to stand close to Ashley’s doorway. “But we don’t think it’s the best approach. Things change and we cannot promise you that things will go as planned. Further...” Ashley stopped typing and looked up, interrupting Noel mid-stream.
“Look, I don’t want to argue about something as basic as documentation. I just need it on my desk by Friday.”
Carter spoke up.
“Ashley,” he began. “Can I have five minutes to try to communicate a different approach? I know you’ve got a full plate, but I think it’s important for you to understand this point before we table our discussion.”
Ashley glanced at her watch, then nodded. “Five minutes. Go.”
“When I was in college, I worked for our university newspaper,” Carter explained. I worked as a sports photographer so I always went with the sports writers to the local football games. I would be on the field, and they would be in the stands.
“It probably won’t surprise you to hear that not one of those sports writers came to the football game with the story already written. Now, they might have done some research on the players. They might have talked to the coaches about their game plans. They might have asked me to be sure to get some shots of a particular player. But they didn’t write the article before the game even began.
“That’s kind of what you are asking us to do with the software. You want the complete story of how this will unfold, including the final game score, before we’ve even started playing,” said Carter.
“Well, that’s how we get things done around here. Without the documentation, I can’t get project approval, and I can’t be sure that you guys understand what we need you to build,” explained Ashley.
Carter continued. “Right. I get that. It’s not unreasonable for you to want some information before we get started. And you should expect to receive frequent updates from us on what’s going on with the project. After all, the reporters I worked with would take notes and write snippets of the article about the game as it was unfolding. They would come down at halftime to talk to me about the shots I had captured and the angle they were working on based on how things were going so far.
“But to ask us to tell you what the software will look like, exactly how much it will cost, and precisely when we’ll be done is like asking us to predict the final score of the football game. We can tell you how we think it’s going to go, but when things are changing and unfolding, it’s difficult to predict all the details.”
Ashley nodded. “But things aren’t always that volatile with our projects. We know basically what we want this to look like. It’s only some things that we aren’t sure of.”
“Right,” said Noel. “And if you’ve got a project where we can nail down most of the variables and have a clear picture of the final product, we can give you more documentation.
Carter nodded, “To go back to my sports writer analogy, there were times when one team was clearly dominating—the game was a blowout. In those cases, the reporters had their stories mostly written by halftime. They’d already come up with the headline, filled in a lot of the details, and were just waiting until the end of the game to add the final stats and score.
“Most times, though, the games were close and the outcome uncertain. In those cases, the reporters would keep filling in the skeleton of the story with the events as they happened in real time. They would come down to the field at halftime, and we would talk about the unfolding story and how they were writing it. We’d strategize and say ‘if the game goes this way, we’ll take this approach. But if it goes that way, will take this other approach.’
“Likewise, the level of detail in our documentation should depend on how certain we are that things aren’t going to change.”
Ashley leaned back in her chair with her hand on her chin, deep in thought. Noel decided to go in for the kill.
“Ashley, remember when the Deepwater Horizon platform exploded and the oil started spilling in the Gulf of Mexico? Or the 9/11 attacks in the US? The London train bombings or the Moscow airport attacks? Or the quake and tsunami in Japan? Or when Reagan or Kennedy were shot?”
Ashley nodded.
“Well, you would notice a trend in all these events. In the initial accounts, the media headlines conveyed the big idea, but not many details. All they could tell us at first was generally what had happened (oil spill/terrorist attack/quake/tsunami/assassination attempts), when, and where. Why? Because the events were still unfolding and that was all anyone knew for sure. As the reporters on the scene learned more, they added the new facts to the story and changed the headlines, and the stories, to reflect the new information.
“All those little updates and facts and details, though, were important to capture in real time, even if they later had to be updated to reflect changes and new information. Without them, much of the information about the events would have been forgotten in the chaos surrounding it. The reporters didn’t try to write more up front than they knew. Instead, they recorded what they did know as they went along. Later, after the details had solidified, they went back through the various articles and wrote a larger, encompassing synopsis that outlined the specific event from the initial failures to the current state,” Noel said.
“That’s what we’re suggesting we do: make our documentation a story in progress. Is this making sense?” asked Carter.
Ashley sat forward.
“I think I get it now. What I originally heard you say was ‘I can’t give you documentation.’ But what you’re actually saying is that you will document certain things up front, most things in real time (updating them as necessary to reflect reality), and some things after the fact. But what does that mean in terms of software exactly?”
Noel spoke up, “One of the things we need to write for this project is the end-user manual and the customer support reference manual for the call centers. I think you’ll agree we should not write those before we write the code, correct?”
Ashley nodded.
Noel continued, “Right, so when should we write them? In the past, we have written them at the very end of the project. When this happens, we scramble to find the little details because we forget to write them down, or we say ‘we’ll remember that’ and we never do. The details are essentially lost, and a significant amount of time is needed to find them and document them, if they can be found at all. In the meantime, we’re holding up a release of a functioning system all because we’ve forgotten exactly what every feature does in the system, and we are re-creating everything so we can create these manuals.
“What we need to do is document as we go, as soon as we can without doing too much. That way when we get to the point where the UI stabilizes, let’s say, we can create even more detailed user guides, but we will not have lost our details. And if things change along the way, we will update what we have written to reflect it. It’s a balance between stability and volatility. The more volatile something is, the more careful we need to be in what level we document. If it’s stable, we can do something like a large database diagram model in a tool. If it’s volatile, we might just draw a picture on the whiteboard—again, both are documents, database models to be exact, but they are very different in terms of formality,” finished Noel.
“So, are we on the same page?” asked Carter.
“Yes,” said Ashley. “I get it now. I think this is a good approach and something that I will advocate, provided you give me regular feedback so I can update senior executive management. But I still need the big headlines by Friday. Agreed?”
“Agreed,” said Carter and Noel together.
And that was that.