For further actions, you may consider blocking this person and/or reporting abuse
Read next
Vitalik’s “The Splurge,” Devcon AA Hub, Kontos L2 Blockchain, Rhinestone’s Smart Account Protocol, and Arcana’s Unified Wallet
Alexandra -
Announcing the MagicAPI AI Gateway: The Fastest AI Proxy for Developers!
shashank agarwal -
VMware'de Bulunan Cihazı GNS3'ye Ekleme
Abdulkadir Erbas -
Benchmark Software Testing: Ensuring Optimal Performance and Quality
keploy -
Top comments (4)
I'm not sure if I'm meant to offer an answer, but here's how I often explain the difference:
To be agile (lowercase A, for the sticklers), do a little and then check in with your team, your stakeholders, and/or your customers. You're more likely to catch mistakes before they get bigger.
Little Timmy, you know what I said about staying away from the medicine cabinet? Do the same with "Agile Project Management"
Seriously though, it's a very broad term and is often done badly. The usual common theme is breaking up the work into very small pieces, and delivering iteratively as opposed to waterfall where everything is speced out, designed, written, tested, deployed one after another.
There are loads of (usually horrible) ways of doing it, the more complicated ones being the worst.
Please note almost all of them have little to do with The Agile Manifesto.
This is my main gripe with all this. Every time you see somebody talk about their Agile process (upper case A), which generally isn't really agile (lower case a).
The agile software development manifesto is not a big document. It's just a few principles. One of the principles is generally violated by the Agile processes which rule in companies who practice Agile software development: Individuals and interactions over processes and tools
They have a process, and that is the way they work. End of discussion.
Quite often companies claim to be agile, but they just do Scrum in the classical sense and to the letter.
Understanding a subject is a process. We learn a few things about the subject. We integrate this into our existing knowledge, building a coherent picture in our mind. That makes us ready for new knowledge about the subject. We can start to look at more details. We integrate those details into our mental picture. Then we might be ready to understand exceptions, and so on. That's how we learn: layer by layer, integrating each before we can understand more.
If you're five, there are many subjects for which only simple answers will work. This is a real-world example of the layered knowledge-acquisition principle at work.
The same with a system or a new product or web-site. We learn as we go. If we try to discover everything and do extensive analysis before we start coding, we will fail. We will need to rework things. Instead, we should bit the bullet and plan for rework. Indeed, we should plan rework as if it is the norm. As we build new things, we will learn more and refactor old code. By understanding how humans learn, we plan for that learning. (Of course rework is not everything -- the net value should grow.
Agile is an approach that recognizes how human beings learn and build mental systems, and plans for implementations to accommodate this human process.