Agile Lite: Agile without all the burnout - <AUTHOR> https://github.com/davebs/AgileLite <comment><USER2> 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.

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

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

<comment><AUTHOR> 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!"

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

</comment></comment></comment></comment></comment><comment><USER6> 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)

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

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

<comment><USER9> Don't make estimates, make... forecasts?

<comment><USER10> 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..."

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

</comment></comment></comment></comment></comment></comment><comment><USER12> 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.

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

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

<comment><USER14> _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.")

</comment></comment></comment></comment><comment><USER15> 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.

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

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

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

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

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

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

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

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

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> 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.

<comment><USER20> I can honestly say that in 15 years and 8 companies I have never seen one that respects developers.

<comment><USER21> What does that mean, really? What is a sign of respect that you find missing?

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

</comment></comment></comment></comment><comment><USER22> 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.

<comment><USER23> Spot on. Agile, scrum, standups are just tricks to enforce micromanagement and take agency away from engineers.

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

<comment><USER23> The usual narrative. A tool that almost nobody is doing right - but blame the people and not the tool.

</comment></comment></comment></comment><comment><USER24> 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.

</comment><comment><USER25> 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/)

</comment><comment><USER26> 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.

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

</comment></comment><comment><USER28> 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.

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

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

</comment></comment></comment><comment><USER30> 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.

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

</comment></comment><comment><USER32> 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.

<comment><USER33> 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).

</comment></comment><comment><USER34> 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.

</comment><comment><USER35> 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.

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

</comment></comment><comment><USER37> 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.

<comment><USER38> 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".

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

<comment><USER38> 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/)

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

<comment><USER38> 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?

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

</comment></comment></comment></comment></comment></comment></comment><comment><USER40> 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.

</comment><comment> 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

<comment><USER41> This is essentially how I run my team. Very close.

</comment></comment><comment><USER42> 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...

<comment><USER43> 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".

</comment></comment><comment><USER44> 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_.

</comment><comment><USER14> 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.

</comment><comment><USER45> 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.

</comment><comment><USER46> You're suggesting giving devs 12 weeks vacation?

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

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

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

</comment></comment></comment><comment><USER49> 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.

</comment><comment><USER50> 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.

</comment><comment><USER51> 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.

</comment><comment><USER52> 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.

</comment><comment><USER53> 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".

</comment><comment><USER54> 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!

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

</comment></comment><comment><USER56> Agile Lite is like Diet Diet Cola. Agile is supposed to be Lite.

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

</comment></comment><comment><USER57> 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?"

</comment><comment><USER58> 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?

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

</comment></comment><comment><USER60> 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.

</comment><comment><USER48> 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.

</comment><comment><USER61> >> 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?

</comment><comment><USER62> 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.

</comment><comment><USER63> Agile is the Agile Manifesto. Anything else is not. All I see are references to Scrum. Maybe this should be called Scrum Lite?

</comment><comment><USER27> 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

</comment><comment><USER64> This project should be called Scrum Lite. Agile software development is a philosophy, not a process or prescription.

</comment><comment><USER65> 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)

</comment><comment><USER66> 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.

</comment><comment><USER67> How do you answer the c-level concern that we are basically going down to 75% output?

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

<comment><USER69> Ah, when the linked article suggested developers go "surfing" I thought it meant in the sea, not the web.

<comment><USER68> I think that was the intention. I just don't believe it will work out.

</comment></comment></comment></comment><comment><USER70> 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?

</comment><comment><USER71> 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.

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

</comment></comment><comment><USER73> Seems like Waterfall with extra steps

</comment><comment><USER74> 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.

</comment><comment><USER75> 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.

</comment><comment><USER76> > 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.

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

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

<comment><USER77> 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?"

<comment><USER39> 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_.

</comment></comment></comment></comment></comment><comment><USER27> 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.

</comment><comment><USER78> 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.

</comment><comment><USER79> 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).

</comment><comment><USER80> 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.

</comment><comment><USER81> 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.

</comment><comment><USER82> 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.

</comment><comment><USER83> 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.

</comment><comment><USER84> 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.

</comment><comment><USER85> I have yet to see an implementation of Agile that's not misused as a pretext for micromanagement.

</comment><comment><USER86> This isn't agile (or lite), this is just ad hoc development with 1 month timeboxing.

</comment><comment><USER87> If Agile really works so well, then why are there so many conflicting opinions about it?

</comment><comment><USER88> 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.

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

</comment></comment><comment><USER90> 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.

</comment><comment><USER91> 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?

</comment><comment><USER92> 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.

</comment><comment><USER93> 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.

</comment><comment><USER94> 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?

</comment><comment><USER95> > "sprint"

 _mashes eject button_

</comment><comment><USER96> 25% of my time painting and surfing?

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

</comment><comment><USER97> This is parody, right?

</comment><comment><USER98> "Daily standups are discouraged" I'm sold.

</comment><comment><USER99> Whole week just for talking? Stopped reading after this.

</comment><comment><USER100> God...I can only dream about such a work life.

</comment><comment><USER101> TL;DL

Ignore all existing literature and experts' previous experience.

Simple.

</comment><comment><USER102> 25% overhead is a little too much

</comment><comment><USER103> Agile is dead. As a subculture the muggles and sociopaths have taken over Agile. I think #NoEstimates is the next cool thing.

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

<comment><USER103> #NoProcess seems ideal for small competent teams. We need to get out of the estimation hell for normal projects.

</comment></comment></comment><comment><USER104> > 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.</comment>


Catching a Mathematical Error Using Haskell's Type System - <AUTHOR> http://cdsmith.wordpress.com/2009/08/19/catching-a-mathematical-error-using-haskells-type-system/ <comment><USER2> I believe the paper the author is referring to is

Franks, John. "Flow equivalences of subshifts of finite type." Ergodic Theory and Dynamical Systems (1984). 4:53-66. Cambridge University Press.

Also, minor errors in mathematics papers are not uncommon. Usually, they are fixed and included in a later edition of the journal as "Errata to [name of paper]." The main purpose of the refereeing process is to detect game-breaking errors such as a missed condition on a theorem used or a misapplication of a tricky technique (usually from another field of mathematics). Interestingly enough, from what I've seen, budding mathematicians actually make a lot of errors that are similar to that of novice programmers (e.g. off-by-one errors in induction, forgetting about boundary conditions).</comment>


Washington Post employees want to go on strike because Bezos isn't paying enough - <AUTHOR> https://twitter.com/realDonaldTrump/status/1008340100877570048 <comment><USER2> Not the greatest source.</comment>


Substituting local data for remote UIWebView requests - <AUTHOR> http://cocoawithlove.com/2010/09/substituting-local-data-for-remote.html <comment><USER2> Kind of off-topic, but Matt (the author of cocoawithlove.com) is one of the best hackers in the iOS/Mac community. You will notice a great majority of his posts contain very valuable information and are simple to consume because of his unique writing style. I highly recommend grabbing his RSS feed into your reader of choice if you are interested in learning more about Objective-C/Cocoa, etc.</comment>


PHP DateTimeImmutable::modify() - <AUTHOR> http://www.php.net/manual/en/datetimeimmutable.modify.php

<comment><USER2> Some discussion about this method at [http://derickrethans.nl/immutable- datetime.html](http://derickrethans.nl/immutable-datetime.html)

<comment><USER3> That seems to explain the logic of having an immutable DateTime type (to avoid breaking backwards compatibility with the inherently mutable old DateTime) but doesn't explain the logic of then including a modify() method for such objects.

"Immutable" probably isn't the right description.

<comment><USER4> objects of the DateTimeImmutable class are immutable. All methods that modify the object will return a new copy.

While the naming is a bit unfortunate, this isn't different from other languages that have immutable types like Java String which also have methods that act on the string they are called on and return a new copy.

Like concat().

        String foo = "foo";
        String foobar = foo.concat("bar");
        // foo is still set to "foo"

And with datetimeimmutable:

        $date = new DateTimeImmutable();
        $other_date = $date->modify('+ 3 days');
        // $date still is today.

Python strings work the same. And all the ruby string methods not ending with a bang also work the same.

The reason why the method is called 'modify' in PHP is because the old DateTime (mutable edition™) method was also called 'modify' and the two should be more or less drop-in replacements.

Besides - what would you call a method that modifies a timestamp?

<comment><USER5> > The reason why the method is called 'modify' in PHP is because the old > DateTime (mutable edition™) method was also called 'modify' and the two > should be more or less drop-in replacements.

The old datetime's method modifies the object in place[-1], if you replace the old with the new it's not going to work anymore.

> Besides - what would you call a method that modifies a timestamp?

Replace[0]? withFieldValue[1]? add with a delta object, possibly relative[2]?

[-1] it also returns the object it was called on since 5.3.0, the method was introduced in 5.2.0

[0] [https://docs.python.org/2/library/datetime.html#datetime.dat...](https://docs.python.org/2/library/datetime.html#datetime.datetime.replace)

[1] [http://joda- time.sourceforge.net/apidocs/org/joda/time/DateT...](http://joda- time.sourceforge.net/apidocs/org/joda/time/DateTime.html#withCenturyOfEra\(int\))

[2] [http://msdn.microsoft.com/en- us/library/system.datetime.add(...](http://msdn.microsoft.com/en- us/library/system.datetime.add\(v=vs.110\).aspx)

<comment><USER6> > The old datetime's method modifies the object in place[-1], if you replace > the old with the new it's not going to work anymore.

Of course it would be impossible to make the APIs exactly the same, because the two classes have different behaviour. But shouldn't they at least strive to make the APIs as similar as possible?

<comment><USER5> > But shouldn't they at least strive to make the APIs as similar as possible?

No, not when the behavior is completely dissimilar and the method name is highly misleading.

<comment><USER6> The behaviour is not completely dissimilar. The only difference between the two methods is what is done with the result. In fact, every method in that class parallels one from the other class in exactly that way, and that behaviour is described clearly on the documentation page for the class:

> This class behaves the same as DateTime except it never modifies itself but > returns a new object instead.

[http://www.php.net/manual/en/class.datetimeimmutable.php](http://www.php.net/manual/en/class.datetimeimmutable.php)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> This is one of those things that seems hilarious only because you are ignorant of what's actually happening. Being proud of finding this funny is being proud of your own ignorance.

<comment><USER8> You could explain what's actually happening instead of ridiculing people for not knowing.

<comment><USER9> According to the comments it returned a modified immutable date. The original date is not modified.

Poor function naming perhaps, (should be `modified()`), but it's not really one of the things that makes PHP infamous.</comment></comment></comment>


Show HN: Coffee++, idea for a language that compiles into C++ - <AUTHOR> https://bixense.com/coffeepp/ <comment><USER2> I'm definitely upvoting this, as i think this is very much the right direction (I'm actually working on something similar).

After reading into it, I think for me personally it really isn't enough though.. These are some of the reasons why I'll never use it :

1\. using := instead of = is straigh up worse. No way i'd use 2 characters instead of 1 for an operator that common.

2.i don't think the eventuality of bugs really justifies the repetition of public and private at EVERY SINGLE variable, that's a lot of repetitions

3\. If I have to learn a new syntax, it really has to make my life easier: this Definitely includes automatic generation of all needed include statements (or import, whatever). I know there is some work to do to make it happen, but we definitely are able to do it in 2017. No way imports are something we should be doing by hand anymore

4\. (also a lot of other minor things that don't add meaning, like (int argc, char __argv) that really shouldn 't be there)

Of course I hope it's clear that this is my very personal point of view :)

<comment><AUTHOR> > 1\. using := instead of = is straigh up worse. No way i'd use 2 characters > instead of 1 for an operator that common.

Maybe you have mistaken := as the assign operator? It rather is for local variable declaration:

foo := xy

becomes

auto foo = xy;

so it's 2 characters instead of 7 :)

> 2.i don't think the eventuality of bugs really justifies the repetition of > public and private at EVERY SINGLE variable, that's a lot of repetitions

Good point. My thinking was that Java/C# seem to be fine with that decision. Also the : after public/protected/private clashes with Coffee++'s Python-like scopes.

> 4\. (also a lot of other minor things that don't add meaning, like (int > argc, char argv) that really shouldn't be there)

The reason for keeping stuff like (int argc, char argv) is that I want this to be used in C++ projects in the sense that you could have some Coffee++ files and some C++ files together with the only difference, that your build system translates the Coffee++ files to C++ before compiling. But I'm open to replacing other annoyances of C++. Maybe

        int main(std::vector<std::string> foo):

could be translated into

        int main(int argc, char** argv) {
            std::vector<std::string> foo;
            for (int i = 0; i < argc; ++i) {
                foo.emplace_back(argv[i]);
            }

;)

</comment></comment><comment><USER3> What is the point ? If it is just academic curiosity that is fine. But if it compiles one to one to C++, then it is just a different and more Python-like syntax for C++ ?

<comment><USER4> Every programming language can be described as "just a different syntax" for some other language, e.g. "C is just a different more Algol like syntax for assembly language." The differences in syntax is what can make a language useful (or not useful, e.g. Brainfuck).

<comment><USER5> That isn't really true.

There are clear differences in semantics between most programming languages. C is not just a different syntax over assembly: It has a type system, and obviously restricts what you can do (e.g. C abstracts over the registers)

A higher level language can be translated to a lower level one, (hence why Haskell can exist), but saying it's a purely syntactic transformation is extremely reductive.

<comment><USER4> A Haskell program compiles to something that uses places and mutates what is stored in those places because a Haskell program ulitimately runs on a machine designed with the Von Neumann architecture.

Reduction is what compilers do. In the old days C was often compiled to assembly (at least the parts that were not in-line assembly) and the assembly was assembled and all of it got linked into an executable. Crenshaw's classic _Let 's Build a Compiler_ is a great way to see how it was done even if it is written using Pascal. [http://www.stack.nl/~marcov/compiler.pdf](http://www.stack.nl/~marcov/compiler.pdf)

<comment><USER5> Umm, I know how compilers work.

C is compiled to still compiles to assembly, but usually (GCC) your compiler driver handles assembling, linking etc.

Haskell is translated to core (basically a simplification of a small subset of Haskell), then the STG(The abstract machine, spinless-tagless-Gmachine) then Cmm (Basically unsafe C) then LLVM.

<comment><USER4> The turtle at the bottom of Haskell is machine code...mutable non functional machine code that is isomorphic with the Haskell source.

<comment><USER5> The machine code can still be basically functional. GHC doesn't use any mutable data unless you tell it to, it generates and then immediately collects garbage rather than reuse mutable memory.

You can have mutable data in Haskell, obviously.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I don't think this is a good idea. I don't like c++, many people don't, so if we're making something better, why make it depend on c++? Why not use a completely _new_ language, like D or nim?

<comment><AUTHOR> Because of existing C++ code. Most languages only have a C FFI - not C++. With Coffee++ you can just mix C++ and Coffee++ source files.</comment></comment>


Ask HN: Side Projects at BigCo (Washington) - <AUTHOR>

http://apps.leg.wa.gov/rcw/default.aspx?cite=49.44.140
When I read this, I think that it would be OK for me to start an open source project so long as it is unrelated to my work.
Have people done this? Are you doing this? What are the potential ramifications for doing what I want and making a new open source project and be public about it. <comment><USER2> As long as you do it on your own free time and doesn't result in a product that directly competes with your employer makes/sells, none.

</comment><comment><AUTHOR> Clickable: <http://apps.leg.wa.gov/rcw/default.aspx?cite=49.44.140></comment>


Why IT needs to stop worrying and learn to love the iPad (and other tablets) - <AUTHOR> http://www.itworld.com/mobile-wireless/160253/ipads-become-inevitable-enterprise-it

<comment><USER2> As someone who runs an IT department and has tested these things pretty extensively this article is uninformed. To address his points...

On Resentment: No IT department in their right mind acts because "users might resent us if we don't". You try to make the users as happy as possible but resentment is part of the job. Because people discover cool things all the time that just aren't feasible given a corporate environment (web based office suites are the perfect example of something users want and I'd love to implement but since the data privacy guarantees aren't what they need to be it can't be done).

On Functionality: So far we've found the iPad doesn't present many functionality gains. The approach I've taken is a "try before you buy" strategy. Which is I have an iPad that I lend to people who want one. In order to get it they have to give me their laptops. Then after a week if they want to keep the iPad in place of their laptop I let them. Thus far no one's kept the iPad. Mainly because it lacks a full version of office and it lacks Flash.

That's not to say there aren't uses. We've deployed 5 iPads at this point to people who just needed to view their data using Box.Net. But those were people who didn't already have a laptop and we still get complaints about the iPad's limited functionality (even ofter loading the full iWork suite)

To drive home the point let me quickly address his individual scenarios...

Constant Connectivity: Users who need this are better served with smartphones. Constant Connectivity doesn't help if the person chooses to leave the iPad in their car because they don't want to carry it around.

Data Access: This is the only point I agree with

form-based data entry: In our tests a person who can type 80 wpm drops to 13 on an iPad. So unless those forms are really, really short this isn't a valid point (though I've been testing a Motorola Xoom because it has Voice Recognition accessible in every app and the results are promising)

simple note taking: Again see the previous point. The notes better be very short.

Presentations: Even though the amount of work to transfer a presentation to an iPad is reasonably small it's still more work than unplugging your laptop, shutting the clamshell and carrying it to the conference room. Plus, in my experience most people finish their presentations about 30 seconds before the meeting anyway.

<comment><USER3> > Mainly because it lacks a full version of office and it lacks Flash.

How is Flash useful in this type of environment? Are they disappointed about video and games?

<comment><USER2> Not so much video games as news sites like TMZ, MLB.com and so on. Definitely not work related but that's sort of the point. They won't install the TMZ or MLB app on their iPad because they don't want to get in trouble but they can't access the web site. In the real world people use their work computers for personal stuff and get annoyed when they can't.

(For the record I have a policy of no-repeat which means even if users tell me they are going to personal sites I don't repeat it because I don't want them to have to hide it from me if one of those sites causes a security problem)

</comment></comment></comment><comment><USER4> Sounds great to me. A whole new platform that will need management tools, testing, productivity apps all redesigned. It's like a whole new IT world to spend money and time on.

 _People think IT policy making is like this:_ Secret IT meeting... "Take away all hardware that's remotely useful, because we don't want to do any more work!"... or alternatively "keep the equipment old and buggy to justify our existence!" /twirls mustache

 _When IT policy making is really like this:_

IT: "Hey management it would be fun to try out some new cloud/tablet/virtualization/SaaS etc..."

Management: "Is the cost greater than $0?"

IT: "Well yes for setup, but we could save-"

Management: "Denied"

And after managment reads this article it's:

Management: "Hey IT support tablets now!"

IT: "Can we drop support for Laptops?"

Management: "No! Of course not!"

IT: "Can we hire someone to help now that we'll have three devices for every mobile user? (phone, laptop, tablet)"

Management: "Nope! Just work more unpaid overtime."

IT: "It will cost some money to build backup/recovery capabilities into these devices."

Management: "No budget changes, we're in a spending freeze."

IT: "Then you won't be able to read employee email that they send/receive on their iPad then."

Management: "NO IPADS ALLOWED!!!!"

</comment><comment><USER5> Frasier Spiers is the IT Manager for a school in Scotland that gave an iPad to every student in the school.

His blog - <http://speirs.org/> \- covers both the shortcomings and positives of the rollout. In general it seems to be a qualified success (in particular from a management standpoint versus laptops of any kind).

</comment><comment><USER6> iPads are great devices for the field force, especially pharma reps. Big pharma is ordering them like mad. Reps love them, far less clutter, always on, big enough to run a presentation on and capture a signature for a sample drop.

Cegedim, Veeva, ... iPad solutions are available and much sought after.

The old school tablet pc is dead in that vertical.

</comment><comment><USER7> Great ammunition for those of us with day jobs. This is the kind of article upper management loves and should really grease the wheels.

<comment><USER8> Not really, it is just filler piece. It does not answer the question, that your manager will ask you:

What's the ROI?</comment></comment>


There Are Whales Alive Today Who Were Born Before Moby Dick Was Written (2013) - <AUTHOR> https://www.smithsonianmag.com/smart-news/there-are-whales-alive-today-who-were-born-before-moby-dick-was-written-660944/?no-ist <comment><USER2> The book "Scale: The Universal Laws of Growth, Innovation, Sustainability, and the Pace of Life in Organisms, Cities, Economies, and Companies" (phew, long name!) is a fascinating read about how the lifespan of whales, humans and shrews are connected and all mammals are basically the same type of system only scaled to various degrees. Example: the number of heartbeats during the full lifespan of a whale and a shrew is more or less the same. Bigger body => longer lifespan.

It then goes on to analyse how cities and companies grow using the same system thinking. Why do cities survive for centuries while companies typically go under after a few decades?

Highly recommended.

<comment><USER3> There's a pretty cool exception to this. A lot of bats tend to have long lifespans. Many microbats can live 25-30 years on average but, as the name implies, are fairly tiny. The species I worked with all weighed under 20 grams.

The leading theory is that because of their hibernation, their heart rate slows down and their lifespan is longer but the number of heart beats still seems to average out when compared to other species with faster or slower heart rates.

<comment><USER4> > The leading theory is that because of their hibernation

So, are they an exception because other hibernating species don't seem to show this? I would expect if it's hibernation, we should see it pretty easily in species that hibernate for winter regularly, like some bears. Or maybe chipmunks or squirrels, if those are easier, but I'm not sure the hibernation is quite the same, and whether that might affect it.

<comment><USER3> I'm not sure entirely the details, but bat hibernation is different than bear hibernation. They don't store fat. The only mechanism they have to survive while hibernating is lowering body temperature and heart rate. It's actually not a true hibernation, they go into extended torpor, they still wake occasionally to drink and mate with sleeping bats. Bats also go into a daily torpor and another one in the latest part of the night.

Many bats are actually crepuscular and not nocturnal, meaning they're active from dusk until early night and late night until dawn. The rest of the time bats spend in that lowered heart rate and body temperature torpor state. This is why white nose syndrome is so destructive. It causes bats to wake up early from hibernation and they end up starving because they can't get food and they can't hibernate properly.

It was about 6 years ago I last worked with bats. That was the leading theory at the time. It may have changed, there's been an increase in bat research since then, but knowledge about bats is fairly scarce compared to other species. There just hasn't been a lot of work done in north america on then and there's a fair amount we really don't know. In Europe and especially England, there's been more research done but, the knowledge doesn't necessarily apply to species elsewhere. Bats are really cool they're distinct than most other small mammals. They're in an order all by themselves and microbats are a huge sub-order with thousands of species all over the world.

</comment></comment></comment></comment><comment><USER5> I am currently reflecting on the passage of time - the last two (working) decades have seemed like a flash of missed opportunities and amazing opportunities grasped and children born and growing

But to have two centuries of children and companions ... well that's just amazing.

(On the other hand the whales are probably thinking something like "you harpoon wielding ape bastards, wait till our spaceship returns we'll have you then")

<comment><USER6> You're comparing your accomplishments to the rest of society. If you feel like you haven't used your last two decades appropriately, and feel like you could really use a couple centuries, remember that if that were the case, everyone else would probably have the same lifespan, and you'd be back to the same position you are now, comparing yourself to others.

</comment></comment><comment> daniel-cussen Time to extend copyright laws to protect whale authors.

</comment><comment><USER7> What a magnificent creature, thank god they can survive in that cold weather. Otherwise thye would have been hunted to the extinction.

</comment><comment><USER8> There are some Greenland sharks that are almost 300 years old, possibly as old as 500. [https://www.theatlantic.com/science/archive/2016/08/these- sh...](https://www.theatlantic.com/science/archive/2016/08/these-sharks-live- to-400/495425/)

</comment><comment><USER9> How can any human come up with the idea of hunting creatures that are 200 years old? Where do we get this sense of superiority?

<comment><USER10> Pigs are smart and can live to be around 15 to 20 years old, and by all accounts are as smart or smarter than whales.

I don't see how the expected lifespan of a single individual is a determining factor in the moral calculus of what humans should or shouldn't kill.

Why isn't it morally equivalent to kill 10 pigs who could have collectively lived to be 200 years old for bacon and killing one whale who could have lived to be 200?

<comment><USER11> Maybe we need to ask ourselves:

Why kill other sentient beings at all when it's not necessary anymore for our survival?

<comment><USER12> Ok, but what if plants are sentient?

[https://www.smithsonianmag.com/science-nature/the- whispering...](https://www.smithsonianmag.com/science-nature/the-whispering- trees-180968084/)

What if survival depends on suffering to some degree?

<comment><USER11> Thanks for that link.

I should have phrased the question slightly differently.

It's more around whether animals (e.g. vertebrates) can suffer and experience pain like we do.

The answer is yes - that's why we use animals in pain research and that's why a pig or cow screams when it's cut with a knife for example.

Even fish feel pain [0].

Plants react to stimuli - but plants don't have a nervous system, they don't have nociceptors (neurons responding to life threatening signals) to experience and feel pain, they don't have any means to 'escape pain', e.g. running away from danger.

[0] [https://www.smithsonianmag.com/science-nature/fish-feel- pain...](https://www.smithsonianmag.com/science-nature/fish-feel- pain-180967764/)

<comment><USER12> No problem. It's a thought that's been consistently nagging me for a while. It kind of throws a lot of things for loops.

For instance, you make a point of specifying you're considering whether things can suffer and experience pain _like we do_.

Why is that the delineating factor here? We don't really understand intelligence of consciousness and we've been basing our measures of both on the only instance where we're relatively confident exists. We think, therefore we are.

But what if we're wrong. What if our way isn't the only way to be intelligent, to be sentient. Why must they experience pain the way we do in order to be afforded protection? If we're just privileging our type of sentience over others, we're just drawing a different line. And always when someone draws a line, I ask, why there?

<comment><USER13> I suppose the most inclusive line would be drawn at the point of our own survival. So at the very least we'd eat plants until we figure out some alternative that doesn't 'kill' plants.

From there on it's a tough one though...

<comment><USER12> Ok, but what gives you more of a right to survival than the plants you kill? If anything, plants are the most benign entities on the planet, they're the only beings capable of producing their own food.

These are hard questions, I don't expect anyone to have the answers.

<comment><USER14> Plants kill animals by being poisonous, and sometimes by eating as in the case of the pitcher plant. Animals kill plants by eating, and sometimes by poisoning, like when dog pee kills the grass.

Everything kills everything else. Living things are merely temporary storage for genetic information. The genetic information that increase's its number of redundant backups faster then the number of instance failures wins.

<comment><USER12> I can't think of any other species off-hand that has a developed sense of general ethics. We're not discussing how the world is. It is how it is.

However, if you're of the opinion that is unethical to cause more suffering and that killing other beings just to ensure your own survival then plants having sentience is a pickle.

Something has to give. You have to give in to the circle of life and acknowledge that your survival will bring in some measure of suffering to other beings. Or sacrifice yourself since there is no way to eat ethically by your standards.

Obviously, the vast majority of people will choose survival. But now they have to draw a line. What's friend and what's food? And once you draw that line, you have to defend that choice. You can't just say "because it's X", you have to explain why it is so.

I mean, learning all of this has just made me more of a "speciesist". I don't believe there is any way to resolve the conflict.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> are any of these whales white though?

<comment><USER16> C'mon man, TFA addressed this.

<comment><USER15> sorry in a bad joke mood lately.</comment></comment></comment>


Angry Businesses Organize Anti-Yelp Websites. This Is A Sure Sign Of Their Success. - <AUTHOR> http://www.techcrunch.com/2008/07/02/angry-businesses-organize-anti-yelp-websites-this-is-a-sure-sign-of-their-success/ <comment><USER2> The 'anti-yelp websites' cited in the article are a blog with 1 post and a discussion board with 1 thread.</comment>


Why Aren't There More Designer Founders? - <AUTHOR> https://www.wired.com/2013/08/why-arent-more-startups-founded-by-designers/ <comment><USER2> This is actually an interesting question. I suspect it has to do with a combination of factors. For example:

\- Design alone won't get you very far in a service business (unless the service is design, in which case you're competing in a crowded market), so you're eliminating a large amount of potential businesses off the bat

\- Design isn't often the foundation of a tech business, the technology is. It makes sense then that design is an additional function rather than a foundational role. What I mean here is that a designer can slap together slideware that looks nice, but a tech person can put together an MVP and a sales person can turn it into money

\- Unless something has changed, design doesn't really pay very well as a career unless you go the agency executive route. As a result, you're not going to have many designers floating around with "startup ramen" cash to burn in their 20s/30s in comparison to big-tech engineers

\- I suspect (but have absolutely no evidence) that there is a mindset difference between designers and founders with traditional backgrounds that plays a role, but I'm not sure what it is

Of course, none of this is to say that designers can't be amazing founders (they absolutely can) or that design isn't important in the business world (it absolutely is), but rather that design doesn't really give you a boost in a modern business founding setting like other skill sets do.</comment>