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

41–50 of 174 posts

Re: Less is more agile

#41

Post by AdieuToLogic »

mbrodersen wrote: post #34

It’s not hard. Maintain a priority list. Always work on what is #1 priority. If #1 priority is blocked then work on #2 priority. Use the priority list to negotiate with your stake holders. That’s it. I have had a lot of success using this simple formula in my 30+ years career. Both as an individual developer and when managing small to large software teams. It’s simple. It works.

Agreed.

  It’s not hard.
  Maintain a priority list.
  Always work on what is #1 priority.
  If #1 priority is blocked then work on #2 priority.
I've described this same approach as "risk driven development." Identify the highest risk to an effort's success, address it, then the next highest, etc.

If, during this process, a newly discovered risk is identified as being more than what is currently being worked, put the new risk at the front of the queue and address it.

This drives risk to 0, which drives the probability of success to 1.

And as you succinctly stated:

  It’s simple.
  It works.

Re: Less is more agile

#42

Post by ineptech »

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 than months

Re: Less is more agile

#43

Post by hannofcart »

tpoacher wrote: post #37

I don't agree with the "no estimates" sentiment. My own view is that estimates are useful, but should be treated less as a fixed point-estimate prediction, and more as a single step in a kalman filter, with the understanding that the output at each step is probabilistic, and the number of steps is unknown.

This is how we do estimates. Nothing set in stone, all just a rough guide.

However, the "don't estimate" school is just a little crazy. In no other discipline would this be acceptable as a doctrine.

Imagine a contractor you hire to build the house shrugging when you ask him how long or how much it will cost.

Re: Less is more agile

#44

Post by icedchai »

duncan-donuts wrote: post #29
bracketslash wrote: post #26

Earlier quoted context omitted.

What would you recommend as a better alternative?

Not op but I’ve worked in Agile™ shops, places that are agile, and waterfall-y enterprise stuff. The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. Pointing doesn’t matter, extensive grooming doesn’t matter, extensive planning doesn’t matter, sprints don’t matter, etc. Grooming your work does matter but 30 minutes is enough for a high performing te…

The ceremonies and pointing are often a big waste of time. I worked at a place that really drank the Agile koolaid, and dreaded every "planning" and "retrospective" because it was so incredibly tedious. "Is it this 2 points or 3?" "What did you learn this sprint? What went badly?"

Re: Less is more agile

#45

Post by mlyle »

user_named wrote: post #38
eyelidlessness wrote: post #30

Earlier quoted context omitted.

I won’t wade into the intricacies of defining Waterfall or whether it has merit, but it definitely should be mentioned that Kanban—a capital A Agile technique which most capital A Agile advocates find unstructured and unpredictable (as in tends towards lowercase a agile)—was popularized by an auto manufacturer, where safety and liability are at least as much a concern as construction.

Kanban is a core but small part of TPS, it can't be said to be pro or against safety.

> > was popularized by an auto manufacturer, where safety and liability are at least as much a concern as construction.

> Kanban is a core but small part of TPS, it can't be said to be pro or against safety.

The poster's point is that it's not obviously defective from that standpoint, despite criticisms that imply that it is.

Re: Less is more agile

#46

Post by dfee »

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…

Point 2 is very interesting. Any anecdata to corroborate?

Re: Less is more agile

#47

Post by lkrubner »

The only practice that I've found to be reliably agile is simply having more one-on-one meetings and less large group meetings. Large group meetings tend to waste time for at least some of the people in the group. Often, if you get 8 people together, most of the conversation is between 3 or 4 of those people, while the other 4 or 5 are bored and disengaged. One on one meetings tend to be productive since the meeting would not happen unless one of those people needed to talk to the other person, so 100% of the people in attendance are needed in that meeting. (I'm excluding those companies that have mandatory one-on-one meetings, where the mandatory nature of the meeting sometimes makes the meeting as useless as a large group meeting.)

I've known managers who say "Group meetings are great because I get to meet with everyone at once and it saves me so much time!" But that only benefits the manager. Meanwhile some of the people in the meeting are just sitting there, killing time, bored, waiting for the manager to have 10 minutes to talk to them. By contrast, more one-on-one meetings, even if only for 10 minutes, allows everyone to be involved during the moments when they need to be involved.

When we criticize some of the rituals and bureaucracy that has become associated with the word "agile" most of the time we are criticizing group meetings. That includes the daily standup. I've run teams successfully by having quick one-on-one 10 minute meetings with everyone on my team, everyday. But I rarely feel the need to get the whole team together. In fact, when I'm leading a large team, I never need to get the whole team together, it is always some smaller subset that I pull together.

If you are the team leader, then you need to think carefully about who you need to talk to for any given purpose. If you have the discipline to only talk to the minimum set of people you need to talk to, then you are freeing up a lot of people to keep working on their real work, since they are not in a meeting with you.

Re: Less is more agile

#48

Post by shoo »

dfee wrote: post #46
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…

Point 2 is very interesting. Any anecdata to corroborate?

A subtlety of point 2 is that not all products or services benefit from multiple deploys per day. If each deploy creates work or risk for the customer, then beyond some point, frequent deploys may be harmful. Your customers may have more valuable things to do than consume or help QA the latest increment of your offering.

Separately from deployments, in some less-than-ideally run organisations, management may whimsically change its mind about what the number one priority is from day to day. Two-week sprints can shield the delivery team from this, by acting as some kind of low-pass filter on thrashing priorities, to create space to get a few things entirely done.

Re: Less is more agile

#49

Post by noirbot »

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…

I mostly agree on this - my extension to #3 is that estimates are fine as long as when you inevitably sometimes miss your estimate, you're not held to the fire for not being a fortune teller and asked why you didn't get it done last month.

I'm also not sure I agree on your take on Sprints. In my mind, the value of sprints is that they provide a barrier where you should be able to go "we already loaded all our work for the next 2 weeks. If you want something done, we'll start it in N days." Done right, sprints are your defense against "can't we just do this thing".

Re: Less is more agile

#50

Post by noirbot »

hannofcart wrote: post #43
tpoacher wrote: post #37

I don't agree with the "no estimates" sentiment. My own view is that estimates are useful, but should be treated less as a fixed point-estimate prediction, and more as a single step in a kalman filter, with the understanding that the output at each step is probabilistic, and the number of steps is unknown.

This is how we do estimates. Nothing set in stone, all just a rough guide. However, the "don't estimate" school is just a little crazy. In no other discipline would this be acceptable as a doctrine. Imagine a contractor you hire to build the house shrugging when you ask him how long or how much it will cost.

The difference is you're hiring most other trades-people to do a generally fairly routine bit of work and then be done. A lot of programming is about doing unroutine work that has no clearly defined end-state.

I've been on teams where estimation is easy - you've got years of roughly the same set of devs doing fairly similar feature/bug work on the same code base to look back on and give an educated guess on sizing. Right now I'm on a team that's mostly doing integrations with third-party systems where our skill levels on the team vary between 20 years and 6 months of experience in the field, let alone this team.

Post reply on HN