I believe an important aspect of Agile is not only releasing what is functionaly requested by the user base and generating revenue for features/product that people want to buy vs. features no longer wanted, but usability has to come into play as well. If you deliver working software without the desired usability, you still haven’t succeeded.
I would also recommend reading Damon Poole’s blog from Accurev. Some very insightful and regular posts that we find valuable.
Thanks for this informative post
It really great to participate in conversation. i got the information from happening discussion here.
THANKS
Thanks Kelly,
This is one of the best Agile's blogs I have ever come across.
It is simple and clear in expalining Agile methodology.
Ahmed.
Thanks Ahmed, that's really nice of you to take the time to say that.
Kelly.
Hi Kelly, This blog is great. Thanks for all your work. I am writing a book on Agile — can I quote you in it? You'd make a wonderful expert for it.
Hi Kelly,
I hope you can help me in my research for my master degree. I am trying to find out where the term Agile working came from and how it evolved.
I am trying to see if it is practical to make the back office employees in a finance company ‘Agile’, and how Agile could inpact on motivation and goverment directives.
Elaine
great list. i always have one more item in mind for myself.
“It’s important what you are doing, but not how you are doing”
Hello Kelly
Nice blog you made here, I got a website about the waterfall Model and also about agile software development. I hope I can call your name here and there.. since you provided me with some really usefull information about agile.
Great post. I know I’m late to the post, but just diving into SCRUM and whatnot. Definitely a lot to learn, but so valuable. Thanks.
Just spare 2 minutes to think that building a software is like constructing a home.
1. You can construct a home without a blueprint.. It will definitely be built…. but if some one else purchases the house tomorrow will he know the wiring, strengths and weakness of the house.
2. Will the new comer know the security advantages and restrictions of the house or should it remain an assumption.
3. Tomorrow if somebody wants to add a new room in a new floor wouldn’t it help to have a blue print of the house or does he have to study the house or just break the house and start allover again because he does not know the wiring details etc
4. Houses if properly planned can be built to even be earth quake resistant as they are now present in earth quake prone regions after a previous earth quake.
5. Watch the news and serials where day in and day out buildings are collapsing or roof is falling or there are water leakages, all due to poor construction work.
In short Waterfall model is one extreme and Agile is another extreme. We need to strive to achieve the perfect results of a waterfall model while using the pace and speed of an agile model. Try to think of the two models as a weighing balance where the product is stable only if the weights are equal.
Conclusion:
1.Just because a region has frequent earth quakes, it is wrong to infer that we do not require a blue print for constructing the house and changing the blueprint as and when new additions are made. On similar terms just because the requirements are changing it is wrong to conclude that changing requirements should not be recorded in a formal approach.
2. We need to aim at Earth Quake resistant houses that have good blue prints and with good explanation of all its whereabouts such as security features, positives and negatives that are not assumed but are explicitly stated. Similarly we need software that are robust and have all requirements captured and that have well documented artifacts that don’t make room for assumptions.
Hi Kelly,
Awesome blog you got here. Really helped me through my studies on agile development.
Thanks alot!
Hi Kelly,
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
http://tusharsomaiya.com/wordpress/index.php/2012/01/agile/coaching-agile-teams/
Edited version of the post also features on ScrumAlliance.org at
http://scrumalliance.org/articles/395-coaching-agile-teams
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.
Tushar Somaiya.
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?
Hi Kelly,
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.
Regards,
Varaprasad
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?
Hi John,
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 http://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 http://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?
