Articles on this Page
- 02/05/12--05:58: _By: Tushar
- 03/21/12--11:09: _By: Mehmet Seker
- 05/09/12--12:05: _By: Agile Developer
- 05/28/12--06:24: _By: Suni Jain
- 08/09/12--01:11: _By: Steve Shields
- 07/29/13--13:23: _By: Varaprasad
- 10/30/13--09:32: _By: achi
- 04/15/14--11:22: _By: john
- 05/07/14--18:19: _By: Brian
- 07/17/14--08:50: _By: Frank
- 07/30/14--11:17: _By: Kate
- 07/30/14--22:22: _By: Sanket
- 08/04/14--01:35: _By: P
- 02/05/12--05:58: By: Tushar
- 03/21/12--11:09: By: Mehmet Seker
- 05/09/12--12:05: By: Agile Developer
- 05/28/12--06:24: By: Suni Jain
- 08/09/12--01:11: By: Steve Shields
- 07/29/13--13:23: By: Varaprasad
- 10/30/13--09:32: By: achi
- 04/15/14--11:22: By: john
- 05/07/14--18:19: By: Brian
- 07/17/14--08:50: By: Frank
- 07/30/14--11:17: By: Kate
- 07/30/14--22:22: By: Sanket
- 08/04/14--01:35: By: P
I resonate with you when you said "what is agile" is one of the most searched question and the count is going up.
For me, agile is not agile manifesto or different methodologies like scrum, XP etc... Agile is much more and beyond values, manifesto, principles and methodologies. It is much much deeper than all of these.
This is what I explained in my blog post
Edited version of the post also features on ScrumAlliance.org at
What is agile? The Free Dictionary defines it as “characterized by quickness, lightness, and ease of movement.” Webster notes that it is “marked by ready ability to move with quick, easy grace.” The way I like to put it is, “Quickly responding to changes defines agility.”
In the context of software development, how quickly, lightly, easily, readily, and gracefully we respond to changes while developing software defines our agility. (Notice the word respond and not react.)
Hope this helps and adds value.
Can I have this post of yours on my site too?
Would you like to write a guest post exclusive for me?
Thanks in advance and best of luck for all you do.
Agile Coach, Results Certified Coach & Servant Leader
I totally agree with you on mixing up useful part of the other methodologies that fits your project better instead of confining into a single methodology.
Thanks for the nice and detailed article, my favorite part is "A collaborative & cooperative approach between all stakeholders is essential"
It takes ages to come to a collaboration and cooperation approach, specially when people are used to work in their own silos.
A perfect and most basic article for agile. I studied it from starting to end and got basic knowledge about agile.
I have read several articles that advocate that the ‘Agile’ Team would be required to be co-located, but surely with modern technology etc and the fact IT suppliers are not always in-house that this is not a pre-requisite?
Nice Article. Given clear high level idea on Agile principles. 10 principles are articulated in very understanding manner. I have worked for 2 major development projects. Initial one have lot of issues due to larger single release with lot of requirments and time duration(More than 2 years). Knowingly or Unknowingly, we follow the most of these Agile principles in the 2nd project and able to deliver multiple modules in iterative manner and able to release timlely deliverables and able to make customer happy.
thank you s much kelly :) :) :)
After reading this I still don't understand Agile (or XP or Scrum).
Aren't the 10 characteristics part of every project planning model? What are the success stories?
Isn't agile all about: a chaotic, developemnt approach steered by customer's changing demands but whithout documentating?
In a traditional software development, you would typically have a requirements gathering phase (analysts plus business stakeholders), design (analysts plus architects or senior developers), coding (development team), testing (developers plus QA), then user acceptance testing, before sign off and release. The key thing to note here is that each part of the process happens only once.
In this model stakeholders are involved at the start and at the end only - this can be months or even years apart - this is considered to be not "active" by the OP. Equally, they only see one "release" and therefore get no chance to steer the software if it is not what they require. The assumptions in waterfall projects that allow a detailed plan to be produced are that the customer knows what they want and that it will not change during the lifetime of the project. Experience suggests this not to be the case.
On your final point, agile software development favours working software that delivers value over documentation. However, if documentation is the most valuable item your team could produce at a given time then that us what they *should be* producing. Agile development does NOT equate to undocumented development
In a traditional software development, you would typically have a requirements gathering phase (analysts plus business stakeholders), design (analysts plus architects or senior developers), coding (development team), testing (developers plus QA), then user acceptance testing, before sign off and release. -
Your previous explanation is good for the traditional method. What will be different if Agile method is used for the same software development description above from your blog. Am so confuse about the difference. Thanks
We’re Building a Planning Poker Tool That’ll Make You Flip, and We Need Your Feedback
Hey there. You’re familiar with Agile, right? Of course you are. Well, then you’re also familiar with the one meeting that you have to have and that you absolutely dread.
Yeah, we’re talking about sprint planning. Long, tedious, boring and seemingly never-ending. We’ve all been there: the epic user story with a zillion details, the one story that is either 5 effort points or 100 (let’s discuss that!), or the lunch order discussion that somehow takes up half the morning.
Well, we’re making a tool to make that all better, and we’d like your help to make it better. We’re calling it Poplr (learn more at www.poplr.io), and we’re really excited about what it will help Agile teams to do.
Here are some features we’re already including in our beta (coming this weekend), but we want to know what else you’d love for us to include:
Unique, shareable poker games for your team; a dealer role to create a game and track results; story point averaging; annotation tools and team chat; a timer to avoid tangents; and the big one – the ability to export to .CSV!
This sounds amazing, right? Right. But we think it can be better if we have your help.
Let us know what type of features you’d like to see in an agile planning poker app. Tell us about some problems you’ve been having in your poker sessions. We’ll let you know when we’re going live (beta coming later this week)!
Check us out at www.Poplr.io, and hit the Feedback button!
Thanks in advance for your feedback. Happy sprint planning!
Agile is the most worst methodology in IT industry.
It treats human as a machine. It over pressurises all participants (Developer and tester) throughout the project and does not guarantee quality of the product.
I have seen many of colleague leaving companies who are trying to implement agile methodology agreessively.
In an enterprise project, being a complex project, most of the people failes to estimate tasks and they starts lagging behind the schedule.
Due to this they either stay long hours in company or works on weekend.
These poor guys spends there most of the life in AC cabins, they loses there connections with outside people and family members.
Due to this they won't able to work for a longer period of time and this results in major health issues, depression and thereby they become jobless.
Agile doesn't give work and life balance.
IT guys should come up with some best methodology which will fall between waterfall and agile.
I'm a Business Analyst and new to AGILE. Our company is looking at moving towards AGILE. My question is in the AGILE environment is how has the role of the BA change?