Less is more agile • Hacker News Board

Re: Less is more agile

#161

Post by roeles » Mon, Sep 05, 2022, 5:20 AM UTC

quickthrower2 wrote: post #59

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 no…

> What about review? Code review? QA? Showing off to stakeholders?

Take a look at Dave Farley's Continuous Delivery YouTube channel to see the answers.

I think it boils down to "don't do that" with good arguments why and how to assure quality instead.

Re: Less is more agile

#162

Post by hw » Mon, Sep 05, 2022, 10:11 AM UTC

ineptech wrote: post #146

quickthrower2 wrote: post #88

Earlier quoted context omitted.

That sounds sensible to me! Thanks. Nice to get these perspectives as I have never heard a colleague say that before. I guess you can then get rid of the 2 weeks? Because you can measure velocity as a continuous rolling average. Retros could be continuous too and standups already are. Grooming is easy to make continuous too.

Sure thing! We do still do 2-week sprints, it's just that nothing really happens when one ends and the next begins.

Try 3 week sprints. Or 4. ShapeUp by Basecamp recommends 6 weeks. Sticking to the same things everyone is doing is counter agile, and you should be experimenting and see what works for your team

Re: Less is more agile

#163

Post by marcus_holmes » Mon, Sep 05, 2022, 10:55 AM UTC

azangru wrote: post #145

Juliate wrote: post #142

Earlier quoted context omitted.

The problem with Scrum is people talking about how this should be more Scrum, or how this is not really how Scrum is/defines things/should happen. Rather than focusing on the team, its own alchemy, its work and the very specific nature of the work. The process should adapt to the people and the work at hand. Not the other way around. That's the very ethos of the Agile Manifesto. Scrum is used in corporate environment…

If you replaced the word "scrum" with the word "agile" in the message above, would you still advance the same argument? Would you say that the problem with agile is that people are talking about how this or that should be more agile; or how a company isn't really agile; or how the way it does things violates the values or principles of the Agile Manifesto? If you would, then why does it seem a problem for you when th…

> scrum is as good a place to start as any

No, it's not. It's a very bad place to start. Because Scrum is a fixed process, with a fixed meaning.

If you started with Scrum and then stopped doing sprints because they weren't working for your team, you would quickly run into all sorts of opposition around "we're not doing Scrum properly; we need to be doing sprints".

Whereas if you started with nothing, no process at all, and later tried adding sprints, everyone would evaluate sprints by themselves with no preconditioned notion of how that should work within the rest of the process.

Re: Less is more agile

#164

Post by arnvald » Mon, Sep 05, 2022, 7:30 PM UTC

azangru wrote: post #144

arnvald wrote: post #143

Earlier quoted context omitted.

The problem is not that Scrum doesn't have these things. The problem is that Scrum is a heavy and rigid set of processes that, besides a few useful things, adds a lot of unnecessary overhead. Daily Scrum, Sprint Review, Sprint Goal, even the role of Scrum Master - depending on the team, some or all of these things can be removed to the benefit of the team, but Scrum itself doesn't allow it. It's either all or nothing…

> Daily Scrum, Sprint Review, Sprint Goal, even the role of Scrum Master - depending on the team, some or all of these things can be removed to the benefit of the team, but Scrum itself doesn't allow it. Of course it doesn't. It wouldn't be scrum if these were removed; it would be something else. Which is fine; but if you prefer to organize your work in a way that isn't scrum, then why would you call it scrum? > It's…

When I work with a framework, let's say Ruby on Rails, and I don't use the build-in ORM, I still use Ruby on Rails.

Agile is an idea, a concept. Scrum is a tool (or even a framework, according to its website), and for a tool that's associated with a concept of being agile and flexible, it's incredibly rigid.

Re: Less is more agile

#165

Post by asdajksah2123 » Mon, Sep 05, 2022, 9:31 PM UTC

andsoitis wrote: post #25

stephc_int13 wrote: post #19

Agile was a relatively good idea, I welcomed the Agile manifesto with open arms because freaking UML was all the rage at the time. Unfortunately, Agile quickly turned to be even worse than what preceded. Corporate bureaucracy should be fought against at all times and by all means. If you work in software, you are valuable enough to have a say, and a choice about who you work for. Not everything has to turn into a bul…

people > process creative work requires a different environment than widget-making.

I think this is one of the biggest problems with the Agile manifesto. The actual line is:

> Individuals and interactions over processes and tools

This makes it seem like processes and tools are not important. But when you get beyond 5 or so people working on something, processes and tools are absolutely critical. There is no contradiction between processes and tools, and individuals and interactions. Better processes and tools will enable better interactions between individuals and will allow those individuals to influence the larger team.

What this should have been is something like:

Individuals and interactions Processes and Tools

Both feed into each other and should be improving each other.

Re: Less is more agile

#166

Post by P5fRxh5kUvp2th » Tue, Sep 06, 2022, 3:53 AM UTC

dhasso wrote: post #56

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 an…

estimate both a time and a confidence (or fitness).

2 weeks with 9/10 fitness is a very different estimate from 2 weeks and a 6/10 fitness. The latter should result in more discussion so those you're giving the estimate to can better understand how likely you are to miss that estimate and what they can do to facilitate a better estimate. "Give me 2 days to investigate this 1 thing that's a total unknown, I can probably give you a better estimate afterwards".

The problem is very few people on either side of that table ever want to do this.

Re: Less is more agile

#167

Post by Juliate » Tue, Sep 06, 2022, 10:07 AM UTC

azangru wrote: post #145

Juliate wrote: post #142

Earlier quoted context omitted.

The problem with Scrum is people talking about how this should be more Scrum, or how this is not really how Scrum is/defines things/should happen. Rather than focusing on the team, its own alchemy, its work and the very specific nature of the work. The process should adapt to the people and the work at hand. Not the other way around. That's the very ethos of the Agile Manifesto. Scrum is used in corporate environment…

If you replaced the word "scrum" with the word "agile" in the message above, would you still advance the same argument? Would you say that the problem with agile is that people are talking about how this or that should be more agile; or how a company isn't really agile; or how the way it does things violates the values or principles of the Agile Manifesto? If you would, then why does it seem a problem for you when th…

> It is one of the ways of putting the manifesto into practice.

It is not because it specifically mandates a given methodology imposed upon a team.

The ethos of the agile manifesto is precisely the opposite.

And Scrum might be a good place to start with in theory, while in practice, it's become in many corporations as the standard way of operations.

It's "what everyone do". It's the "best practice". It's also become a huge red flag for hiring, still few company realize that yet.

Re: Less is more agile

#168

Post by twawaaay » Tue, Sep 06, 2022, 1:42 PM UTC

Juliate wrote: post #167

azangru wrote: post #145

Earlier quoted context omitted.

If you replaced the word "scrum" with the word "agile" in the message above, would you still advance the same argument? Would you say that the problem with agile is that people are talking about how this or that should be more agile; or how a company isn't really agile; or how the way it does things violates the values or principles of the Agile Manifesto? If you would, then why does it seem a problem for you when th…

> It is one of the ways of putting the manifesto into practice. It is not because it specifically mandates a given methodology imposed upon a team. The ethos of the agile manifesto is precisely the opposite. And Scrum might be a good place to start with in theory, while in practice, it's become in many corporations as the standard way of operations. It's "what everyone do". It's the "best practice". It's also become…

I think it is worth to note that there is nothing wrong with the scrum techniques.

Just like any shoe you find in a store might be fully functional and useful to somebody it might just not be good fit for you.

Now, that might not be a problem for a more traditional development process of the past. In the past we would just choose one of the prescribed processes that was deemed the most fitting.

But the agile came and basically said that any set process is by definition wrong. The goal was to pursue constant improvement, forge the process as you go along and the idea was that the company that can improve faster will, over time, prevail over competition (you can't say "win", because it is an infinite game). And that the faster you can execute the iterations of these improvements the faster you can improve overall. And that the higher management is usually ill suited to do this because it just takes too much time to get the improvement iteration and that they usually don't know the specifics anyway.

And out of all this came the idea that the team itself should be responsible for improving their own process because this is the only way to do it fast enough.

In practice when the team notices a problem I may offer a possible solution for discussion and this solution will frequently be something already known from typical "agile"/scrum/kanban literature. Again, not saying it is all wrong but it needs to be viewed as a collection of solutions to individual problems rather than collectively a solution to fixing development process.

Re: Less is more agile

#169

Post by namose » Wed, Sep 07, 2022, 6:10 AM UTC

soperj wrote: post #80

pillefitz wrote: post #69

Earlier quoted context omitted.

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.

That sounds like the estimation process was screwed up, not that all estimation is a waste of time

Re: Less is more agile

#170

Post by namose » Wed, Sep 07, 2022, 6:14 AM UTC

dhasso wrote: post #56

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 an…

I've found estimations helpful when it's really about breaking down parts of a task that aren't independently deliverable, but still independently estimatable. When working with a sufficiently technical manager, it gives them the best idea of your confidence function. It also helps junior members of the team understand more of your process and get some problem-solving practice without years of experience.