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

71–80 of 174 posts

Re: Less is more agile

#71

Post by travisgriggs »

Here’s the part that jumped out at me:

> The problem is that Scrum started out as a lightweight wrapper around Extreme Programming (XP) to make it palatable to management, and it is all that extra cruft that people of added that is the problem.

Look at that statement, and then let’s abstract it and make it a bit more “polymorphic.”

The problem is that process ______ started out as a wrapper around idea/adhoc practice _______ to make it include management, and it is all the other crap that is added that is the problem.

Every time management gets involved with the teams I work on, this is what happens. I hear tales of people who have “helpful” management. Some of my managers have been the nicest guys, and tried to do well by me. But because they’re not part of the team, they rarely add value, but rather burden the team with their non value adding presence.

(Kinda ranty, I know, I’m just channeling the OP which was titled a rant, I guess)

Re: Less is more agile

#72

Post by pillefitz »

ilaksh wrote: post #64
jesstaa wrote: post #58

Earlier quoted context omitted.

Contractor is the wrong metaphor. They're building a house based on a plan already designed by an architect. Software isn't the making of a thing, it's the designing of a thing. Ask an architect how long it will take for them to design your dream home.

Architect designing home is the wrong metaphor. Buildings do not have moving parts. Their core structures are almost all fundamentally the same. There are problems to solve, but again, not dynamic systems, and always variations on very well known themes. Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. There are usually a lot…

Depends, really. Most software is doing basic CRUD and efforts can be estimated reasonably well. Some other software, like your example suggests, is literally rocket science. But even here estimates are typically not too far off.

Re: Less is more agile

#73

Post by tgv »

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.

That's one of the reasons I work for a small company. There's just one boss, and he's also what in the US would probably be called VP, both formally and informally (there's a difference between the formal and informal hierarchy). He knows his limits, is technically adept although he doesn't know much about programming, and just cares about usability. As a consequence, there's no politics, no endless meetings (yes, I've done Agile too elsewhere, with those retrospectives, planning meetings and pointless burndown charts). There's no other team blocking me or forcing me to do something differently (because of course teams are self-organizing, but heaven forbid if you do something that touches the domain of another team). The salary is somewhat lower, but I actually enjoy my job.

Middle management is just nepotism, where incompetent/not-caring managers hire from their network to gain power.

Re: Less is more agile

#74

Post by tgv »

Surfactant7 wrote: post #2

> Allen described his work as a consultant when he goes into a new organisation: > - First he observes > - Then he would try to identify the biggest problem > - Then he would try change it (i.e. run an experiment) > - Then if that works, run another experiment > - If it doesn’t work, go back It's probably no accident, but this is pretty close to the scientific method.

It's common building/engineering sense. It's no accident that (part of) the scientific method looks like that: it's the outcome of this precise process. It may not be optimal, but it delivers.

Re: Less is more agile

#75

Post by quickthrower2 »

ineptech wrote: post #65
quickthrower2 wrote: post #59

Earlier quoted context omitted.

Point 2, even with CI/CD multiple times a day, with zero flaky tests and a sweet build time and automated test time, it sounds like you still need almost zero time between the final git push and merge to $BRANCH causing a deployment. What about review? Code review? QA? Showing off to stakeholders? These things add a delay, and there is a 'crunch' around the end of sprints where things are artificially urgent. I am no…

Obviously not all projects are the same, there are certainly pieces of software that would be disastrous to do that with, I'm just speaking generally. For reference, my (very not-startup) team is ~20 engrs in 3 teams responsible for ~30 services and we deploy stuff ~25x/wk. Also a 'crunch' around the end of a sprint sounds like mini-waterfalls.

How do you avoid mini waterfalls? At some level of granularity you are doing one thing you committed to at a time. If someone else needs to check it thats a handover.

How I have seen sprints done is you commit to X Y Z, have a definition of done like “is in production” and then developer works on X, gets X code reviewed and so on.

If the aim is that the right amount of work is in each sprint then naturally the last day will be busy trying to get stuff reviewed.

Re: Less is more agile

#76

Post by moreira »

ilaksh wrote: post #60
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…

The managers and executives need to have visibility into git commits and deployments. They should literally be able to see the front end and read the progress on the back end code, along with some simple reports as it goes. If they can't understand that stuff they should not be making decisions. But basically it's a list of stuff done, with proof, and stuff left to do. Then they can see the progress bar moving and ma…

> If they can't understand that stuff they should not be making decisions.

That doesn't seem right. As a developer, if I were the CEO of a company, I would not be able to read progress from the legal team, or finance team, or any other team. What's going on with that lawsuit? No idea. Do I know how long it'll take to wrap that up? Nope. I can't understand any of their jargon. I still gotta make decisions about it.

I don't need legal competence in order to run the company or make decisions about stuff, and I shouldn't need technical competence either.

It's on us, as developers, to communicate clearly and give answers and reasonable estimates, so management can make their plans and adjust priorities if necessary. The process we use to generate those answers (agile, git commits, deployments) is entirely up to us and could not matter less to the business, at the end of the day.

Re: Less is more agile

#77

Post by intelVISA »

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?

Re: Less is more agile

#78

Post by gherkinnn »

pillefitz wrote: post #69
soperj wrote: post #62

Earlier quoted context omitted.

Estimating is a bit of a joke though. It's dependent on too many unknowns. Example: How long will it take you to get to China? It entirely depends on how you're getting there and where you're coming from. I can give you an estimate, but if the only known is that you're starting in North America, and you're going to be held to your estimate, you'd better give the estimated time it'll take to walk there. The real issue…

Then use ranges instead, problem solved

I can get to China in the range of 12h and 6 Months, not including hoops to get a visa. Happy?

Re: Less is more agile

#79

Post by intelVISA »

ilaksh wrote: post #60
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…

The managers and executives need to have visibility into git commits and deployments. They should literally be able to see the front end and read the progress on the back end code, along with some simple reports as it goes. If they can't understand that stuff they should not be making decisions. But basically it's a list of stuff done, with proof, and stuff left to do. Then they can see the progress bar moving and ma…

Delegation exists as well if a progress bar is too technical.

Re: Less is more agile

#80

Post by soperj »

pillefitz wrote: post #69
soperj wrote: post #62

Earlier quoted context omitted.

Estimating is a bit of a joke though. It's dependent on too many unknowns. Example: How long will it take you to get to China? It entirely depends on how you're getting there and where you're coming from. I can give you an estimate, but if the only known is that you're starting in North America, and you're going to be held to your estimate, you'd better give the estimated time it'll take to walk there. The real issue…

Then use ranges instead, problem solved

I've been asked to provide estimates on something in hours, and it had no requirements. They'd use this for planning purposes. It's a waste of time.
Post reply on HN