Agile Methodologies - Everything you need to know
Are agile methodologies really useful? Those which are not, are they obsolete? How do I know if a methodology is agile or not? Isn’t it just a matter of popularity? Is there any other agile methodology which is not Scrum? Is a Gantt chart something totally incompatible with “agile”? If my visibility is limited only to the next iteration, what do I answer to my boss when he asks me how long will it take or how much will it cost to finish the project?
If you have asked yourself any of these questions, this article is for you.
The first thing you have to know is that all the methodologies to frame the rules, with which a project of any kind is carried out (although here I am going to refer only to computer projects), are good. The really bad thing is not using a methodology.
Traditionally, we had what was commonly known as structured methodologies. A few years ago, the term agile methodologies began to sound a lot.
The difference is very simple to understand in general terms (I’m going to take several licenses in this article with didactic purposes that may bother some minds a little more conservative or rigorous).
The first ones are stricter and almost all of them aim to perform a rigorous control of the progress and stages of the project. The other ones, on the other hand, are more flexible and aim to generate results as frequently as possible, eliminating any task that is not necessary to reach this result (such as the documentation).
I’m going to take the latter as an example to make it clear. Let’s say we have to build an X version of a certain functionality of a system for a week. As time and resources are very limited, I will eliminate all those tasks that are not essential to achieve my goal. Then I will ask myself: can I achieve the stated goal without making a class diagram of what I am going to build? The answer will surely be “Yes.” Well then, I do not. If the answer is “NO” because the algorithm is very complex and I need to diagram it, then I will include it in the tasks to be performed, however not because it is correct to document everything, but because I need it to achieve my goal.
Having said that, it is evident why agile methodologies are so widespread. From the client’s point of view, this one gains visibility because he obtains partial versions of the product every few weeks. The developer can concentrate on what is important (build the product) without wasting time on secondary or unproductive tasks.
Another very important characteristic of this type of methodologies is its flexibility. This is because only the tasks of the next iteration (or development cycle), which has a duration of 2 to 3 weeks (in general), are planned, so any bug in the course of the project can not exceed that term, therefore it is very inexpensive to change course if the market conditions or the environment from which the product depends changed.
A negative consequence of this type of short-term planning is losing the global or overall vision of the project. I do not know a single boss (who is responsible for the budget to spend) who does not want to know the total time/cost of the project (if you know someone, please introduce him to me).
Here comes the first license that all the project managers do with agile methodologies: we make a global plan (in general a Gantt one) and hide it so that Scrum fans do not get offended.
If you have read me so far, you will understand why agile methodologies are so attractive, but they are not the answer to all problems neither. An agile methodology streamlines the development cycles, but sometimes you need to mix a bit with other tools more typical of other methodologies.
Let’s take another example. Let’s say you have to build in the next iteration of 3 weeks a functionality (a web page) which is the core of the whole system, so not only is it complex because of the amount of information it handles, but it has several usability, performance and security requirements. In general, this will involve tasks of designers, UX personnel, technicians who define a good architecture, computer security people, the user who approves the format and use of the page, etc.
It is true that this can be done perfectly with Scrum if the team is experienced enough. But you could also plan an iteration that is a little more “structured” (sorry for the word). Let’s say that, as a PM (project manager) in charge of the team, I take the license to start adding dependencies and establish internal circuits within the iteration, so that a developer does not decide to code something that the user has not previously approved, or that computer security has not authorized it. Do you think it would be wrong to do something like that? If this contributes to fulfilling the stated objective, even if it goes against the Scrum manifesto, I would do it.
What is the conclusion then? The conclusion is that the goal of any PM is to take the project forward, meet the requirements raised in time and form, within the established costs. The objective is not to be strict with the methodology, but organized, however being flexible enough to fulfill your work.
Throughout this article, I used Scrum examples because it is the most widespread one of all agile methodologies (being strict, Scrum is a framework, not a methodology, although the difference is too subtle for my taste). However, it is not the only one (we can name Kanban or XP if you want to Google them). In terms of structured methodologies, there are many (cascade development, evolutionary prototyping, CMMI, etc.).
You will have noticed that I have not explained any of these methodologies or project life cycles nor compared their differences, pros and cons. You can find all that on the web. My goal was to give you a broader and more general view of the problem. Do not attach yourself to a single methodology, since each organization is a world and each project has its own nature that makes it unique in some way. Be open-minded when deciding how to carry out a project and try to choose management tools that allow you to exercise that flexibility.