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

Agile at 20: The Failed Rebellion

simplethread.com

Post reply on HN
Print view View original

181–190 of 320 posts

Re: Agile at 20: The Failed Rebellion

#181

Post by MauranKilom »

forgotmypw17 wrote: post #52

I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively. The "project manager", a DIFFEREN…

How did this approach deal with difficult technical/algorithmic problems where someone needs to investigate something before further decisions can be made?

Example: You want to improve performance. Somebody will have to fire up a profiler and measure things, and then figure out which hotspots are worth optimizing.

I totally get breaking it down to "set up profiling tool", "do profiling runs for workflow X/Y/Z", and "identify low-hanging fruit". Presumably these tasks are not going to take the entire sprint.

How do you plan the next step in task format? Do you not do any further work on the topic until the next sprint, where you then plan out concrete "optimize function X" tasks?

If not, i.e. whoever does profiling also gets to optimize code during the same sprint, how do you account for that in planning? Three dummy tasks "optimize a hotspot" without any actual idea what it will involve? Maybe it requires rewriting a component to use different data structures? Maybe it's just a single JVM config tweak? "Could be a 1 or it could take my whole life?"

Maybe it's just less common in certain domains, but this kind of "we need to investigate this issue and then decide what changes to make based on the investigation (and good engineering judgement)" - which is bread and butter in my part of the org - does not seem to fit into the "tasks with points" concept at all. Well, unless you want to always spread the process of "investigate issue", "identify problem and solution(s)" and "implement solution" over a whole month. That seems soul-crushing to me.

To be clear, I'm very interested in seeing how to make this mesh with Agile. But it feels like trying to write a binary search in a language that has no indirection or conditionals.

Re: Agile at 20: The Failed Rebellion

#182

Post by username90 »

Robin_Message wrote: post #156
username90 wrote: post #128

Earlier quoted context omitted.

Some developers might love just mindlessly doing trivial tickets week after week, since it means they don't have to worry about anything since the job is so easy. But others will view that as soul crushing, you can't say it isn't soul crushing for them.

Being able to break down a complex technical problem into mostly one point tickets doesn't mean it is easy or mindless, just that you're good at planning and executing.

It means that the day to day job is easy and mindless, even if it is some ok work being done during those meetings. Doing all the real work in a meeting every other week does seem soul crushing.

Re: Agile at 20: The Failed Rebellion

#183

Post by nicoburns »

pjmlp wrote: post #141
nicoburns wrote: post #139

Earlier quoted context omitted.

One key part of this that a lot of businesses miss is that this means that every member of the team shoul have direct contact with thw customer, not just a "point of contact"

Because that isn't something their management levels will even consider a possibility, given security concerns, politics, and whatever might come up if the project goes south and a lawsuit is bound to happen. These agile ideas only work in an ideal world of "we are all friends here".

I'm sure this is true of some companies, but I've definitely seen this done well in a few places. Often software agencies.

Re: Agile at 20: The Failed Rebellion

#184

Post by TameAntelope »

axegon_ wrote: post #178
TameAntelope wrote: post #174

Earlier quoted context omitted.

Even when a company is facing an existential crisis, your estimation is important to help decide if they need to provide additional resources or even replace you if you're not able to do the job (among many other things). They're not going to throw money at you forever, and demanding blind trust is completely unreasonable, especially so in an existential crisis. There is simply never a situation where not having a se…

Pretty sure I just gave you 3 examples where no one cared how much X would cost. "We want it by Q3, figure it out". Where is the documentation? "¯\_(ツ)_/¯". Who built the old system? "Last one died in 98". Who knows how X works? "¯\_(ツ)_/¯, you're smart, you'll figure it out, just remember, Q3". As I said you're either lucky or speaking from the so called "top management" perspective. Things look very different for a…

Yeah, average Joe in your examples here isn’t being given the whole picture. I’m not sure what your point actually is; are you saying that since Story Points don’t help you specifically, they’re a waste? Don’t you get how myopic that is?

Re: Agile at 20: The Failed Rebellion

#185

Post by xg15 »

AndrewKemendo wrote: post #41

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…

So then, what do you advise to do? Give up?

Re: Agile at 20: The Failed Rebellion

#186

Post by koonsolo »

TedDoesntTalk wrote: post #67
koonsolo wrote: post #34

Earlier quoted context omitted.

Agile should include retrospectives, and retrospectives should allow your team to change anything within the process as you need. In fact, all agile needs is good retrospectives, and all the rest you can decide there.

IN my experience, the same two or three people speak up in retrospectives… and no one else, ever.

Then you might have an inexperienced manager or moderator. All it takes is "Hey John, I didn't hear you in the discussion yet. What are your thoughts?". "If there was 1 thing we should improve, what do you think it should be?". Stuff like that. I know even then it's sometimes hard, but at least you should try pulling things out of them.

Re: Agile at 20: The Failed Rebellion

#187

Post by ellen364 »

greatgib wrote: post #169

In my opinion and experience, the best functioning and delivering teams are the one doing Agile without even thinking or saying that they are doing Agile. It is team that are working intelligently with trust between members. Each member does it job, feels responsible and autonomous. Enough to do by itself everything needed for the project to succeed and with other members trusting him to be able to do what he needs t…

Agree completely.

The tough part for me has been experiencing a team like that, then moving and having no idea how to help create a similar environment with my new team. Any tips?

Re: Agile at 20: The Failed Rebellion

#188

Post by forgotmypw17 »

MauranKilom wrote: post #181
forgotmypw17 wrote: post #52

I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively. The "project manager", a DIFFEREN…

How did this approach deal with difficult technical/algorithmic problems where someone needs to investigate something before further decisions can be made? Example: You want to improve performance. Somebody will have to fire up a profiler and measure things, and then figure out which hotspots are worth optimizing. I totally get breaking it down to "set up profiling tool", "do profiling runs for workflow X/Y/Z", and "…

Research and algo design was where most of the 3- and 5-point tickets came from. I think I remember a couple with more points, but not many.

Given the "about one hour of work, give or take" target point value we used, there weren't many tasks which had more points than that.

Re: Agile at 20: The Failed Rebellion

#189

Post by lloydatkinson »

I think one of the biggest indications of failure (because it’s been morphed into something shit by all these business manager types, and not because it’s fundamentally flawed) is the fact that we have dedicated “scrum masters” that never rotate.

Re: Agile at 20: The Failed Rebellion

#190

Post by dragonwriter »

dirkt wrote: post #57
AndrewKemendo wrote: post #41

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…

> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over resp…

I think the way the Manifesto and early community around it lent itself to this inversion is this:

(1) The Manifesto is written in non-actionable terms.

(2) Many of the same people that initially attached themselves to the manifesto were already pitching canned processes, that may have been the outcome of agile process where they originated but did not put the critical feedback mechanisms more prominently than the low-level processes. So, those became the actionable versions of “Agile”.

It would be so much better if instead of the “X over Y” language, the Manifesto has spent a few words talking about how the less important things were subordinated to the more important ones.

The weird thing is that continuous, bottom-up, empirically-based process improvement wasn't an unknown concept at the time the Manifesto was written. It wouldn't have been hard for it to reference more concrete, actionable, concepts and practices.

Post reply on HN