Many organizations are transitioning to Agile as their preferred lifecycle model for software development. Transitions were directed due to inability for former methods to lead to successful results. After being brought in to help manage a portfolio of projects in several organizations, there were some disturbing trends when using Agile:
- Software was delivered, but the users found the software to be unusable.
- Consultants developed the software, then left. The organization staff had no idea how to maintain the software.
- A number of application projects were completed. Each had a different architecture and set of tools required to build and maintain the application.
- Projects were being reported to governance teams with scheduled dates, yet there were no apparent requirements, use cases, user stories, backlog or other lists that might indicate what is being built.
- Management was completely at a loss about how to resource projects since many seemed to be ongoing forever without completion.
There were some exceptions; however, the preponderance of software development initiatives that succeeded were very small in scope and constituted a low percentage of overall projects required for customers. There was some information available within the organizations that indicated a process was initiated to convert from a traditional (Waterfall) lifecycle to the Agile lifecycle. Many of the benefits of Agile, however, were not being demonstrated by the activity taking place. What happened?
