Skip to Main Content
Access your saved content
Dispelling the myths of Agile development in pensions organizations.
Agile is an adaptive software development approach. Many of its behaviors, techniques and tools have high relevance for pensions organizations. The key to truly understanding Agile—and to applying Agile in an agile fashion—means testing new Agile behaviors, techniques and tools and responding actively to feedback to find the ones that deliver genuine value.
For as much interest and real value as there is in Agile, there is just as much misinformation and overpromises. Too many people look to Agile as the be-all/end-all of development approaches. To avoid disappointment, pensions organizations need a realistic view of Agile’s capabilities, which starts with moving beyond the myths.
Agile is undeniably hot—and catching the attention of government—as a software development approach with an adaptive, collaborative and iterative nature. In today’s complex, legislation-heavy, government environment with politically-set deadlines, such iterative development approaches may not seem suitable. But Agile does not have to be an all or nothing proposition for human services.
Agencies are encouraged to break through the myths and determine how the approach can drive new value in human services IT.
Our experience reveals three important myths of Agile in human services:
Myth No. 1: Agile is a methodology
Because Agile is a set of behaviors, it accommodates multiple methodologies. It is defined by a philosophy of seeking and receiving feedback to focus on what adds value to the business. From that perspective, Agile is a very “humble” and sensible approach. Simply put, it inherently starts from the assumption that “you won’t get it right the first time,” but you are always headed in a value-added direction.
In Agile the “best way” is always what delivers the most genuine business value relative to time and budget—within an organization’s particular situation and after a realistic assessment of the risks of delivery failure.
Myth No. 2: It’s Waterfall versus Agile
A whole spectrum of approaches lies between Agile and waterfall, and where to operate depends on many factors. An extreme view of Agile could imply a “just start building it” mentality with little or no upfront requirements analysis or design.
On the other hand, an extreme view of waterfall could mean understanding the full set of requirements, having a complete design before any development begins, and having the late end-to-end solution assurance implied by a fully phase-contained test approach.
However, success rarely comes at the extremes—it comes from finding an appropriate balance. In pensions organizations in particular, elements of waterfall must be preserved. For example, while a bank may choose to build an online application that provides some services first for its premier customers and gradually add other groups and features over time, social security agencies tend to have less flexibility in how they segment customers and products when their obligation is to serve all eligible individuals.
Scope, and even timeframes, are often fixed in legislation. Moreover, public sector leaders must demonstrate value for money and get stakeholder buy-in throughout the project, which can be a challenge for iterative development approaches.
Myth No. 3: Agile at scale is the same thing as scaled Agile
In its smaller incarnations, an Agile project might entail a small team that is co-located in one place, together with the person who owns the requirements. If you try and replicate that model for a much bigger project, you rapidly get chaos. This is particularly relevant in pensions organizations because development projects typically result from legislative change and are by nature large scale.
Agile relies on collaboration; but how to successfully adopt Agile is one thing with a team of 10, and quite another with a team of 400. You need version control. You need design documentation. And you need rigid boundaries.
Agile values individuals and interactions over processes and tools, but that does not mean processes and tools do not matter. The more you scale Agile, the more management and coordination must increase, even though they never supersede individuals and interaction.
Although public sector interest in Agile is relatively new, the concept itself has been in existence long enough to teach some valuable lessons. Most importantly, there is no silver bullet and no one best way to deliver, though the end game is about achieving business value.
Agile behaviors and practices are an essential part of the delivery toolkit, but they have to be understood—particularly for human services agencies that tend to have large-scale, high-impact programs to develop. Expecting purely Agile methods where Agile behaviors are not yet part of the culture could rapidly damage a project. The key to applying Agile in an agile way is to start small, seek feedback and always be willing to learn.
March 7, 2012
Skip Footer Links