Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

What is the Agile?

Agile is just a set of principles and values, which focus on customer collaboration and iterative working software
delivery by the self-organizing cross-function teams.

What are the Agile principles?

Agile defines 12 principles for software development.

Twelve Principles of Agile Manifesto

1. Customer Satisfaction − Highest priority is given to satisfy the requirements of customers through early and
continuous delivery of valuable software.

2. Welcome Change − Changes are inevitable during software development. Ever-changing requirements
should be welcome, even late in the development phase. Agile processes should work to increase customers'
competitive advantage.

3. Deliver a Working Software − Deliver a working software frequently, ranging from a few weeks to a few
months, considering shorter time-scale.

4. Collaboration − Business people and developers must work together during the entire life of a project.

5. Motivation − Projects should be built around motivated individuals. Provide an environment to support
individual team members and trust them so as to make them feel responsible to get the job done.

6. Face-to-face Conversation − Face-to-face conversation is the most efficient and effective method of
conveying information to and within a development team.

7. Measure the Progress as per the Working Software − Working software is the key and it should be the
primary measure of progress.

8. Maintain Constant Pace − Agile processes aim towards sustainable development. The business, the
developers, and the users should be able to maintain a constant pace with the project.

9. Monitoring − Pay regular attention to technical excellence and good design to enhance agility.

10. Simplicity − Keep things simple and use simple terms to measure the work that is not completed.

11. Self-organized Teams − An agile team should be self-organized and should not depend heavily on other
teams because the best architectures, requirements, and designs emerge from self-organized teams.

12. Review the Work Regularly − Review the work done at regular intervals so that the team can reflect on how
to become more effective and adjust its behaviour accordingly.
Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

What are the Agile values?

Per above principles, Agile clarifies its values by following Agile manifesto,

1. Customer collaboration over contract negotiation

2. Responding to change over following a plan
3. Individuals and interactions over process and tools
4. Working software over comprehensive documentation

Why Agile?
Agile is good at handling following type of uncertainties and complexities of projects,
1. Business or requirements are not clear and complex.
2. Technical are risky or uncertain.
3. People uncertainties: distrust, conflicts, bad communications, and lack of collaborations.
Agile vs. Traditional Development
Introduction:
Software development Life Cycle has evolved with newer and more robust kind of approach. It is a
conceptual model that lays the foundation for development of software systems, with well defined phases.
Typically the phases are - user requirements definition, system requirement definition, analysis and system
design, system development, testing, implementation and maintenance.
Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

There are various models, each having its own approach, provide a strong foundation for an efficient software

development life cycle. Few among the many are - Waterfall, Spiral, rapid, prototyping.

Traditional Development Model

The traditional approach to software development includes Waterfall model. Waterfall Model is the oldest form of

software development model that offers the various stages through which the cycle of software development has to

go.

The very essence of a traditional software development life cycle lies in the following few facts:
1. The aim is to understand from a user's perspective as to what their requirements are, design a robust structure
that shall help in delivering the right product, flawlessly.
2. Planning risk management tasks.
3. The traditional model emphasises on finding alternative solutions towards attaining the desired objective, that
is, choosing the best alternate among the available list of alternatives.
4. Such a model relies on the fact that there is an optimal solution available for a problem, as a given problem is
considered to be well-defined.
5. It assumes that the processes are predictable and are repetitive.
6. The model believes that the processes are measurable and any variations in the processes can be controlled
and during the development life cycle.

Based on understanding of systems development, an organisation follows a certain kind of management style.

1. A hierarchy is maintained, therefore assuring a stability across the various levels.

2. An environment of formalisation and standardisation in created. People with specialisation in different roles

are assigned tasks which they are expected to accomplish, to produce the desired outcome.
Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

3. Customers play an active role, mostly during the specification and implementation stages.

Agile Model
1. Agile methods took over the traditional methods, to overcome the rigidity of the traditional model. Agile

follows a dynamic approach to software development. It is an interactive and team based method that aims to

deliver an application in a short span of time.

2. In agile methodology, tasks are categorised into phases and are 'time-boxed', that is, time frames are allotted

to each task. Each time-boxed phrase is called a sprint. Each sprint has a defined duration of time, say, a
week, few days or month

A detailed description of how the agile model helps to overcome the shortcomings of the traditional model.

1. Agile is based on empirical process, which provides a control mechanism based on a defined set of methods.
Empirical method is meant for those processes that are not very well defined, unpredictable or unrepeatable.
Agile technique implements control through frequent inspection and adaptation.
2. It is a dynamic approach to software development. That is, this technique is quick in adapting to changes as
requested by the user.
3. It has brief iterative life cycles, which reflects periodic changes, and thus integrating small change cycle to the
overall system development process.
4. Involves communication with customers consistently, taking their feedback as input, during the different
iterative cycles.
Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

Agile Vs Traditional Model

Traditional Model Agile Model

1. Follows a top down approach, and making
changes is not easy as finishing one phase leads
to another
2. It has a leadership style of working
3. Pre-planning is done to carry out the various
phases
4.Customer is involved only in the initial
phases of requirements gathering
5. The project plan is prepared before
commencing the process of system
development
6. The ownership lies on the Project manager
7. Believes in one-time delivery of the product
1. Team conducts experiments on various
techniques and gradually arrives at the best
possible solution
2. In agile, there is free flow of communication,
anyone can present their ideas within the team
3. This is more flexible as compared to
traditional model, as it can change it's work flow
based on any new request for modifications
4. Customer involvement is crucial for this
model to prove its mettle
5. Project work is delivered to the client in small
amount, that is, as and when one module is
prepared, a demonstration is given to the client,
so as to confirm the work progress in a right
direction
6.It has the concept of shared ownership, i.e,
every team member is equally responsible for
their individual contribution
7. Relies on incremental delivery of the product

Conclusion:
Both agile and traditional models are essential for an efficient software development process. However, in the process
of choosing an appropriate model for software development, one needs to identify the scope and requirements of the
project to be developed. Accordingly, a model is chosen that helps to deliver the right things at the right time.

Agile Model does overcome few deficiencies that the traditional model imbibes, but at the same time each model's
pros and cons must be weighed before reaching a consensus.

Agile Project Management

Agile Project Management (APM) is an iterative approach to planning and guiding project processes.

Just as in Agile Software Development, an Agile project is completed in small sections. These sections are
called iterations. In Agile Software Development, for instance, an iteration refers to a single development cycle. Each
section or iteration is reviewed and critiqued by the project team, which should include representatives of the project's
various stakeholders. Insights gained from the critique of an iteration are used to determine what the next step should
be in the project.

The main benefit of Agile Project Management is its ability to respond to issues as they arise throughout the course of
the project. Making a necessary change to a project at the right time can save resources and, ultimately, help deliver a
successful project on time and within budget.
Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

What is APM?
1. Agile project methodology breaks down projects into small pieces that are completed in work sessions that
run from the design phase to testing and quality assurance (QA). These sessions are often called sprints, the
term for iteration used in one specific and popular Agile development method known as Scrum.
2. Sprints are generally short, running over days or weeks; they're typically two to four weeks long.
3. The Agile methodology enables teams to release segments as they're completed. This continuous release
schedule allows for teams to demonstrate that these segments are successful and, if not, to fix flaws quickly.
The belief is that this helps reduce the chance of large-scale failures, because there is continuous improvement
throughout the project lifecycle.
How APM works
1. Agile teams build rapid feedback, continuous adaptation and QA best practices into their iterations.
2. They adopt practices such as continuous deployment (CD) and continuous integration (CI), using technology
that automates steps to speed up the release and use of products.
3. Additionally, Agile Project Management calls for teams to continuously evaluate time and cost as they move
through their work. They use velocity, burn down and burn up charts to measure their work, instead of Gantt
charts and project milestones to track progress.
4. Agile Project Management does not require the presence or participation of a project manager. Although a
project manager is essential for success under the traditional project-delivery methodologies, such as
the waterfall model (where the position manages the budget, personnel, project scope, quality, requirements
and other key elements), the project manager's role under APM is distributed among team members.
5. For instance, project goals are set by the product owner, while team members divvy up scheduling, progress
reporting and quality tasks. Certain Agile approaches add other layers of management; the Scrum approach,
for example, calls for a scrum master who helps set priorities and shepherd the project through to completion.
6. However, project managers are not obsolete in Agile Project Management. Many organizations still use them
for Agile projects -- particularly larger, more complex ones -- but the organizations generally place these
project managers in more of a coordinator role with the product owner taking responsibility for the project's
overall completion.
7. Given the shift in work from project managers to Agile teams, Agile Project Management demands that team
members know how to work in this new fashion. They must be able to collaborate with each other, as well as
with users. They must to be able to communicate well to keep projects on track. And they should feel
empowered to take appropriate actions at the right times in order to keep pace with delivery schedules.

History of APM
1. The 21st century saw a rapid rise in use of the Agile Project Management methodology, particularly for
software development projects and other IT initiatives.
2. However, the concept of continuous development dates back to the mid-20th century and has taken various
forms and been championed by different leaders over the decades. For example, there was James Martin's
Rapid Iterative Production Prototyping (RIPP), an approach that served as the premise for the 1991
book Rapid Application Development and the approach of the same name, RAD.
3. A specific Agile Project Management framework that has evolved in more recent years is Scrum. This
methodology features a product owner who works with a development team to create a product backlog, a
prioritized list of the features, functionalities and fixes required to deliver a successful software system. The
team then delivers the pieces in rapid increments.
Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

A survey depicts commonly used Agile processes.

Additional Agile frameworks include Lean, kanban and Extreme Programming (XP).

APM vs. waterfall

Agile Project Management was, and remains, a counter to the waterfall methodology. The waterfall methodology
features a strict sequential approach to projects, where initiatives start with gathering all requirements before the work
begins, scoping out the resources needed, establishing budgets and timelines, performing the actual work, testing and
then delivering the project as a whole when all the work is completed.

In response to what were recognized problems in that approach, 17 software developers in 2001 published the Agile
Manifesto outlining 12 principles of Agile Software Development. The principles include to "welcome changing
requirements, even late in the development" and "deliver working software frequently."

These principles continue to guide Agile Project Management even today.

Pros and cons

Proponents of Agile Project Management say the methodology delivers numerous benefits. Those include the rapid
deployment of solutions, more efficient use of resources, greater flexibility and adaptability to changing needs, more
rapid detection of problems -- and thus quicker fixes -- and increased collaboration with users and, therefore, products
that better meet user needs.
Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

There are also potential drawbacks, however, including a tendency for projects to go off track, a lack of
documentation and less predictable outcomes.

Because Agile management relies on the ability to make decisions quickly, it is not suitable for organizations that
tend to deliberate over issues for a prolonged period or for those that take decisions to a committee.

Agile Team Interactions

There are several key differences between the agile approach to team organization and the traditional approach.

1. Agile teams are "whole teams". Whole team is an Extreme Programming (XP) practice that advises you to
have sufficient skills within the team itself to get the job done. The implication is that the development team
has the requisite testing skills, database skills, user interface skills, and so on and does not rely on external
experts or teams of experts for these sorts of things.
2. Agile teams are formed (mostly) of generalizing specialists. A generalizing specialist, sometimes called a
craftsperson, is someone who has one or more technical specialties (e.g. Java programming, project
management, database administration, ...) so that they can contribute something of direct value to the team,
has at least a general knowledge of software development and the business domain in which they work, and
most importantly actively seeks to gain new skills in both their existing specialties as well as in other areas,
including both technical and domain areas. Obviously novice IT professionals, and traditional IT professionals
who are often specialized in just one area, will need to work towards this goal. Generalizing specialists are the
sweet spot between the two extremes of specialists, people who know a lot about a narrow domain, and
generalists who know a little about a wide range of topics.
3. Agile teams are stable. Agilists understand that changing team structures -- this iteration Sally is part of the
team but next iteration she's pulled off to help another team -- is detrimental to project success. We strive to
keep our teams as stable as possible, a goal that is much easier to achieve if people are generalizing
specialists.

Small Agile Teams

There are several roles, which have different names depending on the methodology being followed, common to agile
teams. Roles are not positions, any given person takes on one or more roles and can switch roles over time, and any
given role may have zero or more people in it at any given point in a project. The common agile roles are:

 Team lead. This role, called “Scrum Master” in Scrum or team coach or project lead in other methods, is
responsible for facilitating the team, obtaining resources for it, and protecting it from problems. This role
encompasses the soft skills of project management but not the technical ones such as planning and scheduling,
activities which are better left to the team as a whole (more on this later).
 Team member. This role, sometimes referred to as developer or programmer, is responsible for the creation
and delivery of a system. This includes modeling, programming, testing, and release activities, as well as
others.
 Product owner. The product owner, called on-site customer in XP and active stakeholder in AM, represents
the stakeholders. This is the one person responsible on a team (or sub-team for large projects) who is
Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

responsible for the prioritized work item list (called a product backlog in Scrum), for making decisions in a
timely manner, and for providing information in a timely manner.
 Stakeholder. A stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager,
operations staff member, the "gold owner" who funds the project, support (help desk) staff member, auditors,
your program/portfolio manager, developers working on other systems that integrate or interact with the one
under development, or maintenance professionals potentially affected by the development and/or deployment
of a software project.

Figure 1 overviews the structure of a small agile team. What you typically read about in the agile literature is how a
team of developers, lead by the team lead, works closely with a product owner to build a high-quality working system
on an incremental basis. What you don’t hear about as often is what I call the “supporting cast”:

 Technical experts. Sometimes the team needs the help of technical experts, such as build masters to set up
their build scripts or an agile DBA to help design and test their database. Technical experts are brought in on
an as-needed, temporary basis, to help the team overcome a difficult problem and to transfer their skills to one
or more developers on the team.
 Domain experts. As you can see in Figure 2 the product owner represents a wide range of stakeholders, not
just end users, and in practice it isn't reasonable to expect them to be experts at every single nuance in your
domain. As a result the product owner will sometimes bring in domain experts to work with the team, perhaps
a tax expert to explain the details of a requirement or the sponsoring executive to explain the vision for the
project.
 Independent tester. Effective agile teams often have an independent test team working in parallel that
validates their work throughout the lifecycle. This is an optional role, typically adopted only on very complex
projects (or at scale).

Figure 1. Organization structure of a small agile team.

Figure 2. Product owner represent a range of stakeholders.

 Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

Large Agile Teams

When the size of an agile team gets to be around twenty or more you discover that you need to divide and
conquer and take a “team of teams” approach. The typical strategy is to organize your larger team into a
collection of smaller teams, and the most effective way to do so is around the architecture of your system,.
Each subteam should be responsible for one or more subsystems, enabling them to work as a small agile team
responsible for delivering working software on a timely basis. This strategy is often referred to as Conway’s
Law after Melvin Conway who introduced it in the late 1960s, and is one of severallean development
governance strategies.

The additional roles on agile teams at scale include:

 Architecture owner. This person is responsible for facilitating architectural decisions on a sub-team
and is part of the architecture owner team which is responsible for overall architectural direction of
the project. The architecture owner leads their sub-team through initial architecture envisioning for
their sub-systems and will be involved with the initial architecture envisioning for the system as a
whole (as part of the architecture owner team, see below). Architecture owners are different than
traditional architects in that they are not solely responsible for setting the architectural direction but
instead facilitate its creation and evolution.
 Integrator. The sub teams are typically responsible for one or more subsystems, and the larger the
overall team generally the larger and more complicated the system being built. In these situations the
overall team may require one or more people in the role of integrator who are responsible for building
the entire system from its various subsystems. These people often work closely with the independent
test team, if there is one, who will want to perform system integration testing regularly throughout the
project.

1. Project management activities. At scale it isn’t sufficient to simply focus on project leadership and allow
self-organization to address the technical aspects of project management. This may work on the individual
subteams, but across the entire project/program the technical aspects of project management, such as
Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

dependency management, contract management, resource tracking, vendor management become critical. The
project management team of Figure 3, sometimes called the program management team, is comprised of the
team leads from the various subteams. Their goal is to coordinate the management aspects of the overall team.
This team is likely to have a short coordination meeting each day, referred to as a “scrum of scrums” in the
Scrum methodology, where current status is shared and issues are identified.
2. Technical/architectural issues. The architecture ownership team is comprised of the architecture owners
from the subteams and is responsible for architecture envisioning at the beginning of the project to identify the
initial technical direction and provide a basis for organizing the sub teams. In the first week or so of the
project (sometimes several weeks on more complex projects) their goal is to identify the subsystems and their
interfaces, a strategy called “managing to the seams”, reducing the coupling between subsystems and thereby
reducing the amount of coordination required by sub teams. Once the interfaces are well defined it is possible
for the individual subteams to focus on implementing the innards of those subsystems. Throughout the project
this team will meet on a regular basis to share ideas and resolve technical issues, particularly those
surrounding changes to the interfaces of subsystems. They may choose to meet daily, this is particularly
common at the beginning of the project, but as the architecture stabilizes it is common to see them meet once
or twice a week.
3. Requirements/product ownership issues. The product ownership team is comprised of the product owners
of each sub team and is responsible for coordinating the requirements effort across the sub teams. They will
need to negotiate requirements with the larger body of stakeholders whom they represent and divvy them out
among the sub teams appropriately. They’ll also need to negotiate the inevitable disputes between sub teams
as to who should do what and what a requirement actually means. They also manage the requirements
dependencies between sub teams and strive to minimize overlapping work between sub teams.
4. System integration. System integration is important for any size of project team, but it is often absolutely
critical on large teams (which often address complex problems). The complexities of large project often
necessitate the addition of a system integrator, or several (sometimes called build masters), to the team.
System integration occurs throughout the entire agile life cycle, not just at the end of the project during the
system integration test phase of a traditional project. During the first development iteration, called the
"Elaboration phase" in the Unified Process, an important goal is for the sub teams to create mocks of their
subsystems according to the interface specifications agreed to earlier . The goal is to do a complete, end-to-
end build of the mocked out system to ensure that the sub teams are working to the same technical vision.
You'll undoubtedly discover that you need to evolve the interfaces a fair bit at this point as you run into
technical issues that you hadn't thought through during Iteration 0. There are several advantages for making
mock ups of the subsystems available early in the project. First, the individual sub teams can now move
forward on their own work with few dependencies on the other sub teams. Each team will evolve their
subsystems throughout the project, replacing the mocked out portions of code with real working code. These
new versions are made available to the other sub teams, who in turn will choose when they want to integrate
these new versions into their own environments. In my experience earlier is better than later but you want to
wait until you know that new versions are stable, one of the advantages of having an independent test team,
until you integrate it into your own work. Second, your independent testing team can now test against the
entire build as they see fit. Granted, at first they only have mockups of the system but they can at least start
organizing their test framework(s) for the system at this time. Third, you can similarly put together your
integration framework to support your continuous integration efforts across the entire system as well as
integration efforts on individual sub teams. Fourth, individual sub teams will promote their code after they've
tested it within their own environments. On large-scale agile teams these new subsystem builds are often
vetted by your independent testing team before they're made available to the other sub teams, a process that
should be done quickly and often. The test team will often do a full system integration test, something that
may be difficult for sub teams to do due to timing considerations (integration tests often take a long time to
run) or due to resource restrictions (the test team typically has a more sophisticated platform to test on). Sub
teams may choose to use pre-approved subsystems at their own risk, depending on your organization's culture.
Name of Faculty: SUMIT Kumar Mishra Name of Subject: Agile Software development

Name of Dept: Computer Science & Engineering Subject Code: RCS E43

Name of Institute: BBDEC, LKO Date: Page No.:

Figure 3. Organization structure of a large agile team.

I'd like to share some observations:

1. An interesting feature of Figure 3 is that two supporting cast members of Figure 1, an Agile DBA and a user
experience expert, have become members of the subteam. These roles are examples of a general need by some
subteams to include some technical experts that are specialized in a given activity. By organizing the teams
around the architecture some subteams become focused on certain aspects of the overall system and as a result
it can make sense to include some "overly specialized" people to address the specific aspects of the
subcomponents being addressed by the subteam.
2. As the size of the team grows, there is very little difference in the day-to-day activities of developers. They
are insulated from the complexities of large teams by activities of the coordinators and may not even know
that this is occurring.