Thanks for your thoughts. In order to clearly understand how to plan projects, managers should be more responsible in choosing appropriate planning software that will help them to cope with even the most complex tasks.

Hi Larry. That’s a really great comment from you. You have a good theoretical and practical view on Agile

1) Since things are being broken up in smaller chunks to fit into sprints, non value work is needed to put it back together at some point to have a fully functional process.

2) Because of #1, you have repeated steps to rebuild test data and test environment because of the need to retest as you add on to a fully functional process that was broken up to be smaller just so it can fit into a sprint.

3) Dependencies are typically not defined well as you do work in functional chunks but don’t know enough about the entire system you are building. So Chunk A is built in an early sprint, but you find out later that Chunk B had a dependency on Chunk A. The dependency causes part or all of Chunk A to have to be reworked.

4) The constant sprints require more version control and reconciliation management. This results in not only the lost time of building constantly, but developers chasing ghost bugs resulting in this endless churn of code deploys and reconciliations.

5) Regression testing increases because all of the above.

6) Implementation management and release planning increases because all of the above.

I do like the flexibility of Agile and the just in time planning and not wasting time on estimates that we don’t know enough about but I feel some kind of hybrid approach with more analysis and design to identify dependencies and a better handle of how the sprints could be organized is in order. Also, a heavy investment needs to be made in the ability of version control and builds of code as well as regression testing tools.