Your First Development Sprint (What Will Go Wrong)

You’ve got funding and approval for your core system project, you’ve been exposed to Guidewire products and methodology, and you’ve got a firm grasp on your project scope through completion of the Inception Phase. Now, you’re ready to enter arguably the most exciting phase of the project – the Implementation Phase.

In this Guidewire Smart Approach Blog series, I will highlight some of the key challenges project teams face as they enter their first Development Sprint. While most of our insurance customers are aware that the Implementation Phase will bring on a new set of challenges, many are not prepared for some of the initial challenges that the team might face as they kick off their development activities. In this first blog post, I will present four common areas of difficulty, and will give some thoughts on how these can be mitigated so that they don’t turn into lingering issues for your implementation project.

The first challenge that often arises is that insurers might try to keep momentum by moving immediately from the Inception Phase to the Implementation Phase. While the intention is good, the best Implementation Phases start by having a defined “Sprint 0” period which will allow for planning and stabilization as you enter implementation. Some of the primary tasks of a “Sprint 0” include defining developer machine specifications, defining development standards, setting up source control, setting up automated build procedures, standing up a shared Development environment, organization/setup of your project management tool (i.e. Rally), and formal Guidewire training. Insurers should work with their Guidewire consultants to determine the tasks that are required to be completed in “Sprint 0” to best position their project and to determine the proper duration. Depending on your organization, a “Sprint 0” might last from 1 week to 4 weeks. This investment is one of the most important things you can do to ensure a successful start to the Implementation Phase.

The second challenge in starting your first development sprint is gaining comfort with the agile methodology. For many insurers, this will be the first implementation that utilizes the agile implementation methodology. While we spend time going through key agile concepts during the Inception Phase, things become “real” during the Implementation Phase. One of the biggest adjustments is the development teams realize that they are self-empowered and with that comes great responsibility. It is now the team’s obligation to ensure that they choose user stories from the product backlog that can be successfully delivered during the course of the Sprint. No longer will there be a manager directing the traffic and dictating the work effort – the onus is on the team. This can be a tremendous change for an organization’s culture, and the Guidewire Professional Services Team has experience across over 100 projects to help through this critical time.

A third challenge is the expectation of the team’s velocity. One critical mistake that can be made in the first Implementation Sprint is the assumption that the team will operate at peak velocity. Simply put, this is not a very realistic expectation. Every project team will take time to “gel” and learn how to work together, and this is no different for an agile team. For the first Implementation Sprint, a realistic velocity might be 60%. This means that the team will be able to design, develop, and test functionality at about 60% of their available hours. The team will eventually gain efficiency until peak performance in the Sprint 3 to Sprint 4 timeframe. It is important to set this realistic goal as you plan Development Sprint 1, otherwise the project runs the risk of not accepting user stories at the end of the Sprint and therefore appearing if they didn’t deliver any value. This situation must be avoided during the delicate time when everybody is getting accustomed to the agile methodology.

Finally, in the first Development Sprint there is likely to be more confusion on the technical integration side, and a general feeling of “where do we start?” can exist. The reason for this is because integrations are often large and complex – some of them might take thousands of man-hours. Teams that are new to agile often struggle with breaking large chunks of work into more manageable user stories that can be worked through on a fractional basis. One way this can be mitigated is to have the integration team break down their user stories once they are loaded into the Rally project tool. This is a task that often is done successfully in Sprint 0. If this effort is expended at the start, the integration team will be able to concentrate on choosing manageable user stories that can be delivered, instead of realizing half way through the Sprint that the story they choose is too big. Your Guidewire Professional Services Team can work with you to utilize and structure the Rally software in a manner that keeps integration work logically grouped together, but chunking it into workable user stories.

In summary, the first Development Sprint is probably the most challenging time of an enterprise system replacement project. Recognizing some of the challenges project teams face, and more importantly anticipating how they will be handled, can help to ensure your Guidewire core system project gets off to a successful start.