Hey guys I’m trying to come up with the perfect concise way of explaining what agile methodology is when explaining it to my friends. Every time I do, I feel like I ramble on and on and what it’s principles and values are without actually understanding what they are. My manager also says this too.
In: Technology
Instead of making a batch of 100 cookies, make 10 batches of 10 cookies, because you get more feedback from 10 batches than from 1.
Agile is just building something in iterations rather then designing it fully and then start building. Especially in software design where you can alter anything by just building it again with the only resource lost is coffee.
Often in software design it is just faster and cheaper building a component a couple of times compared too talking about it for ages in meetings.
Waterfall:
Customer says they want a car with 4 wheels and 2 doors. You build them a car with that, it takes 1 year. They hate it. Turns out they wanted it in red and to have 4 doors – even though they said 2 originally.
Agile:
Customer says they want car with 2 doors and 4 wheels. You do 4 weeks of work, then show them the progress. They say “yes keep going” or “no actually let me see the design in red”. Rinse and repeat. Now it takes 2 years instead of 1 because of all the damn meetings but they actually got what they wanted (since honestly they don’t know what they want yet) and you did work in more bite-sized tasks.
Agile is great for designing what someone *actually wants* or needs, especially if the environment is changing a lot. Maybe 2 door cars become really popular next year and you need to adapt. Agile is less popular when you do something that requires VERY strict upfront designs and guidelines to sing off on, like building a bridge.
Agile is a project management philosophy that’s useful when project scope and costs bug unknows. Agile is best defined in contrast to more traditional project management philosophies like “waterfall”. A waterfall plan looks like this:
– Plan your product, and figure out what’s going to cost to make
– Build your product
– Deliver your product to the customer
This works great if your customer knows exactly what they want, how to do it, and how much things are going to cost. So if you’ve done this kind of thing before, Waterfall is probably the right approach. The problem with this is it doesn’t respond well to unknowns and change. What if the customer decides they want something slightly different halfway through the building process? What if costs aren’t what you thought? What if the customer is unhappy with the final product? Maybe they thought it was going to look different. Agile looks like this:
– Plan part of your product to get it working at the bare minimum
– Build it
– Deliver it to your customer
– Get customer feedback
– Use that to plan next stage of improvement process.
– Repeat
This can work really well for certain products. It allows your customer to be directly involved with the process. The key here is that each improvement cycle is fast, so if something isn’t working, resources and time waste is kept to a minimum (this is the “fail fast” mentality) .
We need a meeting to plan our meetings.
Then we need meetings to check-in before all those meetings.
Then we need to have all those meetings.
Then we need to have a meeting to see how all those meetings went.
Somewhere in there, you do actual work.
Latest Answers