I disagree with your assessment of Agile. I've not read the book you've stated, however I know that I spend none of my time waiting around. I'm either spending my time writing code, reviewing code, creating documentation, refining user and / or customer requirements through meetings and speaking with the client, the PM or other members of the development team. I know some people would argue that being in meetings is not developing the product but it is. Creating that shared understanding, within the team, of the expected behaviour for a certain feature drives out assumptions and ambiguity. Couple that with a proper review process then the product ends up with less defects. I would argue that the way in which Agile is being implemented seriously affects the understanding of the Agile process and the outcome of the product and most importantly the quality of the product. Working this way round also reduces uncertainty thus allowing the development team to more accurately estimate the time it would take for a given task. Specifically, using Scrum Poker on a Fibonacci scale more accurately accounts potential risks in the estimation that are inherent with larger tasks.
If the project gets to the point where the development team is missing things close to the deadline then I would argue that the development process is wrong or broken somewhere. Obviously, there may be small things that could be missed - as is the way of nature. But its not a question of graphs, it's a question of why wasn't this kind of stuff raised earlier in development.
All of this can be done using many issue trackers. I have personally used Jira, GitLab, Trello. They all work well when coupled with a good Agile process, utilising BDD and embedding Quality critical thinking at each point of the process and most importantly communicating with the client.
I must admit though, the feature progress section Zepel have built looks quite nice. I've not seen that too often in project management tools.