Regular readers know that in my professional life I'm running a Product Management & Engineering organization which produces standard software solutions for large and x-large enterprises. At the end of 2007 we decided to migrate from a Waterfall dominated software engineering world (we found that most large enterprises tend to think Waterfall) towards a 100% Agile methodology with the agile principles at the heart of everything we do.
Since we made that decision we have made great progress in adopting a completely Agile engineering methodology and we found fantastic tools that support our daily work. I'm planning to write a series of articles about our journey and specifically about the learnings which we've made very soon.
Looking back I can make a very fundamental up-front statement already: Moving to an Agile process has not only significantly increased staff morale, it has literally helped us to live up to timelines and promises which we would never have been able to meet by applying Waterfall principles. Without any religious notion and based on my +11 years in software engineering I've come to the final conclusion that Waterfall in deed provides an outdated framework which primarily create an illusion of having everything under control while the reality is, that almost all Waterfall managed projects exceed time and budget and do not meet scope. I am absolutely convinced that the art of engineering software solutions demands for an Agile process by its very nature and that there are no real alternatives.
I promise to go into much more detail very soon and provide real world examples from the past four Agile months within my company.
With that said I'd like to share a brilliant article taken from the Agile Chronicles. I am sure everybody who has worked or still works in e.g. PMI managed projects will (perhaps silently) agree because we've all been there. We've all written 100s if not 1000s pages of Specifications or Statement of Requirements and acted in a pure Waterfall model just to find out it did not return what we've invested.
I'm curious. Do we all agree that you cannot predetermine the time, cost, and scope of a project and have any hope of being successful? Is it not an axiom of project management that you can fix any two of the constraints but the third has to be variable? Up until recently I had always assumed this was the first law of project physics, the one rule that could not be broken. For some reason I thought that everyone understood this concept.
It is amazing to me how often I find myself talking to people about the triple constraints of project management. I am usually off talking to a group about Agile Project Management when someone raises their hand and asks THE QUESTION:
How does this work on my project where time, cost, and scope are all fixed?
The simple answer is this… it doesn't. The reality is that no project management methodology works when you try to lock all three of the constraints. If this is really true, why is it that Project Managers are constantly asked to manage projects with all three constraints determined in advance? As project managers, why are we so willing to go along when we know we're on a path to failure.
I want everyone to know that I totally understand the desire to have it all figured out up front. It is incredibly appealing to think that we can do enough due diligence and planning such that all three constraints become perfectly clear and manageable. The reality is that it just doesn't work that way. Claiming that this is our reality does not make it so.
Project Managers are in a tough spot. When you have a team of execs that are convinced we can plan our way into certainty, it is very difficult to be the person that raises the flag. Being the guy that draws attention to the elephant in the room is not a formula for career advancement. Put your head down, do the best you can, and hope for the best. Maybe we'll get lucky.
The data is showing us that more often than not... we don't get lucky.
If we are willing to accept the reality of the triple constraints, maybe we can begin to have a reasonable discussion about the kinds of decisions we are making about our projects. Let's talk honestly about what is really flexible and what is not. If we have no room to adjust the plan, what does that mean about the risk to our initiative?
When considering Agile methods, there is a fundamental shift in what we are choosing to assume about our project constraints.
Traditional project management usually starts with a discussion of scope, as in "what's the scope of the project?" From there we estimate the amount of work required to deliver the scope, set the project budget and resources, and determine the timeline. If your lucky, you get some room to negotiate on the front side. More often than not, the discussion ends with someone telling you to get it all done by next Tuesday. Even with room to negotiate, the goal is to lock the constraints and get moving.
Agile Project Management starts with a discussion of time to market and cost, as in "when do we need to get a working product to market and how much are we willing to invest." From there we begin the process of estimating how much scope we think can fit into the window. That estimate is not a fixed commitment. We started with the assumption we wanted to fix time and cost. Scope has to be negotiable.
There are implications to taking this approach. We'll need to look at how we structure contracts, how we forecast revenue, and how we make commitments to our customers. When we plan our portfolios, we have to ask if we can realize sufficient ROI - understanding we might not get every feature we originally hoped for. This is what is means to REALLY manage our projects.
Dealing with reality is not always easy. Agile is not a silver bullet. Pretending is not an answer.