Agile manifesto is around for about 17 years. Even so, there is a lot of unknowns and misconceptions about agile and agile methodologies. First of all let me start by showing the main and, for me, the most powerful declaration of the manifesto:
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, we value the items on the left more.
(Taken from Agile Manifesto: http://agilemanifesto.org/)
As you can see in the last sentence, the manifesto guys recognize value and importance to processes, tools, documentation, contracts and planning. The only point is that they value MORE people, human contact and multidisciplinary teams, the working software and adaptation to changing requirements. Almost all of the 17 guys that developed the manifesto either had managing positions or they had their own companies. So, believe me, they knew the importance of a contract and what that mean. But, even so, they proposed a framework where the collaboration with customer, the adaptation to change and working software were more important than the contract which paid their salaries. Well, of course they cared about their salary and their companies: what they wanted is to get their customers happy by given them working software that fulfilled their needs. If these customers are happy they will spread the word and more customers would ask these guys for their services and everyone gets happy and with more money in their pockets. Hey, but isn’t that what everybody wants? The customers want to have its software done by the price they agreed (assuming a fixed price contract that still is the most used) and the provider wants the project done on schedule and on budget. Well, yes, but everyone has a different opinion on how to get there.
The agile manifesto just showed clearly that the waterfall methodology was being wrongly used for a great number of software development projects (there were also other methodologies that were a mid term between waterfall and agile, however they were not as widely used as waterfall, the de facto standard until then). Is like having a hammer and using it for everything. If you want to tighten a screw, if you hammer it enough times, eventually it will get stuck to the wall. However it is neither the right tool nor the most effective way to get a screw tighten. To tighten a screw you should use a screwdriver. The same happens with software development. Waterfall is the right development process to use when the requirements do not change much and you have clear objectives and application rules. Mathematical applications are good examples of that. First you learn the rules, master them and document them based on the clear goal that you have to your application, then you design your application based on the knowledge that you gained, then you code the application based on the design and finally you test it. It works well if you have a clear goal in mind and because the rules are objective and don’t change very often. The geometry invented by Euclid is still valid today. However, with a business application the same doesn’t happen. First of all, the rules are not clear to everyone (I’ve been in situations where they were clear to no one at all) neither the goal. Second, much of these rules to implement are subjective which means that different people have different answers to the same question of the developer/analyst. Third, and probably the most common one, the rules to implement and the goal change often during the development of the application which means that if you take, say, 3 months (to be optimistic) to do the analysis, then 4 months to do the design, then 7 months to development and another 4 months for testing and bug fixing… 1,5 years assuming that everything went for the best and that the project had a very competent project manager… This is a typical waterfall approach. How many applications do you know that don’t change during 1,5 years? Well, I’ve seen some, but far from being the majority.
The bottom line is that waterfall and agile, both are good tools and both have proven its value. However, each should be used according to the characteristics of the project and the team.
There are some common mistakes that are linked to agile methodologies. Here you can find some of them:
The minimum unit of documentation used in almost all the main agile methodologies is the user-story. This is the equivalent to a requirement or a use-case. It comprises a high-level description of what a customer wants to be done in a particular use-case. It is written or, at least, inspired by the customer and refined by anyone that participates in the project at anytime required. Not all the knowledge of the team is described by user stories (after all it is a slim and high-level description), but every single user-story is always the base of the job to be done by the team so it is always up-to-date. If the project or the team requires a more detailed documentation there will be specific user-stories or tasks that will take care of them. And this documentation is created ‘as required’ and not necessarily in the beginning of the project, since, as we all know, at the beginning of a project, things are not accurate by nature.
In my humble opinion, it is exactly the opposite: You do planning through all the project. The difference is: you plan what you can and need. Usually, at the beginning, you have a short high level plan that sets the goals, overall budget, priorities, but not specific days or duration. Then you do your planning for the first short period of time. At the end of that period you plan for the next short period of time and so on. This is similar to, but not exactly the same, as the rolling wave planning technique proposed by PMI. You plan what you need and leave the rest to the next period. Then, you will have more knowledge that will help you in the next planning step. Of course, all these short period plans take into account the high level plan created at the beginning.
Agile methodologies propose guidelines for work delivered by a team. In fact, some of the most used methodologies (Kanban for instance) came from industry (automobile) and were later applied to software development. Besides that, there are now several areas successfully using agile methodologies to deliver their work. For instance IT support, finance, product development and marketing.
The agile team should organize/manage itself. However, you need someone to set the pace and guidelines of orientation. Undoubtedly the empowerment of the team and the individuals in the team help the “leader” (lets call it like this) and ease its work. However you will need someone to help the team to optimize its performance, to guide to product goals achievement, to follow the environment rules, to be on budget and on time. Depending on the methodology, you can have these tasks distributed by one or more roles.
As stated before, every methodology has its own characteristics that will adapt better or worse to a given situation. Even “inside” agile, there are several different methodologies. Some adapt better to some cases than others. There is no universal panacea. You should evaluate the concrete case where you are and chose the methodology (waterfall or one agile methodology) that best suits your situation. Sometimes you must even change methodology after starting the project. It is the situation and not the methodology that defines what and how should be done to have good results.
The agile methodologies arrived at the software industry in the early 2000’s and they proposed a new way of delivering software. Since then, nothing got back to the way it was before. A new way of thinking brought some sanity to the software world allowing cost reductions and quality improvement to many software projects. Does that mean that waterfall methodology is bad or is dead? No, because it still makes sense and it is the best choice in many types of situations. However a new option has emerged from the agile manifesto allowing you to be able to ask: “How about agile?”.
