Three ways the lockdown improved our agile culture

Tom Wright — Tue, 07 Jul 2020 08:22:30 +0000

This article was written by Paul Boylan. Paul is a Scrum Master at GPI, establishing a supportive environment where the development team can work at its best.

At the end of our Coleridge sprint on the Horizon project, we had our first major demo for the leadership team. Hardly settled into our new offices, we were a little in denial we would soon be working out of our homes. Before the end of our Duxford sprint we were all in lockdown, and we faced the challenge of sprints Ely through Hauxton as individuals.

1. Self-organisation

This was a new team, who hadn’t been working together for long. Normally a challenging time. Still in the polite stage, differences in working styles were showing as a theme in retrospectives. Sending everybody home would likely exacerbate this. In fact, with change now inevitable for everyone, I now saw the team finding ways to work. Practice, the ‘how’, emerged from the team.

2. Stand-up engagement

I have three stand up meetings each morning. I am not in the same room as any of the teams. They might be split across a couple of locations, but they are in a group. This changed with lockdown. The purpose of the stand-up meeting is for the developer to tell their own story to themselves, but also to the team. It is easy to slip into the habit of making each update sound like it is to the Scrum Master, especially when the Scrum Master is the most remote. It is an update to the person who wasn’t here yesterday and won’t be here today. Unexpectedly, with everyone working from home, a more complete circle was formed, increasing participation and collaboration.

3. Story selection

Another area refreshed by the lockdown has been story selection. Over time, the cadence of sprints begins to work against value. We want to deliver the highest value possible each sprint, but we know there is a next sprint coming. In lockdown, I have noticed a new importance in having something great to show. We began to visualize the product, one sprint on, either with or without a feature. It is easy to imagine a craving for interaction and a need for purpose as driving this, but another idea is that we are living with more ‘cannot do’ now and this has sharpened our focus on the ‘can do’: what if the user can do this… or this?

If agile thrives in environments of adversity, unpredictability, and change, then it follows that there is a risk that it loses ground where these are absent. The challenge, I think, is to keep with us the spirit of these times.

How has lockdown affected your agile practice? Let me know in the comments below.

Accelerating data ingestion with Bartscript

Tom Wright — Tue, 23 Jun 2020 08:28:46 +0000

Pricing and reimbursement data are the lifeblood of the pharmaceutical industry. The maintenance of GPI Pulse involves retrieving, standardising, and interpreting data from over 100 different sources. Automating this data collection and processing is vital to our commercial success.

Historically, our data processing pipelines have been built by developers. These work well, until the data source changes. Unfortunately, when the source drifts, it takes a developer to make the corresponding adjustment to the pipeline. One of our significant challenges in the engineering team has been balancing this sort of maintenance with feature development. At the same time, the analysts were facing delays.

Our response has been to invest in bespoke tooling for our data analysts. Taking the lessons learnt from the development of our traditional pipelines, we have been able to produce a generic, customisable pipeline. This approach has put our analysts back in control of data processing and increased the agility with which we can respond to upstream changes in data formats.

Central to this strategy has been the development of an internal “Domain Specific Language” (DSL). For the sake of familiarity, we modelled this new language on Excel formulas. This language allows for the declarative articulation of a group of data transformation actions, arranged in a sequence of phases. We call this new language “Bartscript” in honour of the contractor who lead the development efforts.

Even though it is so niche, Bartscript has many of the features you’d expect from a fully-fledged programming language:

Branching logic
Loosely typed and liberal when it comes to coercion.
Full sandboxing
Comprehensive error handling

Despite this sophistication, Bartscript remains deceptively simple to use. This simplicity has facilitated a team of two analysts and one developer to automate sources at a rate of 5 per sprint. For comparison, under the old approach, we would have expected one developer and one analyst to work on one country full time for one sprint (give or take). In other words, we have reduced development time by two thirds.

The real test will come when one of the pipelines requires some modification due to a change in its source. We hope that, in many cases, the analysts can make the necessary changes with minimal support from the developers. We are still in the early days, but the initial signs are good.

Forem: GPI Engineering

Three ways the lockdown improved our agile culture

1. Self-organisation

2. Stand-up engagement

3. Story selection

Accelerating data ingestion with Bartscript