Agile software development, done correctly, results in a product that does what the customer wants. It achieves this by showing results to customers egularly throughout development and enabling customer testing and input.  It avoids developers going down the wrong path, sometimes to the end of the project, wasting time and resources, and creating an unsuable or ill-fitting system.

Many companies claim to use agile methodology but stop short of fully including the customer as a participant. Specifically they do not show the customer the interim work every two weeks or involve the customer as a partner and expert in their own needs. We think this level of participation and openess is crucial and anything less will not keep the project result efficiently on the right track from day 1 to launch, and ultimately demands more of the client's internal resources.

Agile Divides a Large Project into Short Time Periods to Ensure Steady Progress & The Right Results

At the end of the first 30 days and each two weeks following, our customers see a working product that they can comment on. Agile project management involves "sprints" that clearly define what the developers will accomplish and what the client will do in a two-week period. What is shown at the end of each sprint is by no means the final product, but each sprint produces something that can be shown the client. They can adjust the smallest detail or change their largest goals, with much more knowledge than with traditional methods on how the change affects the project cost and delivery time.

Agile Defines What Developers and the Insurance Organization Need to Do Each Two Weeks

Importantly, each sprint defines what the customer will need to do to meet the goals at the end of the two weeks. Delays with traditional methods are often the result of customers not being given a clear idea of time constraints for what they need to provide or getting all the requests at once at project start.

The developers have daily, short, 15 minute meetings called “scrums”; customers are welcome to join in and are sometimes needed. Each developer presents what they will do that day and any impediments to their achieving the day’s goals. The team gives advice so the developer is working with the full team’s experience as a base. The scrum is held with everyone standing and the time limit is rigorously followed.

Agile Enables the Customer to Ensure the End Product is What They Expect—And it Works!

Each sprint has a written goal to achieve specific functionality at the end of two weeks. The developers present the functionality and the customer can adjust their goals and make changes. This avoids a traditional pitfall of software developers finishing a complete product and then presenting the result to the client who immediately sees that it isn't what they need. Changes at that point are very costly and sometimes mean going back to an early point in development. Revisions can stretch projects out for months or years.

In addition, the traditional approach delays testing until the completion of the project. Agile methodology, because it produces working software features every two weeks, allows client review and testing as the development happens. When the project completion is reached, the bulk of testing is already completed.

ISCS Provides Customers Visibility into Project Status 24/7

ISCS adds extraordinary visibility to the process for customers. Not only does the customer have a structured role to participate, see working functionality along the way, and influence the system's development, the customer can also see the development hours used for each part of the project at any point of time. We use a combination of a customized Salesforce.com system integrated with OpenAir project management to provide Web-based access to hours worked on each section of the project, the overall status and timeline, even what developers are working on which task. Clients have their own log-ins to the project tools.

We don't know of any other vendor in the insurance industry that provides transparency even close to ours. Development is no longer some kind of black box where you have no idea what change orders have done to the overall project, what is left to be done, what has been misunderstood, where a developer is missing crucial information from you, and what will come out at the end. This helps you make informed decisions on how to allocate resources to the project and whether changes that extend the launch date are worth the delay.

ISCS Makes Agile Development Work!

We've had some extraordinary success with our methodology. Much is due to combining the approach with equally sophisticated discovery methods, the insurance expertise we bring, and the modern nature of our technology platform. Our technology begins with insurance intelligence built in throughout the system and into each already working product line, so that deployments can focus on the insurance organization's unique needs in products, underwriting, workflows, business rules, reporting, and so on.