Tom De Cubber
As a 6+ year project manager, I used to apply the PMI or Prince2 methodologies and techniques derived from these waterfall methodologies to my projects. But in a lot of cases, it was very difficult to get grip on the costs and time as the scope was evolving continuously throughout the project. I tried all kinds of techniques to get control on the every changing scope by using change requests processes and installing a complete administration for having an overview on what was going on in the project.
But after I learned about Agile and Scrum it became very soon clear to me that all these administration could be avoided just by using another framework for your projects, where you put more emphasis on the product that has to be developed and on the people working together to create the product. It was not necessary anymore to do a complete analysis of everything on beforehand and then doing some hocus pocus during a couple of months or even sometimes years before coming back to the project owner to find out that she had changed her mind or got new ideas by seeing what had been delivered.
The idea of having constant feedback was very appealing as I saw (with my background as a Civil Engineer) the enormous advantage to be able to adapt your system using the results of what you are doing.
I'm now trying to apply as much as possible the Agile techniques in all of my projects. And although the company for which I work is not currently working with a complete Agile mind set, it is in some cases also possible to have small parts of a project running using a kind of Agile approach (even if it is not real Agile, it can help to show people what it can do and to bring them closer to the real Agile and Scrum approach). It is not a real break through I have in my projects, but I keep trying to use parts of the framework or the techniques to make steady progress in convincing my team mates and hierarchy of the enormous productivity gain that can be achieved by using full fledged Scrum.