Agile Development
The Manifesto for
Agile Software Development
“We are uncovering better ways of developing software by doing it and helping others 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 That is, while there is value in the items on the right, we value the items on the left more.”
Kent Beck et al 2001
Reality
In the modern economy, it is often difficult or impossible to predict how a computer-based system (e.g., a Web-based application) will evolve as time passes.
Market conditions change rapidly, end-user needs evolve, and new competitive threats
emerge without warning. In many situations, you won‘t be able to define requirements fully before the project begins.
You must be agile enough to respond to a fluid business environment.
Reality
We forget frailties of the people who build computer software.
Software engineers are not robots. They exhibit great variation in working styles; significant differences in skill level, creativity, orderliness, consistency, and spontaneity.
Some communicate well in written form, others do not.
Alistair Cockburn [2002] argues that process models can
―deal with people‘s common weaknesses with [either]
discipline or tolerance‖ and that most prescriptive process models choose discipline. He states: ―Because
consistency in action is a human weakness, high discipline methodologies are fragile.‖
What is ―Agility‖?
Effective (rapid and adaptive) response to change
Effective communication among all stakeholders
Drawing the customer onto the team (eliminate
―us and them‖ attitude)
Organizing a team so that it is in control of the work performed
Streamline tasks, plan according to the fluidity, eliminate all but most essential work products….
Yielding …
Rapid, incremental delivery of software
Agility and the Cost of Change
An Agile Process
Is driven by customer descriptions of what is required (scenarios)
Recognizes that plans are short-lived
Develops software iteratively with a heavy emphasis on construction activities
Delivers multiple ‗software increments‘
Executable prototypes or portions of operational s/w
Adapts as changes occur
Agility Principles - I
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying
information to and within a development team is face–to–face conversation.
Agility Principles - II
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
Politics of Agile Development
Jim Highsmith [2002] characterizes the feeling of Pro- agility camp (―agilists‖):
“Traditional methodologists are a bunch of stick-in- the-muds who‟d rather produce flawless
documentation than a working system that meets business needs!!”
Question remains:
What is the best way to achieve it?
How do you build software that meets customers‘ needs today and exhibits the quality characteristics that will enable it to be extended and scaled to meet customers‘
Human Factors
the process molds to the needs of the people and team, not the other way around
key traits must exist among the people on an agile team and the team itself:
Competence.
Common focus.
Collaboration.
Decision-making ability: autonomy
Fuzzy problem-solving ability.
Mutual trust and respect: “jelled”
Self-organization: the team accepts responsibility for fulfilling commitments
Agile Methods
Extreme Programming (Beck, 2004)
Scrum (Cohn, 2009; Schwaber, 2004; Schwaber and Beedle, 2001)
Crystal (Cockburn, 2004)
Adaptive Software Development (Highsmith, 2000)
Dynamic System Development Method (DSDM) (Stapleton, 2003)
Feature Driven Development (Palmer and Felsing, 2002).
Plan-driven and agile
development
Plan-driven and agile
development
Plan-driven and agile development
1. 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.
2. Is an incremental delivery strategy, where you deliver the software to customers and get rapid feedback from them, realistic? If so, consider using agile methods.
3. 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.
Plan-driven and agile development
4. 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.
5. 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.
Plan-driven and agile development
6. 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.
7. 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.
Plan-driven and agile development
8. 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.
9. 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 low skill levels, you may need to use the best people to develop the
Plan-driven and agile development
10. 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.
Agile development is need based!!
Extreme Programming (XP) (Kent 2004)
Pushes recognized good practice, such as iterative development, to ‗extreme‘
levels.
For example, in XP, several new
versions of a system may be developed by different programmers, integrated
and tested in a day!!
Extreme Programming (XP) (Kent 2004)
The most widely used agile process, originally proposed by Kent Beck
XP Values:
communication
simplicity
feedback
courage (design for today!)
respect
Extreme Programming (XP) (Kent 2004)
Communication - Stakeholders
simplicity – Complex items are discarded; refactoring!
feedback – customer, developer & s/w
courage (design for today!)
Respect - Mutual
Extreme Programming (XP)
Extreme Programming (XP)
XP Planning (Planning game!)
Starts with listening
Listening leads to creation of short stories (user stories)
Story describes output, feature and functionality of the s/w
Customer writes story on an index card
He assigns priority value
XP team assesses each story and assigns a cost
Extreme Programming (XP)
XP Planning (Planning game!) contd
If a story demands more than 3 development weeks then it is split into shorter stories and cost is
reassigned
Customer and developer group stories into next s/w increment
Basic commitment (agreement) is made over stories to be included and delivery dates
3 ways:
A. All stories are implemented
B. Stories with highest values is moved up in schedule
C. Riskiest stories are moved up in schedule
Extreme Programming (XP)
XP Planning (Planning game!) contd.
Project velocity – It is the number of customer
stories implemented during the first release. Project velocity can then be used to
(1) help estimate delivery dates and schedule for subsequent releases
(2) determine whether an over-commitment has been made for all stories across the entire
development project
As development work proceeds, the customer can add stories, change the value of an existing story, split stories, or eliminate them
Extreme Programming (XP)
XP Design
Follows the KIS principle
Encourage the use of CRC (Class- responsibility collaborator) cards
A CRC model is really a collection of standard
index cards that represent classes. The cards are divided into three sections. Along the top of the
card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right.
Extreme Programming (XP)
Extreme Programming (XP)
Extreme Programming (XP)
XP Design
Follows the KIS principle
Encourage the use of CRC (Class- responsibility collaborator) cards
For difficult design problems, suggests the creation of ―spike solutions‖—a design
prototype
Spike: During the planning game, questions that cannot be easily answered come to light and additional work is required to explore possible solutions. The team may carry out some prototyping or trial development to understand the problem and solution. In XP terms, this is a ‗spike‘, an increment where no programming is done.
There may also be ‗spikes‘ to design the system architecture or to develop system documentation
32
Extreme Programming (XP)
XP Design
Encourages ―refactoring‖—an iterative refinement of the internal program design
Refactoring is the process of changing a software
system in such a way that it does not alter the external behaviour of the code yet improves the internal structure.
It is a disciplined way to clean up code or modify/simplify the internal design that minimizes the chances of
introducing bugs. Refactoring improves the design of the code after it has been written.
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
Extreme Programming (XP)
XP Coding
Recommends the construction of a unit test for a store before coding commences
(knowing exam questions!)
Encourages ―pair programming‖
Pair programming supports the idea of
collective ownership and responsibility for the system.
It acts as an informal review process because each line of code is looked at by at least two people
Extreme Programming (XP)
―Pair programming‖ (contd)
It helps support refactoring, which is a process of software improvement.
It provides a mechanism for realtime problem solving (two heads are often better than one) and real-time quality assurance (the code is reviewed as it is created). It keeps the
developers focused on the problem at hand. In practice, each person takes on a slightly
different role.
Extreme Programming (XP)
―Pair programming‖ contd.
For example, one person might think about the coding details of a particular portion of the
design while the other ensures that coding standards (a required part of XP) are being followed or that the code for the story will
satisfy the unit test that has been developed to validate the code against the story.
Extreme Programming (XP)
XP Testing
All unit tests are executed daily
―Fixing small problems every few hours takes less time than fixing huge problems just before the
deadline.‖
―Acceptance tests‖ are defined by the
customer and executed to assess customer visible functionality
Extreme Programming (XP)
Adaptive Software Development
Originally proposed by Jim Highsmith (2000) for building complex software and systems
He argues: ASD approach based on
collaboration is ―as much a source of order in our complex interactions as discipline and
engineering.‖
ASD Lifecycle
Speculation
Learning
Collaboration
Adaptive Software Development
Adaptive Software Development
Speculation
A team that ―speculates‖ doesn‘t abandon planning!!
It acknowledges the reality of uncertainty.
During speculation, the project is initiated and adaptive cycle planning is conducted.
Adaptive cycle planning uses project initiation information—the customer‘s mission statement, project constraints (e.g., delivery dates or user
descriptions), and basic requirements—to define the set of release cycles (software increments) that will be required for the project
Adaptive Software Development
Speculation (contd.)
During JAD sessions, requirements are gathered in enough detail to identify features and establish a skeletal object, data or other architectural model.
Based on information obtained at the completion of the first cycle, the plan is reviewed and adjusted so that planned work better fits the reality in which an ASD team is working.
42
Adaptive Software Development
Collaboration
Complex applications are not built, they evolve!
One person or small group cannot possible
―know all‖
Collaboration skills (ability to work jointly to produce results, share knowledge, or make decisions) are paramount.
To multiply the talent and creative output of the team
It encompasses communication and teamwork, and emphasizes individualism, because
individual creativity plays an important role in collaborative thinking.
Adaptive Software Development
Collaboration (contd)
Team members must trust one another to
(1) criticize without animosity, (2) assist without resentment,
(3) work as hard as or harder than they do,
(4) have the skill set to contribute to the work at hand, and
(5) communicate problems or concerns in a way that leads to effective action.
Adaptive Software Development
Learning
Learning is vital to success
Learning helps the team to improve their level of real understanding
Constant knowledge testing
It is done in three ways:
Focus groups,
Technical reviews
Project postmortems
Adaptive Software Development
ASD — characteristics
Mission-driven planning
Component-based focus
Uses ―time-boxing‖
Explicit consideration of risks
Emphasizes collaboration for requirements gathering
Emphasizes ―learning‖ throughout the process
Scrum
Schwaber and Beedle (2004)
A group of players forms around the ball and the
teammates work together (sometimes violently!) to move the ball downfield.
Focuses on managing iterative development rather than specific technical approaches
Scrum
Three Phases
Outline Planning & Architectural Design
Sprint Cycle
Project Closure
Scrum
Outline Planning Phase
General objectives and Architectural design
Sprint cycle
A Scrum sprint is a planning unit in which the work to be done is assessed, features are selected for development, and the
software is implemented.
At the end of a sprint, the completed
functionality is delivered to stakeholders.
Scrum
Scrum
Scrum—distinguishing features
Sprints are fixed length, normally 2–4 weeks. They correspond to the development of a release of the system in XP.
The starting point is the product backlog - list of work to be done on the project.
Backlog—a prioritized list of project requirements or features that provide business value for the customer.
Items can be added to the backlog at any time (this is how changes are introduced).
Scrum
Scrum—distinguishing features (contd)
During the assessment phase of the sprint, backlog 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.
Scrum
Scrum—distinguishing features (contd)
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
channelled through the so-called „Scrum master‟. The role of the Scrum master is to protect the development team from external distractions and act as facilitator.
Unlike XP, Scrum does not make specific suggestions on how to write requirements, test-first development, etc.
At the end of the sprint, the work done is reviewed and presented to stakeholders.
Scrum
Scrum—distinguishing features (contd)
Instead of project manager Scrum has „Scrum master‟.
Daily Meetings:
‗Stand-up‘ meetings, short and focused. All team members share information, describe their progress since the last meeting, problems that have arisen, and what is planned for the following day.
Everyone on the team knows what is going on and, if problems arise, can replan short-term work to cope with them. Everyone participates in this short-term planning—
there is no topdown direction from the Scrum master.
Scrum
Scrum—distinguishing features
Daily Meeting Questions:
What did you do since the last team meeting?
What obstacles are you encountering?
What do you plan to accomplish by the next team meeting?
The Scrum meeting helps the team to uncover potential problems as early as possible. Also, these daily
meetings lead to ―knowledge socialization‖ and thereby promote a self-organizing team structure
Scrum
Scrum—distinguishing features
Project Closure:
The project closure phase wraps up the project, completes required documentation
such as system help frames and user manuals, and assesses the lessons learned from the
project.
Scrum
Scrum— Success Stories (Advantages)
The product is broken down into a set of manageable and understandable chunks.
Unstable requirements do not hold up progress.
The whole team has visibility of everything and consequently team communication is improved.
Customers see on-time delivery of increments and gain feedback on how the product works.
Trust between customers and developers is established and a positive culture is created in which everyone
expects the project to succeed.
Scrum
Scrum—distinguishing features
Development work is partitioned into ―packets‖
Testing and documentation are on-going as the product is constructed
Work occurs in ―sprints‖ and is derived from a
―backlog‖ of existing requirements
Meetings are very short and sometimes conducted without chairs
―demos‖ are delivered to the customer with the time- box allocated
The Scrum process patterns enable a software team to work successfully in a world where the
elimination of uncertainty is impossible.
Scrum
Scrum— Future
Software development now involves distributed teams with team members located in different places around the world.
Various experiments are going on to develop Scrum for distributed development
environments (Smits and Pshigoda, 2007;
Sutherland et al., 2007).
