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

Less is more agile

beny23.github.io

Post reply on HN
Print view View original

101–110 of 174 posts

Re: Less is more agile

#101

Post by BlargMcLarg »

xlii wrote: post #93

I'm seeing a lot of people making Agile something it isn't/shouldn't be. There's a difference between core Agile (as in Agile Manifesto) and one of the many commercial imagination of it. Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. It was "weaponized" by business but (at least from my experience) everything…

>Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape.

I wouldn't describe it as such. Such descriptions are how managers got the idea they can put development teams into their bubbles while restricting their access to assets required, demanding they go through multiple layers of management to get simple things done. Ideally, you don't just have a response, but the power to change things more efficiently.

Case in point: devops, CICD. Most teams would benefit from having their own CICD. Many companies silo a separate "devops" team and multiple development teams, while pipelining the demands of dev teams from manager to manager. "Devops" team gets swarmed by status pings every day, development teams are annoyed because trivial things don't get solved, management gets annoyed because "why is it taking so long?". And the team could easily teach someone the basics and get their test environment running.

Of course, above scenario requires management gives the power to change things to more people. Management in general thrives on lack of trust, so that's a no-no. "We love agile!", they say. Yes, when the teams get nicely silo'd and somehow become "more predictable", but are still as powerless as before.

Re: Less is more agile

#102

Post by hef19898 »

bluepnume wrote: post #40
teeray wrote: post #39

Everything in my experience aligns with what this post states. The best teams had processes that they developed themselves, organically. However, there is a very real, pressing need from middle management to answer “what’s going on with X” when upper management asks. “I don’t know” is not an answer and neither is “we don’t know when it will be done.” These conversations ultimately control the flow of funding. So we m…

Simple: it's the job of a good line manager to embed and ingratiate themselves well enough with those doing the engineering work, that at any point they can give a reasonable estimate for how long a certain thing is going to take when asked middle or upper management. That is, WITHOUT adding extra process. > I quoted the First Law of Mentat at her: ‘A process cannot be understood by stopping it. Understanding must mo…

I spend the majority of my career in SCM, not software development. Your comment is absolutely true in my opinion. A good line manager knows what's going on, any KPIs or dashboards just make it easier for a manager to know.

Managers rellying on dashboards and reports only to know whats going on in their teams, have always teams oerforming sub par. And they aren't able to answer upper management questions any better.

Re: Less is more agile

#103

Post by disgruntledphd2 »

intelVISA wrote: post #77
samizdis wrote: post #8

> Recruiting people does not work by doing laundry lists of questions asked by HR drones that don’t understand context or demand 10 years of experience in a technology that’s 8 years old. Five rounds of interviews, tests and exams where people have to recite algorithms by heart are pretty pointless. I second that sentiment. I've worked in places small and autonomous enough that the office manager would handle the adm…

We in tech are the only ones smart enough to fall for all the well-paid productivity sinks, when was the last time your physician had a scrum master?

They'd be called a ward director or something, but equivalent roles do exist in hospitals, which are analogous to enterprises.

Re: Less is more agile

#104

Post by hef19898 »

stephc_int13 wrote: post #28
bracketslash wrote: post #26

Earlier quoted context omitted.

What would you recommend as a better alternative?

As little middle management as possible. Flat hierarchy is an other kind of bullshit, clearly established leadership is important. When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them. Most of the bureaucracy problems are magically going away when middle management is gone.

>> When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them.

That ia a mjor difference between Amazon and most other places I worked at. Amazon management actually did things beyond managing. There are some of the managers in places as well, they are a minority so.

Re: Less is more agile

#105

Post by hef19898 »

pjc50 wrote: post #99
chii wrote: post #16

Earlier quoted context omitted.

> - Then if that works, run another experiment > - If it doesn’t work, go back The problem is that if it doesn't work for a couple times, you get fired, or at least seen as incompetent. Management want magic rituals that fixes everything, not the scientific method.

> if it doesn't work for a couple times, you get fired That is .. not a reliable description of the outcomes for management consultants, who can inflict spectacular disasters sometimes and still come out ahead. Largely because they deliver the right magic ritual.

As long as it can be perceived it worked, all is good.

Re: Less is more agile

#106

Post by mihaigalos »

ineptech wrote: post #42

I generally agree, couple observations: 1. If the people on the team can't change the process, it ain't agile 2. Sprints aren't a failure of agile, they're a failure of devops. Once you start deploying multiple times a day, nobody will care when one sprint ends and the next begins and it'll be fine 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular tha…

> 1. If the people on the team can't change the process, it ain't agile

Absolutely.

> 2. Sprints aren't a failure of agile, they're a failure of devops.

I don't think so, here's the timeline: Scrum (90s), Agile (2001), DevOps (2009). So sprints have been around a long time before DevOps, the way I interpret it.

> 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular than months

How? Your event horizon spans only the next couple of iterations, everything beyond that is pure speculation.

Re: Less is more agile

#107

Post by pydry »

xlii wrote: post #93

I'm seeing a lot of people making Agile something it isn't/shouldn't be. There's a difference between core Agile (as in Agile Manifesto) and one of the many commercial imagination of it. Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. It was "weaponized" by business but (at least from my experience) everything…

>I'm seeing a lot of people making Agile something it isn't/shouldn't be.

This is kind of expected. Agile was always very vague about what it was from the get go. At this point it's like "god" or "love" - there is no one shared definition and never will be.

Rather than arguing over what really is is or should be we should just be quietly deprecating and using a different name for what we think it should have been all along, making an effort to be specific this time.

XP was specific and good for the time it just... stayed at version 1.0 forever.

Re: Less is more agile

#108

Post by beny23 »

BlargMcLarg wrote: post #101
xlii wrote: post #93

I'm seeing a lot of people making Agile something it isn't/shouldn't be. There's a difference between core Agile (as in Agile Manifesto) and one of the many commercial imagination of it. Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. It was "weaponized" by business but (at least from my experience) everything…

>Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. I wouldn't describe it as such. Such descriptions are how managers got the idea they can put development teams into their bubbles while restricting their access to assets required, demanding they go through multiple layers of management to get simple things done…

I think the main thing about agile is a plan-do-study-act cycle than can be adapted to anything even project management. The trick is not to think I can just adopt a process and will then be agile. It always has to be adapted to context and what works for you.

As to CI/CD pipelines: I think a centralised devops team that blocks everyone is as much an anti pattern as a wild-west approach where 3 teams operate 4 different CI/CD tech stacks. There is much to be said about building a platform (when the size of the operation is big enough to warrant it) and using golden paths or paved roads.

Re: Less is more agile

#109

Post by ema »

ajb wrote: post #89

The problem with this kind of article is that it doesn't recognise that software is built in different contexts. "Don't estimate" may be fine if your product is an SAAS that gets updated incrementally. It won't cut it if your clients question is "we've booked the O2 arena for April 2023. Can you build this by then?"

If you have a fixed deadline you descope to something you think will take ten percent of the remaining time build it in what turns out to be more like half of the remaining time and then add enhancements until you hit the deadline.

Re: Less is more agile

#110

Post by meheleventyone »

mihaigalos wrote: post #100

I loved this article. Countless times I had to estimate Jira "tickets" (actually called issues in Jira terminology) in hours. To this day, I fail to understand why and I haven't gotten a pertinent answer other than "the business needs it for planning, they're paying us, so you do it." Yet this contradicts at least 2 Agile Manifesto pillars: 1. People and interactions over processes and tools (fostering the estimation…

Businesses want to be able to forecast and goals are often set aggressively and ahead of knowing whether they are achievable. There are three basic levers to wiggle at that point. Money, time and project scope.

Money can only really be applied early by staffing up, adding more people to a late project will invariably make it later. Thanks Mythical Man Month.

So for anything in flight that looks like it will miss a desired goal you can only really change the delivery date or reduce project scope.

But you also need to know you’re going to miss so you need some idea of how much work is left and how quickly you’ll get through it. Detailed estimates are a reaction to this along with the idea of measuring ‘velocity’. I’ve never seen either work well but people seem to cling to the idea that next time it’ll help them get it right.

One of the funniest Agile meetings I’ve been in had a producer explaining the state of the project. Slide 1: Velocity doesn’t mean anything outside of the team it’s for, comparisons don’t make sense. Slide 2: A line graph plotting each teams velocity against one another. Cue any useful discussion derailed because people want to know how we can get everyone’s velocity up to what looks like the best teams.

There’s a lot of dysfunction in business and a lot of winging it without really trying to understand why things are being done. You get a lot of odd practices spread around because project success is not necessarily because of “good leadership” but often project success is the measure used for leaders. A couple of wins and you can gracefully fail upwards believing in your own bullshit.

Post reply on HN