Everyone who has worked with me knows that I'm not a fan of Agile. I'm not a fan of the philosophy, the religion, or the self-indulgent arrogance of the manifesto. And in many ways, the die-hard fans of Agile are worse than Agile itself. I mean, come on people. We do work; we get paid for it. We're not that special. We don't need a manifesto any more than leaf-cutter ants do.

But for once, I'm not writing about what's wrong with Agile. I'm deeply grateful to all my friends and colleagues who have been so patient with me over the last 15 years while I constantly point out the problems with it. But I've always been stymied when asked what to do instead.

I have a response now that's been baking in my head for a while. Interval Training, but for work. I'm not going to go deep into the analogy about High Intensity Interval Training or whether it's more healthy than sprinting or whatever because all of these abstractions break down pretty quickly when you put any pressure on them whatsoever. Also, HIIT might actually be worse for you than sprinting. I have no idea. That's not the point.

The point is that it is a way to get work done reliably and consistently and humanely. Without all the pretentious fuss about pretending we software nerds are more important than other people.

I'll describe the attributes of the cycle first and then explain why each of them are important and why they work.

• The cycle is 3 weeks
  • 2 weeks high intensity; 1 week cool-down
• The cycles begin on Tuesdays
• All work stops at the end of the 2 week High Intensity exercise
  • Unfinished work, even if close, goes back into the backlog for review
• Maintain and groom a backlog every week with the whole team
• Break tasks down into no more than 1 day of work
• There are 10 working days in a HI exercise. Assign 10 days of work.
  • This is more than is going to get done. That's good.
• Have a formal check-in half way through the HI exercise
• The check-in discusses status, not progress
  • Status is defined by risk, not effort
• At the end of the HI exercize, project work stops
  • If it's not done, it goes back in the backlog
  • Clearly define "done" for your team
• Retros are about the work process, not the work
  • Do have them
  • Talk about what went well
• Netros are considerations of what went wrong
  • Cordon off the negative meetings
  • Talk about what didn't go well
• The last week is cool-down. Planning, designing, researching, architecting
  • Vital for the next exercise to get off to a good start
  • No project work; only project planning and design

Okay, so let's start at the beginning. Why do I say these things? Why do I think they work?

The cycle is 3 weeks

I've seen things you wouldn't believe . . . . No, not going there. But I've seen Agile sprints from everything to a daily cadence to 6 weeks. I think 3 weeks is the sweet spot because I like the 2:1 ratio of busting ass and planning ass. It's also around the upper limit of what non-technical executives will tolerate. If you tell a CEO that your team goes hard for 4 weeks and takes 2 weeks to recover, you'll get your head bit off about the lost productivity. The 3 week cycle is also small enough to be nimble and responsive to any shifting priorities in the larger organization. But most importantly, you can plan the next cycle during your current cycle while you breakdown the backlog.

The cycles begin on Tuesdays

Why? Work begins on Monday. Why shouldn't your cadence? Because no one should ever put deadlines on Mondays. And the end of a cycle is a deadline. When you put deadlines on Mondays, people do not take their weekends off. They stress, they fret, they try to make things better because Monday is the end of the road for thing x that they are heavily invested in. People do not get the rest and distance from their work that they badly need, not only for their own personal health, but also for the great advantage that comes with distancing yourself from your work for a couple of days.

It seems like it's not a big deal to shift things by one day. But it is really a huge deal. You aren't just giving people an "extra" day. You are giving them 3 days of their life back by doing this instead of stealing their weekends. Over a 3-week cycle across 3 weekends, that's 3 cycles of engagement, withdrawal, fresh engagement. That is incredibly powerful.

All work stops at the end of the 2 week High Intensity exercise

This should probably not be phrased this way. People still work. It's just very differently focused. The meaning is more specifically that task and project work are halted. Anything not completed automatically returns to the backlog. This is an automatic action and a blameless one. No one needs to have a meeting about how or why X task wasn't completed. It wasn't. That's the end of it. Because we tried to do more than we were able to do from the beginning. On Purpose.

Maintain and groom a backlog every week with the whole team

This is critical for people to understand priorities and the relationship of their work to the rest of the company. People operating in a vaccuum don't understand their role. Managers might hopefully understand it, but that doesn't mean indvidual contributors do. Pretending that some people are exempt from these meetings because their time is more important is stupid and counterproductive.

These meetings are about prioritization and about people who are not in the loop getting into the loop. These meetings are for uncovering things that people are not aware that were hidden.

Break tasks down into no more than 1 day of work

If a task isn't so clearly defined that it can't be done by someone, with certainty, in a perfect scenario, in a day, the task is not clearly enough defined to be assigned. Break everything down to the level of 1 day of work. Does that mean it might take 2 days? Sure. But that's not a problem. We don't care about how long it takes at this phase of planning. We care only that it is well enough defined so it's possible to do it in a day.

There are 10 working days in a HI exercise. Assign 10 days of work.

I've seen no end of bulshit from the Agile-Scrum-OverNerds about this self-contradictory bullshit.

"Story points aren't about time!" "Agile isn't about time! It's about effort!" "I think I peed my pants while I was giving this training session! Isn't that great?!"

Also, "We have to be careful about our time! Meetings! Time off! Sick days!"

"So really we should just be assigning about half a day's work for every engineer for the entire sprint. Because effort has nothing to do with time. Obviously"

Fuck that noise. It's so transparently stupid and also incredibly hostile to business management. Businesses are governed by contractual obligations and financial transactions. They are not governed by Agile bullshit. No matter how much you paid for his consulting fees.

This is a fundamental fact of life: tech teams are mountains of uncertainty, and businesses run best on certainty.

Assign the work. Fill up the docket. Prioritize what's needed (that's the whole point of the mid-cycle check-in), cut anything that's not. Expect to not get everything done.

Every minute of your life that you're being a fucking Python genius is a minute someone at the company that pays you to be a Python genius is signing a contract that you are inherently responsible for. That's not a bad thing. That's a reason to get myself off my high horse and do the work every day and earn my pay.

If there is one single identifiable truth in the universe it is this: there's always more work to be done than there are people who are qualified and willing to do it.

We are never going to get all the work done in a cycle. Accept it. But try to achieve it if you can. What's leftover is stuf that might not have been that important anyway. But if we did our jobs right earlier and broke the tasks down into 1-day segments, this should be easily corectible if it is a problem.

Have a formal check-in half way through the HI exercise

I'm not big on rituals, in case you couldn't tell. But this one is important to assess risk. What's first and foremost is the risk of the person who's working on the thing. Is it driving them mad? Are they working weekends because they don't feel good about where they are? Are they not getting enough sleep or rest or enough time to just be human? Are they putting their family aside because of company pressure?

Figuring all that out is the purpose of this meeting. And the meeting is blameless. It's all about de-personalized risk. That's why we only talk about

Status

Status is not about where an IC is on a task. It's not about "progress." Status is all about what is the risk item X won't be done. What is the risk to the project, the team, and the company? This is about shifting people around and moving priorities up and down, and that's all.

At the end of the HI exercize, project work stops

I know I sort of covered this earlier, but it's worth repeating. If you allow project work to continue after the drop-dead date, people will continue to work all the way to the end of the week, take no downtime, and get frustrated and burnt out.

If any ticket isn't done at the end of the HI exercise, the ticket automatically goes to backlog. No questions, no excuses needed. Everything is re-evaluated for the next sprint.

Retrospectives are about the work process, not the work

The work was either done or not done. It's not worth talking about as a team. There may be cases where a manager sees a pattern and need to intervene, but that is not what the retro is about.

The retro asks one question of all the people in the exercise: what could we do better?

That's it. It's actually not the right place to talk about what went wrong during a work cycle.

Netros

The good and bad meetings need to be segregated from each other because the bad news bears tend to dominate and not really be all that helpful (I know because I'm that guy). But have the meeting! Otherwise the disgruntled assclowns like me will feel like we aren't being heard.

The last week is cool-down. Planning, designing, researching, architecting

I think this part is pretty self-explanatory. You actually take cool down time and don't have any deadlines. That doesn't mean work isn't getting done, just like taking a weekend off doesn't mean work isn't getting done.

We're all very smart people, and we're always working on stuff somewhere in our minds. But we're also human, and we all need to catch a break every once in a while.