Truly Agile development revolves around one-on-one meetings, not daily standups

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at:, or follow me on Twitter.

Robin Rendle wrote a good essay “I don’t believe in sprints.” Everyone in tech should read that. My only criticism is that the title is focused on what he’s against rather than what he’s for.

I’ll focus on what I’m for: real agility involves spontaneous one-on-one meetings. I say “spontaneous” because these meetings are not planned, people simply talk when they need to. Large meetings, which often waste the time of at least some participants, are discouraged. If you’re looking for a style of development that is flexible and fast, you’ll want to avoid the ceremonies that are now associated with formal “Agile” methodologies.

I’m writing this from the perspective of someone who has been leading tech teams since 2002, when I co-founded my first startup.

I’ve previously written an enormous amount on this topic but here I’ll try to keep things reasonably short:

Daily Standups?

If I personally have to check with someone, each day, to get good work from them, then my preference is to fire that person and hire someone else who I can trust. If I need to check in with a person every day, then I’m micro-managing this person, and I have to wonder why they need to be micro-managed. The single greatest source of agility in the American system, relative to European systems, is the ease with which American managers can fire people. American managers would be wise to remember this. Aggressively firing weak employees, till you have a team that you can 100% trust, is the fast route to true agility. Once you have a team of people you can entirely trust, then you can focus all of your energy on supporting your people with their work, without having to waste any energy on being the police of other people’s work ethic.

How much you need to check in with people depends on how experienced they are. With senior level engineers, who I trust, I’ll meet with them on Monday and ask them “What do you hope to get done this week?” and then I’ll meet with them on Friday and ask “What did you get done?” and then we’ll talk about how I can help them during the next week. During the week, if they run into anything that blocks their work, I expect them to reach out to me (on Slack or in email or they can text my cell phone) and let me know. Since I don’t waste time on unnecessary meetings, I often have the flexibility to respond quickly. (I could qualify this with a list of various corporate transitions that add additional difficulties, but I’m trying to keep this essay short.)

With junior level staff, they typically need much more time and attention from me. Often, when I hire someone new, I try to check in with them every day, one on one, for at least the first 2 or 3 weeks, until I think they know enough that they can make progress on their own. If I’ve hired a junior level developer then I’ve committed to making a large investment of time, trying to bring them up to speed. This investment often works out well, because I’m careful about who I hire. (In 20 years, I’ve only had to fire one person who I hired, back in 2006. In all other cases, when I fire people, I’m firing a bad hire that was made by someone else.)

A person on my team has my full support so long as I think they are working to learn what I need them to learn. I do everything I can to communicate this, because everyone on the team needs to feel respected. The word “agile” has no meaning if it doesn’t include the esprit de corps of the team. People can only do quality work when they know they are respected.

Some people have suggested to me that firing people damages the esprit de corps of a team. I’ve never found this to be true. If a developer is doing bad work, or is shirking work, they are often hated by the whole team, and when I fire them, and hire someone better, everyone else on the team is pleased with the outcome.

If you’ve read my book How To Destroy A Tech Startup In Three Easy Steps you’ll remember that I spent 3 months trying to train Sital, but he ignored what I had to teach, and he instead invested his time in his weight lifting and gym routine. I didn’t have the power to fire him, but after 3 months I did advocate that he be fired. One of the conclusions I draw, at the end of that book, is that a small, fast moving, agile startup needs to be aggressive about firing weak players — at a small firm a single bad software developer can bring down the whole company. But we should also consider the counterfactual: there is an alternate universe in which Sital was excited by the opportunity he had to become a true AI and NLP expert, he could have studied hard and he could have been one of the main people building the success of that startup. In that alternate universe, instead of advocating for him to be fired, I would have been his biggest supporter. I’m always willing to put my own reputation on the line for a developer who is clearly making progress.

Every human being is a unique individual with unique needs, which is why the daily standup is a bad idea. It’s important to learn who is working for you, learn their strengths and weaknesses, and tailor your support to the needs of that individual. This is much harder than simply having a daily standup, but it is literally a flexbile approach. By contrast, rigidly enacting certain daily or weekly ceremonies is easy, but it is not flexible. The officially Agile ceremonies are anti-agile.

What should the word “agile” mean? In corporate circles the word has had an evolving meaning over the last 40 years. Back in 1999 Ted Goranson wrote a fantastic book about agile corporations. He defined “agile” as the ability to reconfigure a supply chain. So, for instance, if your corporation buys a crucial, custom product from one country, a customized product that relies on you having a deep relationship with that supplier, but then a war breaks out in that country and your supply lines are disrupted, how quickly can you develop a deep relationship with a new supplier in a new country? That is the measure of your agility. (Goranson also worried that corporations were optimizing for short-term profits in a way that actually made them less able to reconfigure their supply lines, and the recent spike in inflation, after the disruptions of the Covid-19 pandemic and the Russian invasion of Ukraine, seems to have proved Goranson correct.)

“Quickly reconfigure supply lines” might sound like a definition of “agile” that only works for industrial corporations, but I think it is a great definition for the various software teams that work in a corporation. A common experience, which I’ve lived through many times, is that a new product is considered the number one priority of a company, but then the top leadership decides they misjudged the product opportunity, and so the product is either canceled or dramatically altered. How fast can you change your internal supply chain, which is the various tech teams in your company? Do you suddenly need more frontenders or less? Do you suddenly need more devops talent or less? How fast can you re-assign your people to new teams and new tasks? How fast can you make those people productive in their new roles? That is a crucial measure of real agility for tech teams — how fast can you re-configure your internal supply chain?

Two week sprints?

Direct, honest communication cuts down on the need for rituals and ceremonies such as a daily standup meeting, or grouping work in two week batches.

Often, when I speak to managers of tech teams, they say the main point of two week sprints is to offer transparency to the leadership above them about what progress can be made during the next 2 weeks. But if you have the guts to put your own reputation on the line, then you don’t need any rituals to justify how much work is getting done — either you are happy with the amount of work getting done, or you are not happy. And if you are unhappy, then either you have a plan to improve the situation, or you don’t. And so, either you’re comfortable asking the top leadership to trust you, or you’re not.

What if the top leadership is unhappy with the amount of work that is getting done? You can invest your energy into systems of documentation, to try to prove to the top leadership that you should not be blamed for the problems that are occurring. But is that truly agile?

What is truly agile: you go for a long walk and decide in your own mind what you believe: is the tech team doing well or poorly, is the top leadership seeing things incorrectly or correctly? And then you can go back and have a meeting with the top leadership and you can do one of 3 things:

1. argue that the tech team is doing very well, and therefore the top leadership needs to scale back its goals or authorize the hiring of more people

2. argue that the tech team has performed poorly, but you have a plan for turning the situation around

3. argue that the tech team has performed poorly, and you have no idea how to turn the situation around, therefore you are offering your resignation

Choosing one of these 3 options is more in the spirit of true agility than trying to build systems of documentation and tracking, if those systems of documentation and tracking are only being built to shift the blame away from you.

Of course, it takes courage to risk your own career. And this brings up a fundamental truth: real agility depends on people having courage to do the right thing. There is no substitute. Daily and weekly ceremonies will never offer the kind of flexibility and speed that a company can get by hiring people who have the courage to do the right thing — people who will plainly state what they know to be true even when they know the truth of the situation is going to disappoint the top leadership.

To the extent that two week sprints serve a mostly political goal, I’d rather address the politics directly. I expect people below to reach out to me directly when they have something to say, and I do the same to the folks above me.

None of this precludes tracking how much work is being done every week, or every two weeks. If the work is being tracked in a tool such as Jira, it is still possible to add up the number of points that are being done each week. Nothing that I say here suggests that I’m against gathering metrics and trying to improve those metrics. But many of the rituals that are currently advocated for Agile development processes waste time on meetings that could more easily be worked out informally in a series of quick one-on-one conversations — a style that is actually agile, rather than burdensome and officially Agile.

In general, meetings that waste time should be reduced to a minimum. Conversations that have specific purposes should be encouraged. Large group meetings should be reduced, and one on one meetings should be favored. This style has worked well me over the last 20 years that I’ve been doing this.

This blog post is getting long despite my effort to keep it brief. This is a huge topic. If you’re interested in further details, nuances, contradictions, and exceptions, I wrote about all of this in my book “One on one meetings are underrated, group meetings waste time.”

Post external references

  1. 1’t-believe-in-sprints/
  2. 2
  3. 3
  4. 4