Articles on this Page
- 02/12/07--04:13: _By: Paul Klipp
- 03/11/07--06:40: _By: Anonymous
- 01/22/08--09:18: _By: Anonymous
- 01/23/08--08:15: _By: Kelly Waters
- 08/11/08--22:33: _By: Karthiganesh
- 08/11/08--22:55: _By: Kelly Waters
- 10/12/08--13:55: _By: Anonymous
- 10/13/08--00:21: _By: Kelly Waters
- 02/25/09--13:44: _By: Mark
- 07/09/09--22:53: _By: Project Managem...
- 06/03/10--01:40: _By: Project Managem...
- 08/19/10--02:30: _By: Anonymous
- 08/19/10--05:59: _By: Kelly Waters
- 08/29/10--09:43: _By: Elizabeth
- 03/20/11--15:25: _By: Elaine
- 05/09/11--08:08: _By: Andrej
- 05/21/11--21:19: _By: Waterfall Model
- 06/10/11--09:11: _By: Casey
- 09/21/11--06:07: _By: Bharath Seshadri
- 01/13/12--23:12: _By: James
- 02/12/07--04:13: By: Paul Klipp
- 03/11/07--06:40: By: Anonymous
- 01/22/08--09:18: By: Anonymous
- 01/23/08--08:15: By: Kelly Waters
- 08/11/08--22:33: By: Karthiganesh
- 08/11/08--22:55: By: Kelly Waters
- 10/12/08--13:55: By: Anonymous
- 10/13/08--00:21: By: Kelly Waters
- 02/25/09--13:44: By: Mark
- 07/09/09--22:53: By: Project Management Templates
- 06/03/10--01:40: By: Project Management Software
- 08/19/10--02:30: By: Anonymous
- 08/19/10--05:59: By: Kelly Waters
- 08/29/10--09:43: By: Elizabeth
- 03/20/11--15:25: By: Elaine
- 05/09/11--08:08: By: Andrej
- 05/21/11--21:19: By: Waterfall Model
- 06/10/11--09:11: By: Casey
- 09/21/11--06:07: By: Bharath Seshadri
- 01/13/12--23:12: By: James
Welcome to agile blogging. Don't be discouraged if you don't get a flood of readers for a while. The community needs as many voices as it can get.
Would you say that maybe one approach to testing is defining how to test the results of what is produced in a sprint before work is done in the sprint?
I am producing code to read data from a database then display it on a form. Should I wait until i'm done or would it be prudent to define the tests for the fields and such before I start?
Personally I like to define how I am going to test what I am working on rather than develop a test case or plug in unit testing after the fact.
What do you think?
8% of the functionality of MS Word?
Isn't that called Word Pad? Does that mean that Microsoft already considered your argunment?
I did notice a few typos with some of the 10 Principles text... perhaps some of the other 92% of MS Word should have been utilised?
Many thanks for the feedback.
I didn't mean to imply that Microsoft hadn't considered the 8% thing, i.e. that most people don't use most of the features. I'm sure they did. And WordPad may well be the evidence of that.
I was just trying to highlight that software teams should proactively consider that fact too. And that maybe this is the basis for a strategy for the earlier iterations of a product's development - business people may say that the product needs all the features - and they may be right. But general evidence is that products do not need to be that rich in functionality to attract the majority of its users.
Thanks for the feedback about the typos in my blog posts! I use Google's Blogger platform to write my blog, which unfortunately has less than 8% of Word - perhaps even as little as 1%, and sadly not a spell check!!! I'll go fix my typos :-)
It is really good work. I am employing Agile Development Model for my current project. Earlier I employed RAD and Waterfall. But current situation makes me use Agile Development. Initially I am reluctant to accept that I am using Agile Development Model, as I did not know much about this. After reading your Blog, I can affirm that I am using this.
I found this blog is useful.
I will post my comments regularly.
Many thanks for your comment, it's really great to get such positive feedback.
First of all I like your top ten and agree that they are all important principles. Unfortunately I miss a common vision in the top five to drive development. I find that a common vision is a great practice to align business and IT, both when things are going “according to plan” and especially when they don’t.
Check out my own top 6 on www.agilethoughts.dk – we pretty much agree on the other 5 ;-)
Many thanks for the feedback...
Shared Vision is of course a very important principle of any project, whether it's agile or not.
I wouldn't include it in my key principles of agile, simply because I don't think it's a differentiator. Traditional development methods emphasise vision as much as agile methods.
Anyway, 11 key principles doesn't have quite the same ring to it :-)
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.
This is one of the best Agile's blogs I have ever come across.
It is simple and clear in expalining Agile methodology.
Thanks Ahmed, that's really nice of you to take the time to say that.
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.
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.
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"
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.
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.
Awesome blog you got here. Really helped me through my studies on agile development.