For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Helitha Rupasinghe -
Ismael Chery -
Helitha Rupasinghe -
Aneeqa Khan -
Once suspended, maheshkay will not be able to comment or publish posts until their suspension is removed.
Once unsuspended, maheshkay will be able to comment and publish posts again.
Once unpublished, all posts by maheshkay will become hidden and only accessible to themselves.
If maheshkay is not suspended, they can still re-publish their posts from their dashboard.
Once unpublished, this post will become invisible to the public and only accessible to Mahesh K.
They can still re-publish the post if they are not suspended.
Thanks for keeping DEV Community safe. Here is what you can do to flag maheshkay:
Unflagging maheshkay will restore default visibility to their posts.
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.