For “you” in this document, read “you and your team”.

I link to some interesting reading on some of these anvils, but mostly I don’t. These are things I generally take as facts about the world, with the usual squishy “it depends sometimes” about some of them. I use agile methodology language, mostly, even though I like to say I really hate agile processes. Do I hate agile? Really? Let the anvils commence!

Don’t let people outside the team assign work to the team. They may propose work, but you decide if you accept that work.

The rate at which you accept work must be less than the rate at which you finish work, or you will have infinite work.

Operational incidents and meetings count as work.

Bug-fixing counts as work.

Don’t accept work that you don’t understand. “Figure out this project well enough to estimate it” is acceptable work, as is “cooperate with a product designer to get design documents into a state where they describe acceptable work”.

Only rarely should you say no outright to work. If it’s not well-defined, push to define the work better. (Unclear requirements make for misery on both sides.) If your team has too much work already, push for prioritization. (Something has to give. It will always give in reality, whether people admit that in advance or not.)

Sometimes you need to communicate the consequences of your team taking on disruptive work and let your customer decide if the cost is worth it.

Technical design and research counts as work.

Estimation counts as work. The more time you spend on accurate estimation, the less time you spend on other work, such as implementation. This is often worth the time anyway, because sometimes the business needs it.

Tools are not a substitute for communication.

One point of the retro is to figure out what your true rate of finishing work is. If you finished less than you took on, then next time take on less work. If you finished more, cautiously take on a little more.

You probably do not spend enough time doing retros and planning for your next sprint. One hour every two weeks isn’t enough.

The more you understand the work, the better you do estimating it.

Corollary: You do best estimating work very similar to work you’ve done before. ¹

Another corollary: Estimates you make at the start of a project, when you know the least about it, are the most likely to be wrong. Build in feedback loops for estimates! Communicate with your customers as estimates change.

Don’t let your early estimates get turned into deadlines.

Sometimes the business itself has deadlines. Frequent delivery of working software is a survival tactic for deadlines.

Sometimes you get it wrong. Use the retro to figure out what you can learn from the mistake. Remember, the map is not the territory. Sometimes that clearly-marked trail turns out to have been destroyed by a mudslide.

High-uncertainty projects dominate software schedules. The thing that’s late because the trail was washed out ends up making everything late. Maybe it was worth an advance scout? ²

If hitting a date you provide matters, invest time in lowering uncertainty.

Fred Brooks spoke truth about how communication overhead dominates work. Most complex software work can’t be parallelized or sped up the way businesses want to speed it up.

The fastest way to get projects done is to have an aligned team take on chunks at their own pace, without doing any planning other than technical planning. Nobody likes hearing this, but it’s a consequence of the overhead of estimating and bookkeeping.

Agile™

Agile™ as practiced has little to do with the original principles of the movement. Those original principles might be summarized roughly as:

• You are building things for a customer. Talk to your customer.
• Deliver frequently.
• Build in feedback loops so you can figure out what you’re doing that’s working and what’s not.
• Let teams self-organize. Trust them.
• Change is inevitable, so plan for it.

I wrote those points off the top of my head, so I went to the original to see how well I did at capturing its spirit. Not bad! This is what the Agile Manifesto says. Go read it! It’s short! Then weep at how far we have strayed from it. Also note what isn’t there: any rigidity about sprint lengths, planning poker, burndown charts, anybody other than the team itself deciding how to do things. It sounds pretty sensible to me, to be honest. (Maybe it’s only Agile™ that I dislike?)

What I also like about that original manifesto is the focus on sustainability. “Sprinting” isn’t mentioned. Communication sure is, though, and I’m 100% aligned with that. Talk to people involved in the project. Frequently. Even about bad news. ³ It’s all about the communication.

And as you know, communication has its own overhead. I point back at Brooks, who says there’s no silver bullet.

Did I have a thesis?

Mostly I wanted to write down some things I take as fact about planning and estimation that are often at odds with how software organizations behave. I’ve been itching whenever I hear about teams “doing agile” or “getting scrum training”. My theory is that processes are never one size fits all. You can’t be dogmatic about them. Teams vary, and so do projects. Some teams write a lot; some teams talk a lot; some teams demo a lot. Some teams pair; some teams mob program. What’s more, teams vary over time even when their membership is mostly stable, because people change and learn.

The best process for any project is probably one you design in the moment for the team. You never have to do this in a vacuum, because there are lots of good processes to steal from, and your team is probably doing some set of things already that are effective for them.

Dogmatic adherence to a half-understood Agile methodology probably ain’t it. So go back to the original! It’s pretty good.