AI has made building easier.
But building the right thing is still hard.
Ten articles every week on what is happening across product, research, design and engineering. Curated by Rory Madden to help teams decide what to build.
Explore the editions ↓The archive
In 1996 the Standish Group released the Chaos Report which showed that 40% of IT projects failed and a further 33% were challenged (over-time and over-budget).
Read edition ↗Our organsiational structures and management practices exist because they were the most successful way of working in the 20th Century. Unfortunately they are no longer the best fit given the expectations of the world today.
Read edition ↗Ford was the poster-child for the benefits of the assembly line way of working. But the approach of breaking down every process into its constituent parts, then optimising each one separately is now backfiring.
Read edition ↗When companies like Airbnb and Netflix measured the success rate of new features they found that only 8-10% achieved the expected benefits.
Read edition ↗Before we can improve efficiency we need to first agree on our definition of efficiency. Many companies look at team utilisation (% of time allocated to capitalisable projects) and predictability metrics (on-time and on-budget). But research from the DevOps Research and Assessmen
Read edition ↗One of the big risks of empowering teams is that you lose the centralised control over the system architecture. Empowered teams require the ability to go from idea to satisfied customers without relying on external approvals like architecture reviews. So how do companies prevent
Read edition ↗Who loves estimating how long it will take to deliver some features? The reason we don't like it is because we never have enough information. We have high level requirements with so many uncertainties that we have to make a lot of assumptions. We then pad our estimates with conti
Read edition ↗I'm sure you've seen the picture from Henrik kniberg depicting the iterative development showing a skateboard, bicycle and then a car. The theory made sense to me but whenever I was faced with a project I couldn't figure out how to apply it. The solution only worked when all of t
Read edition ↗The "Not Invented Here" syndrome is a common challenge in software development, where teams often prefer building everything from scratch rather than leveraging existing solutions. While building custom solutions can provide unique value, it can also lead to wasted time and resou
Read edition ↗After doing fantastic Continuous Research and Continuous Design work, you have a validated prototype. The only problem is that it would take weeks or months to build. Most features fail to deliver the expected business value, so this is unacceptably long to work on the feature. W
Read edition ↗Feature flags let development teams release features incrementally.. However, they come with a significant challenge: test case explosion. As each feature flag essentially creates a duplicate version of the system, the number of potential paths requiring testing grows exponential
Read edition ↗DevOps is often framed as a technical solution: continuous integration and delivery (CI/CD) pipelines, automated testing, and infrastructure as code. But the technology would be pointless without the necessary cultural changes.
Read edition ↗Duke Nukem Forever took over 14 years to develop due to a string of requirements changes, scope creep and unforeseen challenges. The team were struggling to create the graphics they needed with their game engine and decided to swap game engines after over a year and a half of wor
Read edition ↗