One of my frustrations as a developer is waiting for what can seem like forever to get my code reviewed and integrated into the build. I’ve heard many of my colleagues complain about the same issue too. Sometimes we have to chase people to review our code in order to authorize the merge, and other times the roles are reversed and we find ourselves being chased by those same people! Delayed code reviews hold up everything else down the line, such as acceptance testing, deployment and realization of value.
So how could we make code reviews more timely? Let’s look…
People can use the terms “leadership” and “management” interchangeably; other times they mean slightly different things. Leaders typically paint a vision and enlist followers to believe it in, whilst managers typically work to implement that vision. For example, politicians are leaders, while bureaucrats are managers.
In this article, I will lump both leadership and management into one big category meaning “whomever is in charge.”
But before we begin, here are a few questions for you:
Over the years I’ve seen many approaches for working out product focus. Some are relatively simple, like OKRs; others are quite convoluted. Some talk about lofty ambitions to be the “best in the world”; and others focus exclusively on just the work immediately before us. Whilst they all have their merits, none have been able to connect the dots for me between the overall big picture and the minutiae of everyday work. …
Long before Agile, the Iron Triangle — a.k.a. the Project Management Triangle — was a cornerstone of project management. Its origins remain unclear, but it has been used since the 1950s (Wikipedia). It was once a very useful tool to understand the trade-offs involved in delivering a project, and I’ve been wondering whether we can capture it’s embodied wisdom again.
In Part 1 we saw that reductionist User Story Templates of the form “as a user I want some action so that I can receive some benefit” both fails to adequately convey a deep understanding of the customer’s problem, and prematurely jumps to a solution. We proposed a set of long-form questions to ask in order to get a deeper, richer understanding of the underlying problem. We left the article postulating that it must be a lot of work to gather all the information required to answer such questions. (Spoiler: we were right!) Let’s continue…
Such a detailed user story…
Over the years, I’ve been on the receiving end of many terse User Stories, and I’ve often thought to myself “I have absolutely no idea what this means!” At first I thought that these User Stories were just poorly written. But as I saw more and more of them, I started to get the sense that maybe the User Story Template itself was the problem.
To recap, a typical User Story Template looks like this:
As a <type of user>, I want to <perform some task>, so that I can <achieve some goal>
A few examples might be:
The choice between Agile, Lean and Design Thinking can be confusing. There are many articles that dive deep into the weeds of each, describing them in painstaking detail, but not giving much practical advice about which one to choose and when. This is not one of those articles. Instead, I want to look at the bigger picture to help you make a call on this common dilemma. To that end, I will not describe any of the three processes in great depth, but rather direct you to any of the many existing articles freely available.
With that said, let’s get…
Recently, I was talking with my good friend Wil about going through the motions of Agile but not feeling like you’re making tangible progress. He raised the point that a common problem with Agile is that you can easily feel like you’re succeeding when you’re actually not. There’s a term for this: “success theater”…
Vanity metrics are metrics that make you look good to others but do not help you understand your own performance in a way that informs future strategies.
The reason vanity metrics are so decried is that they’re overly simplistic to measure, they skip nuance and context…
In my previous article I wrote about iterations in Agile, and how they can be interpreted in different ways. Specifically, I rejected the frequently used “time-box” definition of iteration in favor of a multiple attempt approach where you iteratively work away at the same problem until you get its solution right:
In response, one of my readers Jessica Knight pointed out:
Actually, I didn’t actually think too deeply about the terms…
“All the cool kids are doing Agile these days.” But if I probe a little deeper to ask what that means at a practical level, many people answer “we’re delivering our product in short iterative chunks.” I previously wrote an article about the delivery-focused benefits of this approach, stating that just focusing on delivery only doesn’t by itself guarantee that you will create an effective product that customers actually want to buy and use:
It struck me as odd that many teams rely solely on incremental delivery as their main interpretation of how to build software that customers would want…
Founder & CEO, PhD, software engineer, author. Helping teams to craft better products that customers love. Connect at linkedin.com/in/rajnagappan