enectoux: @rsessions Don’t agree. It all depends of the scale of the project and awareness of project members.
RSessions: @enectoux The scale of the project is what I mean by it doesn’t scale to complex projects.
enectoux: @rsessions lol, ok then I agree :o) But “complex” is not equal to “large”, isn’t it? To me, a complex project can be a small ones as well and the #Agile issue is more related to scale (large /small) than complex
RSessions: @enectoux But I believe Agile can be applied to large projects once we get their complexity under control.
@RSessions is much more knowledgeable about managing complexity as I pretend to be. If you are interested, you will find lot of interesting thoughts and information at his website: http://www.objectwatch.com/
My intention here is to dig a bit more into this “complexity thing related to Agile”. Basically, if we look at Agile’s manifesto, here are some of the main principles underlie in it (short extract):
Customer satisfaction by rapid delivery of useful software
Welcome changing requirements, even late in development.
Regular adaptation to changing circumstances
So, if we look at these principles, some of them will be very difficult to argue with when it comes to manage complex projects through Agile. Take the principle “simplicity” for instance 😉 or on the other hand, other principles like “adaptation to changing circumstances” are more in favor of managing the complexity.
My point is that we cannot state that Agile doesn’t scale to complex projects. It is all about how you can deal with complexity. How much you (as the project leader or project member) can deal with a complex situation. Are you afraid of complexity or are you comfortable with it? If you are comfortable with it, then Agile methodology can help you to manage your complex project, parallelizing activities, having short development loops, enabling you to validate your “still fuzzy” concepts by testing them towards reality quickly than if you were in a “not Agile way of working”. Agile methodology is, to me, very powerful. But, like any powerful tool, it has to be handled with care. It is very easy to get trapped when using Agile and then, blame the method. I’ve seen and I see it many times. Among the principles I mentioned above, two are missing in this list (but not missing in the full list):
“Close, daily cooperation between businesspeople and developers” and “Projects are built around motivated individuals, who should be trusted“. these two might look obvious, but they are to me the fundamental ones. Without trust between IT and business in a Agile project, there is no way to make it a success. As enterprise architect, one of our challenge is to achieve “Business and IT alignment“.
There is many ways to try to achieve this alignment, but I think that one of the best one, when the trust is lacking, is to re-establish this trust by succeeding a complex project using Agile methodology. Then you prove what you prone as “alignment of Business and IT” has a value for both and for the enterprise.
I have many examples of such projects, at different sizes. Some have failed and some have succeeded. But let’s me ask you about you’re experience. Try to remember, any good personal experience of using Agile methodology in a complex project and making it a success?
Professional blog. Share my thoughts mostly related to: Enterprise Architecture, Leadership, Mind Mapping & GTD. Opinions are my own.