My take on the Agile Manifesto

From my personal experience as a software developer, and having gone through several projects, I have my own share of challenges and struggles. Software development is a complex science and has takes some techniques to create a quality end product. The development team must be equipped with the right skill set and the Management must posses an even better process to lead the team. Given that the project team members has the capability to develop the project software, there are these reoccurring challenges for every software project.

To enumerate, these are:
1.) Just the exact / tight schedule
2.) Unexpected requirements
3.) Late requirements
4.) Unclear requirements
5.) Expectations of Delivery
6.) Technical issues / resource issues

Given the traditional Waterfall model on software delivery lifecyle, The requirements should all be clear at the start of the project. But in reality, it is rarely the case, since exact requirements should be realized, even if it’s in the middle or almost end of the project phase.

Requirements are sometimes bound to change. While final/total requirements is still on process, the work of the software development should commence at the earliest possible time. So that the software should be released in earliest possible time, ahead of any competitors ( if any ). And most important of all, The software should be WORKING.

The solution, or the way to develop software in this circumstance is to adopt to the AGILE way. AGILE is a simple mindset to adapt. This can be used in any software project. Given if it is a start-up, maintenance, using the Waterfall Model, or using SCRUM.

AGILE method is used to address the re-occurring problems of software development, that could not be catered by adhering strictly to the Waterfall process. AGILE method follows the very basic law/manifesto that is created by a group of Software Engineers/Developers as the first signatories.

So here’s the AGILE Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

I personally believe that the AGILE way of software development is the most efficient way, to be used on top of other software practices such as Waterfall and other methods. Although we should maintain the foundation of the Waterfall process, but the project team should check the AGILE law and see if it can solve the problems the team is facing. Software development process using the Waterfall model started way back in the past and is documented as early as 1956 ( according to ), but as software systems / teams / IT industries have evolved in recent years, it seems the reoccurring problems of software development can be solved by applying the AGILE law, on top of an existing Software Development Model ( such as Waterfall )

And last… I randomly checked the AGILE manifesto signatories. And there’s one signatory that just sums it up.

quote: ” Paul Armstrong: (PPM (Pty) Ltd) Common sense rules …” unquote:

Here is the original AGILE manifesto website created in 2001


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s