From the middle of the 20th century until late in the century, project managers used Work Breakdown Structure, or WBS, to manage the complex\u00a0projects. It was the only game in town and every project manager was trained to use this method.\nWhen the desktop version of Microsoft project was released in 1984, the WBS, or waterfall as some would call it, became much easier to handle. Managers could plan and\u00a0share their\u00a0projects with their teams and the executive managers.\nDuring this time, in almost every big company in the U.S., project rooms were filled with huge printouts of project plans from\u00a0MS project.\nIf you are not familiar with WBS, the concept is simple. Before starting a project, you plan everything that needs to be done. Then, you break down the big pieces or tasks to smaller pieces or subtask. You continue doing so until each task is small and is well defined.\nThe problem with WBS is that at the beginning of the projects, all facts are not known. Plus, the requirement changes, the market changes, and the customer has new requests.\nEnter Agile\nThen in the early 21th century, Agile project management\u00a0became all the rage. The waterfall was considered too restrictive and not able to handle rapid market changes. Everybody thought the Agile method with its lean approach would solve all the waterfall problems. After all, the majority of the projects would cost more and finish later than planned.\nThe good thing about Agile is that the customer sees the results in a very short time after the project has started and can change the delivery of the requirements change. Due to the Agile flexibility, the requirements changes don't derail the project.\nSoon it was realized by most managers that the Agile method is not a panacea either. Not all projects are made equal, and not all teams can adjust to one method or the other. So what should a project manager starting a new project do?\nFor one thing, it is extremely hard to accurately estimate when the Agile project will be completed. Also, the constant changes to the requirements are bound to cause project delays and project cost overruns.\nSo if the waterfall is not the right method and Agile is not for all projects, then what should a project manager do?\nBest of both worlds\nThe good news is that a new project management method called hybrid project management is gaining popularity and acceptance. It combines\u00a0the best of Agile and the work breakdown structure to create a new project management method that fits the majority of the projects.\nThe beauty of the hybrid project management method is that it lets the team plan before starting to work on the project, but also divides the development cycle into short-term deliveries called sprints.\nHybrid can handle requirement changes and, due to its iterative nature, can deliver products in stages. As soon as the product reaches the minimum viable product, or MVP, it can be shipped and the development team can continue on future enhancements.\nIn hybrid, the planning is done using the waterfall approach. The execution and delivery are handled by the Agile method. This hybrid approach makes the planning and project estimation a lot more accurate. At the same time, the team can react to market changes and deliver what the market demands in place of what the team planned.\nTo cover all the details of hybrid project management, and which projects benefit from hybrid and which ones from other methods like Agile and waterfall, are out of the scope of this article.\nRecently I wrote a detailed description of hybrid project management\u00a0called \u00a0Hybrid project management manifesto. It is a very detailed document about how hybrid project management works and how it could be used. I recommend reading the introduction and definition to get familiar with this new method.\nIn addition, if you want to know which projects benefit from Agile project management method and which ones don't, read this\u00a0tutorial on Agile project management.