Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile Lite: Agile without all the burnout

github.com

Post reply on HN
Print view View original

91–100 of 292 posts

Re: Agile Lite: Agile without all the burnout

#91

Post by beat »

SketchySeaBeast wrote: post #55
beat wrote: post #52

Earlier quoted context omitted.

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…

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

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.

Re: Agile Lite: Agile without all the burnout

#92

Post by HelloNurse »

aboutruby wrote: post #12

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

Many projects have often predictable periods of intense testing and bugfixing without new feature development.

On the other hand, distinguishing between "the product doesn't do X properly" and "the product doesn't do X yet" isn't necessarily important or meaningful.

Re: Agile Lite: Agile without all the burnout

#93

Post by golergka »

sidlls wrote: post #76
golergka wrote: post #8

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,…

Here's how to handle the situation you are in right now: 1. Work with the team to identify what item in the current sprint will be delayed. 2. The EM and Scrum Master should communicate the delayed issue to their leadership. 3. Identify any long-term objective that will be delayed and communicate that as well. If there's a question about why a delay will occur be honest: either the critical issue affecting customers…

This is good advice, but I'm already doing something along these lines and my point is that this is not covered by the OP at all. My question was not intended as asking for advice for my personal situation - it was a criticism of published document.

Re: Agile Lite: Agile without all the burnout

#94

Post by shay_ker »

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

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

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

Re: Agile Lite: Agile without all the burnout

#95

Post by erikstarck »

PaulHoule wrote: post #79
erikstarck wrote: post #30

Earlier quoted context omitted.

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 understandin…

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…

That was a very good list of things that would typically come up in a healthy retrospective. But, yes, there has to be psychological safety first.

Re: Agile Lite: Agile without all the burnout

#96

Post by oasisbob »

beat wrote: post #52
SketchySeaBeast wrote: post #31

Earlier quoted context omitted.

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 th…

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…

The problem I've seen with this approach is when issues cross org boundaries and have externalities.

Say the event subsystem is shared or is under control of another group. They do maintenance, and the app doesn't restart and stays down because it had bad retry logic and won't retry after the connection is closed. Stupid bug, easy fix.

You're now hobbling that other group from doing their work, and depending on the discipline of the app team to fix it, and that bug may stay in the backlog a long time. Meanwhile, it's going to come up in a handful of meetings with a handful of people as it gets estimated, prioritized, assigned, touched again and again...

Coming to someone after diagnosing and helping them recover from a problem, only to be told "we're busy, come back three weeks from now" sucks.

Re: Agile Lite: Agile without all the burnout

#97

Post by timwaagh »

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

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

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

Re: Agile Lite: Agile without all the burnout

#98

Post by hopler »

matwood wrote: post #22
sailfast wrote: post #3

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…

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…

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.

Re: Agile Lite: Agile without all the burnout

#100

Post by hopler »

EngineerBetter wrote: post #24

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 peo…

"commitments" do not exist in Agile. Agile was created to remove commitments and insert collaboration in it's place.

You don't have to make big promises when your client has ongoing clear visibility into your progress.

Post reply on HN