On small projects, the dialogue between the customer and the developers can flow easy, and good things happen.
The quick analysis
Developer: … so we’re going to complete the current task tomorrow or the day after. Could we discuss what to do next before you’re off to your next meeting?
Customer: Sure. The next task on the backlog is to send the payment request to the accounting system
Developer: Yeah. Um… well, we’re not really ready for the integration tasks yet. I was thinking that we might perhaps pick another user interface task. Would that be okay?
Customer: No problem. Let’s see…. how about “road project submits funding request”?
Developer: Great. What’s that?
Customer: Well, today, the owner of the road project sends in a paper form. Let’s see, the form is available as a PDF on our web site. Let’s take a look.
Developer: Let’s see…. We know how to deal with social security number, names, addresses. This field “municipality,” that’s the usual stuff, right? (customer nods) What about “request id”? What’s that?
Customer: It’s just a sequence number per municipality. It would be really nice if you could suggest a request number and then let the user override.
Developer: That should be doable.
They work out a few more details and get on their way. Total time, 30 minutes
The low ambition implementation
Developer: So, we worked on the funding request UI for the last two days. I think we’ve got something that looks pretty good.
Customer: Great, let’s see it! Let’s see… There’s a new “apply for funding request” menu item. Nice. But it should be “Fund road project” (developer notes feedback). Let me try and press it… Hmm… “select municipality”? Why do I get that?
Developer: Well, we’re still a bit shaky on AJAX. So in order to find the next sequence number, we would like to have the user select municipality first.
Customer: Oh, AJAX. That’s interactive web pages, right? Yeah, I guess that’s fine, but we need to fix up the text a little. So, what happens when I select one…? Nice, it sort of looks like the paper form. That will help us get learn it. But let’s move the fields around a little (he sketches a few change on a piece of paper).
Developer: We were a bit uncertain about this “sum” field. Does the user have to fill in the sum himself? He’s already filled in all the numbers.
Customer: That doesn’t make too much sense. How about if the web pages updates the sum field dynamically? Oh, you’ve got that ‘don’t make me do dynamic webpages’ face again.
Developer: Yeah, sorry. The last time it was a big mess. Can we hold off on that for now? Do you really need it?
Customer: (laughs) No, that’s okay. I guess we can just remove the field. That should be fine.
Developer: Yay! What about validating the bank account number? We left that out, because the documentation is…. well, insane. That alone will take at least another day.
Customer: No, we really need that. People often type it wrong, and then it’s a nightmare to fix all the errors that follow. You just have to fight though it.
Developer: (sigh) I guess it can’t be helped. We’re on it.
Customer: All in all, it looks pretty good. I’ll go over it by myself after lunch and bring you back some issues tomorrow.
The quick completion
Customer: Here’s a list of corrections. Nothing major, just a few misplaced fields and a few extra validation rules.
Developer: Great. We spent all of yesterday doing the bank account number validation. Man, that’s some bad doc! But we should be done before lunch.
Customer: I have an opening in my calendar at the end of the day, let’s take a look then and call it done. Great work, guys!
The contrast
Have you ever been on a small project where everyone has a pretty good understand of what’s going on and the communication works well? Developers can make a pretty good guess at the details and develop a pretty good first version. There may be some more work that’s needed, but these can be negotiated when the developers have a better idea of what’s going to be easy and what’s going to be hard.
When I’ve been on larger projects, this communication seems to break down. Instead the developers require a detailed specification in writing. And if something is missing from the specification, they reject it and ask for further details. And they won’t show the product to the customer before all the kinks are worked out.
When we do it well it’s not so bad, getting a detailed specification and finishing the task before we get real feedback. But it requires the customer to decide on things that may not be important, but that may impact cost substantially. It requires back and forth to get the specification written, reviewed, amended etc.
On a small project, a developer can understand the purpose, build something quickly and adjust it based on feedback. Is the reality of larger projects that this will just remain a pipe dream? If so, why? If not, how do you get the quick and informal feedback?
Reference: Can we replace requirement specification with better understanding? from our JCG partner Johannes Brodwall at the “Thinking Inside a Bigger Box” blog.
But do we really want our lives to be about fighting over who is to blame?