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 like your point about the idealists. IMHO, agile has some merits, rooted in psychology. For example, during stand up to say what your plans are for the day. Same for the sprint and quarter. It helps with communication. I don’t like the thing where everything needs to be a deliverable thing. I’ll poke my eyes out if I need to sit through another example of building a skateboard, scooter, bike, truck. Try that example with something real like a bridge or house. It ends up in a lot of throwaway work. Now try doing that in a highly regulated field like government or finance where you really can’t iterate due to oversight and regulatory compliance.
Oops, this turned into a rant. Well at least agile pays the bills. There’s a lot of money to be made in prolonging the problem.
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.
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.
Agile is not about being quick, it’s about delivering what the customer actually wants. When you do Waterfall you gather all the requirements, then you sit down and code the thing. Only to find out months or years later that you delivered crap as the customer didn’t even know themselves what they wanted.
With agile you take it one step at a time. What is important now? Get the requirements for this feature, deliver it in the next two weeks (or at least a part of it). Then the customer, which can be an actual customer, or your internal Product Owner, or a Product Manager looks it over. If the whole thing is perfect? Nice, carry on to the next thing.
Often you find out some detail was overlooked, or a new requirement came up, or the design didn’t fully work out. So pack it into the next sprint and do it better. You’d never get this feedback if you gather “all” requirements first and then just try to go from start to finish.
Agile certainly has its upsides when done right, unfortunately there’s not a lot of companies who manage to do so (like most I’ve been part of). Despite being messy at times, it’s still better than Waterfall. There’s too many meetings either way.
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 like your point about the idealists. IMHO, agile has some merits, rooted in psychology. For example, during stand up to say what your plans are for the day. Same for the sprint and quarter. It helps with communication. I don’t like the thing where everything needs to be a deliverable thing. I’ll poke my eyes out if I need to sit through another example of building a skateboard, scooter, bike, truck. Try that example with something real like a bridge or house. It ends up in a lot of throwaway work. Now try doing that in a highly regulated field like government or finance where you really can’t iterate due to oversight and regulatory compliance.
Oops, this turned into a rant. Well at least agile pays the bills. There’s a lot of money to be made in prolonging the problem.
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.
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.
Agile is not about being quick, it’s about delivering what the customer actually wants. When you do Waterfall you gather all the requirements, then you sit down and code the thing. Only to find out months or years later that you delivered crap as the customer didn’t even know themselves what they wanted.
With agile you take it one step at a time. What is important now? Get the requirements for this feature, deliver it in the next two weeks (or at least a part of it). Then the customer, which can be an actual customer, or your internal Product Owner, or a Product Manager looks it over. If the whole thing is perfect? Nice, carry on to the next thing.
Often you find out some detail was overlooked, or a new requirement came up, or the design didn’t fully work out. So pack it into the next sprint and do it better. You’d never get this feedback if you gather “all” requirements first and then just try to go from start to finish.
Agile certainly has its upsides when done right, unfortunately there’s not a lot of companies who manage to do so (like most I’ve been part of). Despite being messy at times, it’s still better than Waterfall. There’s too many meetings either way.