The term Agile was born out of the software development industry. The goal of Agile is to provide key principles on which quality software can be built.
One of the main aspects of Agile is the iterative approach. This means that building software should be done in completely testable chunks.
Working Software
Working software is also a key aspect of agile. Why?
Because working software presented to a user will allow for quality feedback. Sure, reading a requirements document is important. But getting to test actual software is preferable. So our testable chunks are actually working parts of the whole program.
Customer Collaboration
Customer collaboration means face to face meetings where you can really get a feel for what the customers problem is. This is how you’ll be able to get an equally accurate feel for what the solution will be.
Responding To Change
Also, even though requirements documentation is necessary, it should not be set in stone. Responding to change is crucial.
Customer needs change. Collaborating could reveal mistakes made in implementation. We must be open minded enough to change plans and deliver the right product.
Waterfall Software Development
In the past software was built as whole and all at once. This would usually end up taking a very long time. And unfortunately, after all this time and effort was spent, there was no guarantee that the software was done right.
You see, since the customers did not get a chance to see the software until it was done. So, they couldn’t tell the developers if they were on the right track.
What ended up happening, is that the developers fell short of customer expectations. This is not the development teams fault. It just happens because throughout the process there were no checkpoints.
So, instead of spending months or years building software that is not idea. Agile aims to bring customers or customer representatives into the process.
Customer or stakeholder input becomes an integral part of building software. Let’s call these small parts of software features
To make this work, it’s critical to have a much shorter iterative process.
Shortening the iterative process means the software functionality must be decomposed. Breaking software down into features is a key part of this process.
The ability to select the right sized features and then decompose them further is essential.
User Stories
The ability to select the right sized features and then decompose them further is key. Let’s call these smaller parts of a feature: User Stories.
User Stories are the parts of features that software developers build one by one. They are the basic building blocks. to get a better idea of how this works, let’s take a look at an example.
Say for example you want to build an email program. One for the first features you’ll want to have is the ability to log into the system.
Next, we want to break this feature down into User Stories. We could start by saying that we need to create a Web based user interface that has an input box for a user name and for a password.
So, the first User Story is for a web designer to create a simple web page that has the company logo and the input boxes.
Another User Story is for a database table to be created to store usernames and passwords.
These 2 stories are different in that they can be said to have different customers.
The user login page story can be seen and evaluated by an actual customer. The database story however, is best evaluated by someone like a software architect.
Regardless, both stories can be developed in a short time span. Let’s say 2 weeks for example. Then, the stakeholders can evaluate the outcomes and determine if any changes need to be made.
This is the beauty of the Agile process. Feedback is given as the product is developed. This is what helps ensure that the right software is created.