Agile Methodology: How to Make It Work?
Recently there have been too many attacks at Agile Software Development methodology, too many cries like "Agile is Dead (again)!" and plenty of wasted words proving to everyone left and right that such technique doesn't work. So in this article I'm not going to give a definition or enumerate its pros and cons. I would rather examine the main points of criticism concerning this approach and try to bring the truth to light. Here's what I managed to find out.
Agile Methodology can only work for a time-sensitive and critical project of short duration (6 weeks max).
Not quite true. What it does though is that it actually allows us to see the result in a short time period. What's wrong with that? You simply divide the project into stages. This is especially convenient when the customer doesn't know what he/she needs (which is a common story). That's where such division comes in handy.
Agile methodology in programming is very responsive and flexible. It allows you to make the changes in time and avoid the situation where you present the result of, let's say, three months which is absolutely different from what was needed. This would be quite frustrating, don't you agree? It also helps the customer to take decisions on the go, collect feedback and adjust the overall course of the project. In addition, agile software development model facilitates the work of devs as they get the parameters of features in a more reasonable way (in contrast to some vague monolithic requirements).
Micromanagement (meaning a big waste of time on reports and frequent meetings).
Some people say that user stories and backlog grooming "suck, and if you're good at what you do, it's insulting to have to justify days and sometimes even hours of your time". I can't see how it can be "beneath you" to simply report in a few sentences and feel great by acknowledging to somebody else that you have done some work that day. Writing a report will take you about 10 minutes. I can hardly call that a waste of time.
As for unreasonably frequent meetings, it is in the power of the company to adjust them to the real needs. In my view, communication between the client and the team should be regular, not necessarily frequent. As often as you feel appropriate for all the parties involved.
Implementing Agile Methodology can ruin the company.
Well, it can. Any approach can destroy a business if it is not implemented correctly… Any good theory can be twisted or standardized so that it won't work as it was originally intended. Pragmatic Dave said, "The whole point of values is that they are a compass, not a map". Agile approach doesn't have ready-made answers, only a short guideline that you need to follow taking into account the context. It is so easy to get lost on the way. But nobody ever said it would be easy or fast!
Adopting agile methodology in software development requires time and training. And so does any new activity! When you decide to learn to drive, you know pretty well that you need proper studying, enough time and money, of course. But after you complete the course it can already make your life much more convenient. However, even then, some months of studying and a license won't make you an excellent driver. You'll need constant practice and experience to become a real professional.
What I'm driving at is that it is absolutely logical that you need training to master some new skill, whichever sphere it is connected to. I'm sure that a lot of criticism comes from people who tried to adapt (ASD) principles, patterns and practices and either failed or twisted them beyond recognition in the process. I would advise you (in case you decided to try this out) to be patient and persistent and everything will come out the way you want it.
Client introduces changes too often.
Actually, one of the advantages of Agile Software Development is that it makes it easy to respond to and implement all changes timely. And it doesn't necessarily mean that the client is a daydreamer, that he/she abuses authority or is too picky. Don't forget that there could be objective reasons for acting so, like changes in the budget or stakeholders, an update on the current project feedback. So when you start working on a project, be ready that it may happen. On the bright side, Agile approach makes it possible to react to them timely.
There are now too many gurus of Agile Methodology.
Well, it's simply not possible to tackle all problems with a one-size-fits-all solution. Unfortunately, there appeared numerous consultants and scholars of this methodology that were welcomed by big companies eager to "go agile". As a result, they tried to impose the best practices of Agile approach on people who were neither interested, nor ready to accept these changes. Or, perhaps, they just didn't care. In addition, one of the ideas of Agile is that it is agile and adaptive, but these "fake gurus" didn't make the effort. Fixed rules didn't work because they lacked context.
As Pragmatic Dave states, "it is impossible to create universal answers — context will always interfere with any attempt to be absolute". Of course, for those people it was much easier to use one magic pill for all companies but remember that rituals are not bad. Problems start when you blindly follow them. So you see, Agile approach is much about context.
Reduced documentation results in laziness.
Lightweight documentation is one of the benefits of Agile methodology. Ideally, it results in releasing more time for actual development of programs and work on the project. Nevertheless, the truth is that this really can lead to worsened workability. And if you have an employee prone to idling away time, believe me, he/she will find a possibility to be lazy whether you're using Agile approach or not.
Agile Methodology involves people from different departments which makes it difficult to communicate.
Well, as I see it, it's vice versa. It gives a better understanding of the problem and makes it possible to cover all the aspects in deep. Moreover, I can't see how communication can be a problem in today's world of developed technologies!
So what is it all about?
I really tried not to answer the question "What is agile software development?" for the umpteenth time but rather give you a better understanding of its essence and how vital it is to apply this approach correctly. Among its core ideas are the following ones: to be agile to changes in the plan, to be adaptive to requirements and your client's wishes, to satisfy your customer's needs and in this way to be better than your competitors. Let's not forget that the work of a programmer isn't for the sake of the programmer. When you get an order, your task is to understand your client and, through discussions of requirements and successive steps, reach the desirable goal. So I'd say that it is indeed more customer-centralized. They came to you for help in realizing their plans and they are exactly the people who will eventually pay for your efforts. Also, they can and will make mistakes (as well as you and me). But this method makes it possible to react timely and help them to make the right decisions.
I guess, you are all familiar with this picture
So of course, you do understand how difficult it is to envision and reach the final goal, but it is in your power to make it as smooth and agile as possible.
If you managed to read this article till the end, you are as well as me, concerned about unjust attacks on Agile methodology and truly believe in its innocence. As a matter of fact, we've been implementing this approach for a long time now and we know for sure it works. If you have some problems concerning it or need some more tips or proof, see how our team can make it work!