Continuous integration - continuous deployment (CI-CD)

DevOps

Feature switching

Git branching models

Open source

Pairing

Test driven development (TDD)

Testing

The build process

Your tech stack

How I learned to code with Advent of Code, and get the most out of it

Learning to code with Advent of Code

New guides on development topics for delivery managers

What dev stuff should delivery managers know or care about?

Should delivery managers run retros?

My experiences moving from branch based development to trunk based development

Getting used to trunk based development

Noting down a couple of handy approaches for tidying up npm dependencies, particularly after running npm audit.

Keeping npm dependencies up to date and secure

3 months ago I made a career change from being a delivery manager to being a developer, this is a reflection on the last 3 months

Making the career change from delivery manager to developer – things I’ve learned 3 months in

Since going remote, we've had to make some changes to how we run our standups and walk through the wall

Refactoring the wall

Being your teams shit umbrella isn't always in their interest

On not being a shit umbrella

Having an extended pause to a project sucks, but we have found some silver linings

Silver linings to an extended project pause

How to improve your standups - a write up from a lightning talk I gave to our engineering community of practice

Better standups

I’ve been thinking recently about team metrics, continuous improvement experiments, and consent. - written up from a twitter thread

Team metrics

We are currently having one of our quarterly spike weeks on our team, and for once I am managing to protect my own time and do my own spike. To help me remember what I've learned, I plan on writing what I did each day. DAY 4

Spike week day 4

We are currently having one of our quarterly spike weeks on our team, and for once I am managing to protect my own time and do my own spike. To help me remember what I've learned, I plan on writing what I did each day. DAY 3

Spike week day 3

We are currently having one of our quarterly spike weeks on our team, and for once I am managing to protect my own time and do my own spike. To help me remember what I've learned, I plan on writing what I did each day. DAY 1

Spike week day 1

I've been thinking more about roadmaps recently and how they differ from delivery plans. - written up from a twitter thread

More on roadmaps

This post is about how delivery managers (and product managers) can encourage and supporting pairing. It has come up a few times in discussions I’ve had about good practice on delivery teams, and there still seems to be reluctance to champion it, or even embrace it. Sometimes this comes from the delivery manager themselves, but more often from a general feeling that their organisation won't accept it. I’ve had on one occasion a delivery manager tell me that pairing is something that can’t be done in government. With a better understanding of how to support pairing, delivery managers might feel more confident in advocating for their team.

How to support pairing

Your whole team should be involved in prioritisation of their work. Providing their knowledge as input directly, and empowering them to decide on their own work produces better software and better teams

Prioritising as a team

Part 2 of service teams rather than project teams, this time with the practicalities of how to govern their spend

Funding service teams rather than projects

The benefits for me of having a service team rather than project teams are team stability, the service stability, and the long-term strategy it enables at the team level. These are all enabled by having service teams that support a coherent set of services for their full life. Funding teams is a necessity to be able to provide this model.

Being on a service team rather than a project team

I've decided to create my own personal site, to keep my blog posts and personal projects together in one place. This is a bit of a meta post on what I've learned putting this together using gatsbyjs.

Trying out gatsbyjs for a personal site

Recently I built my own react app to learn more about react and get in some coding practice. I am a delivery manager and don’t often get the chance to code day to day, so have set it as my learning and development objective. Once I had it written, I decided that learning to deploy something would be a good next step, as before I have just used github pages. A while ago a colleague recommended to me that when I was learning something new I write a blog post about it. It would help me remember and think through what I did, ensure that I fully understood what I had learned, and might help someone else trying to do the same thing.

What I learned deploying my own react app

The roadmaps I’ve seen before have tended to be linear, and have dates. This is the entire point in a roadmap for some people, but for me it is too restrictive if I am meant to be able to respond to changes and new priorities. Once you have a linear roadmap, people expect it to be followed and for things to turn up in exactly that order. This is even worse if there are dates on it, because they expect those things at exactly those times. (Again, this is probably why some people like them, but it doesn’t work if you are responding to what you are learning).

Radarban Roadmap

For a long time, I have avoided estimation. I’ve generally found that story count and cycle time has served me well enough if I do need to provide forecasts, and I have only provided ‘how long might this particular feature take’ forecasts, rather than “when will I get all of this” forecasts of large numbers of features.

Donald Rumsfeld estimating

I’ve been thinking recently about how our team balances the effort we put in to putting together designs for the long term vision for our service, with the work we need to do now to deliver our minimum viable product and the private beta of our service.

Balancing long term vision with short term delivery priorities

Many teams across DWP and government are now using kanban boards to visualise the work going on in their team. However, this is only one part of kanban. Whilst it is an important first stage to map out the flow work takes to delivery, and to visualise what work the team has going on, the main value of kanban comes in using it to then improve the flow of your work. The way kanban does this is through limiting work in progress. It is the most important aspect of kanban, but it is often neglected.

Reducing time spent in queues

One of the things that often gets discussed during our daily team stand up is whether a piece of work should be on our kanban board, and whether the work on the board accurately reflects what the team is working on. To get the most out of kanban, we should be reflecting all the work the team is doing on the board so that we can ensure that the work in progress limits are having the right impact, and improving the flow of delivery.

Types of work on our kanban board

My team started out using the standard stand up format of answering the 3 questions; What did I do yesterday?, What will I be doing today?, What are my blockers?. As a fairly large team we started finding this to be very repetitive.

Why we walk the wall rather than asking for individual updates

I previously wrote about the reasons my team is using kanban to organise our work. Here I go into further detail about how our board is set up and why.

The anatomy of our kanban board

Using kanban has improved our visibility of what work is being done by the team, and prevented each stage of work on a feature from becoming uncoupled from each other.

Eleanor Mollett

Talks

Blog

Guides for delivery managers about developer things

Contact me