What’s riskier? Agile or traditional?

Many government agencies are tempted by allure of developing applications faster, but fear that adopting an agile approach to development is risky.  Let’s face it – government procurement focuses on mitigating the risks for the agencies by trying to ensure ALL of the requirements in a solution are defined by the agency, prior to deciding a) what the solution should be and b) how the solution should be developed.  This basically means that anywhere between six months and over two years can be dedicated to the gathering and vetting of requirements for the solution.  That’s a long time, – even in government and definitely enough time for priorities to change, new legislation and regulations to come into play, or advancements in technology that could and should be leveraged.

So – what’s the riskier approach in dealing with solutions where requirements will change?  Agile or waterfall?

While with waterfall, government agencies might have some degree of comfort that most requirements have been defined up front – these requirements will definitely change before the solution even begins development, much less before the solution goes live.  With an agile development approach, all of the requirements do not – and should not – be defined ahead of time, as changes over time are naturally expected.  An agile development approach embraces changes to project requirements and allows for an on-going method of prioritization for requirement changes.

Another risky characteristic associated with waterfall development is the siloed approach to solutions. The business – or agency domain experts – works with business analysts for that six month to two year period, gathering every possible requirement, condition, or scenario. A very large binder – typically called a specification document – is produced and then thrown over the wall to IT to decipher, interpret, translate, and attempt to create the system the users have spent a considerable amount of time envisioning.  When the user testing finally starts, the items found have less to do with workability as they do with usability.  With an agile development approach, business and IT collaborate from the very start – working together to define requirements, processes, and prototypes.  This ensures that all stakeholders start and end with the same vision.  This also reduces the amount of time and effort required to get to the point of achieving true business value.

So – since Agile is definitely less risk than Waterfall, why isn’t it being adopted by every government agency?

There are many government agencies – across the globe – that have adopted agile and are enjoying incredible success.  Yet other government agencies have been either reluctant, or even unable, to attempt agile.  One of the most common roadblocks comes from the procurement side and basically involves contracting for a project that does not have a definitive start and end.  Even though the benefits of having the flexibility to adjust and realign projects due to changing requirements will ultimately help government agencies deliver on time and within budget, – the strict procurement guidelines government must adhere to directly conflict.  Government procurement guidelines are more interested in mitigating risk and use an Us vs. Them approach to contract negotiations.  Agile is all about collaboration – between business and IT, as well as the vendor partner and the government agency.  To ensure successful delivery of any solution, regardless of agile or waterfall, the relationship between the vendor partner and the government agency needs to be based on trust, ownership, and accountability.  An agile approach helps to foster these characteristics in the relationship.

For government agencies to gain the benefit of agile methodology, procurement/contracting personnel are the first that should take advantage of agile training or other methods of becoming familiar with agile processes.  One approach could be to partner a procurement professional with an expert in agile methodology.  As they learn from each other (procurement processes and agile processes), the goal would be to create the best agile procurement method possible, for their specific government agency.  One that adheres to the procurement guidelines while ensuring the government agency can leverage the full benefits of an agile solution.

2017-04-23T23:03:02-08:00 October 16th, 2014|Categories: Agile government|

About the Author:

AGL served the government innovation community from 2014 - 2020. It has now broadened its mission and community to form a new organization, Technologists for the Public Good. Learn more and get involved at publicgood.tech.

Leave a Reply