Is Agile really my thing?

Having worked in both the service and product segments of the software industry I have had some
amount of exposure to Agile when implemented with products and when adopted for client
deliverables. During early years I did not have sufficient authority to voice my opinions during decision
making and exercise powers while shaping development processes. And to my irritation I still dont have
the power to question the authority or challenge the dominance of Agile. While I am struggling to
understand why Agile is the best framework for me to adopt, I am also beginning to examine cases
when it does work favorably for me. For those of you that undermine the power of Agile, let me put
forward a few scenarios you would want to avoid regardless of which software methodology you follow.

1. Identify your end consumer: Client project or product, youve got to identify who your
customers are and what value your software offers to them while assessing opportunities for
software development processes. If you are restricted by business rules and regulations, Agile
provides you with the flexibility and cushion to cover for disruptions by stating explicitly and
limiting overindulgence of your client. It however does not make room for alterations. Unless
you have extremely critical changes to deploy I would not recommend inviting any external
influences while your sprint is on. When your product is in the market and being used by
millions of people worldwide any slight change that you may have to accommodate to avoid
frustration and damaging reviews may be welcomed. It is a perfect way to execute development
in regulated and demanding environments such as healthcare, finance, construction, etc.

2. Do not kill what does not fit the bill: The waterfall model for software development is often
requirement centric and such requirements are either dictated by the client or projected in a
way so as to ensure commercial success, by the service provider. In such situations, there are
often cases where you would typically ignore improving the software for its long-term
performance or sustainability. When business priorities change it becomes difficult to
accommodate those at a later point in time. It is different with Agile each time-boxed sprint
usually demonstrates shippable product(s) but does not rule out the possibility of interlinking
components that could delight your customer in the long run, either by extending the sprint or
merging with another sprint in future. Remember that Agile does not deliver an entire product
it delivers modules!

3. Nosy colleagues and difficult teams: Although Agile recommends team work and cohesiveness;
it demarcates responsibilities in a positive way and limits authority to respective role-owners
thus making it transparent and less prone to external interference. Agile emphasizes on less
paperwork and more team work, thus reducing the need for multiple people to reflect
contrasting opinions and create differences.

4. Agile is programmer friendly: Lets face it programmers dont love reading epic BRDs or
convoluted business rules and terminologies. A short and crisp user story works well to explain a
particular functionality to them without having to run the risk of iterating and reiterating several
versions of a BRD and literally introducing them to a library of voluminous text.

5. Try, experiment and bootstrap: Agile is perfect for entrepreneurs and small-web based
companies to experiment with a group of users and make alterations as they proceed with their
roadmap. It is at times beneficial to mold product strategy per user feedback and if you are the
type that wants to replicate a Google-model, clearly waterfall is going to cost you dear.

6. Okay youve asked this before but we DO NOT need a RTM: Agile does not require a
Requirements Traceability Matrix mostly because each user story accounts only for a single
requirement or at most a couple. You build test cases for every requirement and detect defects
in your software, without running the risk of having to defuse the bomb later while your
customer is holding it.