(Janeen Blanton is vice president, Insurance Productivity Services & Agile Center of Excellence at Salient Federal Solutions.)
It's easy to see the benefits of agile development when used for software development, but what about package implementations? There are almost always customizations, but the majority of the work is predefined and regimented. Can Agile be of benefit in these types of projects? The answer is absolutely yes.
Let me start by making a statement that will make Scrum Masters everywhere cringe. Agile is not Scrum. Scrum is probably what most of you think of when I say Agile. However, it is only one of many processes—along with Extreme Programming, Kanban, Scrumban, Lean Programming and several others—that can be used to facilitate Agile projects. Agile, itself, is not a process. It is a value system that helps us form an environment where teamwork and continuous value delivery thrive. So, what are some key Agile values?
- Collaboration. Gone are the days of writing a requirements novel and throwing it over the wall to the developers. Agile is about working together as a team to produce a higher quality product, by defining requirements at the time of development, and using immediate feedback to fine-tune functionality.
- Frequent, meaningful communication. With Agile, the focus is on doing the work—not talking about it, not writing about it—doing it. Meetings are focused and time boxed so that only the important things are addressed. The whole team comes away better informed and focused on the task at hand.
- Early and continuous delivery of value. Rather than the traditional big-bang delivery at the end, Agile provides incremental deliveries of production ready functionality throughout the life of the project. This provides a means to see an earlier return from your technology investment.
- Responding to change. Requirements change over time—often between the time you write them and the time they are configured. With Agile, this is not only easily accommodated, it is embraced.
So that all sounds great, but how exactly can this be applied to core systems implementations?
Let's first address the contract. Flexibility is not exactly a characteristic of most contracts. I have actually seen many promising Agile projects beat to death by a contract. So in order to set the stage for success, the contract should address how the flexibility of Agile will be handled. You know things will come up; they always do.
In fact, I recommend that any implementation contract have some sort of contingency reserve for scope changes. In an Agile environment, a good option is to build some flexibility into the scope itself. It's a good idea to have a list of expendable items—the nice to haves—that are OK to end up on the backlog if something more important is uncovered or if something you thought would be small turns out to be big. Then you can simply swap out equal units of work in the existing iterations. I also like to include an extra iteration in both the plan and the budget that would be filled over the course of the project as requirements evolve.
Next, let's talk about how to apply the iterative process. Yes, implementing a policy and claims administration system is a fairly scripted project. But that doesn't mean that it can't be broken down into smaller, logical units of work.
Most implementations include multiple lines of business or multiple states for a single line of business. If not, there will likely be multiple functional modules. These are all great methods of dividing an implementation into more manageable chunks.
The idea here is that at the outset of the implementation, we don't have to know everything about everything. We only have to know enough to determine the magnitude of the work before us. For instance, I don't need to define the General Liability rating algorithm today if I'm not going to start configuring it for another six months. I only need to know that the system will rate a GL policy.
All of those details will be fleshed out when we are ready to actually start that configuration. Also, while the deliverable for each iteration should be production ready, you don't have to actually put it in production. It needs to be fully tested and accepted by the users, but you may determine that it will be less disruptive to group the completed items into larger, less frequent production releases.
Finally, let's acknowledge that we might have to bend a couple of rules here. An iteration, or sprint, is ideally between one to four weeks. There's no way we could configure a complex line of business in that period of time. We might have a hard time simply completing the policy issuance that quickly, but breaking it into smaller chunks can be problematic.
For example, I might need to include only rating in one sprint and forms in the next. But can I say that my rating is production ready if it doesn't attach the mandatory forms? Not really. So, we have to acknowledge that there may be some dependencies that cause our sprint deliverable to be slightly short of that standard.
On the other hand, we may determine that we can complete a simple line of business in five weeks, and that breaking it into smaller pieces just doesn't make sense. That's OK. If we have an occasional sprint that goes past the four week rule, it doesn't mean that we have failed at being Agile.
What I'm getting at here is that when applying Agile to this, or any project, you should take a practical approach that makes sense for that specific situation. By definition, Agile is not about a rigid process. Maybe this isn't what purists would call Agile. Maybe it's Agile-ish. Maybe it's Scrum-but. The bottom line is that we're working in a collaborative way to deliver maximum value, with higher quality, in minimum time. And isn't that the whole point?
(Janeen Blanton is vice president, Insurance Productivity Services & Agile Center of Excellence at Salient Federal Solutions and can be contacted at janeen.blanton@salientcommercial.com)
© Arc, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.