Readit NewsI think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. It's more like mathematics, where it takes time to discover that things are actually rather easy (this quote comes to mind https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-d...).
Of course, if you look at the project from the longer time perspective, it can appear as continuous production of improvements. But it has a kind of quantum nature, if you decrease the scale of time, you will see less continuity and more discrete bursts of code production. There is something like uncertainty principle that on certain scale, it's pointless to try to predict things, because making the correct prediction (which is needed at least to define thing DONE) will take as long as doing the thing in the first place.
I don't consider myself special, but it is possible that Scrum ruins great minds because they seek conceptual clarity (we sometimes humbly call it "lack of technical debt"). I am not sure how to make that work with Scrum. Perhaps if everything was done three times, punctuated by a team discussion, each time with shorter code.
Second thing that I dislike the most about Scrum is that it threw away (or at least "conveniently" renamed) pretty much everything that was ever known about project management. Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss. (I think it comes from the fact they actually realized the quantum nature of development is a problem.) To me, that is a huge red flag that it is, in fact, a snake oil.
P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.
If somebody complains that Scrum is bad because e.g. every day you have to update management at stand-up (as mentioned in TFA), but the Scrum Guide, every book ever written on scrum, the websites of the Scrum Alliance and scrum.org, and more or less every advocate of scrum great and small, states explicitly that this is not the purpose of the stand-up but instead to highlight obstructions and opportunities for collaboration, then I don't see what more there is to say than "you're doing it wrong" - because you are doing it wrong, in letter and in spirit. It may not be your fault that you're doing it wrong (it's my guess that the widespread perception that scrum is management-heavy is a function of scrum's market penetration combined with the inherently dicatorial culture of corporate governance). But doing it wrong you most certainly are.
This is not one of your complaints of course, but you do complain about estimation, which - as a sibling comment mentions - is simply 'out of scope' for Scrum, which is a smaller package than people think. (Plenty of scrum thought-leadery types are part of the 'No Estimates' thing, for example.) It does, however, mandate that you occasionally meet for the explicit purpose of working out how to improve processes that are not working properly (such as estimation) - in other words, that the team takes seriously as a collective all the things that scrum does not talk about in itself.
This has benefits and downsides. One of the one hand, the development team getting to control the estimate helps to control the workload.
On the other, I agree. Why are we pulling estimates of effort out of thin air? Why are we being asked how long it will take to do work in sections of code we have never seen?
Planning could be far more accurate if we just got a proposed task list a day before planning.
It is common enough for those packs of estimation cards to include one with a question mark on it, to denote the "I can't estimate this sight unseen" scenario. The reason it's common is because often people are presented with stuff that isn't well-understood enough, and it's a very good idea not to pull a number out of one's rear in those situations. Don't be afraid to use that card (or do the equivalent and just say so).
If you are afraid because you will be marked as 'not a team player' or whatever, you have management culture problems that neither Scrum nor any other imaginable software development process will fix on its own. They will all end up feeding an idiotic garbage in/garbage out cycle of overpromising, crunch, burnout and general misery, with the superficial appearance of whatever process it was supposed to be.
As a literature graduate, this made me laugh. Maybe literature courses are more leisurely stateside, but for me it was a book a week (not 4 to 6 weeks, as OP suggests). That was literally how classes were run.
And it was stupid for the reasons outlined. I remember my class on Ulysses mostly because a) I was acutely conscious of not having been fully keeping up in the 250 pages before the closing chapter and b) when I arrived at class it became clear after about 2 minutes that only I had finished it, because I had read it over the summer break because I was really keen on those bragging rights, but everyone else has tried to read it in one week, which is a doomed endeavour if ever there was one. It would have been a better experience for everyone concerned if more than one person had done the reading, but that was not realistic on the assumption that Ulysses can be polished off in the same time as The Power and the Glory.
I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work and didn't spend any time on the Kafkaesque exercise of "sprint retrospectives" and "grooming sessions". Our product manager didn't tell us what to build, but acted more as an advisor for the engineering team leads.
I think in some case scrum is an attempt to compensate for inexperienced management.
I assume we just weren't "doing agile", but when I was younger it always left me feeling vaguely inadequate: if I was just more efficient and competent, maybe the 2-week sprint would fit better. Maybe that was the point.
Has anyone here ever delivered useful features to users on that kind of cadence? What was it like?
The devil is in the definition. As an example, we have a tool that bootstraps a new Git repo and we're adding a feature that will include our company Rubocop config if it's a Ruby project. There is no reason on earth that this should take 3-5 developers a week to accomplish (never mind two). But it's a feature and it could be useful. And on top of all the other features, the tool is quite useful nowadays compared to the first extremely thin slice we did.
The trick is reducing what you're counting as a feature to the smallest thing that is actually worth bothering to use. It won't always fit into one or two weeks, especially if you're dependent on hardware manufacture, or beholden to the iOS store approval timetable or whatever. But for your line of business SAAS apps there's absolutely no technical reason why you can't do it; there may be human obstacles to doing so. (Hell, maybe we're all wrong and you shouldn't do it.)
The iPad is a great device but, it isn't essential to anything or anyone. If tomorrow there where no iPads anymore, we would all just get on with our lives.
It's as if somebody were to declare that house music died in 1990, with the only evidence being an analysis of records from that year, and everything subsequent to that year simply ignored.
That is not to say that there's nothing wrong in these scenes, but we then get to the sort of economic arguments he dismisses at the outset; eg, the effect of gentrification on night spots, and so on.
Changing one developers _working code_ after they’ve invested a significant amount of time into without discussing it with the team first it is to basically heap on a number of unwritten requirements and also decide that the schedule allows for addressing them. If removing repetitive code is a requirement then the team needs to be informed that code will be reviewed for repetition, and introduced to various techniques for spotting and removing repetitive code. The schedule also needs to be adjusted to allow for this additional work.
And if the rewritten code is so superior than perhaps there needs to be a discussion about whether there should even be a team, or whether the other people should be let go and all work assigned to the developer who can do the work “properly” the first time. After all, what’s the point in having one developer’s work constantly rewritten by another?
Things like this are never requirements, at least in the conventional sense of 'things the stakeholders ask for the software to do'. Nor should they be: it's our job as professionals to know how to do our work. I don't want a PM or sales rep worrying about the Liskov substitution principle (unless I'm working for code climate or something): it's a waste of their time.
Code cleanliness should make future changes easier. Of course, some 'cleaning' expeditions do the opposite, so there should still be code review etc.
I also much prefer brutalism to soulless glass and concrete skyscrapers or nondescript office buildings. At least brutalist buildings look like something.
I can remember the exact moment I fell in love with the style - I was traveling north on a streetcar on Spadina avenue in Toronto, back in 2005, and I caught a glimpse of the John P Robarts library, and it really did change my outlook. I grew up in Plymouth, which was blighted with poor examples of the style imposed on the town after heavy war damage. Much of the hatred of brutalism stems from the contemptuous attitude these planners and architects displayed to the pre-existing urban fabric.
I felt like the only one until about 5 years ago however, then suddenly there was this revival.
Now I'm more into medieval cathedrals, but it's worth noting that 'sophisticated' tastes were against them for centuries (hence the pejorative term Gothic). I don't think anything can be beautiful without irritating somebody ...
With that said, there are some types of software that exist to deal with complexity external to itself. External systems (integrations, screen scraping systems, etc.) can break without fault internally, but need to be fixed ASAP.
One might say, "You built it poorly by deciding to build this at all." And sometimes that's true. But I've been in plenty of situations where the options were 1) don't solve the customer problem, don't pass go, don't collect $200. Or, 2) build finicky software that works but needs to be babied... and hire engineers that don't mind doing this type of work.
That last bit is critical. Some engineers like the heroics and drama of it. Some people can't help but run headfirst into the fire... and there's jobs for them there :-)