From Agile perspective Devil is Detail or detail is devilish, it opens up like a Pandora's box and there is no end to change in scope in the life of a project, especially an Agile IT project. Saving Changes...
Just because you're using Agile methods, the details [of specs, features, changes...] will not disappear.
You always will work with a lot of details, documents or specifications.
The difference, between Agile and Waterfall methodologies, is the time that you will work with them.
Waterfall process demands a full documentation and specification of the product or service in the begin of you project.
Agile process demands work with small parts of documentation and specifications for each iteration or release planing.
In the end of a project, using agile process, is possible that you'll have so much more documents and specifications than using waterfall.
Elton, very interesting perspective. So agile gives us seed and flexibility but then we may end up with more documentation that waterfall, thus meaning more detail. I never thought of agile in this way, but still I would like to argue, if we end u with more documentation in agile, do we not compromise on speed. maybe the documentation in agile is not in the same format or way that is done in waterfall. To be flexible and fast, we need to have an alternate of detailed documentation, no matter if that is done overtime in iterations. But your point is well-taken.
Arul, maybe this discussion explains my point further. Saving Changes...
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
Well, you might compromise on speed, but it's hard to say. It is certainly possible if, on an agile project, you prioritize lots of user stories for documentation, that you will get lots of documentation as output. But that is as it should be - the customer (Product Owner) is in charge of prioritizing what the team works on.
The key difference is that, each iteration, the Product Owner, when choosing the stories that will be included in the next sprint, will have to face the question "is this documentation the most valuable thing for the team to work on as compared to other usable business funcitonality in the product itself?"
Because documentation is considered as just another possible delibverable, and would be prioritized alongside product features, the business gets to decide how important it is, and how valuable it is to produce. This contrasts with traditional methods, where it was often seen as a necessary activitiy in the "analysis phase" or similar to produce comprehensive documentation, and maybe even get it "signed off", before you could safely move on to actual developement.
What often happens in agile development is that people start out thinking they will need lots of documentation, but as the project progresses, the "documentation" stories never make it in to the iteration plan, as some other user story that delivers actual functionality is seen as more valuable. In the end, the customer may decide that it's not cost-effective to have the team stay together to do documentaiton iterations after all of the desired product funcitonality has already been produced. Saving Changes...
Cheikh FAYE Microsoft Dynamics 365 Business Expert, CEO and owner| Eurêka TechnologiesDakar, Senegal
Hi Iqbal,
You're absolutely true,Devil is in the detail not only in the field of agile project management but in every aspect of human life. The only remedy is religion and faith. Saving Changes...
Bruce Wilkinson MBA, PMPExpert Project Manager / Trustworthy Executive Assistant / Business Coach| goBRUCE Business ServicesCuenca, Azuay, Ecuador
Question: In general wouldn't Agile keep documentation on a higher (grand view) level, and the details of the individual Sprints would often be determined informally, often verbally in stand-ups? This tends to keep the "what" of our project at the higher "manager" levels, and move the decision-making about the "how" further down the chain to the ones actually making it happen. This shortens the preparation phases, and in turn can have the effect of leveraging the "collective" intelligence of those performing the actual work of the project in addition to that of the Project Management team. Saving Changes...
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
That's a fair comment Bruce. Agile does emphasize delivery of completed product over documentation, so that would be a natural outcome of the method.
The key point is that documentation is yet another deliverable, or at least part of the definition of done of most deliverables, but is not a prerequisite to starting development, as it is sometimes seen in traditional, heavier weight project management scenarios.. Saving Changes...
I agree with comments by Bruce and Alistair. Yes, we are trying to give more importance to the finished product over documentation but the need for documentation does not simply be ignored as this ay be one of the deliverables. If we can only do the necessary documentation while we concentrate on delivery of the product, we will harness the DEVIL IN THE DETAIL. Saving Changes...
