Methodology schmetodology
-
I must say it's a very nice idea when all I want is to milk some taxpayer's money back into my pockets, but in private sector, you will be told either to hotfix it or to fuck off...
-
This is not a problem, then. At all. A sprint has a goal you must deliver and one or more candidates which are nice to have. It's when you carry over your sprint goals that a flag must be raised.
Probably depends on who's explaining it, but yes. In general, for us, the two weekly 'Monday meetings' (in-team BLI discussion/preparation of questions, followed by product owner demo/status/discuss future BLIs) are more important than the Tuesday morning kickoff every other week, which mostly serves to tell the other scrum teams what's going to be worked on.
-
Wait what, you always develop projects as a whole?
Of course. What's the point of making 1/3rd of a project? (I guess it works for the Git team.)
You never break them down? No modular structure whatsoever? How do you tell a fucking module or a goddamn library works? You rush to other parts before you can even verify your APIs work?
How does any of this shit follow from "develop projects as a whole"?
-
You either develop a monstrous monolith or you have a modular structure. Can your modules be tested in isolation? Can you tell if you really finished doing work on a module? If no, it's still the same fucking monolith with sugar coating on it.
-
Whether the module functions as the developer expected it to (your definition of "works") sometimes has no relation to whether the product solves a business need, which is what Blakey's using as a definition of "works". Unit tests can tell you the former but can never tell you the latter. You can't do UAT on a piece of a program unless the user interface is working.
-
But when I break my program into modules, these modules have a purpose and acceptance criteria by which I can say they are usable by the rest of the program or not. In the undergrowth, a program is the user of a module, I'm the customer (because I decide to move on and what to move on with next), and there can be acceptance tests. Otherwise, why bother?
-
a program is the user of a module,
Ew.
If a module doesn't do something that ultimately helps the business make money, it doesn't belong in your product.
-
If a module doesn't do something that ultimately helps the business make money, it doesn't belong in your product.
Which I assume it does, because why bother? Look, I assume we are all professional people here, not some wishy-washy Ultimate Grand Architecture Gurus with no connection to reality.
Also, it might as well help not lose existing money.
-
Not losing existing money -> more capital -> investing in the business -> making more money.
I assume it does
That's what ought to be your acceptance criteria: does it help make money or not? Defining your acceptance criteria as "does it afford more functionality to another piece of the program" leads to serious YAGNI concerns.
-
YAGNI
Had to Google that; I don't see it often enough to remember. Pulled up an Atwood blog entry as the third result.Now struggling to reconcile the contents of the blog entry with the design of Dischorse…
-
Not necessarily "more". It may be just as well an essential piece of functionality.
-
-
You want to look it up here
-
If it's essential, then you have acceptance criteria around it.
Look, the whole thing about agile talks about having releasable software at the end of each sprint. It seems to be indicating that you build a vertical slice of the stack at a time: the interface, tables, and code needed to support one whole feature, then a second whole feature. If you're spending entire sprints lost in the weeds of building libraries, you need more help than just tweaking your acceptance criteria.
-
Look, the whole thing about agile talks about having releasable software at the end of each sprint.
I have yet to see a really complex project where you can have anything resembling a money-making feature done in a sprint. You need to bootstrap it somehow. And even agile projects must have an architect with a vision of how it has to look from the bird's view in the end (otherwise I predict a slow death to them).Look, you cannot take a calculator app from a tutorial and evolve it into a payroll database a sprint at a time. Well, maybe you can. I'd like to see a case study.
(On the other hand... Many a project I had my hands dirty with had users, accounts, authentication, and login page. I really need to craft a project stub that has all of it and try to build around it. Looks like a not very stupid ideas, especially compared to other stupid ideas I have sometimes.)
-
I've never worked someplace that actually did Agile. Maybe the methodology's essentially flawed in exactly that way.
-
Agile works well when enhancing a product that already exists; for building from scratch though… use something else.
-
You either develop a monstrous monolith or you have a modular structure.
Right.
Can your modules be tested in isolation?
Sort of.
Can you tell if you really finished doing work on a module?
Usually not.
Whether the module functions as the developer expected it to (your definition of "works") sometimes has no relation to whether the product solves a business need, which is what Blakey's using as a definition of "works".
See, I see my definition as the only reasonable definition of "works".
You can't do UAT on a piece of a program unless the user interface is working.
Indeed.
But when I break my program into modules, these modules have a purpose and acceptance criteria by which I can say they are usable by the rest of the program or not. In the undergrowth, a program is the user of a module, I'm the customer (because I decide to move on and what to move on with next), and there can be acceptance tests.
Do your modules have any form of UI?
If not, if you're just chugging data from one DB to another, fine. You've made the product, it's done.
The product I'm working on has a UI, and (as all products with a UI) the UI is by far the most important part of it. So demoing (or even, to an extent, testing it) without the UI is completely and utterly pointless.
Look, the whole thing about agile talks about having releasable software at the end of each sprint. It seems to be indicating that you build a vertical slice of the stack at a time: the interface, tables, and code needed to support one whole feature, then a second whole feature.
Correct, and my complaint is that even if you take a pretty thin vertical slice in some industries it's literally impossible to complete an entire slice in a single sprint.
Which leads to us splitting it into bullshit fake-o stories that don't make sense, which leads to my distrusting the entire Agile movement is accomplishing anything useful at all, which leads to my typing shit in this thread.
I have yet to see a really complex project where you can have anything resembling a money-making feature done in a sprint.
THAT IS EXACTLY MY COMPLAINT ABOUT AGILE. You were too busy telling me I'm doing it wrong to realize you're making the same argument I am.
-
Which leads to us splitting it into bullshit fake-o stories that don't make sense, which leads to my distrusting the entire Agile movement is accomplishing anything useful at all, which leads to my typing shit in this thread.
Are we just being pedantic about following some agile list of bullet points? Or are you arguing that there's no value in getting iterative feedback from end users? Is it terribad if you start with really basic stuff in the beginning, some of which isn't very interesting or maybe even visible to an end user?
Are we just yelling at each other to take out our other frustrations?
-
Testing (Including UAT and production use) cannot prove the presence of bugs, only their absence.
Wat? Some words swapped you, I think.
-
Agile is good in trying to exploit natural evolution as its model. If you think about it, evolution is a continuous delivery process: all organisms had to successfully procreate at some point. Release, if I may called it so. The bad thing is that evolving OneNote from Notepad might take several million man-years, just like natural evolution making a hummingbird from a bacteria.
Any good creative work doesn't play well with teamwork. Teamwork means early criticism, and early criticism will kill your idea before it has a chance to stand up. Thus I expect the skeleton or a framework to build the guts of the program around must be first done by this architect guy (or gal) in solitude. Then it can be shaped further, grown guts and meat, and here the teamwork and agile go to rescue.
Any good project must have a vision, at the very least to keep it in scope and that money making bit. But inside this scope, piecemeal sprints do just fine. As do other agile bits.
I never do "Agile" to the letter of Scrum guide or whatever (I'd like to look at Kanban sometime, they say it's more suited to research projects and other such), but I try to understand why the particular rules are there in the first place. Daily standups are there so you don't get stuck and can help those who do get stuck; testing everywhere helps you tell if you're done implementing or not and whether you are in scope; sprints being limited help not drown in architecture; retrospectives are there to improve the process overall and adjust; demos are there to get in touch with reality; and so on, you name it. It only helps your processes if you have a complete understanding why a ritual exists.
-
Are we just being pedantic about following some agile list of bullet points?
No, we specifically do not follow the list of bullet points because they don't work for the product we're building.
We still have to pretend to be agile though, or else people complain.
Or are you arguing that there's no value in getting iterative feedback from end users?
Depends on what you do with it. Discourse gets iterative feedback from end users and is a piece of shit.
Is it terribad if you start with really basic stuff in the beginning, some of which isn't very interesting or maybe even visible to an end user?
It's not bad (in my estimation). But it's also not demonstrable, and therefore in the Agile methodology, it counts for nothing at all.
-
It's not bad (in my estimation). But it's also not demonstrable, and therefore in the Agile methodology, it counts for nothing at all.
I demoed refactoring a few times. I told in the Product Owner's face, yep there's nothing really visible in the UI to see, except that support stopped complaining to us every morning about an overnight process stuck here and there, and some other process not doing its work because it hogs the machine and has to be killed all the time.Or that something I did enabled fixing a dozen bugs in some measurable and relatively short time instead of a grim perspective of living with them for the time being, because "architectural reasons".
Doesn't make it Agile; agile, yes (note capitalisation).
-
We still have to pretend to be agile though, or else people complain
Right, but my point is, are you basically compatible with what some "agile" methodology says?
But it's also not demonstrable, and therefore in the Agile methodology, it counts for nothing at all.
I guess I'm not as studied on this and the pedantic need for "demonstrable" stuff.
-
As always, it depends. The most important part of making agile work is sizing your sprints correctly. Less than two weeks, you risk not completing things in time. More, you risk getting stuck on things or slacking off. Sometimes you need to re-size sprints based on the tasks at hand, but it's not unreasonable to start a project in agile.
For it to work, though, you need enough people, well defined tasks, and a good CI build. I've considered trying to implement agile on my project to some extent, but with two people who work in it in our spare time, it would probably feel wrong at this point.
But the most important part about agile is that you don't try to follow a list, and second to that is that you still plan/design everything you can up front. The whole point of it is that the requirements will change, and you need to be able to handle that as quickly as possible, and if you let a process get in the way of that, you are being anything but agile.
But really, who doesn't have something visibly different in their application after a sprint? Maybe a button has moved 3 pixels, maybe a new menu appears or a new value prints. Being ready to release at the end of a sprint does not mean that you'd call it sufficiently done to release it to users after every sprint, just that you could if you had to, and some things would work better than the last release.
-
@blakeyrat said:
Developers chose to have 2-hour-long standup meetings?
Well, yes, that is their choice, since ONLY developers should be in these meetings. If the developers choose to allow the product owner to attend, then that person is an observer only, and should remain SILENT,How much of a "choice" is that when the PMs dictate it to you, and if you don't fall in line you're given a bad review?
And don't say they can choose to leave the company.
@blakeyrat said:
Developers chose to have no QA department
Again, it is a matter of organization. There is definitely a need for many "quality" related issues, but personal responsibility is the most effective means of achieving actual quality. Having a distinct department is really counter productive.No. Just no.
-
and if you don't fall in line you're given a bad review?
If you don't have a spine, you are not a professional. If you let them walk all over you despite knowing nothing, you deserve two-hour standups.
And don't say they can choose to leave the company.
We are in high demand. If you can't convince them to do sane things, why would you stay?
-
@TheCPUWizard said:
@blakeyrat said:
Developers chose to have 2-hour-long standup meetings?
Well, yes, that is their choice, since ONLY developers should be in these meetings. If the developers choose to allow the product owner to attend, then that person is an observer only, and should remain SILENT,How much of a "choice" is that when the PMs dictate it to you, and if you don't fall in line you're given a bad review?
And don't say they can choose to leave the company.
Well, yes. but don't go on to pretend you're doing agile. You're doing micromanagement at that point.
Our team has a long history of 30-45min daily scrums, as we have hashing out the details of implementations and brainstorming on roadblocks mixed in. I don't know which way that's going to move - we'll be down to 3 people in our scrum team soon, and 2 of us seem nearly telepathic at times.
-
@s73v3r said:
and if you don't fall in line you're given a bad review?
If you don't have a spine, you are not a professional. If you let them walk all over you despite knowing nothing, you deserve two-hour standups.
So are you gonna pay my rent while I look for another job? No? Then stop spewing this bullshit.
@s73v3r said:
And don't say they can choose to leave the company.
We are in high demand. If you can't convince them to do sane things, why would you stay?
Cause I enjoy having a place to live and food to eat.
-
Cause I enjoy having a place to live and food to eat.
Then why did you accept a minimum wage programming job?
So are you gonna pay my rent while I look for another job? No? Then stop spewing this bullshit.
- It isn't my fault you are incapable of budgeting your own money.
- You don't have to quit to start your search.
Again, if you like being poor and unhappy, stay. I'm not stopping you. But it's no one's fault but your own.
-
I demoed refactoring
Re-factoring is not features. It is not functionality. It is not useful to the business. It is technical debt, and should never be the only thing you're delivering in a given sprint. It should be done in small doses as you go.
-
So are you gonna pay my rent while I look for another job?
You could certainly put up with it temporarily while you look for a better job. Rushing right out to quit is obviously a bad idea in general.
-
But really, who doesn't have something visibly different in their application after a sprint?
The biggest problem with Agile is that it's got a strong inclination to prioritise the Urgent over the Important. It's not a bad thing to tackle urgent things, but failing to tackle important ones is a huge threat over time. (It's the classic global vs local optimization challenge in a high-dimensional state space.)
-
If you aren't prepared to deal with that, you aren't prepared to produce a good system, regardless of your general strategy.
-
The biggest problem with Agile is that it's got a strong inclination to prioritise the Urgent over the Important.
Slew rate limiting priority changes can help.
-
No, it makes sense: once you've written the test, there's no way you're gonna let it keep failing for more runs than it takes you to fix the issue, are you? Or maybe you even wrote the test after writing the code
. Either way, testing generally shows that the bugs you've identified so far aren't present; it doesn't say anything about the bugs that are present that you haven't found yet.(Not that I believe the original comment actually meant that, mind you. I'm just maliciously reinterpreting it as “the presence or absence of each individual bug tested for” for the sole purpose of contradicting you.)
