Do you ever feel like it takes an eternity for your code to be reviewed, and by the time it does get reviewed the code base has already moved on? Let’s explore how we might narrow that gap.
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…
Have you ever asked the question “who trains Agile leaders?” Moreover, have you ever found a sufficient answer?
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:
- How is management supposed to work with Agile?
- Who trains management how to work with Agile?
- What do you teach them?
- Does management or leadership…
If you’ve struggled in the past to relate a lofty, aspirational Product Vision to your day-to-day work, this layered architecture may help you to connect the dots.
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. …
This once-common tool of planning can still help us in the age of Agile projects, if we learn it’s secrets.
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.
What is the Iron Triangle?
User stories aren’t a noun, they are a verb.
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…
A User Story is a Process, Not an Object
Such a detailed user story…
Have you ever had that problem where someone hands you a terse User Story, and you think “I have no idea what that means?!” (Part 1 of 2)
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:
- “As a…
The method you choose may be based more on your experience and skills than anything else.
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…
Do you ever feel like you’re going through the motions but it’s not actually making much difference?
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 and 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…
Though they may sound similar, their differences can be profound
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:
- “Iterative” vs “increment” was a great distinction to make.
- They may sound superficially similar but they underlie deep differences.
- A series of increments does not actually make you agile.
Actually, I didn’t actually think too deeply about the terms…
In Agile, is incremental delivery the only thing that matters?
“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…
Raj Nagappan
Founder & CEO, PhD, software engineer, author. Helping teams to craft better products that customers love. Connect at linkedin.com/in/rajnagappan
