“Agile Development” is an umbrella term for several iterative and incremental software development methodologies. The most popular Agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development and Feature-Driven Development (FDD).
While each of the Agile methods is unique in its specific approach, they all share a common vision and core values. They all fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system. They all involve continuous planning, continuous testing, continuous integration, and other forms of continuous evolution of both the project and the software. They are all lightweight (especially compared to traditional waterfall-style processes), inherently adaptable and they all focus on empowering people to collaborate and make decisions together quickly and effectively.

Manifesto for Agile Software Development:
“We ‘re uncovering better ways of developing software by doing it and helping others do it. Through this work we have came to value.
- Individuals and interactions over process and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.”

Benefits of Agile Development:

Agile methods grew out of the real-life project experiences of leading software professionals who had experienced the challenges and limitations of traditional waterfall development on project after project. The approach promoted by agile development is in direct response to the issues associated with traditional software development – both in terms of overall philosophy as well as specific processes.
Agile development, in its simplest form, offers a lightweight framework for helping teams, given a constantly evolving functional and technical landscape, maintain a focus on the rapid delivery of business value (i.e., “bang for the buck”). As a result of this focus and its associated benefits, organizations are capable of significantly reducing the overall risk associated with software development.
In particular, agile development accelerates the delivery of initial business value, and through a process of continuous planning and feedback, is able to ensure that value is continuously being maximized throughout the development process. As a result of this iterative planning and feedback loop, teams are able to continuously align the delivered software with desired business needs, easily adapting to changing requirements throughout the process. By measuring and evaluating status based on the undeniable truth of working, testing software, much more accurate visibility into the actual progress of projects is available. And finally, as a result of following an agile process, at the conclusion of a project is a software system that much better addresses the business and customer needs.
The diagram below displays the differences between agile and waterfall development processes. By delivering working, tested, deployable software on an incremental basis, agile development delivers increased value, visibility, and adaptability much earlier in the lifecycle, significantly reducing project risk.

We Use Extreme Programming:

XP, originally described by Kent Beck, has emerged as one of the most popular and controversial Agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices:
1.    Planning Game
2.    Small Releases
3.    Customer Acceptance Tests
4.    Simple Design
5.    Pair Programming
6.    Test-Driven Development
7.    Refactoring
8.    Continuous Integration
9.    Collective Code Ownership
10.    Coding Standards
11.    Metaphor
12.    Sustainable Pace
In XP, the “Customer” works very closely with the development team to define and prioritize granular units of functionality referred to as “User Stories”. The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration by iteration basis. In order to maximize productivity, the practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.

Agile Hallmarks:
Summarized below are several of the key characteristics that successful Agile projects seem to share. For some methodologies these correspond exactly with individual practices, whereas for other methodologies there is looser correspondence.
1.    Releases and Fixed Length Iterations.
2.    Running, Tested Software.
3.    Value Driven Development.
4.    Continuous Adoptive Planning.
5.     Multi-Level Planning.
6.    Relative Estimation.
7.    Emergent Feature Discovery.
8.    Continuous Testing.
9.    Continuous Improvement.
10.    Small, Cross functional teams.

Keeping the Code Agile:

Agile teams have found in practice that Agile code is extensible, low-defect code with the simplest robust design that will work for the features currently implemented. It is well-factored and well-protected by unit tests. Among the Agile methodologies, Extreme Programming (XP) goes into the most depth concerning how programmers can keep themselves and their code Agile. It is increasingly common to find Agile teams that have adopted non-XP customer practices but have adopted at least some of the XP programmer practices:
1.    Test-first programming (or perhaps Test-Driven Development),
2.    Rigorous, regular refactoring,
3.    Continuous integration,
4.    Simple design,
5.    Pair programming,
6.    Sharing the codebase between all or most programmers,
7.    A single coding standard to which all programmers adhere,
8.    A common “war-room” style work area.

Feature Estimation:

In Agile development, a feature is a chunk of functionality that delivers business value. XP uses the term user story or stories to represent the feature. Ideally, a feature should adhere to the following criteria:
1.    It should provide business value
2.    It should be estimable – it must have enough definition for the development team to provide an estimate of the work involved in implementing it
3.    It should be small enough to fit within an iteration – therefore, if it is too big, it should be broken down further
4.    It should be testable – you should understand what automated or manual test a feature should pass in order to be acceptable to the customer
Feature Breaks Down structure and Estimation
Agile development favors a feature breakdown structure (FBS) approach instead of the work breakdown structure (WBS) used in waterfall development approaches. Feature breakdown structures are advantageous for a few reasons:
1.    They allow communication between the customer and the development team in terms both can understand.
2.    They allow the customer to prioritize the team’s work based on business value.
3.    They allow tracking of work against the actual business value produced.
It is acceptable to start out with features that are large and then break them out into smaller features over time. This allows the customer to keep from diving in to too much detail until that detail is needed to help facilitate actual design and delivery. We emphasize on following things during feature estimation.
1.    Build initial features list.
2.    Prepare feature headlines.
3.    Organize feature list
4.    Account the possible risk factors
5.    Estimate Units
6.    Work Units.
7.    Ideal Time
8.    Relative Estimation.
9.    Feature VS task planning

Release Planning:

Planning and estimating in the Agile world depend on a single key metric: the development team’s velocity, which describes how much work the team can get done per iteration. Given a team’s known velocity for its last projects , we prepare release plan that represents how much scope that team intends to deliver by a given deadline.
Release deadlines are often fixed, imposed externally by such things as tradeshows, accounting exigencies, or contractual obligations. But since the goal is to get working software into the users’ hands as quickly as possible in order to make “course corrections” as soon as possible, every effort is made to keep release cycles as short as possible. Agile release cycles ‘re kept shorter than 2 months. A release is, in turn, made up of iterations. For a given project, iteration length will typically be fixed at a length somewhere between 11 working days to the maximum 13 working days. We emphasized that, software should  be delivered to users, or at least a subset of users, incrementally at the end of each iteration or every couple of iterations.
After an initial feature list has been identified, prioritized, and potentially estimated, the team holds a release planning meeting to establish the overall release schedule and determine which features can likely be delivered. The overall release plan in terms of prioritized features is then used to directly feed individual iteration plans.

Iteration Planning:

Iteration lengths typically range between 11-13 working days. Our team holds a planning meeting at the beginning of each iteration to break down each of the features scheduled for the iteration into specific technical tasks. Iteration planning meetings generally last from 2-4 hours, then we start working on following things.
1.    Feature selection
2.    Task Planning.
3.    Iteration Adjustment.
4.    Warning signs.

Programmer Practices at MindBlaze Technologies:

1.    Test First Programming.
2.    Test Driven Development
3.    Test First Vs Debugging
4.    Apply test first techniques
5.    Refactoring [Code Hygiene,Refactoring to patterns,Flow of Refactoring].
6.    Contentious Integration.
7.    Simple Design
8.    Pair Programming.
9.    Common code base
10.    Single code standard.
11.    Open work area.

How we measure Team Velocity:

Velocity is an extremely simple, powerful method for accurately measuring the rate at which teams consistently deliver business value. To calculate velocity, we simply add up the estimates of the features (user stories, requirements, backlog items, etc.) successfully delivered an iteration. In other words “ Velocity is the sum of the estimates of delivered (i.e., accepted) features per iteration”. We measured our team velocity in the same units as feature estimates, whether this is story points, days, ideal days, or hours – all of which are considered acceptable.

Velocity Charts:

Along with release and iteration burndown charts, velocity has proven to provide tremendous insight/visibility into project progress and status. We use velocity chart to show the sum of estimates of the work delivered across all iterations. Typically velocity will stabilize through the life of a project unless the project team make-up varies widely or the length of the iteration changes. As such, velocity can be used for future planning purposes. While typically reliable for a couple iterations out, if you accept that priorities, goals, and teams may change over time and therefore the confidence level of an iteration far in the future, velocity can be used to plan releases much further into the future.

A typical velocity chart for a project team might look like the image above. Initially, teams just need to dive in a select an initial velocity using available guidelines and information. Very quickly (as fast as the next iteration), velocity is measured and adjusted. Velocity, along with granular features (e.g., user stories, backlog, requirements, etc.) and high-level and/or relative estimation (in terms of points, ideal days, or even hours), tremendously simplifies and accelerates the whole project planning, estimation, status tracking, and reporting process.

Measuring Iteration Progress:

When considering a team’s progress within an iteration, it is important to view a measure that reasonably reflects that progress throughout the iteration.Task progress provides a very telling measure of overall iteration progress and has the potential (though it often does not) to remain at a constant rate throughout an iteration. Our Burndown Chart shows a trended view of task progress and is the most common measure of iteration progress.

Measuring Release Progress:

Releases represent the lifeblood of the business. As a result, a team’s ability to successfully deliver software to the business is of critical importance. Given the tremendous churn inside software projects, accurately communication progress, status, and change throughout the development cycle remains a challenge. On the other hand, because Agile development uses the incremental delivery of working, tested software features as its primary planning and tracking asset, directly visibility into project status can be very straightforward.
While planning and executing at the iteration level is very important, our teams do not lose track of where they are in context of the overall release plan. In their desire to make sure iterations are successfully delivered, some teams may lose sight of their progress against the release goals. Additional scope may continue to creep into the plans as the team marches forward. As a result, each individual iteration appears relatively successful to the team, but the higher level goal of delivering the overall release is sometimes forgotten and changes in the release plan are not communicated to the organization. Consider the graph below, where our teams continues to complete features each iteration, but new features are being added to the release just as quickly. If the team does not check its progress relative to the overall release, this situation may not be identified until the release is about over.