If you've been working in the software industry for more than a few years, you've quite possibly experienced burnout. There are many reasons for burnout, but it can most simply be described as the result of working too much, under too much stress, for too long.
It starts with a project. That project has a detailed specification and a deadline. When the specification changes, the deadline does not. Eventually the deadline comes and goes and the spec has turned into something different from where it started. Of course, this is seen as your fault, and you are asked to stay late or to commit to "stretch goals". Eventually you're coming in every weekend and no matter how hard you work, your manager is never happy and the project is perpetually "behind schedule".
Wanting time off or vacation makes you seem like a slacker. It makes you seem like you're the one holding up your team. Perhaps you work in an open office environment; everyone knows when you get there, everyone knows when you leave, and everyone signs an unspoken contract to not be the person that's not working the hardest. So people get good at looking busy, and whenever someone asks you how you're doing, you just reply, "Busy! I'm SO busy!"
But eventually something gives. Maybe you change jobs, but it's more of the same at other companies in the software industry. Maybe you stick through it until there's nothing left and then the company lets you go because you're just "not a culture fit". Maybe you quit and take a job selling cars because programming is just too damned frustrating. As they say, if you want to kill the joy in a hobby, try doing it for a living.
I'm proposing a solution. It's a form of agile that's explicitly designed to help avoid burnout. I call it Agile Lite.
-
The most basic rule is this: Every cycle includes a 3 week sprint and 1 week "off" where sprint planning is done. 3 weeks on/1 week off.
-
A sprint contains Issues and engineers solve Issues, logging pertinent questions and updates to the Issue Tracker.
-
Once a sprint has begun, Issues may not be added to the sprint, but they can be removed. This reduces context switching and that is a good thing.
-
An Issue is any unit of work that should take 4-8 hours of engineering effort. An Issue is either in the current sprint or in the backlog.
-
Any Issues in the current sprint that are not completed by the end of the sprint are reviewed during the 1 week of sprint planning.
-
There is no working overtime. There can be no death marches. Engineers are put on a regular cadence of work and allowed sufficient time to recharge their brains. Management overhead is minimal.
That's pretty much the whole system. It can be modified to suit your purposes. But if there's one differentiator to Agile Lite I'd like to point out, it's that we are explicitly saying, "Hey, agile teams are burning out just as much as other development methodologies, maybe we need to build explicit rules in to prevent overheating the engine that is the engineering team."
Let's stop overheating our engines. There's plenty of work to do out there. A pit without bottom, in fact. But life is too short to spend it all working, stressed, and ultimately burned out.
If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility. Dave Sullivan 2019 [email protected]