Let your teams plan for themselves

As an industry of tinkerers, optimisers and perfectionists we occasionally miss the beauty of unorganisation and human instinct. Our obsession to be more efficient and productive can sometimes have some undesired consequences. At Made we often adapt our processes in the name of efficiency but lately we’ve started experimenting by taking away some of these processes with surprising results.

Products not Projects

Traditionally, software is delivered as a project: a thing with a start and an end date, and probably a list of desired features. The software is (hopefully!) deemed complete by the end date, the project is closed, and the project team move on to their next project.

Technical challenges with adopting Continuous Delivery

I spoke last time about the organisational challenges of adopting Continuous Delivery. One of the key takeaways was the importance of blurring the boundaries between team ownership in order to facilitate better adoption. This time around I want to zoom in a bit and focus specifically on the challenges faced by specific parts of the pipeline. Depending on how far through adoption you are, you likely no longer have dedicated teams for each of these functions, though the problems outlined here can still exist and derail even the most cross functional of teams.