It’s a familiar story. You adopt Agile techniques to start delivering projects, and it seems to work well. So, you start delivering more projects using Agile, and that works well too. Sure, there are a few missteps and a few areas where it’s less successful, but you gloss over those, because, well, it’s Agile! Over time, teams start to create custom processes, you lose any standardization that you may have had initially, and pretty soon, gaining any insight into what’s happening from the top-down becomes impossible. The classic story of the perils in trying to scale Agile.
Click here to read the previous post in this series, or start from the beginning
Realizing Value during Agile Transformation
Agile teams may love focusing on velocity and team satisfaction, but that doesn’t help you manage your portfolio of investments. Ultimately, it doesn’t matter whether your work is delivered using waterfall, Agile or ad hoc methods. What is important is knowing the value that is expected to be delivered, whether that value is actually being achieved and how much that value is going to cost you in effort and financial terms. And you simply can’t get any of that if your Agile transformation is being driven from the bottom up.
Governance shouldn’t be hindrance
If that’s not enough this Agile expansion is resulting in poor governance, a lack of alignment between strategy and work, a lack of transparency into where your money is going and a whole bunch of missed dependencies. You’re no better off than you were when all the work was being delivered using waterfall methods, and in some cases you’re worse off because at least your waterfall approach had some sort of project governance framework built in. Scaling agile right is key to achieving business agility.