
Agile Lite: Agile without all the burnout - dave_sullivan
https://github.com/davebs/AgileLite
======
sailfast
As a developer, seeing another developer suggest that they just take a
vacation and leave the project leads and stakeholders to talk about what
should be done in a month is really weird.

That will not lead to the absence of a death march - it is a recipe for a
death march. Not only will you not have an accurate assessment of the tasks
but they will not be ordered correctly, and likely way overscoped for the
timeframe, and you get no chance to say no. Technical minds / engineers in the
room early and often is critical to success - otherwise you’re just told what
to do instead of architecting it the “right” way.

Communicate when you need to but try it all for a sprint or two (really,
Standup is a hardship? You may not be doing it quite right), then drop after
the team finds a rhythm.

Edit; after reading the author’s other works the burnout seems to be centered
on a big push from stakeholders to accelerate and keep going so a sprint is
seen as a reset - kinda like a new day dawning in a news room. You can plan-in
your work to avoid this and still continue to make progress but it does take
some discussions with leadership, or at least a clear justification about why
this week is exploratory instead of hands-on. Done it many times. I would not
suggest changing the whole method just to accomplish this, however - a process
fix for a problem like this won’t necessarily help.

~~~
phillc73
I'm not sure the author is advocating for no developer presence during the
planning period.

> The first week of each month is spent with project leads and stakeholders
> defining the upcoming sprint

At the very least, I'd suggest that developer leads or engineering managers
are stakeholders and therefore involved. They should be liaising with their
development team (also stakeholders) during the planning phase.

Perhaps this sentence is overstated:

> It is an intentionally light week and many people may simply take the time
> off to paint or surf or whatever.

People should perhaps take SOME time off to relax, but likely not the whole
week.

~~~
addicted
I agree. I didnt read that as an invitation to take 5 days off every month,
therefore advocating 60 additional holidays in a year.

I saw it more as an opportunity to catch up on "other stuff". Maybe a tool you
wanted to work on to make your work life easier, or leave a little early to
wrap up taxes, or do some PoCs etc. to see whether a refactoring idea you have
is actually feasible or not.

~~~
dave_sullivan
Yes, this is more along the lines of what I'm talking about. I'm advocating
common sense over religious adherence. Do what works for you.

I am saying there's a lot of burnout in the tech industry and it's at least
partly a process problem.

Maybe it's just me and I'm "doing it wrong", but I think it speaks to the
issue that the suggestion of "taking it easy a week out of every month" is met
with cries of "This is madness! It will never work!"

~~~
ebiester
You may want to look at some of the arguments for "slack" in agile. Other
agilists have thought about this from various angles, from scheduling it via
WIP limits in kanban to dedicated 1-2 days at the end of a sprint. You're not
"painting or surfing or whatever." At the same time, you can't capitalize
that, and capitalization drives a large portion of IT.

------
EngineerBetter
If you're getting burnout doing agile, you're doing agile wrong.

Don't do sprints. Have a continuous backlog. Don't do overtime. Don't make
estimates. Always do the simplest thing. Only ever do the most important
thing, as defined by the stakeholder.

I've written and talked about this at great length. The fact people suggest
agile gives you burnout reinforces my experience that Scrum is largely
misinterpreted and people incorrectly focus on sprint commitments. If Scrum is
so commonly misinterpreted, it is flawed.

[https://www.linkedin.com/pulse/scrum-makes-you-dumb-
daniel-j...](https://www.linkedin.com/pulse/scrum-makes-you-dumb-daniel-jones)

[https://youtu.be/k9duArRuSjQ](https://youtu.be/k9duArRuSjQ)

~~~
Scarblac
The business wants to know how much feature X is going to cost and when they
can expect it.

They need to know that, because they need to decide if it's worth it in the
first place, or because they need to plan follow-up actions for when the
feature will be done.

If the developer doesn't make estimates, you're just forcing other people to
make their own estimates, that they'll hold you to.

~~~
RandallBrown
Nobody should make estimates. They're _always_ wrong.

Do your best to break tasks up so that all tasks are the same size. Then work
on tasks. You'll find a stable average of tasks per amount of time and that
will let you forecast how long things will take, how much they'll cost, etc.

That's how you figure out when things will be done.

~~~
aplummer
Don’t make estimates, make... forecasts?

~~~
pugworthy
This kind of word game in agile drives me crazy.

It’s like points aren’t hours, but if I estimate (er, forecast) how many hours
it will take, its pretty easy to turn that into points, and vice versa.

I suppose it’s like one of those, “There is no word for it in English, but it
essentially means...”

~~~
pas
Points are a team-internal measure of a task. You can after the fact convert
points to time, and then after a few sprints (when you have a fairly stable
average velocity) _then_ you can convert points to hours and do a
forecast/estimation.

// In my mind you forecast the date of completion, but you estimate the amount
of work. It's probably just mindless semantics, after all saying you can
estimate the date of completion sounds just as natural, but saying you can
forecast the amount of work sounds a bit unnatural.

------
PaulHoule
The key thing people miss about agile (and project management in general) is
that you have to tune the process to the situation.

If you look at the PMBOK (Project Management Book Of Knowledge) it is really a
comprehensive list of all the things you might have to think about while
running a project. All of them are relevant to every project (e.g. hiring,
communicating with the public) but some need a lot of attention for some
projects and others don't.

I've worked on "A.I." projects where the sprint involves running a batch job
that might take two days if it all works right. If it doesn't work right you
might have to retry a few times.

When I was in charge of that batch job I would start it as soon as possible,
sometimes with a week and a half to spare. Whenever somebody else was in
charge of it they would start it with half a day or a day to run and we would
blow the end of the sprint.

I blame the continuous stream of "urgent but not important" communicates
generated by agile for that.

The timeboxing of planning is also a very bad idea. I worked at a place where
we had a timebox of 2 hours for planning but really after that we were nowhere
near a realistic plan for the sprint and it would take another 2 or 3 days of
knock-down, drag-out meetings that would leave us all exhausted to understand
what we had to do. After that the work was mostly downhill, at least the way I
saw it, but one of the other team members would consistently burn the midnight
oil at the end.

Often agile "teams" have a "normalization of deviance" situation where they
have to do one thing (or say they are doing one thing) so they can say they
are sticking to the process, but actually do something entirely different to
get the job done.

That's sad.

~~~
erikstarck
This.

That is why the retrospective meeting is at the heart of agile. A truly "agile
light" setup would be:

Every other week, do a retrospective.

That's it!

On the retro, ask yourself 3 questions (or work with these 3 themes):

1\. Is the way we are working helping us, and the rest of the organization,
make the right decisions and reach our goals in an efficient way? If not, what
needs to change?

2\. Is our understanding of the customer (or whatever system we are trying to
improve) correct or are we basing our decisions on the wrong assumptions? If
so, what do we need to learn?

3\. Do we have a clear picture of where we are going and what we want to
achieve and how that is aligned with the goals of the organization? If not,
how do we course correct or make our progress towards our goals clearer?

There you have it: the retrospective and the 3 dimensions of agile.

~~~
PaulHoule
I would say that retrospectives are the biggest waste in agile in my
experience.

For one thing, retrospectives often come at a time when everyone has been
busting ass for a long time and they just want to go home. If you put it off
till next week then it seems like another distraction.

Like the planning meetings, the timebox for a retrospective is often wrong. In
some cases things went smoothly and there is a little to say. That is where
you should be. In some places you budgeted 45 minutes but there really is a
day worth of material.

On top of that in many (most?) firms there is no sense of psychological
safety. Often the real message is that the process is 99% bull but you can't
say that in a meeting which is claimed to be about continuous improvement but
is really about how to rearrange the deck chairs on the titanic.

In his book "Good to Great", Jim Collins points out the use of the word
"alignment" is a bad smell. In a healthy organization there is alignment,
naturally, built into it. If you feel like you have to paint alignment onto it
after the fact you are just causing more misalignment.

~~~
msluyter
_In some cases things went smoothly and there is a little to say._

Has been my experience (on good teams.) After a while, you tend to gel pretty
well and don't need to spend that much time introspecting. The issues raised
are either generally intractable organizational problems (that'll never get
fixed), or fairly minor, and on several teams I noticed that retrospectives
tended to feel pretty similar after a while (To the credit of the team, at
that point we were like "we probably don't need retrospectives every sprint.")

------
chrismeller
One of my biggest pet peeves is the pointlessness of standups. I have never
worked anywhere where they did not immediately become a status update, which
is (in theory) what the board is for.

Why is the board not up to date? Because we just talked about all of that an
hour ago and doing all of that over again is infuriating. What is the status
of ticket x? Either wait until the next day’s status report/standup or start
writing down notes you can reference. While you’re at it, just go ahead and
put those notes in the comments on the board... oh wait.

~~~
jaequery
I was once a project manager on a team that does daily standups. What
eventually happened was that the team would usually re-iterate what I say, or
vice versa. It made me question what was the point of doing standups.

~~~
jgust
The point of standups is to help teams to learn to communicate and to steer
the team to a habit of working on the most important things. Once that's a
behavior, standups can be less frequent or dropped all together. This is
especially useful for new teams or when the team changes.

~~~
chrismeller
No, the point of standups is to go around in a circle and make sure that
everyone has everything they need to keep working (that there are no
“blockers” in the parlance of agile). That’s why they’re called _stand_ ups -
you’re supposed to stand so that everyone gets annoyed if it takes more than a
handful of minutes.

If you’re discussing what you did yesterday, what you’re going to do today,
when you think x is going to be completed, what is blocking you (other than
that so-and-so owes you such-and-such), or anything else other than nodding
that you’re good you’re missing the point and that’s where the slippery slope
of pointlessness begins.

~~~
Scarblac
But if something is blocking you, you should not wait for the standup to bring
it up, what a strange way of working is that. Just ask someone who can help
you. That's one thing that works well in my company.

Still people also want standups, basically to hear what others are doing and
feel like a team.

~~~
chrismeller
And so we circle back around to the pointlessness of all meetings.

If it is as-needed to hash out an idea or determine the best way to fix
something or to scope and point... that’s fine.

If it’s every day, twice a week, every MWF, etc. there is absolutely no way
it’s actually necessary every one of those times and everyone is _going_ to
eventually defer to human nature and wait for the meeting to bring things up.

Part of that is natural and well intentioned - I’ve got the meeting in an
hour, I won’t bother them yet, I’ll wait for it.

Part of that is natural and self-defeatist - if we already discussed
everything then what will we discuss in the meeting?

The actual solution is to get rid of the meeting. The real solution is to just
wait and discuss it all there. It’s like why I don’t call my mother the day
before I go over to have dinner with her - we’re going to cover it all in the
phone call and it’s going to be awkward silence while we eat.

And finally, if a standup is the best way you’ve found to make everyone feel
like a team... there is no hope. That’s a really, really crappy way to make
people feel included. Though that is what passes for team building at more
places than not...

~~~
Scarblac
I know. I wanted to get rid of our standup as it has no real point. The rest
of the team wanted to hear what people were doing, so it stayed.

~~~
BigJono
I find a good replacement for a traditional agile standup is a board based
one. Rather than going through each person where it feels like you're being
put on the spot individually, you go through each card on the board and ask
what needs to happen for it to move to the next step. 90% of the time it's
going to be one person putting their hand up and saying "I'm working on it"
then you move on, and the other 10% of the time you might actually have a
productive conversation in a meeting, which IMO never happens in a standard
stand-up.

I'm surprised more companies haven't moved to this model. I don't really give
a fuck what Jim is working on today, I just care whether his card that I have
a dependency on is ready or not, or if we need to collaborate on it in some
way. If the team is finding they don't know what's going on, or the board
isn't being kept up to date, then this style stand-up will actually help with
that, rather than just blowing 15 of my most productive minutes listening to
everyone spin some bullshit story about how much work they crammed into 8
hours yesterday and why it didn't perfectly align with what they projected in
standup the day before.

~~~
Scarblac
The thing is that we are ~11 people working on ~20 projects (the largest has
about 2-5 people working on it at any moment, the smallest is worked on a
couple of times per year, all the rest is in between). So without keeping each
other informed there is a lot that goes unnoticed just because your work
_doesn 't_ depend on it.

Going through all tickets would take a lot longer than having an update of all
people so I don't think that will be popular, but I like to look at the
tickets that aren't assigned to anybody yet at the end of most standups so
that we don't lose sight of them.

------
shay_ker
No matter what you do, or what process you implement, if the organization does
not _respect_ engineers, your life will categorically suck.

As others have noted, the amount of process involved with "Agile" these days
is not in the spirit of the original Agile Manifesto. Additionally, how is it
that _some_ organizations do it well, vs. others that make life hell?

This fundamentally comes down to how much the organization values and trusts
its engineers. You only implement process if you cannot trust a person or
group of people to do something on their own. You only track and measure
performance by metrics if you do not trust them to work hard. This is easy to
verify - how often is senior management beholden to process & measurement?
Usually, the only "process" they need to go through is related to laws and
regulations, which - again - is fundamentally based on how must we trust one
another.

~~~
plutonorm
I can honestly say that in 15 years and 8 companies I have never seen one that
respects developers.

~~~
mongol
What does that mean, really? What is a sign of respect that you find missing?

~~~
plutonorm
It's an atmosphere. An air of dismissiveness that is hard to pin down. It
comes out in various ways. Dismissal of estimates. Removal of autonomy,
micromanaging. Transparent attempts to buy productivity with token gestures
like, pizza or beer, when management is at risk of looking bad. Not having
retrospectives, if they are held, nothing is ever taken on board and there may
be slight eye rolling going on. Fictitious deadlines, that arise roughly every
2 weeks, plucked out of thin air to try and stress everyone out to get them to
work harder. Just a very faint whiff of contempt hanging in the air, the
developers never really belonging in the company. Like we are interlopers, a
necessary evil, like... like an air conditioning unit in a boutique hotel. You
cant build it into the wall because it's not a purpose built building and
theres no space, but you also cant not have it in the room. So it just kind of
sits there clashing with the otherwise well thought through and lovingly
created decor. Something to be tolerated but also to be avoided.

I mean developers dont help themselves, they tend to let their desire for
purity and craftsmanship get in the way of getting the job done. They over
state the case for various development practices and management can sense it.
Somehow the two kinds of personality just tend to lose faith in each other and
it all unravels, until there is no trust left and all but the thickest skinned
developers roll off.

------
pferde
Interesting idea. All I've experienced so far was "Agile Enterprise Edition"
\- cargo-culting all the agile terms, wasting developer time in overly-long
standups, yet having a fixed, set-in-stone schedule and delivery plan.
Hilarious.

~~~
eeZah7Ux
Spot on. Agile, scrum, standups are just tricks to enforce micromanagement and
take agency away from engineers.

~~~
pferde
Not quite. Agile, when done right, by small-to-medium teams, can be effective.
However, whenever a big corporation tries to jump on the agile bandwagon, it
turns into nightmare fuel.

~~~
eeZah7Ux
The usual narrative. A tool that almost nobody is doing right - but blame the
people and not the tool.

------
mabbo
I think the author has made the mistake of "what works best for me is what
works best for everyone". It's easy to make. Likely, they had many bad teams
that used "agile" as an excuse for poor management systems, leading to
burnout. Then, they found a system that worked really well for _them_ in
_their project_ and said "aha! everyone who isn't doing it this way must be
experiencing what I experienced before I did this!".

Look, the point of Agile is that the team builds the process that works best
for them within the parameters of the work that needs doing. If you're burning
out because of your process not working, change the process.

For most teams I've been on, a month-long sprint is too much. Once my team
switched from 2-weeks to 3-weeks, and in that situation it was pretty good.
But on other teams, requirements and priorities shifted frequently, and
sometimes 2 weeks felt too long. This same "well that might work" pattern
applies to most of this document's recommendations, in my view.

But kudos to the author for finding a system that works for them in their
current situation.

------
himynameisdom
As others have noted, I think it's important to note the difference between
Agile and Scrum. Agile is a mindset, Scrum is a framework that encapsulates a
lot of Agile tenants. The ideas of a sprint or backlog or cards are purely
Scrum. Agile says nothing about using these items to satisfy customers (the
highest priority per the Agile Manifesto). That said, Agile principles
intentionally include a note about promoting sustainable development. The
sponsors, developers, and users should be able to maintain a constant pace
indefinitely.

TL;DR So long as you are constantly mindful of Agile tenants, there's already
built in awareness around burnout and sustainable practices.

For reference: [https://agilemanifesto.org](https://agilemanifesto.org),
[https://www.scrumguides.org/](https://www.scrumguides.org/)

------
mindcrime
One change I'd suggest: drop the use of the term "sprint". Prefer "iteration"
instead. Talking about "sprints" is a bad metaphor, and the metaphors we use
do shape the way we think and act to some extent. IMHO, along with the "gap
week" between iterations (which I vehemently agree with), this is part of
avoiding the conditions that lead to burnout... if you're sprinting,
sprinting, sprinting, all the time, bad things are going to happen. Not
everything you do needs to be at balls-out, breakneck, full-sprint speed.

~~~
bendixso
Seriously. Development phase or iteration is way better. It's also more of a
flexible concept. It doesn't need to always be two weeks or whatever. We just
decide what to do next and then do that.

------
myth2018
That's a good idea. Consulting firms have really overcomplicated Agile a lot.
I've been displeased to meet bloated implementations these last years.

My only point is that, at least in the companies I've worked for so far, a
practical Agile implementation must provide some device for making a
"pressure" over the team to avoid too many items ending up carried to next
sprint.

Of course there are lots of legitimate situations where an item doesn't fit in
the sprint and this should be acknowledged, providing inputs for the
estimation of the next sprint and making those estimations more accurate.
However, in my opinion, it should also be clear to everyone that those
slippages have consequences and everybody should be employing their best
efforts.

I don't consider this a deficiency in the article though, since Agile in
itself seems to be optimistic about teams by its very nature.

I believe this is going to get me some downvotes, but this is unfortunately
the reality I live in and if I were going to devise an Agile implementation
for my team I would take this into account.

~~~
ajmurmann
Sorry, there is no "faster" button. The only lever you have is cutting scope
as you go. Fixed scope just makes no sense. Otherwise you get one of three
outcomes: 1\. We underestimated how much we can get done. People now start
gold playing stuff and wasting time that would be better spent on future
backlog items. 2\. You estimated just right and are done Friday at 5pm.
Obviously this doesn't happen frequently. 3\. You overestimate and now
something's gotta give. People will start cutting corners or putting in over
hours as a punishment for being bad at estimation. This is not sustainable.

We need to get away from the fixed scope mentality with which Scrum had
poisened the Agile pool. If we cannot trust or developers to do the best work
they can and wanting to be proud of their work, the organization has entirely
different problems.

~~~
myth2018
Experience shows that this is not the way things work.

Real-world team members present varying levels of maturity and, therefore,
commitment levels to the aimed results.

Some will work at their natural pace and deliver the thing, provided the
estimates were accurate; some will relax and leverage the fact that it's
always OK to say that there was not enough time; some will work hard at the
beginning and get contaminated over time; and so on.

It is sad to work without a 100% mutual trust, but we have to be realistic.
Building trust takes time.

------
bunderbunder
It seems like you could solve this problem in an even more dev-friendly way by
sticking to one of the most fundamental principles in scrum (and possibly
others): Don't schedule 100% of your developers' time, and _definitely_ don't
fill them up to 100% on coding work. Not even close. Devs are supposed to work
at a sustainable pace.

A sustainable pace leaves plenty of time for kicking your feet up on the desk
in order to think about things. It leaves plenty of time for chatting with
one's teammates to make sure ideas are fully baked before implementing them.
It leaves plenty of time for trying out new ideas.

And, importantly, it leaves the time for doing this relatively unstructured.
Because the dev team is a bunch of working professionals who should be free
(and trusted) to figure out for themselves when they need to take a pause from
cranking through tickets in order to do other stuff. A "3 weeks on, 1 week
off" approach doesn't get you this.

I think that the spot where the car always ends up upside down in a ditch on
agile implementations is a misunderstanding of the basic idea behind velocity.
It isn't a KPI that you're supposed to maximize. It's a feedback mechanism
that the product owner uses to manage the pacing of some of their own work, in
order to make sure that the pipeline neither empties out nor becomes jammed
full of work.

If the PO is doing that job correctly, then they would be making tough
decisions about what is and is not reasonably doable in a given timeframe, and
providing backpressure to stakeholders when they're asking for too much. If
they're instead accepting every single feature request, and dealing with the
resulting backlog logjam by continually pressuring the dev team to work faster
and faster (and more and more sloppily), then, no sense in mincing words about
it, they're doing a bad job as a product manager. And the dev team is well
within their rights to push back against them on that.

Which, incidentally, is what the orthodox Scrum formulation is trying to do
when it disallows the PO from deciding how many items (or story points, or
whatever) to pull into the sprint. That's supposed to be based solely on the
dev team's own opinion of what's a reasonable amount of work to take on.

~~~
LandR
>It seems like you could solve this problem in an even more dev-friendly way
by sticking to one of the most fundamental principles in scrum (and possibly
others): Don't schedule 100% of your developers' time, and definitely don't
fill them up to 100% on coding work. Not even close. Devs are supposed to work
at a sustainable pace.

This sounds great until you work someplace where you need to allocate 7.5
hours every day to a billable project.

If you don't allocate 7.5 hours you are asked what you were doing the rest of
the day...

I've seen where someone won't have a conversation at work because they can't
allocate a project to 10 mins chatting with work colleagues.

Or when you get asked a coding question from a junior and so you help them,
but then need to get their project code they were working on so you can
allocate that 10 minute chatting /giving advice to that project.

Or helping a junior with something they are stuck on, management sees and
questions why two devs are sitting at one machine...

------
013a
I prefer a structure of: variable length sprints + optional 1 week interlude.

I don't understand why the "sprint length" is this set-in-stone thing. "We do
3 week sprints, we never deviate". That's not very agile. Sometimes you've got
very well-defined requirements on a large project and you could go heads-down
for 3 weeks on something. Other times, you've got a good "phase 1" that would
take 1 week to implement; so let's implement that, then plan the next sprint.
Or you might want to take a sprint to just write more tests, upgrade
dependencies, etc. Plan it, take a week, then lets resync.

The interlude week is used to decompress and give engineers time to plan their
own schedules. They can work on whatever they want; they create the plan,
create the tickets, and execute. Ideally it should have some thread of
connectivity with the team's overall mission, even if only slightly.
Leadership uses this time to plan the next sprint. There's a natural "bulk up"
on meetings during this week that were avoided over the sprint itself.

Specifically: the planning and retros happen during this week. Most teams I've
worked on put the Retro on the final day of the sprint. At one place it was at
like 11am. This is crazy! Combine that with a typical Friday drop in
productivity and you've just written off the entire last day! During a 2 week
sprint, that's a full TEN PERCENT of the sprint. Instead, schedule the retro
on Monday morning during the interlude, and full team planning on Friday
before the sprint.

Often those interlude weeks end with work that's best classified as either
"hackathon-style" (this is cool, not sure if we can use it right now but lets
bank the code and revisit) or "infrastructure" (we've wanted this done for a
long time, but it never got priority, we've finally done it, awesome).
Burntout engineers will naturally schedule themselves less to do or easier
things, like dependency upgrades; this is a great signal to management that
something is up and we should talk about it.

~~~
systemtest
The two week sprint is for management. So that all the stakeholders only have
to travel to "the pit" once every other week for a sprint review. It is vital
that every team finishes the sprint at the exact same time. If teams are out
of sync the stakeholders have to visit once a week or more.

Given how important all these managers are to the organization, they need to
be unloaded with trivial tasks such as playing with their phone during a
sprint "review" (which is actually a demo).

------
tuxie_
I would not suggest a full week off, a lot of people would not have anything
to do in 1 week every 2 other weeks.

Instead give everyone an extra day off, a 3 day long weekend. It's easier to
have a recurring appointment that way, like exercise or take a theater class
or whatever.

I've been working 4 days a week for the past 3 years and I'm not going back to
40h/week.

------
ausjke
Working with agile for the last half-year.

while it does make people agile, i.e. stir things up with daily stand-ups etc,
it also causes more chaos on the technical side.

anyone can pick up any stories, after a while there is nobody that is an
expert in any domain, everyone knows a little about everything but nobody
knows any subject deeper, no more domain expert. Now bugs took forever to
debug, the whole group is constantly in panic mode and burnt out.

to make things worse, document is neglected due to agile's own philosophy and
due to the daily chaos, and it makes development much much slower.

In short, agile gets everyone going and looking busy, but the product can
never deliver because nobody knows enough to fix hard issues. Many of them are
senior developers, the old model seems working better, a bit slower and
quieter but products are out of the door with good quality.

Agile is bad from my experience so far, our product is embedded system that
can't really be sprinted like those fancy front-end UI projects and such.
Agile does not fit us well.

~~~
cromulent
Agile isn't standups, nor user stories, nor sprints. They have been attached
to it, but you can be agile without any of those things.

My understanding of the "Working software over comprehensive documentation" is
based on all the stupid documents that no-one ever read. You should still
document the software for your colleagues, not for imaginary ISO9001 auditors.

There are so many charlatans in this area, it is frightening.

------
golergka
How do you deal with a sudden bug in released version then? Or even bugs in
the curent dev branch? All developers time is allocated to new features, there
are no openings – so all the bugs are moved to the next spring automatically
and we release with criticals?

Edit: everyeone's answering with very good advice on how to handle it, but my
intention was not to ask for advice for any situation I encountered
personally, but rather as a criticism of published document. It's written as
if it covered all the bases, but it doesn't cover bugs.

~~~
numbsafari
I've seen this handled a few different ways. What you do is going to depend on
the size of your team and your current business context. Like the rest of
engineering, there are few hard and fast rules, you have to weigh the trade-
offs.

One approach is to prioritize all bugs before all features. This is the Joel
Spolsky approach. In a typical sprint-based environment, this basically means
that available work effort is allocated to bugs, and only remaining work
effort is allocated to new features. The Google SRE model (as I understand it)
tries to moderate this by basically saying the team has some flexibility in
work allocation between bugs/features unless certain SLOs are missed. When
that happens, you go full Spolsky.

But that doesn't really address the "what if a critical bug comes up mid-
sprint". To address that, you basically adopt an on-call support model. Each
sprint, one (or more, or a half, etc.) are assigned to be the support person.
They triage any issues or bugs and address them as best as possible. It really
helps if there is a rotation, just like your operations on-call rotation. In
fact, it's best if you view this as the "escalation level" from your
operational on-call rotation. You can provide a similar resource for marketing
or other kinds of events as necessary. The benefit is that you have an up-
front acknowledgement of the level of investment needed for responsiveness, as
well as being able to provide folks with periods of interruption vs. periods
of deep work, and share that burden.

Lastly, I think it's really important to separate "release" from "sprint
completion", especially in a SaaS environment. If you build your CI/CD and
release processes around releasing at the end of the sprint, you end up
building a very inflexible infrastructure. It's much better if you can release
often, as work is completed. So, if you have a small feature ticket and you
tackle it early in the sprint, ship it right away. If a bug comes up, release
the fix as soon as it's available. I've been on too many teams where you have
an inflexible release process tied to the sprint. When something comes up, it
interrupts the whole flow to get something done. So, "end of sprint" != "big
release".

~~~
beat
Yes, small releases are a huge part of making this work. "We can't do short
iterations because iterations are so much work!" is the core of resistance.
Something's going to go wrong, and we have this heavy bloated religious
"deployment" ceremony with ten people on a call for six hours and how on Earth
could we do that once a week? Yeah. We can't do short iterations because of
all the crap we do because we do long iterations.

I'm always paraphrasing Kent Beck... if you can't write your requirements on a
card, you need to use a smaller card.

~~~
numbsafari
If we can all agree that "shipping" is a feature[1] and that "shipping faster"
is a competitive advantage, then "shipping fast" is probably one of the first
features we should invest in as a team, from leadership to private chef.

If it takes 10 people and six hours to accomplish the release of even the
smallest of features, then it sounds like there's a bug with your "ship fast"
feature and the team should invest some or all of its resources in fixing
that. You probably can't do it over night, but you gotta chip away at it over
time at the very least.

If you are looking for justification backed up by real world numbers, I highly
recommend the book "Accelerate" by Nicole Forsgren, et.al.[2]

[1] [https://a16z.com/2014/04/16/shipping-is-a-feature-some-
guidi...](https://a16z.com/2014/04/16/shipping-is-a-feature-some-guiding-
principals-for-people-that-build-things/)

[2] [https://www.amazon.com/Accelerate-Software-Performing-
Techno...](https://www.amazon.com/Accelerate-Software-Performing-Technology-
Organizations/dp/1942788339/)

~~~
beat
Yeah, I know. And I've read the book. But I work in enterprise devops. This is
the reality of many, many teams. Which means there's a lot of unnecessary
process that needs to get tossed and a lot of automation that needs to be
built in order to do short iterations and get out of the 3-6 month window.

~~~
numbsafari
Me too! I feel your pain.

Have you considered giving it as a gift to your peers and leadership? I really
think it's a great read and resource for anyone trying to sell organizational
change.

I wonder if any of those "automation needs" could be turned into startup
ideas?

~~~
beat
Done that, too.

I actually tried a startup in the monitoring space, but sadly failed (it was
great fun losing $100k or so, tho... well worth the experience!). But the
automation needs problem is more a consultancy thing than a product thing.
There are lots of products. Teams buy them, with the best of intentions. Lots
of management wants to believe they can buy their way out of the hard problems
of not having any discipline. Sigh.

------
dyeje
Company culture is what causes burnout. Process is mostly a reflection of a
company's culture. You can't fix burnout by changing process because the
process will inevitably warp to fit the culture of those who use / define it.

Changing culture is really, really, really, really hard. Unless the company is
tiny, I recommend looking for a better fit instead.

------
y-c-o-m-b
What we do where i'm at is the perfect amount of "agile" for me. Granted we're
a small team, but it's worked VERY well for 3 years now.

What we do:

\- Standup twice a week, never lasts more than 15 min

\- 1 hour "planning" meeting each sprint where we discuss new stories for the
upcoming sprint and assign them points

\- 2 x 2-week sprints (1 release a month containing work from both sprints),
this gives us flexibility for unexpected problems if we have to cut stuff out
of the release or add features missed during planning

\- We do not track hours

\- We track velocity by points, but it's only a guide for the next sprint and
not taken as do or die

\- Developers freely choose what they want to work on, but they must go down
by priority on the sprint's items

\- When a dev is finished with their story, they pickup the next item in the
sprint

\- If all sprint items are taken/done, we grab from the next sprint
assignments. If those are all done, we have another planning meeting or work
on tech debt in the backlog

EDIT: Formatting, words

~~~
joelesler
This is essentially how I run my team. Very close.

------
rutthenut
Pah, I've not seen Agile cause burnout at all. Far from it, the way sprints
become long slow walks and stories move from one sprint to the next, at the
altar of 'Agile' and not 'Delivery', developers appear to be under way less
pressure than in older forms of project management. With, you know,
deadlines...

~~~
commandlinefan
Well, sort of by definition, if you're doing "agile" and it's causing burnout,
you're not "doing it right", but that seems to be the crux of the problem -
every place I've ever worked that has tried to adopt a mindset of actual
agility has almost immediately fallen back into the authoritarian command-and-
control centralized decision management style that dictators prefer: "tell me
everything that you're going to do and exactly how long it's going to take and
then I'll argue with you that it shouldn't take that long and blame you when
it takes longer".

------
davedx
Everyone has their own vision of what agile and/or scrum _should_ be. Every
company, manager and developer has their own special and unique recipe. There
are as many flavours and variants as there are rules for playing a game of
pool across the world.

Personally my main takeaway from the whole agile world is "people over
process".

Sort out your communication, trust, and how you work together first. _Then_
start looking at whether you want to work with agile, XP, scrum, kanban or
_some other recipe_.

------
msluyter
I think people respond well to natural rhythms with contrasting phases (a time
to sow; a time to reap...) so I find the general concept quite appealing. One
thing that always bothered me a bit about scrum was that it's basically an
endless series of sprints. Just saying it like that sort of illustrates the
problem that you can't sprint indefinitely.

Additionally, I've found that for maximum creativity/productivity, I need
periods of down time. Work on a problem, then put it down, and often the
solution will pop up while you're in the shower or taking a walk. So I think
explicitly building some sort of breaks ("take a couple of days to learn/rest
or work on whatever you want") is a good idea. I'd advocate doing this
informally when needed or when schedule permits, rather than formally
scheduling 3 on, 1 off.

------
amai
Kanban works since 1947.

[https://en.wikipedia.org/wiki/Kanban_(development)](https://en.wikipedia.org/wiki/Kanban_\(development\))
[https://en.m.wikipedia.org/wiki/The_Toyota_Way](https://en.m.wikipedia.org/wiki/The_Toyota_Way)

But lets reenvent the agile wheel a thousand times. We have no other problems
to solve.

------
btbuildem
You're suggesting giving devs 12 weeks vacation?

I love it. Our management would murder you in cold blood for merely mentioning
it.

~~~
ngngngng
I feel like our minds take at least 12 weeks off a year anyways, why not let
our bodies leave the office as well?

~~~
geofft
My mind doesn't take 12 weeks off a year on a schedule dictated by management,
and it certainly doesn't take the remaining 40 weeks on on a schedule dictated
by management. I'll work a lot better doing 6 hours of work a day every week
than 8 hours of work with no slack for three weeks straight.

------
dkhenry
I don't think this is a viable solution to Agile. I think the spirit is fine
in that its painfully obvious that Agile has become little more then a
buzzword sold by consultants, and almost all implementations of it look a lot
like mini-waterfall then anything truly agile, but this misses the biggest
faults in current agile implementations

1\. It still puts process over people, you can never have an agile workflow
that has ordained gatekeepers, in this case the separation of "project leads
and stakeholders" from "developers" is going to lead to the same class of
sprint problems you have in any implementation today. The people you need are
the one's doing the work ( every single one of them, from the most junior to
the most senior ) to sit down with the people

2\. The lack of agility in scoping work in sprint means this is just a three
week waterfall rather then a two week waterfall. You can't call any process
agile that doesn't allow you to change direction at any point in time, hence
the word agile. In traditional agile this is supposed to be a terminated
sprint, but for reasons this is almost never done.

3\. The baked in rest week will just make people unhappy. Teams are at their
best when they are working together and making progress, that rest week will
foment dissent within the team, especially since the "stakeholders" still have
tasking to be done that week.

------
everdev
I work mostly with startups and I don't know any that could survive with a
plan like this:

> 3 weeks on/1 week off development cycle

Unless you're lucky enough to have no competitors and a ton of runway and no
major support issues ever, there's no way you can give your engineering team
12 weeks of vacation a year all at the same time.

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

Yes, minimizing context switching is a great thing, but for 4-8 weeks you
can't adapt to changing business conditions? A change that comes in on day 2
will have to wait 8 weeks to go live as it won't be put into a sprint for 4
more weeks and then launched another 4 after that.

I'm a developer and totally understand the desire to have every requirement up
front and peace and quiet to implement it. The goal should be to get as close
to that as possible but still being open to business needs.

Unfortunately I've seen first a dev team sink a multi-million dollar business
through a lack of flexibility and turnaround time.

I don't think you'll find many managers rushing to implement this, which is
basically inflexible agile with a week of vacation every month. I think the
experience of managing a dev team while trying to balance a budget would be
invaluable for anyone thinking that this process makes sense.

------
JakeWesorick
We do something very similar to this where I work. Week 1 is not a vacation
for us. Each developer has work assigned for the cycle but it might be high
level or vague. We spend the first week designing the feature and nailing down
requirements. We also do allow very important stuff to get added to the cycle.
We have very brief standups at the begging of each week, but we also
communicate throughout the cycle over slack.

It works very well for us as a small team of five developers.

------
EnderMB
Purely my opinion, so feel free to agree/disagree.

Most of the time, agile fails due to an unwillingness to be flexible. It's
either stakeholders or managers with rigid deadlines/demands, or teams that
are incapable of adapting their processes to increase productivity.

If you ever want to test your agile setup, ask yourself this: what happens
when you finish a sprint and you have time remaining on a task? For me, this
is the ultimate test of agility in an organisation, and it's usually where you
see the first problem(s).

A lot of people in tech like to complain that consulting firms have ruined
agile, but I blame you/us. We've ruined agile because we refuse to be agile,
and we ultimately accept a process where we rush into development without
adequate planning, or the ability to change course during production.

In all fairness, it's not just developers faults. It's also the fault of
managers that implement this "agile" thing we've sold as a rigid process that
needs to fit a set of concrete parameters.

------
ozim
Please don't read it literally.

Seems like author did not really meant that to be specific advice or exact
manual. It seems more like talking piece and maybe some distant idea we could
strive for.

I was also at first thinking "what kind of company has those kind of
resources, and what kind of ideal world is that where you can plan 3 weeks of
work in 1 week without adding stuff to sprint".

------
gumballhead
I've never gotten burned out from working too hard. I get burned out by having
no say or control over what we are working on or how it's done, and by getting
stuck working on low-value tasks for prolonged periods of time. Those projects
are the ones that make me not excited at all to come to work.

It's usually because the client / product owner has no idea what they're doing
but still insists on making all of the decisions with no input from users /
developers / designers. And it sure sounds ridiculous, but it is the norm.
Developers are viewed as people who do not want to participate in meetings or
planning, and who exist on streams of work to do. If the developers run out of
work, they'll go crazy! As long as we "keep them unblocked" and have tasks
ready for them, we're doing our jobs and they'll be happy!

~~~
JohnFen
> I've never gotten burned out from working too hard.

Me neither. I burn out when I'm working on something that I don't love working
on (and things like feeling powerless or bad management can make it something
I don't love working on). Not coincidentally, I also don't work as hard on
those things despite all good intentions.

This is why the #1 requirement I have when I'm considering a job is that it is
something that I will enjoy. That's more important than compensation or
location.

------
dodyg
Agile Lite is like Diet Diet Cola. Agile is supposed to be Lite.

~~~
ajmurmann
I believe this happened because enterprises and dusty orgs wanted all the
benefits of Agile without touching any of the real problems that make their
orgs suck. Like communication issues and unrealistic expectations. This lead
to first Scrum and now Safe.

------
devin
Stakeholder: "So, just so I understand, your team went surfing for a week, and
the reason we didn't finish everything in scope for the sprint is what again?"

------
beardedwizard
I think agile has always suggested modifying to fit the team - so then do we
need an agile light, or just critical thinkers doing whatever agile provides
actual value?

~~~
volfied
And the industry pretty much modified agile in a way that gets the most work
out of people, regardless of fit. So yeah, sometimes we do need something
that's written as a "manifesto" to remind people what agile actually was
supposed to be.

------
tshannon
This kind of reminds of a weight training regimen.

3 weeks of clearly defined goals and progressive load, followed by a "deload"
week where you're not sitting around doing nothing, but you're lifting lighter
weights to let your body recover.

Makes sense to me, because whether you're lifting weights or working on
software, stress is stress and probably follows the same patterns of
progressive overload and recovery.

------
geofft
My worry with a mandatory one-week vacation every month is that people won't
take the vacation - they'll use the time to make progress on features or other
work-related projects. Burnout isn't solved by a simple "You must spend this
time away from your keyboard and this time at your keyboard," and some of the
most difficult burnout for me to work through has been when a problem has
seized hold of my mind and I've felt compelled to keep working on evenings
even when I clearly wasn't making progress.

If you end up in a situation where the document on paper says everyone's
taking time off to surf and paint and the actual practice is that some
contributors are doing work during this time—and, almost certainly, not
getting punished and in fact getting promoted for doing so (perhaps because
they commit locally and rebase so nobody knows they were working during this
time)—you're going to end up with way more frustration, burnout, and
uncontrolled work schedules than you ever started with.

------
viach
>> It is an intentionally light week and many people may simply take the time
off to paint or surf or whatever.

And the next week will be spend on meetings where management is trying to
explain to the returned (hopefully) surfers what was decided to implement on
the previous week meetings?

And it will turn out something was missed out and needs re-planning?

Another week, another iteration of planning and surfing?

------
ben509
This seems like it repeats the same problem I generally have with most
methodologies: it treats planning as being separate from development.

Plans go into (Jesus make the hurting stop) Jira while development goes into
Git.

And, okay, all of this requires new tooling, that figures out what your
"issues" are based on the state of your source repos.

But... Suppose you were doing (Something Like) TDD and your "planning" was to
write a bunch of tests that broke.

Or you're even not doing TDD but you can detect stubbed out code and draw
issues from that, possibly by reading related documentation.

And your working set of issues, then, are all the tests / stubs detected in
active branches.

(And this needs some logic to clean up the duplicates, and needs to be smart
enough to notify people when things finish. And you want smart tests like
TestNG that can identify dependencies.)

And it needs to serve aspects outside development; let's say functions that
touch the UX must be certified by a designer / tester. That person should be
able to digitally sign code (maybe even just a handle and date is enough) and
then those changes are known good.

The reason I bring this up is because of a big deficiency in the issue
trackers: identifying a new issue is cognitively/technically/procedurally
expensive.

One of the big things language designers try to do is make elements
lightweight. Python added inline assignment because they saw people would
repeat code just to avoid creating a new variable name.

And when we're doing issues, planning out a new issue means setting up a
meeting or opening a ticket in Jira and filling out a ton of paperwork, etc.

It seems like it _ought_ to be as light-weight as defining a new test, or
writing out a stub function.

------
snarfy
Agile is the Agile Manifesto. Anything else is not. All I see are references
to Scrum. Maybe this should be called Scrum Lite?

------
bendixso
Is anybody else a little creeped out by this recent insistence that we refer
to everything being done as an "issue"? I never agreed to this. I don't know
where it came from, but it's really weird.

Issue implies something is already wrong with what is being built.

How can we be wrong when we haven't even started yet? It's utter madness

------
kevlar1818
This project should be called Scrum Lite. Agile software development is a
philosophy, not a process or prescription.

------
gfs78
There are three parts involved in any project. The product, the process and
the people. As it currently stands scrum does not make any provision to
address the people. Hence management uses this void to turn scrum into scrum
butt and turn the devs into jira ticket processing machines which are pushed
until they break.

Until the big names in the industry accept that error and address that, I
guess there will be no hope for most people doing dev work.

Most companies on themselves don't have any incentive to address this fact
because the commoditization of programmers benefits them and because they
aren't in a position to understand the long term consequences of this (or
don't care)

------
fallingfrog
My experience of agile has been that it’s a justification for management to
put a lot of pressure on their team while micromanaging them at the same time
and always making everyone feel like they are failing. If you can get everyone
to announce what they got done _every day_ then one developer is thinking, I
did ok, and the rest are panicking and thinking, I’m going to get fired if I
can’t keep up with that person! Meanwhile there’s nothing in agile about team
members having actual agency in determining their own priorities or making
decisions. It’s just classic top down pressure cooker micromanagement. In my
experience.

------
batchfile
How do you answer the c-level concern that we are basically going down to 75%
output?

~~~
hvidgaard
Telling your developers to bugger off for 1 week every month will never work
out. They still need to be at the office, but they can pursue learning, help
with planning (this is critical), or focus on other development tasks they
actually want to make.

~~~
sefrost
Ah, when the linked article suggested developers go "surfing" I thought it
meant in the sea, not the web.

~~~
hvidgaard
I think that was the intention. I just don't believe it will work out.

------
edpichler
Does anyone had worked on a company where you can stay for 3 weeks without
stakeholders appearing with "urgent" things to add on the sprint with an
excuse that this is necessary to don't lose that unmissable deal?

------
gfodor
Any methodology where it takes more than a month to turn around a bugfix for a
discovered issue in the first week of the month seems flawed. Unless I'm
missing something, that's the case here.

~~~
scriptkiddy
The author did mention that some urgent issues don't fit inside the sprint
window and should be tackled immediately. I can only assume he meant hotfixes
for bugs and things of that nature.

------
robinduckett
Seems like Waterfall with extra steps

------
ironic_ali
An understanding of every comment here shows agile (or any other methodology)
in all its "glory"......

People just can't agree on anything is the simple answer. It's how we get
round that to get anything done as a group (given the many personality types
and their experiences) that matters.

Usually, for something successful to occur (scope, time, budget are met), it
comes down to a knowledgeable leader who understands people. And there's not
many of them around.

------
nobatron
This doesn't seem very agile. Without developer input into the sprint planning
meeting this is going to lead to 3 hard weeks where overtime is highly likely
because the team didn't have any say on what work was done and 1 week off to
recover.

Whilst this may help with burnout so do the main implementations of agile when
done correctly.

Agile done properly is all about quickly getting feedback on the speed of work
so the business can correctly plan in accordance to this.

------
aboutruby
> Issues may not be added to the sprint

I don't see this happening, even if that's a good rule, because issues come up
that take higher priority than existing issues.

~~~
SketchySeaBeast
I noticed that as well. That'll be pushed back against, and the leadership is
going to decided that they must respond to SOME issues to appear responsive,
and let's be honest, it's going to have to happen regardless of project
ideology. There'll be some silly rule put in place that only priority "X"
issues get looked at mid sprint, and suddenly every issue is going to be
priority "X", and now someone gets to spend the time they would have spent
fixing the issue going "Ok, is this really a priority 'X' issue?" and fighting
with whoever raised it.

~~~
beat
Decent iterations cannot be done without immediate management playing defense,
period. As long as _anyone_ is allowed to interrupt the iteration, then
iterations are just going through the motions and won't solve any actual
problems - because the problem is a lack of control.

The engineer's response to unplanned work should be "Go talk to my manager",
and the manager's response _must_ be "Wait til next iteration". If the team
can't defend its own boundaries, it's hosed, period.

~~~
SketchySeaBeast
I've never know immediate management to understand the business nor the system
as well as the ones with boots on the ground. I've yet to see a situation
where the manager doesn't end up coming out of his office and asking someone
on the team "so, what's this mean?"

~~~
beat
It's not management's job to understand details of the code (and it's probably
a problem if they do). And it's not their problem to understand the business
perfectly (and it's probably a problem if they do). It's their job to
_facilitate getting work done_. That means helping their developers work as
effectively as possible. And in most cases, that means keeping customers from
end-running around whatever work management process is in place. If you're
doing agile, the manager's job is to protect the iteration, and shield the
developers from politics and pressure so they can work well.

I often use a bread-baking analogy here. Making software is like baking bread.
This iteration, we get some flour, water, yeast, and salt, mix them together,
knead, rise, and bake. And if someone comes in five minutes before baking is
done and says "Can't you just add some raisins now? It's just a handful of
raisins, it's not much work". No. It means _starting over_.

------
bendixso
I have never worked in a field more obsessed with talking about how it does
its work. Today we're standing on one leg. Tomorrow we're programming in
downward dog stance. Next week, we're gonna try the Red Bull diet and see how
that goes.

This really doesn't have to be that hard. You talk to people. You figure out
what's important. Then you do that stuff. Then you talk to more people again.

------
president
I have always said that Agile methodology, as it is used by most companies, is
just a way to squeeze every drop of efficiency from an engineer and ensure
that people aren't goofing off. Agile works assuming that you are able to drop
features or push deadlines if needed but in my experience in startups and
enterprise tech companies, this NEVER happens.

------
1337shadow
Great guide that does what it says: assure defense to protect developer in
weak positions, which as we know is a normal part of experience.

However, maybe it would be nice to add a guide for shadow operations that
hackers may want to undertake to ensure project long term success, for when
they have a strong position ("aggressive agile" if you want).

------
hanzg
Agile burnout means that there are to many items in the sprint, and that your
estimation points / priority is not right. Nobody needs to burn out when you
do a good estimation planning that fits into a 40 Hour workweek. Every hour
above that is less productive and will work towards a burnout.

------
jrochkind1
This seems like more or less basically what I've been doing.

(Not with "one week off" though, that sounds nice but neither necessary or
realistic).

It works out okay. As with everything else, the
competencies/interests/capacities of the people, especially "product owner",
make a big difference.

------
neogodless
The TL;DR of this is "work less (hours), avoid burnout."

But this prescription needs a few more paragraphs of caveats that describe the
company, team, product and other factors that affect whether this strategy is
viable. The simple answer is "do what works for your situation" but that's
light on useful information. If you can make Agile or Agile Light or Waterfall
work for your team, go ahead. If your team cannot wait 7 weeks for a
production issue to be fixed because "we don't add issues to sprints" then you
might not be able to work with this system.

When I saw 3 weeks on/1 week off, I was actually thinking of a sort of reverse
- 3 weeks of active development with a final week of catching up on QA and bug
fixes discovered in the sprint, as well as retrospectives, grooming and sprint
planning (though, presumably, a dedicated product owner would get most of that
work done concurrently with ongoing development.) You don't end up with _an
actual week off work_ but it is a lighter week.

The main issues I've seen with Agile were not burnout related, but simply
having an incorrect or weakened team structure. Not enough testers,
insufficient engagement of a product owner, overloaded manager/scrum
master/architect. It kind of goes without saying that if you try to follow
Agile but you omit key team members, the existing team members are then more
likely to be overloaded to pick up the slack, quality will go down, and the
smoothness of the sprint cycle will decrease.

------
aitchnyu
My friend, software engineer at a VFX company, said his sprint meetings were
only for planning ahead and no crunches to snap deadlines to sprint "ends".
Thats silly, stuff always exceeds sprint ends.

My team insists on sprint deadlines, but no sprint meetings . That's cargo
culting.

------
systematical
Pretty much what we do except our sprints are two weeks with two of those days
devoted to planning. If it's a bigger project then planning may be a sprint
task of is own.

We release on Tuesdays so every other Friday and Monday end up being pretty
light assuming the Thursday QA went well.

------
tempodox
I have yet to see an implementation of Agile that's not misused as a pretext
for micromanagement.

------
keithnz
This isn't agile (or lite), this is just ad hoc development with 1 month
timeboxing.

------
ravenstine
If Agile really works so well, then why are there so many conflicting opinions
about it?

------
devstoner
I've been through the wringer it sounds like this team is going through more
than once.

You have to teach your stakeholders and managers how to be agile, if they
aren't willing to actually get that, it always turns into a death march
eventually.

~~~
jrs235
And agility requires slack (unscheduled capacity) which means less than
optimal "resource" efficiency. Stakeholders and managers need to understand
that if they what to be able to handle changing plans and requirements then
their time can't be fully booked. Problem is then many expect the developers
to just work more hours leading to burnout and turnover. I really think
developers should push for hourly exempt status (the only class of workers in
the US that are allowed hourly exempt status) instead of salary exempt status.
With hourly exempt, while you won't be paid time and a half, at least you'll
be paid straight time for anything over 40 hours a week.

------
alasdair_
A missing piece is how to handle things like major production issues
occassionally popping up and decimating a planned sprint. The idea that
“nothing can be added to a sprint” doesn’t work if things break badly enough.

------
shatteredvisage
What industry do you work in that you can let product decide everything with
out any engineering input, and also allows you to go 3 weeks without reacting
to buisness/shifting priority?

------
edoo
I'm a big believer in the 6 hour work day now. A single 6 hour push is better
in a lot of ways than the traditional 3-4 hour push with the post lunch 3-4
hour meander.

------
timwaagh
mate, i don't get 12 weeks of vacation each year. only five. this method
basically requires to be pinned down in labor contracts. this also basically
transforms a 40 hour week into a 36 hour week.

but i suspect this schedule is still going to be difficult for people in
relationships. it would be nice for me though.

the premise is right though: scrum is bad. as a developer always argue against
estimations and so on. after much bickering we succeeded in getting rid of
them here.

------
rparet
Went to github, saw the word “sprint”, closed window. I really appreciate any
effort to return us to basics. However, we should have a firm grasp on what
the basics are first. Today, you wouldn’t batch all of your team’s code
together this week and then do a build - you would build and integrate
continually. Why would you adopt large batch, non-continuous process for your
overall development process?

------
jarcane
> "sprint"

 _mashes eject button_

------
OJFord
25% of my time painting and surfing?

Where do I find a company implementing this brand of agile..?

------
gpmcadam
This is parody, right?

------
VectorLock
"Daily standups are discouraged" I'm sold.

------
EugeneOZ
Whole week just for talking? Stopped reading after this.

------
elindbe2
God...I can only dream about such a work life.

------
yamadapc
TL;DL

Ignore all existing literature and experts' previous experience.

Simple.

------
ai_ja_nai
25% overhead is a little too much

------
foobar_
Agile is dead. As a subculture the muggles and sociopaths have taken over
Agile. I think #NoEstimates is the next cool thing.

~~~
jrs235
I feel like #NoEstimates has been a thing. I think #NoMethodology or
#NoProcess is the next cool thing (Some might call it #GSD).

~~~
foobar_
#NoProcess seems ideal for small competent teams. We need to get out of the
estimation hell for normal projects.

------
diminoten
> most communication happens through the issue tracking system (which is
> faster to work with than e-mail)

Written by someone who hasn't communicated this way (especially remotely).
This is _really_ just a way to mark your ticket as blocked, and fuck off for
the rest of the day because the person who needs to respond won't get to it
until they're out of "flow" or whatever (isn't maker time great?).

> Once a sprint has begun, Issues may not be added to the sprint

So the company is just supposed to eat the extra time in a sprint if there
happens to be that extra time? No fucking way will a company opt into that,
especially combined with the monthly beach week time (AND any reasonable
absences during the sprint itself).

This is a pipe dream. Sorry, but asking a company to treat you like this is
asking a company to basically pay you for doing nothing. Ridiculous.

