Agile Methodology in e-Governance

School Mapping for Better Learning

Before we get into the topic, it's pretty important to know what Agile Methodology is. Why it is different from the traditional project management processes and what benefit it has over other models. Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change.

It is a conceptual framework that focuses on frequently delivering small increments of working software. This means the client needs to be in the team from day one of the project till its closure. This is the reason why it is widely accepted in the IT industry that Agile is not for everyone, certainly not for government clients. We can see this from perspectives of the three major stakeholders of any project i.e. the buyer, the bidder and the Project/Product Manager.

From Buyer's perspective, Government procedures require a clear statement of what is being procured, how it will be inspected & accepted (audits & certification as needed) and how it will be paid for. Unless this is clear, government is not willing to engage any bidder for any kind of software development. Buyers usually don't mess with this process – lest they attract undue attention from auditors.
Large RFPs carry many inherent risks. Part of the risk mitigation strategy is for a bidder to peg down every last bit of effort and every bit of risk to be understood and addressed.

This means every “in-scope” item must be spelt out clearly; no changes allowed (without much procedure), and so forth. It follows then that bidders, not just buyers, too, want clarity and stability of requirements that are so antithetic to Agile.

Project Managers have been taught for decades that “rework is a sign that someone didn't plan well enough early on”. As a result, it is practically an industry norm that “Software Requirement Specifications (SRS) must be signed off by the customer” before a single line of code is committed. Even the new breed of Agile PMs are afflicted by contractual constraints that they can't freely practice their agility – unless they are in an internal product development environment where they don't have to worry about the contractual obligations. So the third stakeholder in this process is NOT in favor of Agile.

These are the general perceptive of the stakeholders on Agile methodology in eGovernance projects. But this might not always be true. In India, the eGovernance projects have been conceptualized when there was no formal arrangement for procurement, change management and implementation framework is formed for IT projects. Till now many government offices carry an impression that the eGovernance project means office automation where large portion of the budget goes for IT Hardware procurement.

So procurement is limited to traditional good procurement procedure. The Service level agreement are made in a traditional way where the job of the vendor is to supply goods in full working condition as per the standard specifications. But there are few states who are advanced in eGovernance project implementation and have understood the reason for failure of such projects. There few such projects that can be taken as case study on how agile methodology helped in materialize the project and gave a better success rate.

Haryana Integrated Village Information System (IVISS) project is taken as a good example where a multi-pronged integration architecture was visualized, covering Software-level Integration, Process-level integration, Operational integration (through a CSC governance framework), Data-level integration (through a State Resident Data Base that extends the Aadhaar concept significantly), Payments integration (through a VLE collections Gateway), MIS integration (through a single GIS based cross departmental MIS platform), and more. In Odisha, we used Agile Methods in the Food Supplies & Consumer Welfare department to automate the procurement and PDS cycle and this can examined to know what made it such a success.

We chose a small portion of the big vision and delivered it as a proof of concept within 4-5 weeks time. Then we took the next step by developing and implementing small modules. We could develop and integrated more than 8 sub modules including mobile apps in a framework where almost all stakeholders have access across the state.

WHERE DO YOU GO FROM HERE?

Like most of the Agile projects, there is always room for improvement in the form of refactoring. We need to ensure the code in developed in incremental modules so that it is not a mammoth task to recode or refactor a part of code without breaking the entire application. There are cases where rework could not be avoided as there were dependencies and few change requests came during the roll out stage. Testing Automation is great to talk about, but implementing it still remains a goal for us. There is huge demand for new services to be launched, new applications to be integrated and so forth. We have completed few modules of the whole work plan, there is a lot of work to be done, most of them are statewide rollout. The biggest challenge we are going to face in future is the integration with other existing systems. Our plan must be solid enough to handle such situation, but we are sure this will be done like the earlier releases.

This proves we can still achieve our goals in government projects by following agile where there is a higher level of acceptance from the head of the organization. Because many officials in government right now are not ready to take up bigger projects due to time constraint, it is advised to build smaller stages of implementation with the help of consultants. Agile methodology helps bigger projects to be successfully implemented.

AUTHOR:

CSM Editorial