This category contains 158 posts

Avoid hostage situations when refactoring

Last week I talked about refactoring and the need—throughout that process—to still be able to deploy frequently. What I did not explain was why it was important to still be able to deploy frequently, and that was a bit of an omission, because we shouldn’t take these kinds of mantras lightly. The reason is to … Continue reading

The word puzzle analogy for technical changes

I’ve often come across a situation where a team needs to undertake a major refactoring or some other technical change, which may take in the order of days or weeks, and we need to discuss how to approach it. In years gone by, before continuous deployment was the norm and microservices were popular, it usually … Continue reading

Carpe sprintum

I’m reading a book called “Carpe Diem Regained”, about how the phrase (meaning seize the day) has been interpreted and misinterpreted over the centuries, and what it can usefully mean to us today. One aspect that I found parallelled my project work life was that one interpretation of carpe diem is about effective prioritision. The … Continue reading

Burn-up charts made even easier

I’ve updated my Google Sheets burn-up template once again. Here are the changes: There’s a handy new shortcut key for the most common action: adding a new line to record a change in a user story. This is Shift + Ctrl + Alt + 1 on PC and Shift + Option + Cmd + 1 … Continue reading

Improve quality through doing the thing more often

The other week I was reading about the quality problems with major Windows 10 releases. To recap, Microsoft started rolling out to the public their second Windows 10 release of the year (called 1809), but had to halt it quickly when it was discovered it was deleting some people’s files. Before Windows 10 Microsoft would … Continue reading

A strategy for making progress

Often in a work environment I find I’m faced with difficult problems, and while I manage to find ways to move forward, I do this without knowing exactly what the end state should look like. An example of such a problem might be agreeing the best process for something within a team, or a company. … Continue reading

A bad time to estimate

The other day a friend and I were discussing a project which had notably overrun its original expected delivery date. “The problem is,” he said to me, “You estimate a project at the point you understand it the least.” This is a great phrase, and good to remember, even though it’s not strictly true. If … Continue reading

A plan for a plan

The other day a developer in my team asked, “So what’s your plan for…” and then described a particular organisational and technical challenge that several of us had been discussing on and off for a while. It was something that I was pushing forward, but I didn’t have all the answers yet. Of course, I … Continue reading

Product through customers

In the last couple of years I’ve met a few people who have been challenged by balancing building a product suitable for everyone versus building a customised product suitable for just one customer. The challenge is that while building a product suitable for everyone is clearly preferable, it takes a huge amount of time, and … Continue reading

Technical stories are (probably) not negotiable

Two of the INVEST criteria for user stories are that they should be negotiable (meaning the details can be adjusted) and independent (of each other). But if we write the stories in difficult language those two criteria become challenging. Some time ago I was discussing stories which were described in very technical language. This made … Continue reading