Agile

• Key Features of Agile Software Development:

• Iterative: Entire application is distributed in incremental units called as iteration. Development

time of each iteration is small (couple of weeks), fixed and strictly adhered to. Every teration is a mini

increment of the functionality and is build on top of previous iteration.

• Active Customer involvement: There is lot of client involvement and face-to-face interaction.

Every iteration is tested and approved by client. The feedback obtained is implemented in subsequent

iterations; thus minimizing risk and ensuring higher client satisfaction.

• Feature driven: More emphasis is on providing the required features in the application. 80/20

principle is applied to decide the 20% features which would be used 80% of the time.

• Fixed Time: Each iteration has a fixed time span in which it is delivered.

• Priority based delivery: Features are prioritized depending on customer need, development risk

etc. High priority features are developed first. After every iteration, the project priorities are re-evaluated.

• Adaptive: The methodology in general is very adaptive, so that the application that is developed

can cater to inflow of new requirements throughout its development. Goal is not to remove the

uncertainty in the very beginning, but is to adapt to the changing needs.

• Empowered Teams: The project teams are generally small and have lot of interaction and

communication. Since entire team is actively involved, team is empowered to take decisions. No separate

team to manage project.

• People Centric: More emphasis is on using the adequately skilled people to do the development

than on following the processes. The documentation and other non-development activities are minimized

and more time is devoted to development and testing.

Rapid development: Generally the development is done rapidly using light weight development

technologies.

• More disciplined: Being rapid, everything has to be delivered correctly first time. So the process

involves lot of team and self discipline Thus, it requires highly skilled and organized team members.

• Simplicity: Emphasis is on keeping things as simple as possible and being open to change.

Why Agile Software Development should be considered:

Benefits to the Customer

1. Customer is more actively involved, and gets higher priority
2. He gets to know regular and frequent status of the application
3. Requirements are accepted after each iteration
4. Since the methodology emphasizes rapid delivery, time-to-market is less. So the key       functionalities can be available to use sooner.
5. Delivery is defined by fixed timescale. So customer is assured of receiving some functionality by a fixed time period.
6. More Testing is done, so better software quality is delivered

Benefits to the Project Teams

1. Project teams are involved more actively in all the stages, have to ask right question. The teams collaboratively take the decisions and are more empowered.
2. Since the development is Incremental, teams can focus on the specific requirements at any given  point of time.
3. More emphasis is on developing the application only, and not on documentation. Simple and minimal documents are used to exchange the views.
4. The teams receive frequent feedback as the testing is integrated; so the rework is reduced .
5. Less time is spent in gathering requirements as all the requirements are not gathered upfront and are implemented as and when they arise.
6. So less time is required for planning.
7. Less cost of development as rework, management, documentation and other non-development work related cost is reduced.
8. Teams develop applications collaboratively and in cooperative environment.

Agile vs. Traditional Software development

Challenges involved in Agile Software development

Agile is difficult as

It Requires more TESTING & active CUSTOMERS involvement

It impacts Management more than Developers. Management had to be more open, be actively involved in

development process and more importantly allow the teams to take decisions.
Agile is More disciplined

The code may be integrated continuously, sometime after every update in source code repository. To

ensure the application is always in workable state, all the code has to work fine always.

Higher(?) technical and managerial expertise is needed.

Each feature has to be completed before moving on to the next.

Needs teams and self-discipline

More Planning is needed

Since the planning is done frequently (for each iteration), and the plan is updated as and when needed

more focused planning needs to be done. The plan has to be adaptive to meet the changing requirements.

When to (not!) use Agile

1. Before going Agile; Ask
2. Is functionality split-able
3. Is customer available
4. Are requirements flexible
5. Is it really time -constrained  Is team skilled enough

Agile software development methodology is best suited for a project with

1. Frequently changing requirements
2. Not highly distributed environment
3. Client open to lot of involvement and ready to invest time 

 

SCRUM Values

The SCRUM values are derived from the Agile values of software development.

• Individuals and interactions over processes and tools - processes and tools are helpful, but they will do you no good if the team does not communicate and collaborate in a constructive fashion.

• Working software over comprehensive documentation - documentation is important, but what's most

important is to have working software.

• Customer collaboration over contract negotiation - you are not just looking to get a contract and get

money that way - you are solving the customer's problem.

• Responding to change over following a plan - if the requirements or perceived requirements changed, so should the plans and design.

The Scrum Team

The SCRUM team consists of 2 groups - the interested team, which consists of people who are interested, but who
will not be doing the work, and the working team - people who are interested, and will be doing the work on the
project.

A team typically has no more than 6-9 working members, although SCRUM has been successfully used with more
members. If there are more members than manageable, the project should be broken into multiple sub-projects, each
focusing on one, self-contained area of work (one for QA, one for documentation, etc.). There should be people to
act as bridges - that is, to attend the meetings of more than one SCRUM team, and act as a communication bridge
between the teams. Members of teams that are closely related/involved with each other should sit in on the other
teams' SCRUM meetings.

The leader (SCRUM Master)

The team's leader is called the Scrum Master. He should be one of the members of the working team - that is, he
should be one of the people who is actually doing the work on the project. The SCRUM Master measures progress,
removes impediments, and leads the team meetings.

Commonly Used Terms

Sprint

The product is developed in a series of 1-to-4-week iterations, or sprints. Before a sprint is begun, a Sprint Planning
Meeting is held to determine what features are to be implemented in that sprint. The sprint has 4 major steps:

• Develop the product further - implement, test, and document.

• Wrap up the work - get it ready to be evaluated and integrated.

• Review the work done in this sprint.

• Adjust for any changes in requirements or plans.

Product Backlog

A product backlog is dynamic—Items may be deleted or added at any time during the project. It is prioritized—
Items with the highest priority are completed first. It is progressively refined—Lower priority items are intentionally
coarse-grained.

Sprint BackLog

A sprint backlog is a negotiated set of items from the product backlog that a team commits to complete during the
timebox of a sprint. Items in the sprint backlog are broken into detailed tasks for the team members to complete. The
team works collaboratively to complete the items in the sprint backlog, meeting each day (during a daily scrum) to
share struggles and progress and update the sprint backlog and burndown chart accordingly.

Sprint Goal

The Vision for the current sprint. This is an agreement between the team and the product owner and helps
the team to meet the objectives for the sprint.

Unit Testing

A unit test is an automated test that ensures that the functionality required for a certain area of a project is
implemented, and that there are no breaking changes that have not been taken into consideration.

Impediment

Impediments are things that get in the way of the progress of the project. The SCRUM Master is responsible to look
for and remove these obstacles so that they do not slow down or impair the project.

3 Questions

The Scrum Master asks the developers 3 important questions at every SCRUM meeting:

1. What have you accomplished since the last meeting?

2. Are there any obstacles in the way of meeting your goal?

3. What will you accomplish before the next meeting?

Product Owner

The person who commissions the project, and defines the requirements and priorities for the product.

Sprint Planning Meeting

A meeting at the beginning of a sprint where the sprint is planned. Items from the Product Backlog are selected to be
completed in the sprint, based on the priorities set by the Product Owner.

Daily SCRUM Meeting

A 15-minute SCRUM meeting is held every day. The SCRUM Master asks the three questions, and all members
of the team and interested parties take part and give feedback. The meeting should be held at the same place every
time, so that people know where to go.

Sprint Review Meeting

A sprint is closed with a Sprint Review Meeting where the progress made in the last sprint is demonstrated, the
sprint is reviewed, and adjustments are made to the project as necessary.

Retrospective Meeting

The retrospective meeting is a time for a team’s members to check in with one another and candidly
assess their performance. In retrospectives, the team and the ScrumMaster talk about how their process is
going, what could be improved, and how they’re working together. This meeting is about team health and
communication, not about the product itself.

Potentially Shippable: Potentially shippable means that the increment/deliverable could be released to a

customer.The product owner makes the decision about when to actually release any functionality or deliverable.

More on ......   Agile Methods