Many of us have been through mainstream both types of development: traditional and Agile. I am not going to speculate on which one is best because no one but you can answer this question with due probability. The choice depends on many parameters that no one can advise you on. In short, Agile works best in the situation of volatile requirements whereas traditional shows better results backed by steady specifications.
Still many people try to use Agile in all cases, mostly because it is "more fun to do". Well, if it was about having fun we would probably spend our time riding a roller-coaster rather that sitting in our offices. So it is not about fun you get in the process, it is rather about the fun we get successfully launching the system, seeing it doing something useful and helpful. This is the kind of fun that I personally prefer.
The road to this goal itself is also important but as much as it does not compromise the goal itself. For example, choosing Agile for a mission-critical system may become fun in development but a huge frustration in the end. The devastating effect will be so big that you would not remember a minute of fun you have had in the process.
Agile is definitely attractive to the developers because it allows to jump into the coding not bothering doing boring routine work. It allows to skip the hardest efforts such as trying to think ahead, measure risks and probabilities. But it comes at the cost of missing important aspects of system design or requirements which will be hard to add on later, when the shortage is revealed. So be flexible. It is good to have more then one tool if conditions change.
Quick turnover cycles also attract stakeholders. They can see results quicker and try out the system earlier. It enables them making corrections if their understanding of the business processes was not optimal. Which in turns makes unsteady requirements even more volatile and Agile even more efficient. But this is only in theory. The reality is more complex as stakeholders fail to understand what it takes sometimes to convert a prototype into a production solution. It may not be easy to convince your boss that the system that he can see working is not ready to be released after few fixes. You must be prepared and keep delivering the message about what they see consistently. Otherwise you have a big chance to lose this battle and deal with evolving prototype kind of project with no time available for refactoring. I have been thought a project that took few weeks to be coded into Alfa but costed us six months to fix up and refactor. You have a good chance not to repeat our mistake.
All in all, Agile or not should not be your personal preference. It is not a religion or us against them. This is simply a tool that you should be using wisely. You have choices and whether you make them right will most likely define the success of your future project. So, choose insightfully and enjoy project success.
Still many people try to use Agile in all cases, mostly because it is "more fun to do". Well, if it was about having fun we would probably spend our time riding a roller-coaster rather that sitting in our offices. So it is not about fun you get in the process, it is rather about the fun we get successfully launching the system, seeing it doing something useful and helpful. This is the kind of fun that I personally prefer.
The road to this goal itself is also important but as much as it does not compromise the goal itself. For example, choosing Agile for a mission-critical system may become fun in development but a huge frustration in the end. The devastating effect will be so big that you would not remember a minute of fun you have had in the process.
Agile is definitely attractive to the developers because it allows to jump into the coding not bothering doing boring routine work. It allows to skip the hardest efforts such as trying to think ahead, measure risks and probabilities. But it comes at the cost of missing important aspects of system design or requirements which will be hard to add on later, when the shortage is revealed. So be flexible. It is good to have more then one tool if conditions change.
Quick turnover cycles also attract stakeholders. They can see results quicker and try out the system earlier. It enables them making corrections if their understanding of the business processes was not optimal. Which in turns makes unsteady requirements even more volatile and Agile even more efficient. But this is only in theory. The reality is more complex as stakeholders fail to understand what it takes sometimes to convert a prototype into a production solution. It may not be easy to convince your boss that the system that he can see working is not ready to be released after few fixes. You must be prepared and keep delivering the message about what they see consistently. Otherwise you have a big chance to lose this battle and deal with evolving prototype kind of project with no time available for refactoring. I have been thought a project that took few weeks to be coded into Alfa but costed us six months to fix up and refactor. You have a good chance not to repeat our mistake.
All in all, Agile or not should not be your personal preference. It is not a religion or us against them. This is simply a tool that you should be using wisely. You have choices and whether you make them right will most likely define the success of your future project. So, choose insightfully and enjoy project success.
No comments:
Post a Comment