Blasphemy! You would say.It might be, especially when the whole software world treats agile methodologies as a panacea to all its problems. I have to admit that I've been in a perpetual state of skepticism about the benefits of agility and the fact of the matter is that I haven't found any valid reason to move out of my comfort zone of skepticism.
I think it tries hard to solve the problem of showing the ROI faster to the client but in the process ends up creating an even bigger problem -- Chaos. Chaos has ensued in almost all the engagements that we have executed using agile methodology. Some of it definitely comes from our lack of understanding of the agile practices but most of it comes from the way the methodology evangelizes the projects to be executed. IMHO, agility has got benefits but it hasn't matured yet(again, could either be lack of our understanding or dearth of good case studies). Most of the material out there has been written by very gifted writers which ends up seducing everybody to espouse it but I think most of it is bit pedantic and lacks pragmatism. Furthermore, almost all of it has been written by comparing it with the wooly mammoth of Waterfall -- Waterfall is bad thus Agile is good, hence proved. Whoa!
What leads to this chaos? The culprit, more or less, in all the engagements has been the flux in requirements and the monstrosity involved in managing frequent iterations. I believe the whole notion of succinct user story is somewhat misleading. It doesn't give good enough idea to think about the design holistically and provide enough opportunity to put hooks in place so that the system can evolve over a period of time. Think of products like Operating Systems, Office based applications, your favorite IDE, Amazon.com, eBay, iTunes etc. -- do you really honestly believe that the engineers of these systems would have just gotten user stories, planned them in iterations, did few design spikes, few whiteboard sessions, created "just enough" documentation, planned enough for the first few months and starting churning out code without putting emphasis on rock solid design and what the future holds. Well, I don't think so.
I don't think one can adopt the agile philosophy to create systems which target millions of users. I believe all the lofty notions of brief user stories, design evolution and "design is code" can be put on a decorative mantle in these cases. While constructing such systems, wouldn't you want to detail out the vision of the system? Wouldn't you want to create detailed use cases from the perspectives of all the users? Wouldn't you want to take your time to design? Wouldn't you want to get submerged in creating comprehensive documentation to convey the thought process to the army of developers rather than doing the "just enough" documentation which can lead to ambiguity? I think the cost of refactoring the design and code and deploying them again is astronomical in this context thus it's better to follow a thorough approach rather than an agile one.
The other thing which contributes to the crazility is frequent releases. Somehow, the development team always gets bogged down by fixing the critical bugs from the previous iteration's feedback loop. One would think that the choice comes down to working on new set of requirements or bugs from the previous cycle but that generally isn't the case. Why? The thing is the development team has to roll out the agreed upon user stories and the customer also expects the team to fix the bugs thus the team dynamics goes out for a spin. It seems to me they get tied in a vicious cycle where they are always constantly refactoring the design and code to accommodate the new set of changes. It is like a dog chasing its tail.
The problem worsens when one doesn't have strong program management in place which can't push back and educate the customer about its fallout on the team dynamics. Ultimately the developer team has to work longer hours at work. This defeats one of the core objectives of agile which mandate the developers work only 40 hours week in regular iteration followed by a sprint towards the roll out of the product.
Don't get me wrong, I absolutely love the idea of frequent iterations as it provides real value to the customers as they get to be part of the growth of their software but detest it for its repercussions on team dynamics. I love it as it gives the customer an opportunity to provide early feedback to the team but abhor how the development team has to work long hours to incorporate that feedback. I think the core of both the above problems is that agile methodology believes there would be enough time to build the software the right way but the fact of the matter is that software is always conceived by a strong time bound market need and, the software would gather dust if it was to miss that timeline. In my experience, I've not once seen a piece of software being constructed without a time bound market need.
I believe most of the agile practices are best suited for a very ideal software construction setting where the developer works in tandem with the customer and both of them somehow magically agree on all timelines and what features have to be constructed. I think that kind of framework would let developers easily manage the flux in requirements and incorporate the changes from the feedback loop without any added pressure.
Nonetheless, as I said in the beginning, I'm a skeptic, but still working passionately towards to become a believer as there are lot of merits in following agility. Thus, I'm currently reading two of the famous works on Agile which have been recommended to me by people I respect a lot --
1. Agile Principles, Patterns, and Practices in C# by Robert C. Martin
2. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results by David Anderson
I would love to hear any thoughts on how to execute projects on agile methodology, especially some good case studies of executing large scale enterprise projects.
Got Thoughts?
PS - Thanks to my friend Rajeev Singh for coming up with a very creative name for the problems we are facing on daily basis i.e. Crazy + Agile = Crazile
7 comments:
Excellent thoughts!! Well... Its been a long drawn out battle between agile v/s traditional methodologies ... let me take a different route... what I don't understand is the 'search for panacea',...why are we always looking for a single tool to work in all situations? Why should I always pick one of the pills, can't I keep both, Blue and Red (loved matrix trilogy) :) . Let's follow the 'horses for courses' approach..quick ROI, lean inventory, instant value all these make perfect sense to me and if agile can deliver them I'm all for agile even if it will work in only 60% of the projects and I'm more then willing to accommodate traditional methods in the other 40%...
Tarun totally agree with your thoughts. Every thing has it set of advantages and disadvantages associated with it, but you know the basis project management works is "9 women can deliver 1 baby in 1 month" and the philosophy that is encourages such thoughts "Client is GOD". Agreed client pays you, but I don't think he pays you to agree with whatever he says / feels, but he want you to add value by your experience, so its our moral duty to guide our client what can go wrong and how we can improve it. I know its easier said then done, but this is what I believe.
Being involved into working with "crazile" model past few months I truly believe that this article is a great piece and it reflects an in-depth analysis of an agile project.
One does understands the business need of delivering the software products or applications in as short time as possible (especially for the Small and Medium Scale Business), but it does has its toll on the development team due to lack of expertise on project management level.
The agile model has been evolved to help the business but a lot of work needs to be done to build an understanding with respect to project management for a project following an agile model.
The most painful part of the whole agile process is that things are moving at such a fast pace that the developers do not get an opportunity to go in depth of a problem and work out the best solution. Whether it’s technical or functional business knowledge, there always remains a void. Due to such timeline constraints (I would rather say time mismanagement) people although assumed to be working on the latest technologies and highly sought after business domain in actuality have very little to cherish about. Things are just happening with not all getting the opportunity to gain the real knowledge. Lack of proper design, documentation and too frequent iterations results in substantial time being spent on re-factoring. If anyone from the management team does some analysis on working out the cost thereby incurred they would find it wasn't at all cost effective to the business.
Agile certainly can be (and I do believe it must be in its real sense) a developer friendly model. But, I strongly believe we need to work upon the project management skills and also educate the business about the issues persisting in the agile model and how to handle such issues. We cannot use agile as a tool to hide ones not very good requirement analysis and project management skills.
Interesting thoughts. I agree that Agile methodologies as implemented today are aimed at delivering current demands with reduced burden on development (as compared to conventional methods); hence the stress on flexibility.
This seems to lead to an attitude of satisfaction with sub-optimality which is kinda' alarming!
Hi.
I used to work with Thoughtworks which uses agile methodologies for all its projects. One of the projects that we executed was a decently big project involving almost 40 developers for more than a year and it was a success.
I think one of the important requirements of an agile project is a strong development team. Every member in the team needs to have a decently good command on modeling and understanding of test driven development.
Apart from that, one of the principles that needs to be followed is constant refactoring to keep the code clean and model correct. Its important to follow principles like DRY(Dont repeat yourself). I think its also important to push logic to right layer to keep the code maintainable.
All in all, code maintainability is the most important thing in an agile project. If the developers do not understand or follow good design practices and the code is not maintainable one cannot expect to reap the benefits of agile development.
Tarun
Good post.
You might want to check out what I think about evolutionary design here.
Post a Comment