Lecture-03

Agile Software Development

Nahida Islam
Lecturer, Department of CSE
Email: [email protected]
What is Agile?

 Agile software development is a conceptual framework for software engineering that

promotes development iterations throughout the life-cycle of the project. It denote the ability
of Agile Methods to respond to changing requirement in a controlled but flexible manner.

 Software developed during one unit of time is referred to as an iteration, which may last from
one to four weeks. Agile methods also emphasize working software as the primary measure of
progress.
 What is Agile?

 Key term IID –

 The simple ability to revisit the “phases” of development dramatically improves project
efficiency.
 The idea of revisiting phases over and over is called “incremental and iterative
development” (IID).
 The development lifecycle is cut up into increments or “iterations” and each iteration
touches on each of the traditional “phases” of development.
 Why do we need new Project
Management Methods?
 Information Technology (as well as other industries) are continuously being challenged by
emerging technologies and requirements.
 Traditional Project Management “Best Practices” suggest that we should lock down
requirements and setup a change control system up front.
 Traditional Project Management practices also tend to refer back to the original requirements
(and/or the contract) when enforcing change control.
 Chaos – Junior Project Managers tend to either:
 allow too much uncontrolled changed to take place (to ensure customer satisfaction)
 or are too strict in allowing for change (resulting in irate customers).
 Why do we need new Project
Management Methods?

 Dramatic Project Underperformance – According to the Standish Group’s Chaos Reports, only
16 percent of IT projects are successful, the remainder are:
 Late.
 Over Budget.
 Deliver only a fraction of original scope in order to meet budget restrictions.
 Cancelled.
What is different about Agile?

 Flexible enough to manage the impact of change on a project.

 Allows change to be introduced into a project in a orderly way that that attempts to maximize
the benefits for the sponsor.
 Controls the risks that the change introduces.
 Iterative and Incremental development that break down development into a number of
repeating cycles called Iterations
 Short iterations are used to keep the feedback flowing (allowing for increased responsiveness
to change and reducing the risk of building the wrong thing).
 Open, Flexible and Extensive design using open standards whenever possible
What is different about Agile?

 Empowered Teams – Experienced specialists are encouraged to work out the detail design on
their own.
 Personal Communication – Rather than relying on written documentation to communicate
design decisions, technical approaches and other typically documented items, agile method
suggest that the team work in the same physical space (co-location). Use of white boards in
the work area is encouraged rather than lengthy formal detail design documentation.
Agile Manifesto

 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.
Characteristics of Agile Software
Development
 Light Weighted methodology

 Small to medium sized teams

 vague and/or changing requirements

 vague and/or changing techniques

 Simple design

 Minimal system into production

 Benefits of Being Agile

 Reducing Risk – The benefits from improved control and improved communication lead to
reduced risks. Examples of risks include:
 Risk of building (or doing) the wrong thing. Did the sponsor get what they asked for but
not what they actually wanted?

 Risk of building the right thing poorly. For example, was the product poorly crafted. Was
it thoroughly tested as a part of each iteration? Is the final produce extensible?

 Risk of being placed into an endless cycle of design updates and reviews due to changing
requirements or high levels of complexity
 Relief from continual design revisions -- Agile Methods are of the most benefit when
applied to projects where the requirements are either unclear or evolving
 Benefits of Being Agile

 .Agile methods allow the Project Manager to their control over the project in high change
environment. Utilizing less rigid, yet structured agile methodologies, control is through a
number of mechanisms.

 Frequent delivery of working code allows progress to be objectively measured.

 Early and frequent stakeholder feedback allows the Project Manager to redirect project
priorities when needed to ensure that real value is delivered.

 Misunderstandings are cleared up early in the project life-cycle.

 Benefits of Being Agile

The
. sponsor is able to end the project earlier than scheduled and still receive value.

 Short daily meetings allow team members to share both successes and problems with each
other. Each team member should share:
 What they have just completed (so that team members working on dependent tasks are
notified).
 What are they going to work on next (allows other team members to contribute
information that may be helpful to the task).
 Issues that are slowing down or halting their progress (so that other team members and/or
the Project Manager can provide assistance).
Agile Method of Planning of a Software
Development Project

 Initial Analysis
 Initial Design
(When problems are identified they are pushed back into the analysis step, to improve
it).
 Initial coding
push back identified design problems back. Perform another iteration of design to
improve it.
 Initial Testing
Identified problems are feed back into another iteration of coding.
 Integration and deployment
Feedback any problems you encounter into the process.
 A system of incremental/continuous improvement.
Agile Methods are all about incremental
progress
 Working incrementally allows the most critical portions of the product to be delivered
earlier.

 Working incrementally can help reduce risk by receiving stakeholder feedback in

increments rather than at the end.

 Working incrementally allows project teams to continuously make small corrections

along the way. Each incremental corrections contributes to the overall quality of the
entire project.
Agile--- Challenges

 Dedicated developers

 Experienced developers

 Small collocated teams

 Automated Regression testing

 Easy to access users.

Agile Documentation
 A document is any artifact external to source code whose purpose is to convey information in
a persistent manner.

 Reasons to create documentation:

 Project stakeholders require it (a Business decision with costs and benefits associated with it)
 To define a contract model (to define how your system and an external one interact with each
other). Typically required when an external resource controls an IT resource your system
requires (e.g. DB, Application or IT service)
 To support communication with an external group (e.g. a non-co-located group).
 If it will assist you in thinking something through.
When is Documentation Agile?
 Generally – when it is “Good Enough”, but no more. This of course is subjective.
 When it maximizes stakeholder investment.
 When the documentation contains “just enough” information to fulfill its purpose (and no
more).
 Is purpose driven. If you are not clear about the purpose you are creating the document, you
should not be doing so.
 When it contains information that is “Less Likely” to change.
 When the documentation contains critical information not readily available.
 When the documents have a specific customer and facilitate the work efforts of that customer.
 When the documents are sufficiently indexed, accurate, consistent and detailed
Existing Agile Methods

 Extreme Programming
 Scrum
 Crystal Methods
 Feature Driven Development
 Lean Development
 Dynamic Systems Development Methodology (DSDM)
Extreme Programming--XP

 Most prominent Agile Software development method

 Prescribes a set of daily stakeholder practices

 “Extreme” levels of practicing leads to more responsive software.

 Changes are more realistic, natural, inescapable.

Extreme Programming--XP

 A system of practices that a community of software developers is evolving to address

the problems of quickly delivering quality software, and then evolving it to meet
changing business needs.

 Most prominent Agile Software development method

 Prescribes a set of daily stakeholder practices

 “Extreme” levels of practicing leads to more responsive software.

 Changes are more realistic, natural, inescapable.

Refactoring
 Programming team look for possible software improvements and make these improvements
even where there is no immediate need for them.
 This improves the understandability of the software and so reduces the need for
documentation.
 Changes are easier to make because the code is well-structured and clear.
 However, some changes requires architecture refactoring and this is much more expensive
 Design becomes everybody’s daily business
 Continuously improve quality of the code
 Unit Tests and Pair Programming give courage
 Result:
 Fast development speed
 Code becomes easy to change
Examples of Refactoring

 Re-organization of a class hierarchy to remove duplicate code.

 Tidying up and renaming attributes and methods to make them easier to
understand.
 The replacement of inline code with calls to methods that have been included in a
program library.
Why XP Works?

 Light-weight: discipline without bureaucracy

 Under stress, people do what is easiest
 All XP practices have short-term benefits as well as long-term benefits
 Development as a Conversation
 The code is the documentation
 XP is fun.
Who Benefits from XP ?

Programmers: Customers:
 get clear requirements &  get most business value first
priorities
 get accurate feedback
 can do a good job
 can make informed business
 can make technical decisions decisions
 don’t work overtime  can change their mind
Scrum- An Agile Process
 Scrum approach is a general agile method but its focus is on managing iterative
development rather than specific agile practices.

 There are three phases in Scrum.

 The initial phase is an outline planning phase where you establish the general
objectives for the project and design the software architecture.
 This is 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 frames and user manuals and assesses the lessons learned from
the project.
Functionality of Scrum
Scrum Components

 Scrum Roles

 The Process

 Scrum Artifacts
 Scrum Master

 Represents management to the project

 Typically filled by a Project Manager or Team Leader

 Responsible for enacting scrum values and practices

 Main job is to remove impediments

 The Scrum Team

 Typically 5-10 people

 Cross-functional (QA, Programmers, UI Designers, etc.)

 Members should be full-time

 Team is self-organizing

 Membership can change only between sprints

 Product Owner

 Acts like one voice (in any case)

 Knows what needs to be build and in what sequence this should be done

 Typically a product manager

 The Process
 Sprint Planning Meeting

 Sprint

 Daily Scrum

 Sprint Review Meeting

Sprint Planning Meeting

 A collaborative meeting in the beginning of each Sprint between the Product Owner, the Scrum
Master and the Team

 Takes 8 hours and consists of 2 parts

 before lunch and after lunch
 Parts of Sprint Planning Meeting
 1st Part:
 Creating Product Backlog
 Determining the Sprint Goal.
 Participants: Product Owner, Scrum Master, Scrum Team
 2nd Part:
 Participants: Scrum Master, Scrum Team
 Creating Sprint Backlog
Pre-project/Kick-off meeting:
 A special form of Sprint Planning Meeting
 Meeting before the begin of the Project
Sprint

 A month-long iteration, during which is incremented a product functionality

 NO outside influence can interference with the Scrum team during the Sprint

 Each Sprint begins with the Daily Scrum Meeting

Daily Scrum

 Is a short (15 minutes long) meeting, which is held every day before the Team starts working
 Participants: Scrum Master (which is the chairman), Scrum Team
 Every Team member should answer on 3 questions:
 What did you do since the last Scrum?
 What are you doing until the next Scrum?
 What is stopping you getting on with the work?
Daily Scrum

 Is NOT a problem solving session

 Is NOT a way to collect information about WHO is behind the schedule

 Is a meeting in which team members make commitments to each other and to the Scrum
Master

 Is a good way for a Scrum Master to track the progress of the Team
Sprint Review Meeting

 Is held at the end of each Sprint

 Business functionality which was created during the Sprint is demonstrated to the Product
Owner

 Informal, should not distract Team members of doing their work

Scrum Artifacts

 Product Backlog
 Sprint Backlog
 Burn down Charts
Product Backlog

 Requirements for a system, expressed as a prioritized list of Backlog Items

 Is managed and owned by a Product Owner
 Spreadsheet (typically)
 Usually is created during the Sprint Planning Meeting
 Can be changed and re-prioritized before each planning meeting.
 Estimation of Product Backlog
Items
 Is only a FORECAST!-> is not exact
 Establishes team’s velocity (how much Effort a Team can handle in one Sprint)
 Determining units of complexity.
 Size-category (“T-Shirt size”)
 Story points
 Work days/work hours
 Methods of estimation:
 Expert Review
 Creating a Work Breakdown Structure
 Sprint Backlog

 Is a FORECAST
 A subset of Product Backlog Items, which define the work for a Sprint
 Is created ONLY by Team members
 Each Item has it’s own status
 Should be updated every day
 No more then 300 tasks in the list
 If a task requires more than 16 hours, it should be broken down
 Team can add or subtract items from the list. Product Owner is not allowed to do it
 Burn Down Chart
 Are used to represent “work done”.
 Are wonderful Information Radiators
 3 Types:
 Sprint Burn down Chart (progress of the Sprint)
 Release Burn down Chart (progress of release)
 Product Burn down chart (progress of the Product)
 X-Axis: time (usually in days)
 Y-Axis: remaining effort
 Sprint Burn Down Chart

 Depicts the total Sprint Backlog hours remaining per day

 Shows the estimated amount of time to release
 Ideally should burn down to zero to the end of the Sprint
 Actually is not a straight line
 Can bump UP
 Release Burn Down Chart

 Will the release be done on right time?

 X-axis: sprints
 Y-axis: amount of hours remaining
 The estimated work remaining can also burn up
 Scaling Scrum
 A typical Scrum team is 6-10 people, but according to Jeff Sutherland - up to over 800 people
can be involved,
 Agile methods have proved to be successful for small and medium sized projects that can be
developed by a small co-located team.
 It is sometimes argued that the success of these methods comes because of improved
communications which is possible when everyone is working together.
 Scaling up agile methods involves changing these to cope with larger, longer projects where
there are multiple development teams, perhaps working in different locations.
 "Scrum of Scrums" or what called "Meta-Scrum“
 XP @ Scrum

 Scrum is an effective project management wrapper for eXtreme Programming development

practices, which enables agile projects to become scalable and developed by distributed teams
of developers.
The END