3

It happens in my workplace that when a product is finished, and just some weeks before it is released and the project is closed, some business considerations remain about features that are wanted for future versions.

A revision is made about the features when the project is closed, and the clients and stakeholders, along with the team decided, for example, that they want to open a new project that has as objective to create a new version of the project that includes some new requirements.

Now this is a typical case, but it happened before that the team that made the product, now works for another company and a new fresh team is formed to do this project. I know Agile aims to give value to interactions rather than documentation, but how does Agile manages this? How do you continue a new project to extend an already existing product without documentation?

Improve this question
2

5 Answers 5

Reset to default
3

Read the Agile Manifesto again. The key clause is at the end "while there is value in the items on the right". The word Agile is used over and over again to justify no documentation. That was never the intent of the signatories.

Uncle Bob puts it best. "Produce no document unless it's need is immediate and significant." But again the "unless" of this clause is often ignored.

Developers don't like documentation, so these are very good sources to misquote.

So let's not blame Agile for this problem, let's blame the original team. Even more fundamentally, blame the management for not demanding "immediate and significant" documentation on their departure.

However, blame does not solve your problem. I'm afraid that the only solution is digging through the code, looking at the software, talking to your users. Learn from your predecessors' mistakes and create some immediate and significant documentation which the rest of the team can read, so that you can learn from each other.

Improve this answer
2

I don't think that this is an "Agile problem". Scrum is considered a low-documentation proces. But at the same time it is a Business Value based process. So, if management is focused on business value, they will concider technical knowledge transfer - including documentation -- as a high business value at the closing of any project, if there is a fair chance that the project will reopened at a later stage.

However, it happens from time to time (read: almost every time) that management loses focus when a project is delivered to a customer. Their attention tend to wander off to other revenue generating projects. If that is the case, the only option is to use your first sprints of the new project on providing the knowledge needed to reopen the project. This means a lot of code inspection, talks with the programmers, architects, users etc. More time consuming than if documentation was already there, but I'm afraid that this is just a fact of life.

This is not an agile problem as I said in the beginning. Before agile you would battle the same issues or even worse: Documentation that is not up to date. At least this is not a problem in Agile projects, because you make documentation only WHEN AND IF it is needed.

Regards, Morten

Improve this answer
1

I've heard from people who are only tangentially "Agile" that Agile isn't about planning/testing/documentation. See Pidr's answer for more.

While the documentation may not be there, I would hope there are tests, hopefully expressed in terms of the business requirements. The first thing I want to do when stepping into a new codebase is look at the tests. All the better if they're something along the lines of Cucumber output. That would at least give you entry to the domain and begin to understand how to modify the domain.

Improve this answer
0

To me it sounds a bit stupid to switch full development team and replace it with a new development team. At least several core people should remain to transfer knowledge. Otherwise unnecessary additional risks appear.

Improve this answer
0

Unfortunately, it happens like that. This is the case of projects made for thesis in the university for example. People graduate with these projects that takes 8 months to do. Once they graduate, they begin working and don't have much time to give you specifics about the project itself, and that's the case of project chiefs, resources like programmers is the worst case. They become project chiefs a year later, and they don't remember what they developed.

In other words: Is a model where personal for every project will always change, and where resources are shared from time to time. Bothersome, yes. But that's what we have.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.