As I’ve done each of the past few years, I’m starting the new year with a list of the most popular blog posts I shared the prior year. Based on page views per day and the number of comments, here are the ten most popular posts of 2020, starting with #10 and building up to the most popular blog I wrote last year.
10. Use a Pre-Mortem to Identify Project Risks Before They Occur
We’re all familiar with the benefits of a retrospective or post-mortem. This article describes the powerful process of a pre-mortem.
In a pre-mortem, team members imagine it is the future and they are looking back to the present. Their project has failed. They discuss why, and then take steps to avoid those causes of failure actually occurring in real life.
9. Overcoming Four Common Problems with Retrospectives
The iteration retrospective is perhaps the most important meeting an agile team does each iteration. It’s also the meeting most teams wish they could skip.
In this post I describe the four most common problems teams struggle with in their retrospectives. I then offer advice on overcoming each.
8. Are We Really Bad at Estimating?
Humans get a bad reputation at estimating. And none so much as software development teams. Some of that reputation is well deserved, but not all of it.
In this post I share research that shows we’re not really that bad—that is, we’re not that bad at estimating things we know enough about.
I also explain why development teams get the undeserved reputation of always being late.
7. Can There Be Too Much Transparency?
Transparency is a good thing. In fact, it’s so important that it’s often described as one of the three pillars of agile.
But, just as with ice cream, is it possible to have too much of a good thing?
Yes! But read the post to see why and to learn exactly what a team should be transparent about.
6. How to Estimate Story Points with Multiple Teams
You say toe-may-to, I say toe-mah-to. Your team says five points, my team says eight points. Here’s how to establish a common story point baseline that can be used by multiple teams on the same project.
5. Time Pressure Improves Productivity & Quality…Up to a Point
I haven’t had a chance to run yet today. I’ve promised myself that if I stay focused and get this blog post written by 4:00 p.m., I can knock off for the day and go for a run. That little bit of time pressure is helping to keep me focused.
Time pressure works the same way for teams. The research I cite in this post shows that a little pressure (a little!) goes a long way and can actually lead to improvement in both quality and productivity.
4. Can a Team Vote Someone off the Team?
Ever since the Survivor TV show debuted in 1997, I’ve heard teams talk about “voting someone off the island.” Usually this is said as a joke, but some teams do have the authority to remove someone from the team.
These are known as self-designing teams. They’re one of four types of teams I consider in this article. I answer the question of whether it’s good for a team to be allowed to remove team members and offer an alternative approach for when someone isn’t performing well.
3. 25 Questions that Will Help You Know Your Teammates Better
When our organizations have a “human resources” department, we complain that we aren’t resources. Yet, unless you’ve made an effort to know your teammates better, you’re likely just treating each as a resource. Jenny is the resource who tests my code. Jakob is the resource who designed the user interface I code.
The more deeply we know each other, the more we relate to one another as humans rather than as resources. This was especially important during 2020 as so many teams shifted to entirely remote work. This article shares 25 questions team members can discuss to get to know each other better.
2. Is the Distinction Between Outcomes and Output Overdone?
I don’t think a day passes without me hearing that it’s important to focus on outcomes rather than outputs.
True. But does that mean outputs can be ignored?
I don’t think so. Read the post to see why.
1. Are Estimates Ever Helpful to Developers?
Developers resist estimating because the estimates they provide are often used as weapons against them. If a developer says “five days,” they’re in trouble if it takes an hour longer than that. If they come in early, they merely did what they said they’d do. That is, they met expectations.
This leads many developers to avoid providing estimates. But estimates can be extremely useful not just to the business, but to the developers as well. Read this post to see how a history of pretty good (not perfect) estimates can dramatically improve the relationship between developers and stakeholders.
