Agile at 20: The Failed Rebellion • Hacker News Board

Re: Agile at 20: The Failed Rebellion

#51

Post by jarl-ragnar » Sun, Jul 25, 2021, 6:31 AM UTC

chmod600 wrote: post #12

I'm not an expert on this subject, but I feel like "agile" could be summarized as "a process for actively incorporating feedback early and often". That doesn't mean you need points or tshirt sizes or constant status meetings. You just need channels of communication with the right people and a chance to adapt to what they say.

This is how I see agile too. With it’s links to lean, it’s about minimising waste by minimising work in progress. Since the biggest waste is building something no-one wants, getting a small increment into the hands of a user/customer as soon as possible is key.

The problem, in my experience, is many development contracts are still structured in such a way that this becomes too difficult. Management fearing early exposure to the customer will lead to scope creep and cost growth.

Re: Agile at 20: The Failed Rebellion

#52

Post by forgotmypw17 » Sun, Jul 25, 2021, 6:31 AM UTC

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 DIFFERENT PERSON was part of the "business", and interfaced primarily with the scrum master, but they were with us for several hours of both planning and retro.

Our sprints were 2-3 weeks. At the end of the sprint, we spent AN ENTIRE DAY on retro. Before the next sprint started, we spent AN ENTIRE DAY on planning. We used a physical board which was matched by the tracker. They were kept in sync by individuals and validated by the DEDICATED DOCUMENTATION PERSON.

We broke down the tasks relentlessly, until there were almost no 3-point tasks, maybe one or two 5-point tasks, and everything else was 1-pointers. I think this one is the most bang for your buck, lowest hanging fruit, easiest to implement winner. Someone has to enforce it vigilantly until everyone is used to it.

Those three things are, IMNSHO, the keys to getting halfway decent Agile going.

Edit: Was one of the least soul-crushing and nicest experiences in professional software development. The planning meetings were a serious effort, but also a pleasure because I liked everyone on the team, and the large time windows made it not seem rushed, so we had time to joke around and shoot the shit.

Re: Agile at 20: The Failed Rebellion

#53

Post by pjmlp » Sun, Jul 25, 2021, 6:32 AM UTC

catmanjan wrote: post #42

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…

I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't want you'll probably be close

That is the theory, except on the customer side you actually need the people that will use the product.

Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be.

So the same mismatch is bound to happen anyway.

And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause being negative isn't good) and then completely find it unusable on final delivery.

Agile misses that many engineering teams lack people skills to actually navigate and avoid these scenarios.

EDIT: several typos

Re: Agile at 20: The Failed Rebellion

#54

Post by pjmlp » Sun, Jul 25, 2021, 6:37 AM UTC

brundolf wrote: post #32

throwaway290232 wrote: post #18

Agile is a generic umbrella term that involves a vast array of complex, subtle knowledge and skills. It's like saying "Engineer", or "Chef". Each has a shared skillset, to be sure. But each category's members can't just work the same way at all jobs, and there's no book on how to be an Engineer or Chef everywhere. The Agile Manifesto is a failure at trying to make Agile happen because it can't tell you how to make it…

The product and engineering managers I've had in the past have generally been humble, acting as a touchstone of coordination for the folks on the ground rather than a controlling force. And the engineering managers have all just been former engineers who decided they preferred doing this kind of facilitation work instead of writing code. Maybe this isn't the norm?

I do enterprise consulting for a couple of years, the kind of organisations that buy Oracle or MSDN licenses without thinking twice about it.

The best I have seen were mini-silos that managed to de-couple themselves from the org chart.

However I also have seen that it hardly lasts more than a couple of years, because as soon as someone noticed the success of the business unit they were re-integrated so that they could teach the reasons for their success to others.

You can imagine how well did they usually fare afterwards.

Re: Agile at 20: The Failed Rebellion

#55

Post by emptysongglass » Sun, Jul 25, 2021, 6:38 AM UTC

ipaddr wrote: post #39

emptysongglass wrote: post #23

Earlier quoted context omitted.

> And that's why things like "Agile", "DevOps", etc will fail. I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about. If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement…

That's a junior approach thinking you know more than your pm and have no respect if they didn't come from your ranks. In the end if you are difficult you become easy to replace.

My PM does know more than me. And he's good at directing where the team should invest it's efforts. That's why he's my PM.

You seem to have completely missed my point, which is that technical leads and PMs should have domain knowledge and that this is why DevOps is not in danger of failing at competent companies.

Re: Agile at 20: The Failed Rebellion

#56

Post by Clewza313 » Sun, Jul 25, 2021, 6:40 AM UTC

pjmlp wrote: post #53

catmanjan wrote: post #42

Earlier quoted context omitted.

I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't want you'll probably be close

That is the theory, except on the customer side you actually need the people that will use the product. Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be. So the same mismatch is bound to happen anyway. And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause b…

This is (IMHO) the biggest single miss in most attempts to be "Agile". The customer/end user is supposed to be embedded in the team, doing actual work with the program, raw and hacky as it may be. This way the feedback is immediate and accurate. Passively watching smoke and mirror demos once every sprint is a far cry from this.

Of course, this isn't applicable/possible for all types of software (you can't really iterate your way to an MVP nuclear reactor) but there's less of this than you'd think.

Re: Agile at 20: The Failed Rebellion

#57

Post by dirkt » Sun, Jul 25, 2021, 6:40 AM UTC

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 responding to change

Because that's what makes middle management happy.

So this perversion of "Agile", which is actually the opposite of Agile, is the FUNDAMENTAL problem.

Re: Agile at 20: The Failed Rebellion

#58

Post by TedDoesntTalk » Sun, Jul 25, 2021, 6:41 AM UTC

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…

This sounds soul-crushing and I hope never to work in such an environment.

Re: Agile at 20: The Failed Rebellion

#59

Post by watwut » Sun, Jul 25, 2021, 6:41 AM UTC

ipaddr wrote: post #39

emptysongglass wrote: post #23

Earlier quoted context omitted.

> And that's why things like "Agile", "DevOps", etc will fail. I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about. If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement…

That's a junior approach thinking you know more than your pm and have no respect if they didn't come from your ranks. In the end if you are difficult you become easy to replace.

That being said, non technical PM always turned to be bad. Theoretically they don't need knowledge, but practically they do and it shows.

Re: Agile at 20: The Failed Rebellion

#60

Post by RandomLensman » Sun, Jul 25, 2021, 6:41 AM UTC

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 vast majority of software is not for flywheel type situations.

For internal customers or in B2B settings getting the actual users and outcome owners involved early is vital - but they are often poorly incentivized to get into the action as there are layers of business mangers etc in place that are supposed to stand in (but lack the detailed knowledge).