AgileLite

KO | EN

gitlite — search

#ai #typescript #llm #golang #go #android #linux #nodejs #cli #awesome-list #vue #ios #openai #mcp

(★ 2,074)

Agile software development without all the burnout.

File Explorer

Download Latest Version (.zip)

- agile_lite_for_developers.md
- agile_lite_for_managers.md
- faq.md
- README.md
- agile_lite_for_developers.md
- agile_lite_for_managers.md
- faq.md
- README.md
- agile_lite_for_developers.md
- agile_lite_for_managers.md
- faq.md
- README.md
- agile_lite_for_developers.md
- agile_lite_for_managers.md
- faq.md
- README.md
- agile_lite_for_developers.md
- agile_lite_for_managers.md
- faq.md
- README.md
- 01.jpg
- agile_lite_for_developers.md
- agile_lite_for_managers.md
- faq.md
- README.md
- agile_lite_for_developers.md
- agile_lite_for_managers.md
- README.md
agile_lite_for_developers.md
agile_lite_for_managers.md
faq.md
README.md

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Agile Lite: Agile without all the burnout

"Agile software development" is a great idea that's been overcomplicated by the publishing and consulting industries. Agile Lite is an attempt to simplify the situation. You do not need a book or a workshop to explain Agile Lite. You just need a text file with several paragraphs. This is that text file.

Agile Lite is pretty simple. It can be applied to any project with people working on it, assuming that the work can be broken into smaller component tasks that we'll just call Issues. Like other agile methodologies, it utilizes short development cycles called Sprints. Somewhat uniquely, Agile Lite explicitly acknowledges the prevalence of burnout in the software development industry and attempts to mitigate it directly via a 3 weeks on/1 week off development cycle.

The basic setup is this:

* The first week of each cycle is spent with project leads, developers, and other stakeholders defining the upcoming `sprint`. Despite a week being allocated, a sprint planning session should take no more than 2 hours and probably about 45 minutes if done correctly. It is an intentionally light week and many people may simply take the time off to paint or surf or whatever.

* The `sprint` takes place during the remaining 3 weeks of the cycle. During this period, engineers will work on the Issues that were allocated to them during the sprint planning sessions. Because the team may be fully remote and distributed over time-zones, "live" meetings happen infrequently and most communication happens through the `issue tracking system` (which is faster to work with than e-mail). A shared kanban board like Trello is a sufficient issue tracking system, but a spreadsheet is probably not. Daily standups are discouraged; a basic pulse on the project can be obtained by reviewing issue tracking system updates.

* 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.

* Issues that are not completed during the sprint are reviewed at the next sprint planning session and it's decided whether to move the Issue forward into the next sprint, put it back in the Backlog, or reassign it to a different developer.

* An issue is either in the `backlog` or in the `current sprint`.

* As mentioned, developers are encouraged to take it easy during the planning week to allow their brain time to recover from the previous sprint. There are no death marches. Developers don't work on the weekends. This all helps avoid burnout. Avoiding burnout is good for everyone.

While most work in a given sprint can be planned, sometimes things do happen unexpectedly. These unexpected issues are called `Support Issues`.

We suggest allocating time for unplannable Support Issues to certain members of the team during sprint planning. For instance, "Dave has 12 hours during the next sprint that can be allocated to support issues (the specifics of which will be defined later)." It is often beneficial to have a rotation where the developer(s) in charge of support during a given sprint will change each rotation.

To increase estimate accuracy, at each sprint planning session, the amount of support work that was actually done in the previous sprint is reviewed and it's decided whether *more* time or *less* time is needed for support work in the next sprint.

In practice, different teams have different definitions for support work. Perhaps it means to support the customer/clients. Perhaps it means to support other developers. It is up to you to pick and choose which elements of this general methodology apply best to your team.

That's pretty much it. Agile Lite is a better, more sustainable way to develop software. It empowers software developers while delivering a consistently solid level of productivity to project stakeholders.

To learn more about Agile Lite, I encourage you to read:

[Agile Lite for developers](agile_lite_for_developers.md)

[Agile Lite for managers](agile_lite_for_managers.md)

[Frequently Asked Questions](faq.md)

---
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 dave.brian.sullivan@gmail.com

AgileLite

File Explorer

Today's picks

Was this content helpful?

Recent Feedback

AgileLite

File Explorer

Today's picks

Was this content helpful?

Recent Feedback

Download README