Demystifying Agile Project Management

Hi Everyone,

There are hundreds of articles you might find about the popular Agile delivery approaches for software development in the global internet and today I am going to try to explain most of the background about Agile in a nutshell here in this article. So we can say the goal of this article is to demystify Agile and let's have a quick start:

As many of us already know “Agile Development” is an umbrella term for several iterative and incremental software development methodologies. In other words, agile is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value to their organizations.

But why did we need to change our approach? What was wrong with the traditional waterfall delivery and basically what is better in agile? The answer is the following:

Former software development processes were too heavyweight and cumbersome. Too many things were being done that were not directly related to software product being produced during the development phase.

As this is a very well experienced fact, there was a major problem dealing with the changing requirements as well and learning from the failure can happen too late due to the nature of the methodology that is why there would be very less time to fix the entire project.

One of the other aspects which Agile performs better than the former methods is to use active customer (internal or external) involvement more than the other ones. Basically agile proponents figured out long time ago that there would be no such thing called “perfect software” so the methodology should be aligned with this approach to create the best value possible in the shortest term instead of trying to make your product perfect.

The chart below summarizes the difference between waterfall (sequential) and agile approaches in a nutshell. Agile simply brought the idea of doing a little of the every item for software development in each step instead of spending huge amount of time for requirements, design etc. beforehand and seeing the value very late (with many question marks) at the end.

For the ones who want some theoretical background about agile approach it is good to go and check the agilemanifesto.org as the foundation.

The beauty of this manifesto is that it provides just enough direction, but permits anyone to choose their ideal trajectory. From that perspective it is easy to say agile is generally a mindset, rather than a strict methodology.

According to this manifesto, organizations should follow these 4 values and 12 principles to be agile, but there are many Agile methodologies that embrace this manifesto. Ultimately, focusing on creating value for customers and promoting healthy human behaviors are the secrets to a successful Agile adoption.

I will not go into the details of these values and principles but basically what this manifesto is saying as Agile values are the following:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, Agile approach and proponents value the items on the left more.

By saying so, I hope you don't get me wrong and interpret these values in the right manner. We have to admit that Agile does not mean lack of governance, visibility and control over the projects. On the contrary, it accelerates value delivery (fast time to market), ensures continuous customer feedback and improves transparency more than the traditional methods.

This is it for today. Hope you enjoyed the article and next time I will try to give you some foundation about Scrum, the most famous Agile methodology.