A flexible development methodology is a great idea that is too complicated. Agile Lite - an attempt to simplify the situation. You do not need books or workshops to explain Agile Lite. All you need is a small text with a few paragraphs. Here is the text.

Agile Lite is pretty simple. It can be applied to any project, provided that the work is divided into smaller tasks (issue). Like other flexible methodologies, it uses short development cycles - sprints. But unlike them, Agile Lite explicitly recognizes the prevalence of burnout in the software development industry and tries to mitigate it directly by implementing the “three weeks of development / one week of rest” cycle.

Fundamental rules:

• The first week of each cycle, project managers, developers and other interested parties determine the upcoming sprint. Although the week is highlighted, sprint planning will take no more than two hours, and with the right organization, it will take about 45 minutes. This is a deliberately easy week: many may just take a vacation to surf, paint or something else.
  
• Sprint passes in the remaining three weeks. During this period, engineers work on the tasks assigned to them during planning. Since employees can be remote and distributed across time zones, live meetings occur infrequently, and most of the communication goes through the tracker (which is faster than email). A common Kanban board like Trello is quite suitable, and a spreadsheet is unlikely. Daily scheduling is not encouraged: the overall pulse of the project is fully monitored by the tracker updates.
  
• After the start of the sprint you cannot add tasks to the sprint, but you can delete them. This reduces context switching, which is good.
  
• Incomplete tasks are considered at the next planning session of the sprint - and it is decided to move the task to the next sprint, return to the wish list or reassign to another developer.
  
• Each task is either in the wish list or in the current sprint. Each task should take 4–8 hours to complete.
  
• As already mentioned, developers are recommended to rest during the week of planning so that the brain can recover from the previous sprint. This is not a crusade. Developers do not work on weekends. All this helps to avoid burnout, which is useful for all.

Although the main work in the sprint can be planned, sometimes something unexpected happens. These unexpected issues are called Support Issues.
')
During the planning of the sprint, we propose to allocate time for solving support problems that are not amenable to planning. For example, “during the next sprint, Dave is given 12 hours to solve support tasks (the details will be determined later).” It is often useful to support the rotation, where on each sprint the developer (s), responsible for support questions, change.

To improve forecast accuracy, the amount of support work actually performed in the previous sprint is analyzed at each planning session of the sprint, and it is decided whether it takes more or less time to support the next sprint.

In practice, different groups have different definitions for support tasks. Perhaps this means customer support. Perhaps the support of other developers. It is up to you to decide which elements of this general methodology are best for your team.

By eliminating unnecessary complexity, Agile Lite is the best, more sustainable way to develop software. It helps in development while providing a consistently high level of performance.

Agile Lite for developers

If you are not new to the industry, you may well have experienced a burnout. It has many reasons, but the easiest way to describe burnout is the result of working too hard under too much stress for too long.

It all starts with the project. Each project has a detailed specification and deadline. When the specification changes, the deadline is not. In the end, the deadline comes, and the specification turned into something different from where it started. Of course, this is considered to be your fault, and you are asked to stay up late or make a “goal stretching.” As a result, you work every weekend, but regardless of your efforts, the manager is always unhappy, and the project is constantly “behind schedule”.

Wanting to take time off or leave, you seem like a bum, who does not support the team. Perhaps you work in an open office; everyone knows when someone comes and goes, and everyone signs an unspoken contract to work less than others. Therefore, people are well able to look busy. When someone asks how are you, you just answer: “Busy! I'm so busy! ”

But in the end something happens. You may be changing jobs, but these are usually other companies in the software industry. Maybe you give all your strength to complete devastation, and then the company releases you, because you are no longer “fit for culture”. Maybe you quit and start selling cars, because programming is too frustrating. As they say, if you want to lose the pleasure of the hobby, try to earn on it.

I offer a solution. This is an Agile form that is clearly designed to avoid burnout: Agile Lite. There is no overtime work. Engineering work put on stream, and the developers have enough time to recharge the brain. Overhead management costs are minimal.

Almost the entire system is described in six points above. It can be changed according to your goals. But I would like to highlight one feature of Agile Lite. Here we clearly say: “Hey, flexible teams burn out just like other development methodologies. It may be worthwhile to state explicit rules to prevent the engine from overheating, which is the engineering team. ”

Let's stop overheating the engines. We have a lot of work. In fact, it is a bottomless pit. But life is too short to spend on work, stress, and ultimately burnout.

Agile Lite for managers

Have you had problems with developers in your company? Projects often missed deadlines? Have you worked with developers who start out fine, then slowly degrade and then disappear? Perhaps this is a talented programmer who has experienced burnout.

Burnout is extremely common in the software industry and is a key reason why many software projects fail. Burnout can best be described as the symptoms of post-traumatic stress disorder associated with this project or organization. For example, the brain seems to be turned off and you are extremely anxious at the mere mention of a certain project. This is burnout. A developer in this state, most likely, will not be able to continue working on this project, and in subsequent projects will not be able to work at full capacity. Burnout can cripple a career.

This is similar to running a car engine at high revs for a very long time without adding oil or fuel. In the end, this engine will break down and it will be difficult to assemble it back.

The basic principles of the Agile Lite system are described above and are subject to change according to your goals.

FAQ + typical statements

The only general rule in the agile world is that everyone does it wrong. @fwip

So, engineers get 12 weeks of vacation per year for surfing and painting? How will this work in a world where working from 9-00 to 21-00 six days a week becomes the norm?

I think your developers should rest as much as they need.

I note that the 40-hour work week was once considered a radical idea. Google started with 80% of the working time for major projects, now we have 75%, I would like to reduce it to 10% (Ferris method) by the end of the 2020s.

System 996 (from 9 am to 9 pm 6 days a week) is the opposite approach, which seeks to extend the 40-hour work week to 72 hours. I see this as a setback and I think that we should stop making overtime fetish. In fact, it does not give an increase in productivity.

In addition, you decide what to do during the "week of rest": go on vacation, assign a lighter workload or something else. The answer may depend on the specific week.

Maybe “easy week” is easier for people than “week of rest”. Use what you prefer.

Surfing and painting are by no means obligatory, they are given just as examples. I myself do not even surf and paint.

People are assigned tasks or do they predict what they will get?

They predict. It's okay if your estimates are wrong. This is part of the process, and all on the same team.

Can this be called iteration instead of sprints?

Of course! "Sprint" is suitable for me personally.

Is it possible to do a sliding iteration in the kanban style, where the start and end dates vary and depend on the circumstances?

I really appreciate the concept of a work cycle with defined start and end dates, and defined by a single block of tasks. Sliding iterations that are not synchronized with a particular cycle will spoil it.

Why exactly three weeks of sprints?

Because development plus restoration is placed in 13 slots per year. When the cycle is finished, a new one begins. Week "rest" allows you to reboot before starting a new sprint. It is about achieving cadence and clear, consistent intervals.

Does this mean that the start and end dates of sprints often fall on the middle of the calendar month?

Yes.

Are developers involved in sprint planning?

Yes. They are not forbidden to attend the meeting. It's just not necessary, especially if the task tracker works well, and the team discussed some of the points for the next sprint during the previous one.

I am for fewer meetings. They are very few people like. If you are one of those, then do not count on me.

Does it take a week to plan a sprint?

No, that's the thing. This is an easy week.

Are stand-ups really a problem?

In my experience, yes. Usually everyone stands in a circle, listening to one person for 20 minutes. Of course, this is the “wrong” approach, but I have never seen anyone do them correctly, and would prefer to completely abandon the daily planners. More difficult (or at least inconvenient) to carry them out when your team is geographically distributed. But if they are very valuable to you, do not let me stop you.

Should we do it this way?

Not. Nobody forces you to anything. These are recommendations, not rules.

This is not a religion.

These rules are political only in the sense in which the propaganda of the 40-hour work week was political.

What works for you may not work for others. Do you know about this?

I am sure about that!

Frequent statements

No need to make predictions on the timing, because estimates are impossible.

Forecasts are considered to be forecasts, not contracts signed in blood. Therefore, if they are not respected, it is normal. Make every effort and try to make a forecast in 4-hour increments.

Developers cannot be trusted, and you need to keep track of all their time, because this is how work is done.

I really disagree, but I cannot quickly explain why. We have fundamental differences in worldview.

This is not Agile.

Of course Agile, he's right in the title.

It is unreal.

And yet it works.

You are doing agile wrong.

Unfortunately, the problem with Agile is that it cannot be done correctly.