Before we get into the de­tails, let me begin by trying to define Agile. So, here we go – Agile is a movement that seeks alternatives to the traditional method of man­aging software projects, namely ‘Waterfall’. Then the question that needs answering is - “Why Agile” and “What is wrong with Wa­terfall”? The answer to the second question should, in all probability, answer the first.

Waterfall is a methodology of software development in which development proceeds sequen­tially through a series of phases, starting with system requirements analysis and leading up to product release and maintenance. Things move from one phase to the next, much like a waterfall. There are numerous positives of this methodology. One, the phases enforce discipline: each phase has a defined start and end. The emphasis on documenting requirements before coding is expected to ensure clarity of thought. Also, the focus on documenta­tion of formal specifications helps in knowledge transfer through different phases. However, over time, there has been a realization that the very distinct phases have their disadvantages too. More often than not, customers can’t envisage what they want in the requirements discussion phase and the needs usually change during the develop­ment phase. In the end, what is delivered is not up to their expectations and at times unusable.

Enter, the Agile model. The idea in Ag­ile is to develop software in small iterations and thus be able to adapt to the changing customer needs better than in Waterfall. According to Wikipedia, ‘Agile Software Development’ describes a set of principles under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, evolutionary development, early delivery, and continu­ous improvement, and it encourages rapid and flexible response to change.” There are a variety of Agile methods in use today, with some of the more well known ones being Scrum, RAD (Rapid Application De­velopment), XP (Extreme Programming) and Kanban.

The most talked about methods these days are Scrum and Kanban. In Scrum, work is organized into smaller time frames called sprints. These are typically 2-4 weeks long and have to be accomplished by a cross-function­al team. In Kanban too, work is accomplished in small chunks, with the difference being there are no time peri­ods and the limits are placed on work-in-progress to suit the team’s development capability. However, this is not to say that Agile is the panacea of all software project management ills. While the positives are that the cus­tomers, more often than not, get what they want, there are possibilities of budgets and deadlines being missed in the bargain. In addition, regression testing could go for a toss leading to new functionality breaking old ones. Last but not the least, Agile doesn’t insist on collabora­tion between development and operations, which mean these silos could remain intact.

Now let me introduce another concept here – DevOps. This term is a combination of software Devel­opment and IT Operations leading to its name. DevOps tries to bring Development, Operations and Quality to­gether to communicate and collaborate better. The pro­cess can be depicted as in the figure below:

With continuous delivery and continuous integra­tion, there are frequent releases that reach the customer. Cooperation between the three teams enhances problem resolution and all stake-holders have good visibility to the project execution. In DevOps, the focus is on con­figuration and release management and monitoring of performance and user experience.

Agile and DevOps are complementary in nature with the singular objective of delivering software projects bet­ter. While Agile represents the ‘What’ - of Project Man­agement, DevOps is the ‘How’. Both work towards the objective of faster releases to customer with lower failure rates.

All this is easier said than done. Moving to Agile and DevOps is a tectonic cultural shift. What could work is to begin small, create passionate, self-driven teams and get some small but quick wins. For example, trying out Agile on a legacy system of records would be rather daunting, but it would be a good idea to try it out on a new mobile app development where the chances of success are much higher. Also needed are leaders who believe in it and are willing to champion the cause, how­ever difficult it may seem in the beginning. In today’s day and age where organizations are getting leaner by the day, these concepts are here to stay, and are definite­ly worth experimenting with.