This article is aimed at Business Managers who need to gain a basic understanding of the Agile Software Development process.
This is a very simplified explanation of the Agile process, it should not be used as a blueprint for running a project. Basically, you've heard about Agile and you want me to give you a quick introduction.
Let me get one thing out of the way first. Agile, does not mean cowboy slap dash programming. Agile software development is a highly disciplined and transparent process.
In most software development methodologies you create a set of requirement documents before any coding starts. This is not the case with the Agile methodology.
A requirements document goes into miniscule details about what you want. On a medium sized project the documentation alone can take several months to draft and refine.
How does Agile Software development work without a requirements document? Well you still have a specification. But it's very high level, with just a few main paragraphs such as "We need new cash point software". "It must interact with a mobile phone". "It must cater for all the banks and UK issued credit cards".
The high level specification gives an overall indication of the intention of the project. Creating the high level statements are stress free and easy to check.
This brief specification is basically enough to start an Agile project. An Agile project ticks along in regular periods, say a week, two or four weeks.
For the first period, the Developers and Architects will be looking at your existing infrastructure, security etc. They will start to build a basic framework of the cash machine software.
By the end of the next period, some very basic code will be working and fully deployed in a pre production environment. The basic code will just have one or two bits of functionality. Such as pressing a button on screen that goes to the database, gets some data and displays it on screen.
This basic code will have resolved or uncovered many problems that are left until the end of a most other methodologies. This is also known as a "vertical strip of functionality" or a "walking skeleton".
So, onto the end of the next period. You will have a few real bits of functionality deployed that you can test and use. It won't be much, but you'll see some tangible results for your budget. Instead of waiting 6 months to see some output from other methodologies.
From then on, new functionality is delivered at the end of each period. It's not long before you can actually start using the application.
This is where you get some great benefits. If a real user is using the application he can highlight potential problems at an early stage where they are easy and quick to rectify and most importantly, low cost to fix.
As the project progresses you can change your requirements. For example, new regulations may come into force. Well that's no problem for an Agile project. You wait for the current period to finish and test the functionality. You then discuss the new requirements with the Developers. The Developers take it calmly and say OK we will postpone what we were doing in the next period and implement those changes.
So, if you don't have a detailed specification, how do things get done? Well I mentioned earlier that you still have a top level requirements. At the start of a project that is the only information you need.
When a Developer gets to do a piece of work, he goes and sits with the user and discusses the requirement to get the exact details. Generally these bits of work should take about three days to complete. During these three days the Developer will be in constant contact with user asking questing and showing the progress to the user.
Having the users involved ensures that the project is developed exactly as required. The users will be far more amenable to the final application when it is delivered.
Possibly the Agile methodology is not suited to all environments such as NASA, the military etc. But it is certainly applicable to most industries such as Insurance, Finance, Healthcare, Government, etc.
Let me make it clear, implementing a project in Agile is not easy, it is highly disciplined and needs buy in from everyone involved and that includes all stakeholders in the project. It requires a lot of communication which is best done face to face.
Source: Ezine
Let me get one thing out of the way first. Agile, does not mean cowboy slap dash programming. Agile software development is a highly disciplined and transparent process.
In most software development methodologies you create a set of requirement documents before any coding starts. This is not the case with the Agile methodology.
A requirements document goes into miniscule details about what you want. On a medium sized project the documentation alone can take several months to draft and refine.
How does Agile Software development work without a requirements document? Well you still have a specification. But it's very high level, with just a few main paragraphs such as "We need new cash point software". "It must interact with a mobile phone". "It must cater for all the banks and UK issued credit cards".
The high level specification gives an overall indication of the intention of the project. Creating the high level statements are stress free and easy to check.
This brief specification is basically enough to start an Agile project. An Agile project ticks along in regular periods, say a week, two or four weeks.
For the first period, the Developers and Architects will be looking at your existing infrastructure, security etc. They will start to build a basic framework of the cash machine software.
By the end of the next period, some very basic code will be working and fully deployed in a pre production environment. The basic code will just have one or two bits of functionality. Such as pressing a button on screen that goes to the database, gets some data and displays it on screen.
This basic code will have resolved or uncovered many problems that are left until the end of a most other methodologies. This is also known as a "vertical strip of functionality" or a "walking skeleton".
So, onto the end of the next period. You will have a few real bits of functionality deployed that you can test and use. It won't be much, but you'll see some tangible results for your budget. Instead of waiting 6 months to see some output from other methodologies.
From then on, new functionality is delivered at the end of each period. It's not long before you can actually start using the application.
This is where you get some great benefits. If a real user is using the application he can highlight potential problems at an early stage where they are easy and quick to rectify and most importantly, low cost to fix.
As the project progresses you can change your requirements. For example, new regulations may come into force. Well that's no problem for an Agile project. You wait for the current period to finish and test the functionality. You then discuss the new requirements with the Developers. The Developers take it calmly and say OK we will postpone what we were doing in the next period and implement those changes.
So, if you don't have a detailed specification, how do things get done? Well I mentioned earlier that you still have a top level requirements. At the start of a project that is the only information you need.
When a Developer gets to do a piece of work, he goes and sits with the user and discusses the requirement to get the exact details. Generally these bits of work should take about three days to complete. During these three days the Developer will be in constant contact with user asking questing and showing the progress to the user.
Having the users involved ensures that the project is developed exactly as required. The users will be far more amenable to the final application when it is delivered.
Possibly the Agile methodology is not suited to all environments such as NASA, the military etc. But it is certainly applicable to most industries such as Insurance, Finance, Healthcare, Government, etc.
Let me make it clear, implementing a project in Agile is not easy, it is highly disciplined and needs buy in from everyone involved and that includes all stakeholders in the project. It requires a lot of communication which is best done face to face.
Source: Ezine
Done a excellent job in this blog, Alternatively create a great blog question for the readers specially for Agile Software Development.
Changes in requirements and scope have always been primary sources of trouble for a project, leading to late delivery, missed schedules, and unsatisfied customers.