Skip to content
Agile software development without all the burnout.
Branch: master
Clone or download
davebs Merge pull request #19 from adolfont/master
Brazilian Portuguese translation
Latest commit 8d86c91 Apr 8, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
portuguese Update portuguese/README.md Apr 8, 2019
spanish url fix Apr 5, 2019
README.md
agile_lite_for_developers.md
agile_lite_for_managers.md
faq.md

README.md

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 and 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 the planning week off to allow their brain 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.

That's pretty much it. The system doesn't really prescribe engineering practices and I think that's ok. Engineering practices can be defined at a per project level.

Support work is done on a rotating basis because sometimes things do happen unexpectedly and need to be dealt with, but a surprising number of issues can wait until later.

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 managers

Frequently Asked Questions


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

You can’t perform that action at this time.