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 while adopted for client deliverable. 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 don’t 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 favourably 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.

• Identify your end customer: Client project or product, you've 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 over indulgence 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. But when your product is in the market and being used by millions of people worldwide, any slight change you may have to accommodate in order to avoid damaging reviews and frustration may be welcomed. It is a perfect way to execute development in regulated, high-growth, dynamic, heavy usage and demanding environments such as healthcare, finance, construction, etc.

• Do not kill what does not fit the bill: The waterfall model for software development is often user-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 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!

• 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.

• Agile is programmer friendly: Let’s face it – programmers don’t 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.

• 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.

• Okay you’ve 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 before each shipment, without running the risk of having to defuse the bomb later while your customer is holding it.