Agile principles

People not process

self-organization and motivation are important, as are interactions like co-
location and pair programming.
Customer collaboration
As the requirements cannot be gathered completely in the beginning of the
project due to various factors, continuous customer interaction is very
important to get proper product requirements.
Working software
Demo working software is considered the best means of communication with
the customer to understand their requirement, instead of depending on
documentation.
Incremental delivery
The software is developed in increments with the customer specifying the
requirements to be included in each increment.
Embrace change
Expect the system requirements to change and so design the system to
accommodate these changes.
Maintain simplicity
Focus on simplicity in both the software being developed and in the
development process. Wherever possible, actively work to eliminate
complexity from the system.
 Agile or plan driven
Is it important to have a very detailed specification
and design before moving to implementation?
If so, you probably need to use a plan-driven approach.
Is incremental delivery strategy to get rapid feedback
is realistic?
If so, consider using agile methods.
How large is the system that is being developed?
Agile methods are most effective when the system can be
developed with a small co-located team who can
communicate informally. This may not be possible for
large systems that require larger development teams so
a plan-driven approach may have to be used.
 What type of system is being developed?
Systems that require a lot of analysis before
implementation (e.g., real-time system with complex
timing requirements) usually need a fairly detailed design
to carry out this analysis. A plan driven approach may be
best in those circumstances.
What is the expected system lifetime?
Long-lifetime systems may require more design
documentation to communicate the original intentions of
the system
developers to the support team.
However, supporters of agile methods rightly argue that
documentation is frequently not kept up to date and it is
not of much use for long-term system maintenance.
 Scrum
There are three phases in Scrum.
The first is an outline planning phase where you
establish the general objectives for the project
and design the software architecture.
followed by a series of sprint cycles, where each
cycle develops an increment of the system
the project closure phase wraps up the project,
completes required documentation such as
system help files and user manuals, and assesses
the lessons learned from the project.
 sprint cycles
Sprints are fixed length, normally 24 weeks.
The starting point for planning is the product backlog, which is the list of work to be done on the
project. During the assessment phase of the sprint, this is reviewed, and priorities and risks are
assigned. The customer is closely involved in this process and can introduce new requirements or
tasks at the beginning of each sprint.
The selection phase involves all of the project team who work with the customer to select the
features and functionality to be developed during the sprint.
Once these are agreed, the team organizes themselves to develop the software. Short daily
meetings involving all team members are held to review progress and if necessary, reprioritize
work. During this stage the team is isolated from the customer and the organization, with all
communications channeled through the so-called Scrum master.
The role of the Scrum master is to protect the development team from external distractions. The
way in which the work is done depends on the problem and the team.
Unlike XP, Scrum does not make specific suggestions on how to write requirements, test-first
development, etc. However, these XP practices can be used if the team thinks they are appropriate.
At the end of the sprint, the work done is reviewed and presented to stakeholders. The next sprint
cycle then begins.
Scrum:
 Some Principles of Scrum Model
Always have a product that you can
theoretically ship: done can be declared at
any time.
Build early, build often.
Continuously test the product as you build it.
Assume requirements may change; Have ablility
to adapt to marketplace changes during
development.
Small teams work in parallel to maximize
communication and minimize overhead.
 The idea behind Scrum is that the whole team should be
empowered to make decisions so the term project manager, has
been deliberately avoided. Rather, the Scrum master is a facilitator
who arranges daily meetings, tracks the backlog of work to be
done, records decisions, measures progress against the backlog,
and communicates with customers and management outside of the
team.
Agile methods were developed for use by small programming
teams who could work together in the same room and
communicate informally. Agile methods have therefore been mostly
used for the development of small and medium-sized systems.
Of course, the need for faster delivery of software, which is more
suited to customer needs, also applies to larger systems.
Consequently, there has been a great deal of interest in scaling agile
methods to cope with larger systems, developed by large
organizations.
 Scrum for large projects
For large systems development, it is not possible to focus only on the code
of the system. You need to do more up-front design and system
documentation. The software architecture has to be designed and there
has to be documentation produced to describe critical aspects of the
system, such as database schemas, the work breakdown across teams, etc.
Cross-team communication mechanisms have to be designed and used.
This should involve regular phone and video conferences between team
members and frequent, short electronic meetings where teams update
each other on progress. A range of communication channels such as e-
mail, instant messaging, wikis, and social networking systems should be
provided to facilitate communications.
Continuous integration, where the whole system is built every time any
developer checks in a change, is practically impossible when several
separate programs have to be integrated to create the system. However, it
is essential to maintain frequent system builds and regular releases of the
system. This may mean that new configuration management tools that
support multi-team software development have to be introduced.
 Scrum advantages
Daily meetings make it possible to measure individual
productivity. This leads to the improvement in the
productivity of each of the team members.
Issues are identified well in advance through the daily
meetings and hence can be resolved in speedily
It is easier to deliver a quality product in a scheduled
time.
The overhead cost in terms of process and
management is minimal thus leading to a quicker,
cheaper result.
 Scrum disadvantages
Agile Scrum is one of the leading causes of scope
creep because unless there is a definite end date,
the project management stakeholders will be
tempted to keep demanding new functionality is
delivered.
If a task is not well defined, estimating project
costs and time will not be accurate. In such a
case, the task can be spread over several sprints.
If the team members are not committed, the
project will either never complete or fail.
 Scrum disadvantages
It is good for small, fast moving projects as it
works well only with small team.
This methodology needs experienced team
members only. If the team consists of people who
are novices, the project cannot be completed in
time.
Scrum works well when the Scrum Master trusts
the team they are managing. If they practice too
strict control over the team members, it can be
extremely frustrating for them, leading to
demoralisation and the failure of the project.
 Scrum disadvantages
If any of the team members leave during a
development it can have a huge inverse effect
on the project development
Project quality management is hard to
implement and quantify unless the test team
are able to conduct regression testing after
each sprint.
1. What technologies are available to support system development? Agile methods often rely on
good tools to keep track of an evolving design. If you are developing a system using an IDE that
does not have good tools for program visualization and analysis, then more design
documentation may be required.
2. How is the development team organized? If the development team is distributed or if part of the
development is being outsourced, then you may need to develop design documents to
communicate across the development teams. You may need to plan in advance what these are.
3. Are there cultural issues that may affect the system development? Traditional engineering
organizations have a culture of plan-based development, as this is the norm in engineering. This
usually requires extensive design documentation, rather than the informal knowledge used in
agile processes.
4. How good are the designers and programmers in the development team? It is sometimes argued
that agile methods require higher skill levels than plan-based approaches in which programmers
simply translate a detailed design into code. If you have a team with relatively low skill levels, you
may need to use the best people to develop the design, with others responsible for
programming.
5. Is the system subject to external regulation? If a system has to be approved by an external
regulator (e.g., the Federal Aviation Authority [FAA] approve software that is critical to the
operation of an aircraft) then you will probably be required to produce detailed documentation
as part of the system safety case.
 Mastering Practices with Collaborative
Construction

Collaborative construction refers to techniques in which teammates share

responsibility for creating code and other artifacts. It is the simplest way to
ensure that engineering practices are successfully applied and mastered
Collective code ownership requires that all teammates ensure software quality
and share responsibility for maintaining the source code.
Pair programming is a technique in which two teammates work together at
one workstation: the driver, typing at the keyboard, and the observer, verifying
what is produced. The two teammates switch roles frequently. While
reviewing, the observer also considers the constraints imposed by the
practices. The observers main contribution is to come up with ideas for
improvements and identify potential problems. This enables the driver to
focus his attention on the task at hand, using the observer as a safety net and
guide.
Not all the source code should be written in pair programming; only a subset
should be done in pairing according to selection criteria
In addition to promoting the proper use of engineering practices, pairing can
also act as defect-detection techniques during construction.
 Extreme programming
1. Incremental development is supported through small, frequent releases of
the system. Requirements are based on simple customer stories or
scenarios that are used as a basis for deciding what functionality should
be included in a system increment.
2. Customer involvement is supported through the continuous engagement of
the customer in the development team. The customer representative
takes part in the development and is responsible for defining acceptance
tests for the system.
3. People, not process, are supported through pair programming, collective
ownership of the system code, and a sustainable development process
that does not involve excessively long working hours.
4. Change is embraced through regular system releases to customers, test-
first development, refactoring to avoid code degeneration, and continuous
integration of new functionality.
5. Maintaining simplicity is supported by constant refactoring that improves
code quality and by using simple designs that do not unnecessarily
anticipate future changes to the system.
 Refactoring
A general problem with incremental development is that it tends to degrade the software structure,
so changes to the software become harder and harder to implement. Essentially, the development
proceeds by finding workarounds to problems, with the result that code is often duplicated, parts
of the software are reused in inappropriate ways, and the overall structure degrades as code is
added to the system.
Agile tackles this problem by suggesting that the software should be constantly refactored.
This means that the programming team look for possible improvements to the software and
implement them immediately. When a team member sees code that can be improved, they make
these improvements even in situations where there is no immediate need for them. Examples of
refactoring include the reorganization of a class hierarchy to remove duplicate code, the tidying up
and renaming of attributes and methods, and the replacement of code with calls to methods
defined in a program library.
Program development environments, such as Eclipse or Intellij include tools for refactoring which
simplify the process of finding dependencies between code sections and making global code
modifications.
In principle then, the software should always be easy to understand and change as new stories are
implemented. In practice, this is not always the case. Sometimes development pressure means that
refactoring is delayed because the time is devoted to the implementation of new functionality.
Some new features and changes cannot readily be accommodated by code-level refactoring and
require the architecture of the system to be modified.
 Pair programming
Programmers work in pairs to develop the
software. They actually sit together at the
same workstation to develop the software.
However, the same pairs do not always
program together. Rather, pairs are created
dynamically so that all team members work
with each other during the development
process.
 Pair programming advantages
It supports the idea of collective ownership and responsibility for the system. The
software is owned by the team as a whole and individuals are not held responsible
for problems with the code. Instead, the team has collective responsibility for
resolving these problems.
2. It acts as an informal review process because each line of code is looked at by at
least two people. Code inspections and reviews are very successful in discovering a
high percentage of software errors. However, they are time consuming to organize
and, typically, introduce delays into the development process. Although pair
programming is a less formal process that probably doesnt find as many errors as
code inspections, it is a much cheaper inspection process than formal program
inspections.
3. It helps support refactoring, which is a process of software improvement. The
difficulty of implementing this in a normal development environment is that effort
in refactoring is expended for long-term benefit. An individual who practices
refactoring may be judged to be less efficient than one who simply carries on
developing code. Where pair programming and collective ownership are used,
others benefit immediately from the refactoring so they are likely to support the
process.
 Is Pair Programming less efficient?
In a given time, a pair of developers would produce half as much code as
two individuals working alone.
There have been various studies of the productivity of paid programmers
with mixed results
One study found that productivity with pair programming seems to be
comparable with that of two people working independently. The reasons
suggested are that pairs discuss the software before development so
probably have fewer false starts and less rework. Furthermore, the
number of errors avoided by the informal inspection is such that less time
is spent repairing bugs discovered during the testing process.
However, studies with more experienced programmers found that there
was a significant loss of productivity compared with two programmers
working alone. There were some quality benefits but these did not fully
compensate for the pair-programming overhead. Nevertheless, the
sharing of knowledge that happens during pair programming is very
important as it reduces the overall risks to a project when team members
leave. In itself, this may make pair programming worthwhile.
 Preventative maintenance by refactoring

Refactoring is the process of making improvements to

a program to slow down degradation through change.
It means modifying a program to improve its structure,
to reduce its complexity, or to make it easier to
understand.
When you refactor a program, you should not add
functionality but should concentrate on program
improvement. You can therefore think of refactoring as
preventative maintenance that reduces the problems
of future change.
Obviously, this means additional costs, over and above
those of implementing required system changes.
 Why Refactoring
The need to make the change quickly means that you may not be
able to follow the formal change analysis process. Rather than
modify the requirements and design, you make an emergency fix to
the program to solve the immediate problem.
So the requirements, the software design, and the code become
inconsistent.
Emergency system repairs usually have to be completed as quickly
as possible. You chose a quick and workable solution rather than
the best solution as far as system structure is concerned. This
accelerates the process of software ageing so that future changes
become progressively more difficult and maintenance costs
increase.
As a system is changed, its structure is degraded. The only way to
avoid this happening is to invest in preventative maintenance.
 Test-driven development
(Executable requirement Spec)
Identifying the functionality(user story/task) to implement.
This should normally be small and implementable in a few
lines of code.
Write a test for this functionality and implement this as an
automated test.
Run the test, along with all other tests that have been
implemented. Initially, you have not implemented the
functionality so the new test will fail.
Implement the functionality and re-run the test. This may
involve refactoring existing code to improve it and add new
code to whats already there.
Once all tests run successfully, you move on to
implementing the next chunk of functionality.
 Front-Loading
Tackle the unknown and harder parts earlier
rather than later.
Better to find out about infeasible, intractable,
or very hard problems early.
The easy parts will be worthless if the hard
parts are impossible.
Find out about design flaws early rather than
upon completion of a major phase.
 Capability Maturity Model (CMM)
A bench-mark for measuring the maturity of
an organizations software process
CMM defines 5 levels of process maturity
based on certain Key Process Areas (KPA)
 CMM Levels
Level 2 Repeatable (~ 15%)
-- software configuration management
-- software quality assurance
-- software project tracking and oversight
-- software project planning
-- requirements management
Level 3 Defined (< 10%)
-- peer reviews
-- intergroup coordination
-- software product engineering
-- integrated software management
-- training program
-- organization process definition
-- organization process focus
 CMM Levels
Level 5 Optimizing (< 1%)
-- process change management
-- technology change management
-- defect prevention
Level 4 Managed (< 5%)
-- software quality management
-- quantitative process management