How can I integrate information from a waterfall customer into an agile project?

Question

We're currently doing an agile project where the customer is less agile than what we actually hoped for (he stays with waterfall). Also, while an official requirements specification exists, it is unfortunately not updated by the client (timing problems, whatever), so, our current process to get information we need looks like this:

• to get the requirements right we collect questions to the "epics" we identified in a Wiki (Confluence)
• for each epic, we export these questions to a Word file and send them to the customer
• the customer comments on these questions and sends them back
• we copy-over the comments from the Word file back into the Wiki and further comment on them or close the questions, eventually we send updated epic exports back to the client

The reason why we try to keep these information in the Wiki is because we would like to have one central, searchable place where all the project requirements are clarified and described in detail (no Word document hell). Furthermore, we currently write our system specification in the same Wiki as well, which gives us the ability to reference customer answers / requirements to the functional requirements we define and much more.

Obviously though there is at least one problem with this approach: The hand-copying of answers and the exporting of question catalogues over and over again. This, paired with the problem that some kind of "external" agreed document must always exist to reference later on in case stuff goes wrong, is a major headache for us.

I know people used Action Item lists for these kind of things in the past, but this does not at all fit our information finding expectations. On the other hand, a Wiki, by its nature being able to be edited at any time, surely will also not match the "agreed document" requirement.

So, what are some valid techniques to do these things better (proper tool support even?!) or have you already ran away after you read the first paragraph of this question?

Answer 1

This is a common problem with most methodologies. Tracking and documenting changing requirements is difficult. Both the customer and development team need to be award of changes to the requirements. And both will likely be driving changes to the requirements. If the client has done Big Upfront Design, rather than Waterfall, they are less likely to drive changes.

As you are finding, the development team is generating requests for clarifications of the requirements. The client may also have changing requirements. This is commonly dealt with by a change control process.

You may find keeping the documents flowing between the team and the client in a text format works better. Doing the communication using email messages may make the transfer of information flow more easily. Depending on the answers received, it may be appropriate to cut and paste the answer into the requirements document. Other changes may result in edits to the requirements. In any case, you should be able to trace the current requirements to the original requirements, and any approved changes.

Asking for clarification more frequently may help reduce the friction in the change process. Adding the changes and responses to a bug/issue/task tracking system may also help in a number of ways. With the appropriate work flow you will be able to track the changes through their life cycle. It may be easier to get the client to join use the issue tracking tool than update the wiki.

Answer 2

I'm still not sure that I understand the question/problem, and @skilwz's comment leads me to believe that this might be an X:Y problem. There is going to be turbulence & friction if your customer is committed to waterfall, and you're committed to agile. The real problem may be differing conceptions of how to manage change and scope. I also suspect that this is a violation of CodeGnome's law - you're masking the technological implementation rather than the core problem. (Neither of those comments are a criticism of you; the situation is what it is, and you're trying to navigate your way through it as best you can.)

As I understand it, you're managing change, but your customer is not participating in the change management process. Some alarm bells go off in my mind at that point that have nothing to do with agile/waterfall/whatever. The customer's detachment from change and scope management concern me at a fundamental level. If it were possible to resolve that problem, I'm sure you'd have done so, so let's proceed on the assumption that you don't have the option to affect that problem.

Proceeding on that assumption, you've taken the defensive step of formally requesting your customer's participation in change management, and formally recording the customer's input. I think there are two goals

1. Be effective in incorporating the customer's input into the change control process despite the customer's reluctance.
2. Ensure that you've got formal traceability from customer input to requirements.

The desire for formal traceability raises the volume of the warning bells, but there is nothing we can do about that.

My first priority would be to make sure that the team understands the problem and the solution. If the team doesn't understand the problem, not amount of sophistication in the technological implementation will matter.

Then I'd import or attach the customer's response document (what I would call the "epic word document") to the wiki page. (depending on what your wiki supports), and build links from your requirements to his comments.

Sorry for the longwinded reply, but the peripheral issues concern me more than the core question.