Agile is effective, and has become the standard of practice. Embracing change, coding in short sprints, an emphasis on automated testing and short feedback loops; all these things lead to improvements in quality and productivity. A decade from now, we'll still be improving on it, but the principle benefits are realizable today by organizations and teams that take it seriously.  

But you'll have noticed that software teams today haven't exactly run out of problems as a result.  A central problem that Agile was intended to address was the inability of software teams to adapt to changing customer requirements. So now we're getting good at adapting to change, but that only compounds what is still one of the most intractable problems: in the face of ever-increasing complexity, that of actually finally releasing software.

Continuous Delivery practice intends to deal with the delivery question as Agile did with that of adapting to change.  As with Agile, a central focus of CD is to mitigate risk.  CD is built on a foundation of Dev-ops practices.  First is Continuous Integration, which is the cornerstone of CD. But First-Class software build pipelines are the main show in the Continuous Delivery game. 

Martin Fowler said of build pipelines: “One of the challenges of an automated build and test environment is you want your build to be fast, so that you can get fast feedback, but comprehensive tests take a long time to run. A deployment pipeline is a way to deal with this by breaking up your build into stages. Each stage provides increasing confidence, usually at the cost of extra time. Early stages can find most problems yielding faster feedback, while later stages provide slower and more through probing. Deployment pipelines are a central part of Continuous Delivery.”

But still we're really only talking about the technical side of the delivery puzzle.  
We need a full stack solution.  
We need the whole team in.  

You don't get to the best benefits of Continuous Delivery simply by automating deployment.   As with Agile, we need to move culture, to engage the whole team, with people in less-technical and non-technical roles assuming more responsibility in the actual delivery process. 

The software build pipeline is where your team rehearses for delivery, so that by the time you're ready to go out on stage, the technical issues should be resolved.  One of the great unrealized benefits of delivery automation is that it allows dev and ops to take a step back.    Delivery is no longer a technical silo. Responsibility for release now belongs to business analysts, project managers, or stakeholders, where it belongs.  Effectively, delivery becomes a business decision, instead of a technical one. 

This changes everything.  Agile recognizes that when stakeholders first see working software, it changes their perceptions of requirements; so now we don't go and burn the budget before we show them something.  In delivery practice, once release becomes a business decision, it profoundly changes stakeholder perception of the process, which implies the potential for much richer customer relationships, and the opportunity to take your agency to a whole new level.