35 ms·

Agile Lite: Agile without all the burnout

• beardedwizard 8y ago
  I think agile has always suggested modifying to fit the team - so then do we need an agile light, or just critical thinkers doing whatever agile provides actual value?
  • volfied 8y ago
    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.
  • hvidgaard 8y ago
    The core DNA of agile was always adaption. But when your adaption consists of using your existing methodology with some agile concepts, but no retrospect on the methodology itself, you're not agile by definition. What this "Agile Lite" puts right in the center is to split up your goals such that you can make meaningful work in a 3 week window, and track it asynchronously. Managers are free to have an overall plan for release in 12 months, as long as it's split up into units of work at most 1 day long. What I think I read from your comment is that if you couldn't get this to work in the "Old" agile, you will fail with this as well, and I agree.
  • chris11 8y ago
    Personally I think that asking how teams do agile differently and how team members change agile practices can be a good gut check to see what agile is like at a company. If some teams do scrum and some do kanban or some teams have daily standups and others don't, then agile is probably more developer driven. But if the answer is something small, like the time of the daily scrum then agile's probably management driven.
• sailfast 8y ago
  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.
  • matwood 8y ago
    I agree. The team (which includes developers) should be the ones pulling issues into the sprint. Leads and stakeholders can prioritize on their own, but again developers need some say in that process because technical issues my drive some prioritization. I get the concept, but a week off seems a bit extreme and a hard sell. The team should already be working in some slack time in the sprint. The reason for slack time is that it gives a bit of a cushion if something runs over, and it keeps people from burning out. The other big upside for those on the outside is it helps build confidence that when a ticket is pulled into a sprint it almost always get completed.
    • hopler 8y ago
      No no no! Agile has never been about predicting what you will do during a spent and then having slack or crunch time. Agile is about ranking your work by priority and dependency, setting meaningful milestones, and then adjusting your estimates frequently to avoid false promises and react to changes in the environment. If you don't finish planned work in a sprint, that is a planning success because after only a brief 2-4 week delay you actually know your performance against estimate and got clear information about how much you can do in a month, and a better chance at estimating what you can deliver next month.
• rutthenut 8y ago
  Pah, I've not seen Agile cause burnout at all. Far from it, the way sprints become long slow walks and stories move from one sprint to the next, at the altar of 'Agile' and not 'Delivery', developers appear to be under way less pressure than in older forms of project management. With, you know, deadlines...
  • commandlinefan 8y ago
    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".
• PaulHoule 8y ago
  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.
  • brazzledazzle 8y ago
    >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. You’ve succinctly defined the problem in a very profound way. A verbal punch to the gut for sure.
  • Matticus_Rex 8y ago
    > 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. Wow! Sounds like decision-making processes needed tweaking even aside from Agile practice.
• batchfile 8y ago
  How do you answer the c-level concern that we are basically going down to 75% output?
  • hvidgaard 8y ago
    Telling your developers to bugger off for 1 week every month will never work out. They still need to be at the office, but they can pursue learning, help with planning (this is critical), or focus on other development tasks they actually want to make.
    • sefrost 8y ago
      Ah, when the linked article suggested developers go "surfing" I thought it meant in the sea, not the web.
      • hvidgaard 8y ago
        I think that was the intention. I just don't believe it will work out.
  • DJBunnies 8y ago
    It was always 75%. The choice is: predictably over time, or when burnout occurs & all at once (for each engineer.) C-bro wants predictability.
• golergka 8y ago
  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.
  • beat 8y ago
    Apply the five whys. Why do you have a critical bug in the production release? Is is environment-specific? Did the released code not match requirements? Or were the requirements themselves wrong? It's not "What do you do about critical bugs?", it's "How do you stop having critical bugs so they don't disrupt your development process?" If criticals in production are a regular part of your life, then you're doing something wrong as an organization. But to answer the question itself... if you have a critical bug that requires enough development resources to prevent completing the iteration successfully, then the iteration is ruined. End it right there and start over with a fresh planning session. Yes, everyone will howl. Pain is your body telling you something is wrong.
    • SketchySeaBeast 8y ago
      > If criticals in production are a regular part of your life, then you're doing something wrong as an organization. I believe that may be slightly idealistic - a test case doesn't get covered by the stakeholders and suddenly once the solution is in, it suddenly pops up its ugly head. It takes a ton of self-awareness and resources for a project to know its every use before it gets to the end user.
      • beat 8y ago
        One oddball case does not a "critical" make. That's part of it. Not every bug is a critical bug. Not every bug is worth wrecking your iteration over. And if you're seeing critical bugs that wreck iterations on a regular basis, we're back to my point - you're not planning very well.
• myth2018 8y ago
  That's a good idea. Consulting firms have really overcomplicated Agile a lot. I've been displeased to meet bloated implementations these last years. My only point is that, at least in the companies I've worked for so far, a practical Agile implementation must provide some device for making a "pressure" over the team to avoid too many items ending up carried to next sprint. Of course there are lots of legitimate situations where an item doesn't fit in the sprint and this should be acknowledged, providing inputs for the estimation of the next sprint and making those estimations more accurate. However, in my opinion, it should also be clear to everyone that those slippages have consequences and everybody should be employing their best efforts. I don't consider this a deficiency in the article though, since Agile in itself seems to be optimistic about teams by its very nature. I believe this is going to get me some downvotes, but this is unfortunately the reality I live in and if I were going to devise an Agile implementation for my team I would take this into account.
  • ajmurmann 8y ago
    Sorry, there is no "faster" button. The only lever you have is cutting scope as you go. Fixed scope just makes no sense. Otherwise you get one of three outcomes: 1. We underestimated how much we can get done. People now start gold playing stuff and wasting time that would be better spent on future backlog items. 2. You estimated just right and are done Friday at 5pm. Obviously this doesn't happen frequently. 3. You overestimate and now something's gotta give. People will start cutting corners or putting in over hours as a punishment for being bad at estimation. This is not sustainable. We need to get away from the fixed scope mentality with which Scrum had poisened the Agile pool. If we cannot trust or developers to do the best work they can and wanting to be proud of their work, the organization has entirely different problems.
    • myth2018 8y ago
      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.
• aboutruby 8y ago
  > Issues may not be added to the sprint I don't see this happening, even if that's a good rule, because issues come up that take higher priority than existing issues.
  • SketchySeaBeast 8y ago
    I noticed that as well. That'll be pushed back against, and the leadership is going to decided that they must respond to SOME issues to appear responsive, and let's be honest, it's going to have to happen regardless of project ideology. There'll be some silly rule put in place that only priority "X" issues get looked at mid sprint, and suddenly every issue is going to be priority "X", and now someone gets to spend the time they would have spent fixing the issue going "Ok, is this really a priority 'X' issue?" and fighting with whoever raised it.
    • beat 8y ago
      Decent iterations cannot be done without immediate management playing defense, period. As long as anyone is allowed to interrupt the iteration, then iterations are just going through the motions and won't solve any actual problems - because the problem is a lack of control. The engineer's response to unplanned work should be "Go talk to my manager", and the manager's response must be "Wait til next iteration". If the team can't defend its own boundaries, it's hosed, period.
      • SketchySeaBeast 8y ago
        I've never know immediate management to understand the business nor the system as well as the ones with boots on the ground. I've yet to see a situation where the manager doesn't end up coming out of his office and asking someone on the team "so, what's this mean?"
        • beat 8y ago
          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.
• pferde 8y ago
  Interesting idea. All I've experienced so far was "Agile Enterprise Edition" - cargo-culting all the agile terms, wasting developer time in overly-long standups, yet having a fixed, set-in-stone schedule and delivery plan. Hilarious.
  • eeZah7Ux 8y ago
    Same here: it's make-believe work.
  • jupiter90000 8y ago
    Same here. I call it "agile waterfall" development.
  • dilyevsky 8y ago
    An idea that you can document and track newrly 100% of time of 100% of your “resource” gives mediocre manager great pleasure.
  • eeZah7Ux 8y ago
    Spot on. Agile, scrum, standups are just tricks to enforce micromanagement and take agency away from engineers.
    • pferde 8y ago
      Not quite. Agile, when done right, by small-to-medium teams, can be effective. However, whenever a big corporation tries to jump on the agile bandwagon, it turns into nightmare fuel.
      • eeZah7Ux 8y ago
        The usual narrative. A tool that almost nobody is doing right - but blame the people and not the tool.
• neogodless 8y ago
  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.
• deleted 8y ago
  [deleted]
• yamadapc 8y ago
  TL;DL Ignore all existing literature and experts' previous experience. Simple.
• hanzg 8y ago
  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.
• EngineerBetter 8y ago
  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-jones https://www.linkedin.com/pulse/scrum-makes-you-dumb-daniel-j... https://youtu.be/k9duArRuSjQ https://youtu.be/k9duArRuSjQ
  • fatnoah 8y ago
    Scrum is a framework to achieve "agility" and people forget that. The point is agility, not scrum.
    • EngineerBetter 8y ago
      Indeed, and the Scrum-Industrial Complex has vested interests in codifying a certain format that it can sell.
      • reallydontask 8y ago
        not heard that term before (Scrum Industrial Complex) but it's pretty good, going to use it from now on :)
        • beat 8y ago
          I just used it in another comment. :)
    • ako 8y ago
      And agility in this case being Business Agility: the business being able to change course, not being hold hostage to a years long plan which cannot be changed. Agility has nothing to do with software development, and everything with business.
• tuxie_ 8y ago
  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.
• btbuildem 8y ago
  You're suggesting giving devs 12 weeks vacation? I love it. Our management would murder you in cold blood for merely mentioning it.
  • ngngngng 8y ago
    I feel like our minds take at least 12 weeks off a year anyways, why not let our bodies leave the office as well?
    • geofft 8y ago
      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.
• davedx 8y ago
  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.
• himynameisdom 8y ago
  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/
• dodyg 8y ago
  Agile Lite is like Diet Diet Cola. Agile is supposed to be Lite.
  • ajmurmann 8y ago
    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.
• bunderbunder 8y ago
  It seems like you could solve this problem in an even more dev-friendly way by sticking to one of the most fundamental principles in scrum (and possibly others): Don't schedule 100% of your developers' time, and definitely don't fill them up to 100% on coding work. Not even close. Devs are supposed to work at a sustainable pace. A sustainable pace leaves plenty of time for kicking your feet up on the desk in order to think about things. It leaves plenty of time for chatting with one's teammates to make sure ideas are fully baked before implementing them. It leaves plenty of time for trying out new ideas. And, importantly, it leaves the time for doing this relatively unstructured. Because the dev team is a bunch of working professionals who should be free (and trusted) to figure out for themselves when they need to take a pause from cranking through tickets in order to do other stuff. A "3 weeks on, 1 week off" approach doesn't get you this. I think that the spot where the car always ends up upside down in a ditch on agile implementations is a misunderstanding of the basic idea behind velocity. It isn't a KPI that you're supposed to maximize. It's a feedback mechanism that the product owner uses to manage the pacing of some of their own work, in order to make sure that the pipeline neither empties out nor becomes jammed full of work. If the PO is doing that job correctly, then they would be making tough decisions about what is and is not reasonably doable in a given timeframe, and providing backpressure to stakeholders when they're asking for too much. If they're instead accepting every single feature request, and dealing with the resulting backlog logjam by continually pressuring the dev team to work faster and faster (and more and more sloppily), then, no sense in mincing words about it, they're doing a bad job as a product manager. And the dev team is well within their rights to push back against them on that. Which, incidentally, is what the orthodox Scrum formulation is trying to do when it disallows the PO from deciding how many items (or story points, or whatever) to pull into the sprint. That's supposed to be based solely on the dev team's own opinion of what's a reasonable amount of work to take on.
  • LandR 8y ago
    >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...
• mabbo 8y ago
  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.
• gfs78 8y ago
  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)
• ai_ja_nai 8y ago
  25% overhead is a little too much
• chrismeller 8y ago
  One of my biggest pet peeves is the pointlessness of standups. I have never worked anywhere where they did not immediately become a status update, which is (in theory) what the board is for. Why is the board not up to date? Because we just talked about all of that an hour ago and doing all of that over again is infuriating. What is the status of ticket x? Either wait until the next day’s status report/standup or start writing down notes you can reference. While you’re at it, just go ahead and put those notes in the comments on the board... oh wait.
  • jaequery 8y ago
    I was once a project manager on a team that does daily standups. What eventually happened was that the team would usually re-iterate what I say, or vice versa. It made me question what was the point of doing standups.
    • jgust 8y ago
      The point of standups is to help teams to learn to communicate and to steer the team to a habit of working on the most important things. Once that's a behavior, standups can be less frequent or dropped all together. This is especially useful for new teams or when the team changes.
      • chrismeller 8y ago
        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 standups - you’re supposed to stand so that everyone gets annoyed if it takes more than a handful of minutes. If you’re discussing what you did yesterday, what you’re going to do today, when you think x is going to be completed, what is blocking you (other than that so-and-so owes you such-and-such), or anything else other than nodding that you’re good you’re missing the point and that’s where the slippery slope of pointlessness begins.
        • Scarblac 8y ago
• 013a 8y ago
  I prefer a structure of: variable length sprints + optional 1 week interlude. I don't understand why the "sprint length" is this set-in-stone thing. "We do 3 week sprints, we never deviate". That's not very agile. Sometimes you've got very well-defined requirements on a large project and you could go heads-down for 3 weeks on something. Other times, you've got a good "phase 1" that would take 1 week to implement; so let's implement that, then plan the next sprint. Or you might want to take a sprint to just write more tests, upgrade dependencies, etc. Plan it, take a week, then lets resync. The interlude week is used to decompress and give engineers time to plan their own schedules. They can work on whatever they want; they create the plan, create the tickets, and execute. Ideally it should have some thread of connectivity with the team's overall mission, even if only slightly. Leadership uses this time to plan the next sprint. There's a natural "bulk up" on meetings during this week that were avoided over the sprint itself. Specifically: the planning and retros happen during this week. Most teams I've worked on put the Retro on the final day of the sprint. At one place it was at like 11am. This is crazy! Combine that with a typical Friday drop in productivity and you've just written off the entire last day! During a 2 week sprint, that's a full TEN PERCENT of the sprint. Instead, schedule the retro on Monday morning during the interlude, and full team planning on Friday before the sprint. Often those interlude weeks end with work that's best classified as either "hackathon-style" (this is cool, not sure if we can use it right now but lets bank the code and revisit) or "infrastructure" (we've wanted this done for a long time, but it never got priority, we've finally done it, awesome). Burntout engineers will naturally schedule themselves less to do or easier things, like dependency upgrades; this is a great signal to management that something is up and we should talk about it.
  • systemtest 8y ago
    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).
• gpmcadam 8y ago
  This is parody, right?
• dyeje 8y ago
  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.
• mindcrime 8y ago
  One change I'd suggest: drop the use of the term "sprint". Prefer "iteration" instead. Talking about "sprints" is a bad metaphor, and the metaphors we use do shape the way we think and act to some extent. IMHO, along with the "gap week" between iterations (which I vehemently agree with), this is part of avoiding the conditions that lead to burnout... if you're sprinting, sprinting, sprinting, all the time, bad things are going to happen. Not everything you do needs to be at balls-out, breakneck, full-sprint speed.
  • bendixso 8y ago
    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.
• ausjke 8y ago
  Working with agile for the last half-year. while it does make people agile, i.e. stir things up with daily stand-ups etc, it also causes more chaos on the technical side. anyone can pick up any stories, after a while there is nobody that is an expert in any domain, everyone knows a little about everything but nobody knows any subject deeper, no more domain expert. Now bugs took forever to debug, the whole group is constantly in panic mode and burnt out. to make things worse, document is neglected due to agile's own philosophy and due to the daily chaos, and it makes development much much slower. In short, agile gets everyone going and looking busy, but the product can never deliver because nobody knows enough to fix hard issues. Many of them are senior developers, the old model seems working better, a bit slower and quieter but products are out of the door with good quality. Agile is bad from my experience so far, our product is embedded system that can't really be sprinted like those fancy front-end UI projects and such. Agile does not fit us well.
  • cromulent 8y ago
    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.
• robinduckett 8y ago
  Seems like Waterfall with extra steps
• viach 8y ago
  >> 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?
• shay_ker 8y ago
  No matter what you do, or what process you implement, if the organization does not _respect_ engineers, your life will categorically suck. As others have noted, the amount of process involved with "Agile" these days is not in the spirit of the original Agile Manifesto. Additionally, how is it that _some_ organizations do it well, vs. others that make life hell? This fundamentally comes down to how much the organization values and trusts its engineers. You only implement process if you cannot trust a person or group of people to do something on their own. You only track and measure performance by metrics if you do not trust them to work hard. This is easy to verify - how often is senior management beholden to process & measurement? Usually, the only "process" they need to go through is related to laws and regulations, which - again - is fundamentally based on how must we trust one another.
  • plutonorm 8y ago
    I can honestly say that in 15 years and 8 companies I have never seen one that respects developers.
    • shay_ker 8y ago
      The company I currently work at respects developers immensely.
    • mongol 8y ago
      What does that mean, really? What is a sign of respect that you find missing?
      • plutonorm 8y ago
        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.
• timwaagh 8y ago
  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.
• kevlar1818 8y ago
  This project should be called Scrum Lite. Agile software development is a philosophy, not a process or prescription.
• systematical 8y ago
  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.
• devin 8y ago
  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?"
• everdev 8y ago
  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.
• snarfy 8y ago
  Agile is the Agile Manifesto. Anything else is not. All I see are references to Scrum. Maybe this should be called Scrum Lite?
• steve76 8y ago
  It's wrong to assume your client is good, doing good things, and not hiding anything, like they are taking all the credit, and putting all the blame on you. It helps if the client is another programmer so they actually know what they are asking for. Too often clients ask for way too much. Ask for one thing, do it right, make money, and come back for more features. The big trend I am seeing with designs are "time bombs". You get deep into what they want, and find out they hid something that makes it 100x more complicated. Why? !!!
• gfodor 8y ago
  Any methodology where it takes more than a month to turn around a bugfix for a discovered issue in the first week of the month seems flawed. Unless I'm missing something, that's the case here.
  • scriptkiddy 8y ago
    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.
• foobar_ 8y ago
  Agile is dead. As a subculture the muggles and sociopaths have taken over Agile. I think #NoEstimates is the next cool thing.
  • jrs235 8y ago
    I feel like #NoEstimates has been a thing. I think #NoMethodology or #NoProcess is the next cool thing (Some might call it #GSD).
    • foobar_ 8y ago
      #NoProcess seems ideal for small competent teams. We need to get out of the estimation hell for normal projects.
      • deleted 8y ago
        [deleted]
• y-c-o-m-b 8y ago
  What we do where i'm at is the perfect amount of "agile" for me. Granted we're a small team, but it's worked VERY well for 3 years now. What we do: - Standup twice a week, never lasts more than 15 min - 1 hour "planning" meeting each sprint where we discuss new stories for the upcoming sprint and assign them points - 2 x 2-week sprints (1 release a month containing work from both sprints), this gives us flexibility for unexpected problems if we have to cut stuff out of the release or add features missed during planning - We do not track hours - We track velocity by points, but it's only a guide for the next sprint and not taken as do or die - Developers freely choose what they want to work on, but they must go down by priority on the sprint's items - When a dev is finished with their story, they pickup the next item in the sprint - If all sprint items are taken/done, we grab from the next sprint assignments. If those are all done, we have another planning meeting or work on tech debt in the backlog EDIT: Formatting, words
  • joelesler 8y ago
    This is essentially how I run my team. Very close.
• devstoner 8y ago
  I've been through the wringer it sounds like this team is going through more than once. You have to teach your stakeholders and managers how to be agile, if they aren't willing to actually get that, it always turns into a death march eventually.
  • jrs235 8y ago
    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.
• shatteredvisage 8y ago
  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?
• dkhenry 8y ago
  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.
• jrochkind1 8y ago
  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.
• diminoten 8y ago
  > 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.
• aitchnyu 8y ago
  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.
• nobatron 8y ago
  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.
• alasdair_ 8y ago
  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.
• JakeWesorick 8y ago
  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.
• tempodox 8y ago
  I have yet to see an implementation of Agile that's not misused as a pretext for micromanagement.
• EnderMB 8y ago
  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.
• 1337shadow 8y ago
  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).
• EugeneOZ 8y ago
  Whole week just for talking? Stopped reading after this.
• gumballhead 8y ago
  I've never gotten burned out from working too hard. I get burned out by having no say or control over what we are working on or how it's done, and by getting stuck working on low-value tasks for prolonged periods of time. Those projects are the ones that make me not excited at all to come to work. It's usually because the client / product owner has no idea what they're doing but still insists on making all of the decisions with no input from users / developers / designers. And it sure sounds ridiculous, but it is the norm. Developers are viewed as people who do not want to participate in meetings or planning, and who exist on streams of work to do. If the developers run out of work, they'll go crazy! As long as we "keep them unblocked" and have tasks ready for them, we're doing our jobs and they'll be happy!
  • JohnFen 8y ago
    > 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.
• geofft 8y ago
  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.
• rparet 8y ago
  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?
• msluyter 8y ago
  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.
• tshannon 8y ago
  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.
• edoo 8y ago
  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.
• amai 8y ago
  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.
• edpichler 8y ago
  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?
• OJFord 8y ago
  25% of my time painting and surfing? Where do I find a company implementing this brand of agile..?
• VectorLock 8y ago
  "Daily standups are discouraged" I'm sold.
• ozim 8y ago
  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".
• jarcane 8y ago
  > "sprint" mashes eject button
• ben509 8y ago
  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.
• ravenstine 8y ago
  If Agile really works so well, then why are there so many conflicting opinions about it?
• keithnz 8y ago
  This isn't agile (or lite), this is just ad hoc development with 1 month timeboxing.
• president 8y ago
  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.
• OnlyRepliesToBS 8y ago
  agile makes developers into cogs
• fallingfrog 8y ago
  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.
• bendixso 8y ago
  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
• bendixso 8y ago
  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.
• fukbezos 8y ago
  Agile is the scam of the century
• ironic_ali 8y ago
  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.
• elindbe2 8y ago
  God...I can only dream about such a work life.