Agile Intelligence: Leveraging Agile Methods in non-IT Services

Traditionally, Agile methods were developed and applied for software development only. The foundation processes for a successful project following Agile methods were largely focusing on the interactions among programmers and managers grown out of programming environments. Nevertheless, the promise of changing specification during the course of SDLC (production period) and flexibility to demonstrate work-in-progress had its own influence, even within the community of stakeholders who were not generally related to software development work. Also, over the period of time, the IT managers started assuming the role of the BPO/KPO service delivery managers as their companies started taking such work offshore. As a result, many of the IT practices has started finding their relevance within IT Enabled Services as well.

The concept of agility was not new in the non-IT space though. In fact, Agile Manufacturing is a not-so-new terminology used to express a manufacturing process or setup that can react to the fast changing product specification in the fast changing competition landscape. Agile Manufacturing setup also allows the product marketers, product designers, and production personnel to share a common goal and a common set of information all through the product life cycle to efficiently handle the upstream and downstream activities.

In the area of IT Enabled Service delivery, Agile Programming methods are certainly not going to be applicable as-is. However, there are certain good practices, that can be adopted and applied to realize benefits. The practices that would be useful quickly and without tailoring are Scrum, Test Driven Development, Continuous Integration, and Backlog Management. As a caveat, I must submit, none of these are usable by its original names, nor by its original terms as dictated by the Agile proponents. Each of these practices are to be called with a relevant name and to be brought under relevant set of activities & steps. Moreover, it must be understood that these set of practitioners are not going to be programmers, techies, nerds, or of that sort. These practitioners will be come from a diverse set of backgrounds: by academic background, by experience, and by mindset. So, each of these four practices will require comparable level of revisions and modifications to fit the respective needs, their implementation risks are to be assessed with due care, and only after that should be brought in practice. We will look through each of these practices keeping this context in mind, in the following posts.