

What they don’t tell you about Agile - handler
https://medium.com/what-i-learned-building/5ce4e0318eea

======
mindcrime
The "take a break" thing is crucial, IMO. I know it's only an analogy, but
think about it... in "real life" you can't sprint, sprint, sprint, sprint,
sprint, sprint, ... forever and ever. You have to stop and take a breather
every now and then.

Personally I don't even like the term "sprint" in Agile methodologies and try
not to use it. I prefer "iteration" anyway, because it doesn't carry the same
connotation of absolute, balls-out, do-or-die effort, which can actually be
harmful.

But regardless of what you call the time-boxed increments, I prefer to never
have more than three in a row that are done in full-on "sprint" style.
Ideally, every 4th iteration or so, would be a "light" iteration that A. lets
everyone catch their breathe, and B. gives some time for taking care of the
"loose ends" that otherwise fall through the cracks. Stop (or at least slow
down), look at the big picture, look at paying down technical debt, and don't
work yourself into an early grave. If you're a team leader, take one day off
during the iteration and take the whole team out to see a movie or something.

------
andremalan
I think the sprinting analogy is a good one. I think the biggest piece to take
into account is that the harder you sprint, the longer you need to rest. I
think just like a good coach, a PM needs to play with the sprint/rest/slow
cycles until they get to a cadence that pushes, but does not hurt the team.
Also, as with running, as the team adapts, the cadence can and should change
to better suit their progress.

