It is generally agreed the risk of failure associated with core system legacy replacement has lessened in recent years. While measuring the frequency and severity of failures remains hard for several reasons, it is widely agreed these numbers are trending in a more positive direction.
Likewise, despite the lack of hard numbers to support the optimistic view, there are good reasons to believe the trend is real. As we have discussed in past articles, the newer vendors in our space are good software developers that write high-quality, configurable software, and in response to these newer and better vendors, the legacy vendors have improved their game considerably. Better software is a significant factor in fewer failures. But so is project delivery. One of the defining marks of the newer breed of vendor is its approach to building and delivering software. The “new kids on the block,” as we characterized them in an article last year, are adherents of the “agile” methodology of development and delivery, and as we will see, this also greatly enhances the likelihood of project success.
Drowning in Waterfall
Before we discuss what agile is and what is so great about it, let’s ask why we need it? The traditional method of organizing and executing projects is referred to as the “waterfall methodology.” This term refers to the way in which we used to break down the work structure of a project into lengthy, sequential activities on a Gannt chart that is stair-stepped from top left to bottom right like . . . a waterfall. These activities usually were described in such terms as: “gather requirements, design solution, build solution, and test solution.” The waterfall methodology is based on several problematic assumptions, including:
• All requirements can be known and gathered upfront.
• Requirements will not change over the time line of the project.
• The business environment and drivers will not change.
• The business users effectively can visualize a new end state when specifying requirements for the system.
• The construction of the system will take place in a predictable way.
In other words, the assumptions behind this model of project execution require the project operating in a static world, with no uncontrolled external variables. This world does not exist, except inside the heads of old-school project planners. Adding to the problems created by these assumptions is the fact it may be many months, if not years, between users specifying the business requirements and users’ opportunity to validate and verify what was built in response to those requirements. At that verification point, several things usually happen: The users find out what they asked for is not what they wanted, or they find out the developers misunderstood what they asked for, or they recognize the world outside the project has changed and some requirements are no longer appropriate. Sound familiar?
Agile
Hence, agile. Agile project techniques (and there are several flavors) were borne out of the recognition that software development and implementation projects do not take place in static, controlled environments and that change is a fact that must be accommodated, even embraced, for projects to succeed. Agile is based on iterative development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams, and is characterized by frequent inspection and adaptation. The flavor of agile that has been most widely adapted in the market is called scrum. It is an empirical approach to controlling projects, meaning the methodology takes account of and responds to learning and experience as the project progresses and adjusts accordingly. Scrum is good at controlling the conflicting interests and needs that always arise in a project. It is designed to maximize productivity, and it relies on project teams that are horizontal and self-organizing, not rigid and hierarchical.
Perhaps the single key principle of scrum is its recognition that during a project, customers can change their minds about what they want and need. Scrum allows users to interact with the system at predefined review points and to incorporate feedback into subsequent development cycles. This scheme makes both progress and problems transparent at an early point in the project. As is well understood from the general body of project knowledge, the earlier a problem is discovered, the easier, quicker, and cheaper the solution. So, how is this achieved? A scrum-based project is planned as a series of brief phases known as sprints. A sprint is usually about 30 calendar days in duration. Usually a project consists of three types of sprints: planning, development, and testing. What is of real interest to us here is what goes on in a development sprint and how it relates to the next development sprint.
Sprinting Through the Project
The overall scope of a scrum-based project is defined in a relatively high-level statement known as the project backlog. Please note the qualifier “high level.” This is not an attempt, like waterfall, to define all the requirements upfront; rather it is a rough outline of the entire project. Through the planning process, a logical subset of requirements from the project backlog is defined as the scope for a given sprint, becoming the sprint backlog. Now, it gets interesting. In the next 30 days, the sprint backlog requirements are refined, agreed, built, and verified through a demonstration process. At the end of the sprint, the users get to see and touch what they asked for and are invited to propose changes! How great is that? User-proposed changes can result in various actions. They can be incorporated into the next sprint, deferred to a later sprint, or if significant enough, input to a change control process.
My company has been involved in several major scrum-based projects, and our collective experience is as follows:
• Projects generally are delivered on time and on budget. I suggest you read this statement again—what used to be the exception is now the rule.
• Projects deliver significantly higher user satisfaction and are rated as a better fit to expectations. The organization of the project around brief sprints gives the users far greater insight into the behavior of the system as it evolves and allows them to request and get system changes as they progress. This results in the system they want and need rather than the system they requested years earlier without any clear notion of what it would look like.
• There is significantly less rework and cleanup in subsequent “phases” after the project goes live; or the rework is already known, agreed to, and incorporated or at least planned for.
• We have not heard of nor been involved in a scrum-based project failure. Given we have participated in at least 15 scrum-based projects and given the failure rates often quoted, you would expect between five and 10 deeply problematic projects, not zero.
• Most client companies that are introduced to scrum through a vendor-related project adopt scrum as their internal project standard going forward. These clients in turn report significantly better project results in terms of cost, time, and customer satisfaction.
That is a pretty impressive list of achievements. What are the qualifiers? Well, first, these projects involved very capable vendor staff with good software and a lot of scrum expertise. You don’t just figure this out on your own and succeed the first time out. Second, it is not as readily apparent scrum delivers such significant benefits if it is used to control projects that are based on difficult-to-modify legacy systems. After all, one reason 30-day sprints work so well for modern vendors is they have highly configurable software that can deliver a lot of system features in a short time frame. Third, scrum-based projects feel very different than waterfall projects. The project teams have much more autonomy than in the waterfall world, and freedom and responsibility can be frightening. The project feels less formal and yet also is tightly focused on execution. People need time to learn and adjust to scrum, and a few don’t ever make the adjustment.
But these points are nits compared with the advantages outlined above. Scrum and, more generically, agile are a superior way to organize and execute projects. If your vendor touts agile (development and) implementation, it is likely one of the newer, more forward-thinking vendors in our market space. It probably builds better software, and it probably has a superior implementation track record.
George Grieve is CEO of CastleBay Consulting. Previously a CIO and still an acting consultant, he has spent much of the past 25 years with property/casualty insurers, assisting them in the search, selection, negotiation, and implementation of mission-critical, core insurance processing systems. He can be reached at 512-329-2619.