We all knew it
Personally, I was never great with agile projects. I get that it’s good for most and sort of used it when I was a CTO but as a solo developer, there are days when I’d rather eat a bowl of hair than write code and then some days, I’ll work all night because I got inspired to finish a whole feature.
I realize I’m probably an exception that maybe proves the rule but I loathed daily stand-ups. Most people probably need the structure. I was more of a “Give me a goal and a deadline and leave me alone, especially at 9am.” person. (Relatedly, I was also a terrible high school student and amazing at college. Give me a book and a paper to write and you’ll have your paper. If you have daily bullshit and participation points, I’ll do enough to pass but no more.)
Stand-ups can become so proforma. What did you do yesterday? I coded. What are you doing today? I am going to code. Do you have any blockers? No. It gets a little repetitive after a while.
I think you are missing the part where you help others with their blockers.
If someone is blocked I’d be pretty cranky if they waited until the next day to mention it. Blockers are to be dealt with swiftly and with extreme prejudice.
Wtf is Agile ? I can’t get my head around that.
It is a methodology to develop software quickly. It has some good things about it. But it can be very heavy on meetings and agile idealists are not very flexible. As many of the other comments say, a mixture of agile and some other methodology or starting with agile and developing your own process that works for your team or project is the best way of managing a project. I don’t understand why so many people don’t seem to write requirements when using agile. Even with agile I will not start coding until I have relatively clear requirements. It is not too bright to start speculative development without really knowing where you are going. https://agilemanifesto.org/
I don’t understand this… How do you code if you don’t know where you’re coding for? Am I the only one that thinks that sounds crazy?
Commonly you will have a relatively broad goal of providing some functionality by the time a project is done. Every sprint, commonly two weeks, you concentrate on producing a piece of functionality that will get you closer to that goal. At the end of a sprint, many teams are expected to have what’s called a minimally viable product that is technically usable. The problem with that concept is MVP almost always becomes production. That results in poor coding that is hard to support. It almost always involves rework later on, often when something is already in production. And you are not crazy. Not having a clear idea of what you’re coding for is wasteful and very inefficient.
But it can be very heavy on meetings and agile idealists are not very flexible.
Seems a little ironic haha
Right? I find agile purists to be some of the least flexible people I’ve ever met. They are the exact opposite of agile. To be fair though, I have found that a good scrum master can be worth their weight in gold. You always know the status of a project and the individual stories. It can be very, very helpful.
Pbpbpbp…agile fails fast by design.
The counter from the article is you need a specification first, and if you reveal the system wasn’t going to work during requirements gathering and architecture, then it didn’t count as a failure.
However, in my experience, architects are vastly over priced resources and specifications cost you almost as much as the rest of the project due to it.
TLDR…it’s a shit article that confuses fail fast with failure.
