Problems in applying Agile software development model and solution proposal.

There are problems in using Agile software development operations, especially in B2G sector. As no-one denies that the continuous and short interval discussions between service provider and client is huge benefit, downsides lay beneath.

First of the problem is that in government organisations usually allocates a person that has know-how on software development as product owner – the person rarely is involved in daily operations where the software is used. So, often goals of continuous user testing and communication does not fulfil its purpose.

Second problem is that the service providers incentive is sell as many hours within the project as possible, as their income is bound to the number of hours sold – not outcomes of the project. This means the bottom-line incentive is faulty.

Third problem is lack know-how in government organisations. I’ve read reports where government officials have ordered work by e-mail without specifying the content of the order. And the same issue is related to the fourth problem. When clear specifications of the project are missing, no-one is in control of the project.

Fifth problem is that government tenders usually includes high restrictions on participation requirement. At least most studies Finland show that in government receives offers from 1-3 service providers in the projects. And yes, these providers are usually same year after year.

Sixth problem is lack of incentives in tenderer side. As government salary level is set low and no financial incentives is applied, officials tend to form tendering requirements so that it limits participation of potential tenderers. So, no reward - no risk of improving using government money in these projects.

Seventh problem is political guidance for improving employment level. In my experience, small team with right skills provides better ICT-systems in shorter time than large organisation with huge roll-over. And yes, this also relates to the incentive for buying more hours than outcomes.

Solution proposal

Reasoning that the old-school waterfall model is too strict and changes to the system are very hard and expensive to implement is usually the argue I receive when discussing the issue. In my opinion, this is a contract issue and not a fundamental problem in implementing waterfall model as part of agile development methods. So, my solution would be to implement best of both models to the contract and move the incentive from selling more hours to outcomes. Lowering tendering entrance limitation in public tendering and adding financial outcome incentives to the officials tendering the project would most likely move the focus from buying hours to outcomes. In addition, tenderer could include several service providers within single project and so forth the tenderer would be able to tender small changes within the project. For obvious reason, most of the larger companies and government officials seems to object this idea.

Best Regards

Henri Memonen