I am not pro-agile, but also not anti-agile. I did just enjoy reading a post by Giles Bowkett on "
Why Scrum Should Basically Just Die In A Fire." I think agile methods (including Scrum) can work, but time morphs any processes and agile is no different. Giles presents a lightly-humored touch on how Scrum can go wrong.
For me the biggest issue with agile (at least today) is its inability to weed out poor-performing members. Even weeding out bad-performing members is pretty difficult. The second biggest issue with agile is the ability to game the company system. Another big issue that most sites do not point out is that agile is not good for high risk solutions, especially solutions that may determine real life and death risks like medical solutions or an airplane.
There are other issues that agile also do not manage well is regression test. It requires that it to be automated which is fine, but how would it regression test features that take up real physical time like scheduled jobs that are triggered daily or even weekly. Agile also loses performance when dealing with multiple components or multiple environments, where the project essentially becomes traditional methods to coordinate all the different pieces.
Poor-Performing Teams
My biggest problem with poor-performing members is that we have the misconception that those members are dumb. In reality they are just not good at their role, but are smarter than people credit them to be. So this allows a lot of freedom for people to game the system or start politicking.
The easiest excuse is that agile is new, so they still need to work out the kinks. Blame the other group, blame the requirements, blame coding, blame testing. Everyone just points fingers at everyone else. Sadly, these poor-performing teams come out looking better because they are more prepared to blame others while the good teams were working how to fix the issues.
Even if you can isolate the team, identify the individual is even more difficult. There is less information as there is less focus on documentation (if there is an documentation at all). Is the problem with the scrum master not leading properly or the developer not coding properly or the tester not testing sufficiently? Or the scrum master does not have proper support or the requirements are consistently poor or test cases ill-defined? Finding the high-value and low-value members is like a game of
mastermind.
High Risk Solutions
I find it odd that I have not come across any sites, posts, or forums (even anti-agile fanatics) mention that agile is not advisable for solutions that have high risks if something does fail. I surely do not want to be on an airplane that went through an agile process... unless maybe if it were on its one millionth iteration and the last 500,000 iterations had no deaths. Or use the laser eye surgery. With my luck, I will probably be that one test case that no one anticipated.
I am also sure that financial companies would not want to risk millions of dollars due to a flaw in the system. I doubt explaining that they didn't provide the proper requirements would make financial companies feel any better. Telling them that the next iteration would correct the problem would not be much consolation.
Or an online bank losing your life-savings. An individual losing $100 of life-savings will likely be just as angry as another person with $1,000,000 of life-savings. Sure there is insurance for that too but who really wants to go through that experience.
Sure some solutions do not carry such risks like Candy Crush or Farmville (there have been extremes with some video gamers that could probably prove that wrong too). The problem is defining where that line is like a cloud solution that promises 99.99% uptime. Is the risk worth all the customers possibly switching to your competitor?
Documentation
How many people do you know that the value to agile methods is "comprehensive" documentation in its core value: working software over comprehensive documentation? How many of those people even know what that mean? Most people hear "no documentation is needed" (at least the people I know). Not sure how many times I had to point out that we still need some documentation after hearing that they are not supposed to provide documentation anymore because they went agile.
There is definitely something wrong if that value even has to be stated. What company would not love to drop documentation as part of the process if the software just worked? Writing documentation takes up time, and to our corporate world, time is money. I mean they will drop testing if that would save them money too. Besides time and money, I think traditional methods can also drop comprehensive documentation so making it a value of agile is kind of redundant.
Comprehensive documentation came out of technical writers wanting to keep their job and managers wanting to make people as replaceable as possible which means that the documentation also needs to be continuously updated (mostly the latter which coincidentally didn't get complaints from technical writers). If it is faster to read code to learn what it does than it is too read documentation, the documentation is too comprehensive. I have personally read some old corporate documentation that went into such details as even providing illustrations on single-clicking versus double-clicking or how to move the mouse or how to insert a disk (although the
younger generation probably would need that step today).
But my main issue with agile is that people seem to take this to mean "no" documentation. Although it is not stated that way in the manifesto, many people perceive it that way. Developers don't want to document, managers don't want people to waste time documenting, so it appears like a win for everyone.
That is until 6 months later and the whole development team has changed. New updates are needed on the old code which no one knows about. No documentation, so more time is spent figuring it out. Code is eventually updated and passes the end-user acceptance test. Deploy the change then realize an old process has changed which broke something else. Maybe the change was a comma instead of a semi-colon which passed regression test but fails for the client. The point is more time was spent than was necessary. Management is going to put this as a lesson learned or retrospective, then will require more documentation. 10 years later and we are all going to be back with the issue of comprehensive documentation for agile and traditional methods (or whatever new method name it will be in the future).
I haven't even touched on audit which is already a nightmare with traditional methods. Surprisingly I have not had to experience audit with agile project (yet), but I would guess that it would be just as difficult as traditional in its best case. More likely it would be more painful due to lack of documentation which is a majority of the problems I face in traditional methods. But I supposed it could be easier just to tell the auditor that it just does not exist than trying to hunt down the document, then let someone else worry about what process need to be put into place to "correct" the audit problem.
Solution Complexity
Assuming a great and awesome agile team, the agile method will slowly become similar to traditional methods as the solution grows in complexity and scale large enough to partner with other groups. Having to coordinate times, priorities, and many values to traditional methods, agile cannot avoid certain decision gates needed for multiple team coordination. Agile can work purely in the requirements through development phase, but once it reaches integration another branch of code is required. Then the company will also need another set of testers and developers to fix issues because the agile teams are to be working on the next iterations. If the same team is used, then most of the agile iterations are pretty moot.
Assuming another team is available to support code that is being prepared for production, processes need to be available to merge code to any code that is still open. Further regression test is required. And this is probably the easiest and most regular process.
How will the group manage if there is a production issue that needs to be corrected while in the middle of an iteration? What if it happens to be in the middle of an iteration and in the middle of integration? Is there a separate team? Does integration stop to work on production issue? Now there are at least 3 branches of code being developed. That is only if the code is for one group.
Working with multiple groups, departments, partners, etc., there is bound to scenario where there is not enough resources. In traditional world, all the requirements are coordinated. For agile, this may be more difficult because iterations now have dead-lines which is almost counter to its values. One of the groups may keep its agile schedule, but the others have to coordinate accordingly to their dependencies. Working with other partners may even mean coordinating different flavors of agile methods.
And this is becoming more and more commonplace, as companies have software solutions for billing, accounting, finances, manufacturing, sales, and other departments. Then you want to interact with other companies.
Conclusion
I think agile is basically the same as traditional but just from a different view angle. I think traditional has always been trying to go agile, and many companies probably have made it work. Most of those methods are probably more agile than traditional compared to the corporate world. I think some would argue that it was more or less lean processes like six sigma.
I spent most of my career with small to medium sized companies which basically are traditional methods in a very fast paced world which forced us to be very agile-like. So when I learned agile, most of it was already very familiar except without all the fancy terms and ceremonies. The learning curve was actually harder when I worked with a corporation sized company where the bureaucracy was so daunting.
So, I feel that agile is either the leanest process of traditional method or a traditional method that goes through many prototyping that just never gets refactored. In the smallest of worlds, developers at the very beginning is the truest form of agile where we our own client, product, end-user, developer, and tester. Came up with an idea, tried to program, test, check with initial idea, come up with new idea, develop, test, accept the result, repeat if not acceptable, then becomes final product when accepted.
