Software Development- The Agile Way

It is all about Common sense.

Audience: Development Team

What is Agile

Group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.

History • Evolved in the mid-1990s as part of a reaction

against "heavyweight" methods.• Heavily regulated, regimented, micro-managed

use of the waterfall model of development.• Initially, agile methods were called "lightweight

methods." • Common Methods: Scrum (1995), Crystal

Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995)

History• In 2001, 17 prominent figures, at the Snowbird

ski resort in Utah, coined the terms "Agile Software Development" and "agile methods", and they created the Agile Manifesto.

• Later, The Agile Alliance, a non-profit organization that promotes agile development.

• In 2005, Alistair Cockburn and Jim Highsmith gathered another group of people—management experts, this time—and wrote an addendum, known as the PM Declaration of Interdependence.

The Values behind the Agile Manifesto

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

The principles behind the Agile Manifesto Customer satisfaction by rapid, continuous delivery of useful

software Working software is delivered frequently (weeks rather than

months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and

developers Face-to-face conversation is the best form of communication

(co-location) Projects are built around motivated individuals, who should

be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances

Problems with Suitability of agile methods Large scale development efforts (>20

developers), though scaling strategies and evidence to the contrary have been described.

Distributed development efforts (non-co-located teams). Strategies have been described in Bridging the Distance and Using an Agile Software Process with Offshore Development

Command-and-control company cultures. Forcing an agile process on a development

team

Agile methods / practices Agile methods

Agile Modeling Agile Unified Process (AUP) Agile Data Method DSDM Essential Unified Process (EssUP) Extreme programming (XP) Feature Driven Development (FDD) Getting Real Open Unified Process (OpenUP) Scrum Lean software development

Agile practices Test Driven Development (TDD) Behavior Driven Development (BDD) Continuous Integration Pair Programming Planning poker RITE Method

Agile Modeling (AM) Core Practices:

Active Stakeholder Participation including direct users, their management, senior

management, operations staff, and support (help desk) staff.

Model With Others. Apply The Right Artifact(s). UML diagram/ER diagram Iterate To Another Artifact. Prove It With Code. Use The Simplest Tools. Model In Small Increments. Single Source Information.

Agile Modeling (AM)Collective Ownership.Create Several Models in Parallel. Create Simple Content. Depict Models Simply. Display Models Publicly.

Supplementary Practices: Apply Modeling Standards. Apply Patterns Gently. Discard Temporary Models. Formalize Contract Models. Update Only When It Hurts.

References: http://www.agilemodeling.com/practices.htm

Scrum

• Iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development

Key Terms• Product owner Project’s key stakeholder and represents users,

customers and others in the process. • Scrum Master Responsible for making sure the team is as productive

as possible. • Product backlog Prioritized features list containing every desired

feature or change to the product • Sprint: Time-boxed period of software development

focused on a given list of goals (but with variable scope).

Meetings Daily Scrum /“the daily standup” During the meeting, each team member answers three questions:

What have you done since yesterday? What are you planning to do today? Do you have any problems preventing you from accomplishing your goal?

Scrum of scrums Each day normally after the daily scrum.

These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.

A designated person from each team attends. The agenda will be the same as the Daily Scrum, plus the following four

questions: What has your team done since we last met? What will your team do before we meet again? Is anything slowing your team down or getting in their way? Are you about to put something in another team’s way?

Sprint Review Meeting Review the work that was completed and not completed Present the completed work to the stakeholders (a.k.a.

“the demo”) Incomplete work cannot be demonstrated Four hour time limit

Sprint Retrospective All team members reflect on the past sprint Make continuous process improvements Two main questions are asked in the sprint retrospective:

What went well during the sprint? What could be improved in the next sprint?

Three hour time limit

Burn down • Graphical representation of work left to do versus

time. • The outstanding work (or backlog) is often on the

vertical axis, with time along the horizontal.

Burn down Types

• sprint burndown chart • Release Burndown Chart • Alternative Release Burndown Chart

General practices of ScrumThe following are some general practices of Scrum:

• Customers become a part of the development team (i.e., the customer must be genuinely interested in the output).

• Scrum has frequent intermediate deliveries with working functionality, like all other forms of agile software processes. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.

• Frequent risk and mitigation plans are developed by the development team itself—risk mitigation, monitoring and management (risk analysis) occurs at every stage and with commitment.

• Transparency in planning and module development—let everyone know who is accountable for what and by when.

• Frequent stakeholder meetings to monitor progress—balanced dashboard updates (delivery, customer, employee, process, stakeholders)

• There should be an advance warning mechanism, i.e., visibility to potential slippage or deviation ahead of time.

• No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.

• Workplaces and working hours must be energized—“Working more hours” does not necessarily mean “producing more output.”

Scrum Methodology

An other view(SCRUM Methodology)

SCRUM PhasesSCRUM has the following groups of phases:1.Pregame2.Game3.Postgame Pregame

Planning : Definition of a new release based on currently known backlog, along with an estimate of its schedule and cost. If a new system is being developed, this phase consists of both conceptualization and analysis. If an existing system is being enhanced, this phase consists of limited analysis.

Architecture : Design how the backlog items will be implemented. This phase includes system architecture modification and high level design.

SCRUM PhasesGame

Development Sprints : Development of new release functionality, with constant respect to the variables of time, requirements, quality, cost, and competition. Interaction with these variables defines the end of this phase. There are multiple, iterative development sprints, or cycles, that are used to evolve the system.

PostgameClosure : Preparation for release, including final

documentation, pre-release staged testing, and release.

Planning

Development of a comprehensive backlog list. Definition of the delivery date and functionality of one or more

releases. Selection of the release most appropriate for immediate

development. Mapping of product packets (objects) for backlog items in the

selected release. Definition of project team(s) for the building of the new release. Assessment of risk and appropriate risk controls. Review and possible adjustment of backlog items and packets. Validation or reselection of development tools and infrastructure. Estimation of release cost, including development, collateral

material, marketing, training, and rollout. Verification of management approval and funding.

Architecture/High Level Design• Review assigned backlog items.• Identify changes necessary to implement backlog

items.• Perform domain analysis to the extent required to

build, enhance, or update the domain models to reflect the new system context and requirements.

• Refine the system architecture to support the new context and requirements.

• Identify any problems or issues in developing or implementing the changes

• Design review meeting, each team presenting approach and changes to implement each backlog item. Reassign changes as required.

Development (Sprint) The Development phase is an iterative cycle of

development work. The management determines that time, competition, quality, or functionality are met, iterations are completed and the closure phase occurs. This approach is also known as Concurrent Engineering.

Development consists of the following macro processes :Meeting with teams to review release plans.Distribution, review and adjustment of the

standards with which the product will conform. Iterative Sprints, until the product is deemed

ready for distribution.

Development (Sprint)

Each Sprint consists of one or more teams performing the following:

Develop: Defining changes needed for the implementation of backlog requirements into packets, opening the packets, performing domain analysis, designing, developing, implementing, testing, and documenting the changes. Development consists of the micro process of discovery, invention, and implementation.

Wrap: Closing the packets, creating a executable version of changes and how they implement backlog requirements.

Review: All teams meeting to present work and review progress, raising and resolving issues and problems, adding new backlog items. Risk is reviewed and appropriate responses defined.

Adjust: Consolidating the information gathered from the review meeting into affected packets, including different look and feel and new properties.

Development (Sprint)Each Sprint is followed by a review, whose characteristics are: The whole team and product management are present and

participate. The review can include customers, sales, marketing and others. Review covers functional, executable systems that encompass

the objects assigned to that team and include the changes made to implement the backlog items.

The way backlog items are implemented by changes may be changed based on the review.

New backlog items may be introduced and assigned to teams as part of the review, changing the content and direction of deliverables.

The time of the next review is determined based on progress and complexity. The Sprints usually have a duration of 1 to 4 weeks.

Closure

When the management team feels that the variables of time, competition, requirements, cost, and quality concur for a new release to occur, they declare the release “closed” and enter this phase. This phase prepares the developed product for general release.Integration, system test, user documentation, training material preparation, and marketing material preparation are among closure tasks.

Comparison of methods

Key Terms

• Velocity:The amount of work that you can do in each

iteration How much product backlog effort a team can

handle in one sprint. Impediment

Anything that prevents a team member from performing work as efficiently as possible.

Estimation Using Scrum

• Involve everybody you think would be part of the project.

• The first step is to break your requirements into user stories.

• User stories is a piece of functionality which has a functional flow and can be delivered.

• User stories are simple, clear, brief descriptions of functionality that will be valuable to either a user or purchaser of a product

• User stories: help deferring details till later They talk problems not solutions They fit nicely as your Product Backlog items

Scrum Planning • The two levels of planning

Strategic level / Story level / product backlog Tactical level / Task level / spring backlog

Estimation method

Example

Support in MS visual studio 2008

• http://channel9.msdn.com/pdc2008/TL09/

Support in MS visual studio 2010

• A special template is provided to follow Scrum

Drawback of Agile

No process is guaranteed to work straight out of box.

References

• http://www.agilemanifesto.org• http://agilesoftwaredevelopment.com• http://www.agilesecrets.com/• http://www.agile-software-development.com• http://www.agilemodeling.com/• http://www.agilemodeling.com/• http://scrumforteamsystem.com• http://www.agilejournal.com• http://www.youtube.com/view_play_list?

p=E5EAAE9043D08AB4

Further Discussion

A soft copy will be available at: http://softarchitect.wordpress.com

For Future discussion, join http://tech.groups.yahoo.com/group/

SoftArchitect/