10 Key Principles of Agile Software Development

Agile Software Development is one of the big buzzwords of the software development industry. But what exactly is it? Agile Development is a different way of managing software development projects. 10 Key Principles, and how Agile Development fundamentally differs from a more traditional Waterfall approach to software development, are as follows:

1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative & cooperative approach between all stakeholders is essential

There are various methodologies and standards that address various aspects of software development, for instance PRINCE2 for Project Management, Use Cases/UML for Analysis and Design, ISEB for Testing. Although these are typically applied to Waterfall development projects, elements of these methods can also be applied in an Agile Development approach.

There are also methods that are specifically designed around Agile Development:

DSDM is probably the original Agile Development method. DSDM was around before the term Agile Development was even invented, but is absolutely based on all the principles we’ve come to know as Agile Development.

SCRUM is also an Agile Development method, which concentrates particularly on how to manage tasks within a team-based development environment.

XP (eXtreme Programming) is a more radical Agile methodology, focusing on the software development process and addressing the analysis, development and test phases with novel approaches aimed at making a substantial difference to the quality of the end product.

DSDM is probably the most complete Agile methodology, whereas SCRUM and XP are easier to implement and complementary because they tackle different aspects of development projects and are both founded on the same principles of Agile Development.

In reality, there is no magic bullet for software development. The real trick is to know lots of techniques from various Waterfall and Agile Development methods, and to select a mixture of the best approaches that are most appropriate for any given situation. To do this reliably with any degree of success really requires a lot of experience and skill.

In Agile Development projects, Project Management takes a slightly different form, relying more on the project manager's skills in communication, facilitation, coordination, and emphasising less on planning and control.

Agile Development can be a very exciting and invigorating approach, although some projects suit Agile Development more than others. The collaboration and visibility can provide a much richer and more rewarding experience for teams to develop great software products. Agile Development can be a lot more enjoyable than the staid Waterfall approach that requires lots more documentation and is less flexible by its nature. And when people enjoy their work, it’s amazing what they can achieve!

See also:
10 Key Principles - PowerPoint Presentation

P.S. Click one of the icons below to join the growing community of people reading this blog by RSS or by email...
subscribe by rss feedsubscribe by email

6 comments:

Paul Klipp said...

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.

Paul Klipp
agileactivist.com

Anonymous said...

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?

Thanks.

Anonymous said...

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?

Kelly Waters said...

Hi anonymous,

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 :-)

Kelly.

Karthiganesh said...

Hi Kelly,

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.

Cheers!

Kelly Waters said...

Hi Karthiganesh

Many thanks for your comment, it's really great to get such positive feedback.

Kind regards

Kelly.