Agile Project Management in an eGovernance Project

Sastry Tumuluri, Information Technology Advisor & Chief Information Security Officer, Government of Haryana
Rochak Chauhan, System Architect, IVISS Project (Integrated Village Information & Services System), Haryana

Agile is not for everyone. Certainly not for eGovernance Projects. This is so widely accepted in the IT industry, that any debate about it is always sparse and short. Among the many reasons for this are:

>>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.
>> Buyers usually don’t mess with this process – lest they attract undue attention from auditors.
>> Even with guidance like the “Cult of the Done Manifesto”, Agile needs seasoned mentors to succeed.
>> 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 evil” and that “It is a sign that someone didn’t plan wellenough 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. Never mind all the ulcers this norm causes all round. 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 (without contracts to worry about).
>> So this is the third stakeholder (Buyers & Bidders being the first two) who is NOT in favor of Agile.
Does this mean that Agile won’t ever work for eGovernance Projects?
We used Agile methods (a much better term than “methodology”) to such good effect in the Haryana Integrated Village Information System (IVISS) project, that it may be worth examining what made it such a success.

Introduction to the project
Haryana OneState was proposed as a vision to the State Technical Committee in 2012.The thought behind this was that our eGovernance programs have seen several years of standalone application software. Citizens have become accustomed to the current levels of electronic service delivery and are eagerly looking for more.
However, you can’t deliver high-speed travel on roads built for bullock-carts. Thus it became clear that is time to move to a higher level of maturity – to integrated applications that create a whole new set of process improvement opporunities, both to the citizens’ delight as well as to enhance Government’s efficiencies. A multipronged integration architecture was visualized, covering Software-level Integration (through a light-weight middleware), Process-level integration (through process asset management), 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 crossdepartmental MIS platform), and more.

Was “Agile” a goal?
No. We had a problem to solve. We had a big vision. Nothing this big was attempted before. We didn’t have crores of budget. We had to show something working in a very short period of time, to prove that it is worth going after. So Agile just happened to be the only practical choice.
We chose a small, visible, but demonstrable slice of our big vision and delivered it as a proof of concept (PoC) in about 6 weeks.
This is huge, considering that we had developed the foundations of an integration framework and 6 independent but integrated systems during this time.

Left to Right: Sastry Tumuluri, Information Technology Advisor & Chief Information Security Officer, Government of Haryana; Ghan Shyam Bansal, State Informatics Officer, NIC Haryana; Y S Malik, Additional Chief Secretary, Electronics & Information Technology,Government of Haryana at eHaryana 2014

Yes, there was some outsourcing. Bulk of it was to small organizations and in a “Time and Materials” model. This derisked the companies to some extent; allowing the buyer to share the risk with the companies.
This (sharing of risk) is a critical mind-set requirement for Agile projects. Buyers must both be willing to share the risk. This is also most unusual in eGov projects.
No single company could give us all the skillsets we needed. So developers from three different organizations were roped in. Jumbo- Labs, WeExcel and Enterprise Mobility Xperts, all from the tri-city were the initial partners. All of them knew and accepted the risks – that this project may never see the light; it may never scale up; the payments and team sizes were too small to make sense. Yet, they shared the vision and the dream and decided to invest their time and their best developers in the project.
Larger organizations like Accenture, E&Y and Wipro jumped in after the PoC stage, by when it was clear that something big was brewing. Each of them contributed in their own ways, but voluntarily and at no cost to us; something that we deeply appreciate.

Convincing the Government
The first challenge was to build a shared vision. This isn’t something you can sell to a nonbeliever. We wouldn’t have been able to start if the foundation for the vision wasn’t already there.
It took many months of back and forth to articulate the vision in a concrete and mutually acceptable form. Once this was done, the rest became a matter of taking one small step at a time. Each time we asked only two things:
>> Believe in the vision
>>Approve a small investment in building towards that vision
The Government’s belief in the vision as well as the desire to make it real was strong. That’s how it started. Thereafter, it just boiled down to delivering what we promised. Each time we delivered, the confidence grew.
Then came a point when it was possible to present the whole thing and ask for a one-shot approval for “let’s go for a state wide rollout”. Here we had to give a series of demonstrations to most Administrative Secretaries and show them that this was worth building upon. The demos played a critical part when the project came up for discussions in the high-level committees. The stakeholders had something to relate to, instead of just papers written up to convince them.
Neither the beginning nor the big-approval would’ve been possible if the leaders weren’t deeply positive and already yearning for something like this. Having such progressive leaders is a fundamental pre-requisite to even start off anything like this.

Planning the sprints
For planning sprints we stuck to the basics. Our first step was to listen to all the software specifications or wishlists, if you will.
Our next task was to convert these wishlists into possible user stories.
Then backlogs were created from all the user stories.
Now came the important and tricky part. Based on the priority, duration and dependency we assign the user stories in the current sprint. Needless to say we had to add tasks to all these assigned user stories.
The idea was to ensure that no task takes more than 3 hours to develop.

Tools and techniques
Due to our Scrum approach the classic Web-based Project Management Systems were not an option. For this project we opted for KADOS, a Kanban Dashboard for Online Scrum. It has a simple and intuitive “drag-ndrop” feature to maintain backlogs and sprints dashboard.
We used four environments namely Development, System Testing, Staging and Production. The first three were deployed in a Eucalyptus Cloud in our data center. Production environment is hosted in a BSNL Data Center.
Each user story is developed and tested on development environment. From Development environment the code is moved to our Source Code (SVN) Repository. All stages from there on only take code from the SVN repository. This ensures the necessary discipline that helps us deploy to production.
We introduced another big change (from the usual) here. We moved the Quality Assurance activities aka testing as close to the developers as possible. The intent was not to make the Testing Team as the gate-keepers, stopping bad code late in the process. Instead, they help detect and fix defects earlier in the process, so that QA steps become easy to pass through.

Development Platform
The entire work is based on the LAMP stack (Linux, Apache MySQL and PHP).
Ubuntu was the flavor of choice; Yii Framework for PHP was a natural fit, with many productivity and security benefits. The middleware was written to RESTful API specs, consuming JSON objects. This not only made the whole framework very light-weight, but also served as a platform neutrality enabler.
We have one application that was developed completely on the .NET (Microsoft0 platform but is fully integrated with the rest.

Parting advice for Agile Managers
Well its not just good enough to develop a web application quickly using Agile. It is important to create the DevOps culture. One of the most important persons in the process is the release manager – our “DevOps Borat”, who tracks and deploys the code after each sprint. If as in the traditional environment, each deployment takes weeks, the whole effort is for naught.
This demands that the deployment process is simple, quick and error-proof. Now we don’t want the hardwork of developers go wasted due some typo in the configuration file or some important file missing. It is imperative that developer is not missing out on securily and performance aspects in the race to meet the schedule (the sprint). This can be ensured either by pair programming or by putting some static analysis tools to use. A combination of human expertise and automated tools usually works best.

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. We try to automate as much as we can in the cycle from development to deployment. 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 a state-wide roll-out plan that we need to support too

Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Most Popular

To Top