To manage a software project in efficient manner we need some effective good practices. Lack of effective good practices can lead- unpredictability, repeated error and wasted effort. In that case-
- Customers are disappointed by slipping of schedules, growing of budgets and poor quality of product (software).
- Developers are disheartened by working ever-long hours to produce a poor quality product (software).
The Agile Alliance
Some industry experts calling them Agile Alliance observed that many of the software teams of different corporations were stuck in such ever-increasing process. So they met early 2001 and outlined some values and principles that would allow software teams to develop quickly and respond to change.
Then they worked next several months and create a statement of values. This is known as The Manifesto of the Agile Alliance
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile philosophy gives priority on left items more than the right items i.e. we will give more priority on
Individuals & Interactions than Processes & Tools
Working Software than Comprehensive Documentation
Customer Collaboration than Contract Negotiation
Responding To Change than Following A Plan
However agile doesn’t suggest to ignore right items i.e. Processes & tools, Comprehensive documentation, Contract negotiation and following a plan. It just says all left items i.e. Individuals & Interactions, Working software, Customer Collaboration & Responding to change are more important than all those right items to make software successful.
Signatories of Agile Manifesto are-
|Kent Beck||Mike Beedle||Arie van Bennekum||Alistair Cockburn|
|Ward Cunningham||Martin Fowler||James Grenning||Jim Highsmith|
|Andrew Hunt||Ron Jeffries||Jon Kern||Brian Marick|
|Robert C. Martin||Steve Mellor||Ken Schwaber||Jeff Sutherland|
Now we will discuss details about each value statement of Agile Manifesto.
Individuals and Interactions over Processes and Tools
Consider following scenarios
- We are following world best processes and tools but we don’t have any good team player then the project will fail definitely
- We have a team with best programmers but follow bad process and tools then also the software can be inefficient
- We are following world best processes and tools also have best programmers but they are unable to use those processes and tools then also the project will fail
On the other hand
- We have a team of average programmers and they are expert in communicate each other and following the process well and make use tools successfully then the project will get success
So what we see from above scenario is-
Processes and Tools are important to develop software but it is team people who will make the project successful by successfully using those processes and tools.
So it is recommended to
- First of all build a self-organized and cross functional team
- Then let the team to configure the environment, select process and tools on the basis of need
Working Software over Comprehensive Documentation
Working software makes our client happy and makes our project successful. So team’s main goal will be build working software. Team will give their highest effort to build working software.
Without documentation software is kind of disaster. So write short and structured document of one or two dozen pages and only contain overall design and high level structure of the system.
There have a simple rule to prepare such document is
Produce no document unless its need is immediate and significant
Customer Collaboration over Contract Negotiation
We make the software for our customer. So their needs, their satisfaction will be our highest priority.
To make a product successful customer feedback on a regular and frequent basis is very important. Rather than depending on a contract, or a statement of work, the customer of the software will work closely with the development team so that they can provide regular and frequent feedback as per development and design. On the other hand if needed the development team will change the developed product as per customer’s feedback.
Responding to Change over Following a Plan
Software success or failure depends on it’s ability to change.
Planning is very essential part of make the system successful. But long term plan can make disaster because-
- At the beginning of developing any software, the customer often fail to explain exactly what they was but when the system become visible they feel to need some changing or adding of features and functionalities.
- If the business environment changes then in order to cope with new environment need to add or change some features and functionalities.
If we make long term plan then it becomes difficult to adapt those changes into the system because we already have the plan and need to go through that plan. But as the customer doesn’t need some of the features of the software anymore; so the system will become quite useless. So what is recommended is that-
- Design the system flexible so that it can adapt any changes during development
- Make a detail plan for next week i.e. we should know the details of each individual tasks on which will work on next week
- Rough plan for next 03 months i.e. roughly know the requirements on which we will work on next 03 months
So in summary we can say-
Don’t go for long term plan because customer requirement can change at any time. Design your system in such way so that it can adapt any future changes.
CSM, CSPO, CSD, CSP-SM, CSP-PO (ScrumAlliance.org)
Certification Profile Link-
Currently working as Lead Team (Application Architecture) at Raven Systems Ltd. Passion for software development especially agile practices such as TDD with in depth knowledge of Object Oriented Programming, SOLID Principles, Gang of Four Design Patterns, Some Enterprise Application Architectural Patterns. Over 8 years of software development experience ASP.NET. Has the ability to understand and transform complex business requirements into software ensuring applications are delivered on time. Also experience in non Microsoft .NET technologies such as Dapper.Net, Git, Structure Map & Angular, Bootstrap, HTML-5, CSS-3 etc.