Insurance Solutions | Georgina | 14 January 2022
In Right First Time we explore how assuring successful change management is crucial in transformational programmes. Dynamic software applications allow insurers to transact policies and enable digital platforms more effectively than ever before. However, implementation is not merely a matter of getting it done, but in getting it done right the first time, every time.
Sprint Reporting is commonly used by many insurance projects. Here we explore a typical programme issue and how Sprint Reporting addresses it.
The issue: The need for insight
Insurance transformational programmes very usually use Sprints as discrete timeboxes, within which development teams undertake the work required. Those teams, many using Agile, or Hybrid Agile methodologies, attend several scheduled meetings. Ranging from Sprint Planning to the daily stand-up, these meetings are essential in delivering the work.
An all-too-common issue, prevalent in many insurance programmes, is where these meetings become bloated by additional attendees. These are interested parties, including Stakeholders, Project Managers, Business Liaisons, and others, who need or feel the need to know what is going on inside the development teams. Not only is this behaviour wasteful of resource but the attendance of these extra people, especially those of great influence, can be inhibiting for the proper functioning of the development team.
On some projects, the number of these extraneous attendees can outnumber the development team. Then, there is a tendency for the purpose of the meeting to transform into one where the aim is to explain to the ‘higher ups’ what is going on. Then, as the downward spiral continues, additional meetings are set up to explain every action in miniature. Ultimately leading to an upward transfer of day-to-day ground-level decision making, where a micro-managing cottage industry attempts to run every single facet of the programme. Meanwhile, the development teams are so bound up with explaining themselves, fearful of wrongful steps, that little development work is actually delivered.
Sound familiar? But this is a symptom, not a cause. An insurance transformational programme, quite rightly, has interested parties, who need insight into what is happening. However, how can the development teams keep those interested parties advised without impeding getting the work done? Sprint Reporting.
Defining Sprint Reporting
Not to be confused with the historic, backwards-looking formats most usually associated with the word ‘Report’, Sprint Reporting is a continuous and contiguous method for reporting on progress within project development teams.
Sprint Reporting operates in the now, providing a holistic view into the present. To do so, Sprint Reporting relies on the Sprint Model, which details the current state of work, and the immediate collation of meeting outputs to produce the Sprint Reports.
When described in this way, Sprint Reporting might appear a lot of effort. However, when measured against the waste of resource caused by over attendance alone, Sprint Reporting is lean and efficient. Additional benefits, in velocity management, dependency tracking and other keystone elements, may also be realised.
Each development team has its own Sprint Model. This model details the Big Five (Work, Dependencies, Capacity, Resources, and Tools) for that team. The model is updated throughout the day. Once, or twice a day, the individual models for the teams are merged into the workstream model by the workstream Project Manager. Those parties who are interested in the current state and progress of work may then refer to the Sprint Model to understand what is going on, rather than feel the need to attend all those meetings.
Each development team forwards after-action notes to the Project Manager, recanting the actionable outputs, including items for the decisions and risk logs. These are merged into the workstream Sprint Report daily. Instead of attending endless meetings, those parties interested in the operational aspects of progress in the development teams may refer to the Sprint Report for that workstream to understand what is happening.
How Solution Assurance helps
Solution Assurance is a vital third-party service that assists customers to install and develop effective enterprise insurance software solutions.
Setting up and managing Sprint Reporting in this manner has some initial complexities. However, Solution Assurance can assist in the initiation and furtherment of effective Sprint Reporting.