Hi Mohamed --
It sounds like you're working on a team that follows a waterfall (or, at least, a waterfall-like) process. I'm actually really happy to hear the questions that you're asking, because they're exactly the questions that we answer in
Learning Agile. I hope you get a chance to read it -- if you do, I would very much like to hear what you think of it.
Here's a little more information to address your specific questions and comments, and hopefully help you sort things out a bit.
I am a team member who reads well defined specs and get tasks assigned from a boss and starts development/coding straight away.
When you're following a waterfall process, each project typically goes through a set of sequential stages or phases (eg. planning, requirements, development, testing, deployment). Typically, different teams are responsible for different phases. The reason that it sounds like you're following a waterfall process is that you're following a spec that was already completed before you got to it, and you're assigned tasks that are probably part of a project plan. The spec was probably created during an earlier requirements phase, and the tasks were probably divided up during a planning phase.
One way that agile differs from waterfall is that the development team is heavily involved in deciding what gets built, how the project is planned, and who does what tasks. You still have a boss, but he generally trusts the team to divide the work. But that trust must be earned by having everyone on the team take a much more active interest in the people you're building software for, and what's important and valuable to them.
Then there is my own testing, and then two levels of testing before I send my deliverables for deployment to production. there are occasional team meetings frequency of which depends on the boss under whom i work. Whenever necessary I am able to query the users/clients regarding any questions that arise out in the middle.
This is also typical of a waterfall team. The developers do their unit testing, decide their work is done, and then pass their code on to a testing team to do their own testing. The developers and testers don't usually work together -- in fact, it's very common for developers to talk about passing their work "over the wall" to the testing team.
Another way that agile differs from waterfall is that the developers are highly involved in quality--and the testers are highly involved early in the project, in the planning and even in development (if they can). Everyone is much more interested in each others' work, and can give a lot of feedback to each other.
I am hearing this term Agile only recently. is it a recent hit in software development process just like bootstrap/jquery libraries suddenly boomed into popularity?
or I have been left out of the world for so long for not knowing it?
The term "agile" was coined in 2001, and has been getting more and more popular over the last decade. It has a lot of staying power because many agile teams report extremely good results, and are able to get past serious problems that have plagued their projects for years.
As an aside, the reason that bootstrap and jquery have gotten so popular is because they make certain things about web development much, much easier -- just like agile has made running projects much, much easier for many teams.
I think i have to learn Agile to stay relevant to the IT industry.
In my personal opinion, this is true. It is also why Jenny and I dedicated so much time and effort to making agile as easy to learn as possible in our book.
