231–240 of 271 posts
I feel this in my core. There has been a period of the last 5-6 years where folks have stopped writing specs entirely and it has driven me nuts. Everything is a story or some other abstract requirement. The absence of a specs has made software worse and less predictable in my opinion. All hail the specification!
There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere. In that: if it fails, it is only considered evidence that you were not doing it enough . The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty. It's also true for Cloud providers; that they're not suited for certain…
It's definitely not a magic bullet and I suppose the only reason it's had the staying power it has had is because unlike other project management philosophies, it has an extremely profitable "Agile Seminary" ecosystem.
Earlier quoted context omitted.
> "You're going to do agile .... and this list of features will be ready on September 20th." Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then. We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.
What has happened to me in those cases is that Architects lumped on a lot of extra nice to have things which would certainly have made us fail the time constraints. It was completely un-agile and I only got things done on time by demonstrating very clearly that time sensitive work is not the place for grand refactoring and at last winning over the main architect. When there's a time constraint one has to be able to w…
Earlier quoted context omitted.
I think the confusion comes from considering Agile as a process instead of a set of values and principles. The Agile Manifesto only talks about values and principles( https://agilemanifesto.org/ ). Values are not right or wrong, they are just values you agree to or don't. The problem mostly arises when processes are shoe-horned under the guise of 'Agile' in setups where they might not be the best fit by so-called pro…
I think it’s long past the time where we can pretend that The Agile Manifesto is representative of what the word “Agile” means in tech companies. The manifesto is a minimal set of principles but every real world Agile shop I’ve interacted with has subscribed to a set of processes that everyone in tech would recognize as “Agile”. The manifesto has become a safe retreat that agile fans bring out whenever someone has cr…
Yeah, spending the amount of words in this thread trying to diagnose or complain about this simple problem in abstract strokes seems silly and frankly confounds me when considering the amount of time people wish to waste discussing the problem.
As with political parties, bad gentrification in cities, and all the rest, once money and consultants turn things into an industry you're pretty much fucked.
People should just immediately stop taking people with conflicting interests at face value when they talk. Stick to concrete details when you talk about stuff, avoid industry terms, don't let them turn things into abstract and general discussions. It only feeds the trolls (consultants) when you even complain generally about it.
Fight it with your day-to-day actions, not so much with your words. And then let it die in silence, it will die faster (I'm referring to any tech topic captured by consultants and monied interests).
Earlier quoted context omitted.
I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.
Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.
Earlier quoted context omitted.
Yes, that's agile software development.
No, not quite. The specifications we use for agents make any ticket written before them pale in comparison. That enables a hybrid workflow that is both spec-driven and "agile", in the sense that you're doing very rapid development cycles.
I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams. For reference, here's all the Agile you need, it's 4 sentences: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding t…
Yeah we work agile, just look at this diagram, it's super agile. https://framework.scaledagile.com/safe-6-0-configurations/ It's got loops and infinity markers, AND iconography representing humans!
If you've never built a complex thing out of wood, I highly recommend it. There's an interesting curve of experience. First you try to build basic things, and it seems kinda easy, everything just works. Then you start trying more advanced things, and it seems like everything gets screwed up constantly. Finally you master the advanced things, and you screw up less and it gets easier. The same is true of software. At f…
And that's why agile is not a set in stone process, that imposes tools and process upon the devs, but states: "Individuals and interactions over processes and tools". Basically, it tells you, that you will need to figure out what works for this project and this set of people.
Say you're building a boat. Boats require not only lots of skills in woodworking, but a whole 'nother skill of design, to get a boat that does what you want on the water. It is always time-consuming, expensive, and hard.
And there's two basic ways to build it: with plans, and without plans. Without plans, you have to design it yourself, then try to build it, then make mistakes, maybe even to the point you have to start from scratch. Time-consuming, expensive, hard. But start with plans that have already been built, and you benefit from somebody else's time, money, expertise and toil. The boat is built faster with less effort and fewer mistakes. And instead of needing master craftsmen, you only need journeymen who can follow orders.
There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere. In that: if it fails, it is only considered evidence that you were not doing it enough . The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty. It's also true for Cloud providers; that they're not suited for certain…
The do-more-with-less cancer that is infecting so many companies, where the tumor is Continuous Growth.