Agile Is Dead, Long Live Continuous Delivery • Hacker News Board

Re: Agile Is Dead, Long Live Continuous Delivery

#131

Post by bmm6o » Fri, May 06, 2016, 3:35 PM UTC

voodootrucker wrote: post #38

lostcolony wrote: post #25

I like how he tries to supplant agile with something that doesn't even attempt to solve the same problems that agile (like waterfall before it) attempts to solve. Both agile and waterfall methods attempt to give you a pattern by which you can predict when software will be delivered. That's the main business value. The suits don't care how the devs operate, provided they can get things on time. Waterfall tried to do t…

The trouble is that in dynamic environments, the discipline necessary to properly practice scrum isn't really possible. It takes longer to define the requirements than it does to code, and once coded they change mid-sprint. The trouble with waterfall is that it tries to predict beyond the scope of a sprint, which just isn't valid. Project estimates are asymmetrical curves (likely poisson?) and you can't add them up a…

> It takes longer to define the requirements than it does to code, and once coded they change mid-sprint

It sounds like your product owner isn't doing his job. What specifically does it mean for requirements to change? If the specifications were unclear or incomplete, well you should have held out for clear and complete specifications. If you can't do that you have an organizational problem. But did the customer change their mind about what they want? Not likely, but possible I guess. The only thing left is that the owner didn't really understand the customer's needs.

Re: Agile Is Dead, Long Live Continuous Delivery

#132

Post by barrkel » Fri, May 06, 2016, 3:49 PM UTC

blowski wrote: post #107

barrkel wrote: post #56

Earlier quoted context omitted.

The trouble with waterfall is that it tries to predict beyond the scope of a sprint, which just isn't valid. This assertion is nonsense. There's nothing magical about a couple of weeks such that it forms a boundary outwith lie impossible predictions. The validity of predictions depend entirely on the understanding of the problem domain and the complexity of the solution space. The single biggest benefit from agile in…

If you've got a bunch of good, productive developers, you've got to work really hard to get anything but good software out of them. They will probably self-organise into an effective team, whatever the methodology. On the other hand, if you have a bunch of inexperienced, mediocre developers (myself included) then "bite-size stories being fed on a conveyer belt" is probably a good way to get productivity out of them.…

You'll get a blob that gets harder and harder to modify over time. For a throwaway system and / or with piles of money, it may work until the system needs replacing.

Different people working on similar vertical slices through the system leads to slightly different parallel implementations and probably some duplication of helper logic. Refactoring won't get scheduled and it'll become technical debt in the way all duplicated logic is: not a big deal to start with, but an increasing source of bugs and features fixed / implemented in one place but not another.

Inexperienced developers won't be disciplined in keeping their abstractions separate; they tend to intermingle their abstractions so that the boundary is fuzzy. Specifically, they lack layering discipline. Instead of libA using libB which uses libC, they'll pass bits of libA into libB and return bits of libC. When implementing a complex algorithm that joins libA to libB, they'll write code that zips the two together within its convolutions, rather than creating adapters for libA and libB so that the algorithm follows naturally. And they'll model the domain, but nothing much more abstract, and write convoluted procedural algorithms in VerbingClasses (new ThingDoer(x).doThing(y)), possibly with interfaces for mockability.

And to be frank, many line of business applications can cope with this. The developers are cheaper and easier to find, and IT was always a cost centre anyway. It's no way to live if you love code, though.

Re: Agile Is Dead, Long Live Continuous Delivery

#133

Post by joshuacc » Fri, May 06, 2016, 3:51 PM UTC

ktRolster wrote: post #3

Has anyone ever worked on an 'agile' team that wasn't based around scrum or XP? I'd be interested in hearing your experiences.

Yes, I have worked on agile Kanban teams. The experience was more or less the following...

1. What's the next task/bug/story we should be working on?

2. Build & test it.

3. Ship it.

4. Rinse & repeat.

We'd have meetings periodically to define new sets of tasks and figure out priorities, and/or to reflect on things that hadn't gone well. But these weren't necessarily scheduled on a regular basis. We did them as needed.

Re: Agile Is Dead, Long Live Continuous Delivery

#134

Post by tamana » Fri, May 06, 2016, 3:52 PM UTC

maxxxxx wrote: post #34

enjo wrote: post #27

Earlier quoted context omitted.

I see no indication that agile is dying. The consultant speak cult that developed around it is. The hugely processed SCRUM version of it seems to be. Yet the fundamental idea behind Agile (in the manifesto) seems to be as relevant as ever: >Individuals and interactions over processes and tools >Working software over comprehensive documentation >Customer collaboration over contract negotiation >Responding to change ov…

Yep. If people checked their actions against the agile manifesto they would immediately see that most scrum teams violate "Individuals and interactions over processes and tools" and "Responding to change over following a plan". A lot of scrum teams I see are fully process and tool oriented and have no ability to respond to change. I hate when I hear "Yes you are right but we can't make changes because the sprint woul…

>Yes you are right but we can't make changes because the sprint would not finish".

That makes absolutely no sense because the sprint always finishes, on a scale far basis.

The only way to make a sprint not finish is to submit code that cannot be safely deployed, and that is a bug in the code, nothing to do with changes in plan.

Re: Agile Is Dead, Long Live Continuous Delivery

#135

Post by GBond » Fri, May 06, 2016, 4:12 PM UTC

andrewbinstock wrote: post #62

chrisseaton wrote: post #52

Earlier quoted context omitted.

People tell me that waterfall was never really a thing, and it was only ever a name for how things should not be done and that nobody ever actually advocated it. Is this not true? I'm too young to remember what came before agile.

Pure waterfall as it's depicted by Agile consultants was never a thing. Think about it, how could you possibly code an entire app and only then debug it? However, there was a waterfall-like process that was widely used. After getting the reqs and design in place, you started coding and you mostly coded. You would compile as you went along and made sure that your code worked on the handful of tests you put together as…

This thread makes me feel old.

Re: Agile Is Dead, Long Live Continuous Delivery

#136

Post by wmonk » Fri, May 06, 2016, 4:26 PM UTC

morgante wrote: post #93

I stopped reading at "Agile had a great run in it’s youth by taking on some obviously bad practices such as 'Waterfall' software development." Nothing about waterfall is obviously bad. It's how most engineering projects are done. Heck, it's how most projects generally in the world are done. There's a reason it took a long time to move away from waterfall. It solves obvious problems and meshes with how the rest of cor…

You are not wrong, it is written by the CMO of Gradle.

Re: Agile Is Dead, Long Live Continuous Delivery

#137

Post by geebee » Fri, May 06, 2016, 4:28 PM UTC

maxxxxx wrote: post #34

enjo wrote: post #27

Earlier quoted context omitted.

I see no indication that agile is dying. The consultant speak cult that developed around it is. The hugely processed SCRUM version of it seems to be. Yet the fundamental idea behind Agile (in the manifesto) seems to be as relevant as ever: >Individuals and interactions over processes and tools >Working software over comprehensive documentation >Customer collaboration over contract negotiation >Responding to change ov…

Yep. If people checked their actions against the agile manifesto they would immediately see that most scrum teams violate "Individuals and interactions over processes and tools" and "Responding to change over following a plan". A lot of scrum teams I see are fully process and tool oriented and have no ability to respond to change. I hate when I hear "Yes you are right but we can't make changes because the sprint woul…

The daily standup ("scrum") did make some sense in the context of agile development. The idea is that you embrace the unpredictability of software and respond to change. So you take on a task, but you accept that the task is likely to not go as you expected. You may need to change direction. You may need to take a different approach. Or you may need 10 weeks instead of 1, and even that is getting fuzzy… under these circumstances, it can be useful to remain in frequent contact with the development team and business/end users users.

But as you pointed out, daily scrums can essentially devolve into what is essentially a policing of developers to make sure they are staying the course and are reminded daily of their deadlines.

It's actually just an unusually unfriendly version of waterfall. Why? Cause at least in waterfall, the business users are forced into something unfair and impossible as well. It's impossible for developers to accurately estimate completion dates, but it's also impossible for business units to accurately and fully spec out a software application. "You didn't meet your estimate"... "Yeah, well, you changed your mind".

It's a nasty business, but there you go. Best to avoid the entire thing and work on projects that are very high value but aren't deadline dependent, where the value of a developer is measured by working software at reasonable intervals rather than daily discussions of sprints, stories, and deadlines.

Actually, in some ways, that sounds more like what agile is supposed to be than all this scrum/velocity/stories stuff that isn't in the manifesto in the first place.

Re: Agile Is Dead, Long Live Continuous Delivery

#138

Post by blowski » Fri, May 06, 2016, 4:32 PM UTC

barrkel wrote: post #132

blowski wrote: post #107

Earlier quoted context omitted.

If you've got a bunch of good, productive developers, you've got to work really hard to get anything but good software out of them. They will probably self-organise into an effective team, whatever the methodology. On the other hand, if you have a bunch of inexperienced, mediocre developers (myself included) then "bite-size stories being fed on a conveyer belt" is probably a good way to get productivity out of them.…

You'll get a blob that gets harder and harder to modify over time. For a throwaway system and / or with piles of money, it may work until the system needs replacing. Different people working on similar vertical slices through the system leads to slightly different parallel implementations and probably some duplication of helper logic. Refactoring won't get scheduled and it'll become technical debt in the way all dupl…

Of course. If we lived in a world where good, productive, experienced developers were cheap and plentiful, we could do things very differently. As it is, it can be more efficient to pay cheap developers to continually patch (or even rebuild) big balls of mud than pay expensive developers to build it properly in the first place.

And I'm not going to complain, because I benefit from the current system.

Re: Agile Is Dead, Long Live Continuous Delivery

#139

Post by emitstop » Fri, May 06, 2016, 4:37 PM UTC

morgante wrote: post #93

I stopped reading at "Agile had a great run in it’s youth by taking on some obviously bad practices such as 'Waterfall' software development." Nothing about waterfall is obviously bad. It's how most engineering projects are done. Heck, it's how most projects generally in the world are done. There's a reason it took a long time to move away from waterfall. It solves obvious problems and meshes with how the rest of cor…

Yeah and I like how he goes in on 'Agile Gurus' and then at the end of the article plugs his continuous delivery conference like it isn't the exact same thing in a different hat.

Re: Agile Is Dead, Long Live Continuous Delivery

#140

Post by lostcolony » Fri, May 06, 2016, 5:39 PM UTC

wsc981 wrote: post #117

lostcolony wrote: post #65

Earlier quoted context omitted.

So the way I have always handled it - Product owners create stories. These are titled things like "As a (type of user), I want to be able to X". The point of the title is to determine who this actually benefits. Then, they attempt to define it with acceptance criteria. These are a list of "what does it mean to solve this need". Ideally, it implies a set of tasks, and gives a decent starting point for QA to start test…

What always annoyed me about Story Points is that it's a measure of complexity, not time. At least that's what Story Points are supposed to stand for. When you state that a team should know how many Story Points it can handle, it would make much more sense to see Story Points as some measure of time. If you've completed last few Sprints 38 to 42 Story Points, with 2 full-time devs, than one could state that a single…

I'm not that dogmatic. But complexity should loosely correspond to time, I would think. A deeply complex task is going to entail more work than a simple one.

That said, there's a good reason to say it measures the complexity, and not the time. You want to keep distance between your estimates and time, or else the business people are likely to come to you and say "You said this will take 6 hours, so I expect it tomorrow". Nevermind that it requires another task to be done first, that it's blocked on getting something from another department, that you only ever committed to delivering it at the end of the sprint, and that you underestimated how long it would take anyway (but it doesn't matter because you overestimated something else so it comes out in the wash), -you- said it would only take 6 hours!