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

51–60 of 174 posts

Re: Less is more agile

#51

Post by eyelidlessness »

mlyle wrote: post #45
user_named wrote: post #38

Earlier quoted context omitted.

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.

Almost exactly my point. There’s a fairly strong set of evidence that it’s safety-neutral at worst.

Re: Less is more agile

#52

Post by mlyle »

eyelidlessness wrote: post #51
mlyle wrote: post #45

Earlier quoted context omitted.

> > 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.

Almost exactly my point. There’s a fairly strong set of evidence that it’s safety-neutral at worst.

I love kanban. It's not perfectly suited for knowledge work, though. Great for smaller projects and for places where precise scoping and predictability is less important than just making progress.

Re: Less is more agile

#54

Post by karmelapple »

shade wrote: post #33
duncan-donuts wrote: post #29

Earlier quoted context omitted.

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 biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. The best project I ever worked on: one developer (me), one project manager on our side, one QA/test person at the client, and one manager at the client who was what we'd call a product owner on a scrum team. No ceremonies, no pointing, very little backlog grooming. Shared Bitbucket repo for issue…

Have you read Team Topologies? This sounds like a stream aligned team, albeit a small one, and sounds like you had great success.

Re: Less is more agile

#55

Post by whynotminot »

shade wrote: post #33
duncan-donuts wrote: post #29

Earlier quoted context omitted.

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 biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. The best project I ever worked on: one developer (me), one project manager on our side, one QA/test person at the client, and one manager at the client who was what we'd call a product owner on a scrum team. No ceremonies, no pointing, very little backlog grooming. Shared Bitbucket repo for issue…

Who knew coordinating development work could be easy with one developer?

Re: Less is more agile

#56

Post by dhasso »

I'm always very confused about this kind of statement: "Don’t estimate". To me, projects without estimates tend to take way too much time. It's also federating a team to have deadlines. But I agree that estimations often become a joke when your manager asks you to estimate something that you have no idea how long it will take. How to reconcile both? Being more flexible on the estimation? Taking them as a team goal and not a business one? How to manage the lack of estimation when company planning is important? I can hardly see how "Ok everybody, we are going to release a product but we don't know when! Soon!" could work.

Re: Less is more agile

#57

Post by ineptech »

noirbot wrote: post #49
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 fo…

re: estimates: This is equivalent to saying don't confuse estimates with delivery dates, which I wholeheartedly agree with. But you also have to be willing to say "The estimate was wrong, here's a new one" sometimes.

re: sprints: You don't need a barrier against "can you do this thing". If the thing is important enough, do it; if it isn't, don't. You work on whatever the top priority is, and your sprint commitment is just a list of what the priorities were, N days ago.

(Edit: you do still need a PO willing to say "doing the thing would delay the other thing" though)

Re: Less is more agile

#58

Post by jesstaa »

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.

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.

Re: Less is more agile

#59

Post by quickthrower2 »

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, 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 not sure that is optimal. I have not heard a reasonable solution to this, other than abandon sprints maybe?

I think this stuff works wonders when at MVP stage and number of users < 10 maybe. For mature and complex products, the type I typically have worked on it is not ideal.

Re: Less is more agile

#60

Post by ilaksh »

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 make decisions based on that. To get estimates, ask for explanations of what is involved in the remaining steps. Again, they should have technical competence to get a rough estimate from those reports.

Post reply on HN