Project management happens differently at different levels of scale and abstraction. There is the team or feature level (around 10 people), the project level (between 50 and 5,000 people working on a specific release), and the product level (multiple releases led by executives). Agile methods work beautifully at the team level; formal methods work beautifully at the project level; and long-term strategic planning methods work beautifully at the product level. However, people rarely work at multiple levels at once; in fact, years typically separate those experiences for individuals. So people think effective methods at one level should be applied to others, which is how tragedies are often born. The moral is: small tight groups work differently than large disjointed organizations. Choose your methods accordingly.
Scrum is loaded with planning, and efficiently tracks more data in more detail than any other project management method I’ve seen at Microsoft (except for
TSP, used by a few teams). Likewise, high-level project planning is critical to successfully scoping, coordinating, and delivering any large-scale initiative. If you have limited vision, then Scrum alone is fine. If you want to deliver lower quality and less customer value in more time than your competitors, or if you want to micromanage every aspect of your limited scope, then project planning alone is fine. If you have a bold vision with broad scope that you want delivered efficiently with high quality and copious customer value, then you need a balance of both high-level project planning and Scrum.