6 November 2018
The past two years I was active (via Co-Learning of course 
) as Scrum Master for De Persgroep. My primary team was D.I. JOE, who’s main goal was to build a datalake as part of the move to the cloud, using the AWS platform.
One of my first tasks with D.I. JOE was to help the team in creating a Definition of Done.
For a long time “done” meant for D.I. JOE that the story was Ready for UAT. The release flow till production was tracked on a separate board.
A few sprints ago the team noticed that this was no longer working as intended. Stories stayed for a too long time on the Release Board, some stories were already in Production but the status on the release board was not updated, etc.
So the team decided in a retrospective to extend their Definition of Done to include: In Production. This meant their Definition of Done now contained the whole end-to-end scope.
This had of course an impact on the lead times. As suddenly all UAT & release work was now included.
As you can see in above graph lead times jumped drastically up in Sprint 41. Stories (blue) went up from around 4 days to 24 days, while bugs (red) went from around 4 days to almost 60 days!
But as you can also see the team quickly had things under control. Story lead time has been under control to a level below their normal lead times (around 3 days now). Bug lead times were a bit higher than before, but still within acceptable parameters for the team.
This showed me that, as a scrum master, we should never be afraid to challenge our teams in extending their Definition of Done.
GitOps
The above success also made me wonder if the team’s ‘GitOps’ approach was helping them into getting such a quick grasp of their extended ‘done’ scope.
GitOps is defined as follows: “GitOps builds on DevOps with Git as a single source of truth for declarative infrastructure and applications – the whole system”.
Once the team was settled in their current configuration (somewhere around October 2017) they quickly agreed, during a retrospective, to go for GitOps.
So we commit to master, with CI/CD (Concourse CI) fully integrated for infrastructure (Nifi and AWS via Packer/Terraform) and application code (Spark via SBT (Scala Build Tool)).
Very rarely has the D.I. JOE team a separate feature branch, and if so those are short lived. We’ve set up a whole deploy chain (using Terraform and Concourse) that includes automatic (regression) testing that activates upon commit and at certain fixed times. This helps us to deploy to production multiple times per day.
Below is a screenshot of the current configuration of their Concourse deploy pipelines.
I want to end this post by saying that it was a real joy to work for De Persgroep. Their open culture, “Fail fast, learn fast” approach, “You Build it, you run it” motto and much more all show what a great environment a company can offer their employees. Thus enabling them to deliver great value, within the freedom given. The above is proof of that. It clearly shows how a team can take control, and decide on tools and approach that fit their taste, to create amazing product.
You can follow De Persgroep online via their ICT twitter account and LinkedIn.
