Agile Software Development

Session 1

Content:1. Why Agile?

Traditional Development Waterfall problems

2. In search of Structure The Scrum Team -> Jazz Band

3. What is Agile?

4. Agile Manifesto

5. What is a Feature?

6. Application of Agile Software Development Whole Team

7. Roles1. Product Owner2. Scrum Master3. Development Team

8. Helpful Links

Traditional Development (Waterfall)

Requirements

Design

Implementation

Verification

Maintenance

Waterfall Problems

Longer time to market; developers isolated from customer needs.

Planning far in advance causes the plans to be no longer matching the reality by the time they’re implemented.

Lack of visibility into rate of progress.

Customers get access to new features infrequently and after long delay so they can only provide feedback “too late”. That occurs because the process doesn’t allow for rapid incremental learning.

In search of Structure

Rather than being a classical orchestra with its deterministic score, a software development project is like a Jazz session in which conductor and team mix outlined structures and patterns with improvisation and interaction.

But how? How can we avoid improvisation turning into anarchy and chaos? If there is no generic master plan, and if we condemn too much structure, are there any guidelines to follow?

What is Agile?

A small group of people got together in 2001 to discuss their feelings that the traditional approach to managing software development projects was failing far too often, and there had to be a better way. They came up with the agile manifesto [VALUES].

“Agile is a mindset defined by values guided by principles and manifested through many different practices”

Agile Manifesto

Agile Manifesto

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

That is, while there is a value in the items on the right, we value the items on the left more.

What is a Feature?In agile development, a feature is a chunk of functionality that delivers

business value. Features can include additions or changes to existing functionality. For planning purposes, some methodologies also use the notion of "work items" that can include features, bug fixes, documents, and other artifacts. But features are the main unit of planning.

Ideally, a feature should adhere to the following criteria:

It should provide business value

It should be estimable - it must have enough definition for the development team to provide an estimate of the work involved in implementing it

It should be small enough to fit within an iteration - therefore, if it is too big, it should be broken down further

It should be testable - you should understand what automated or manual test a feature should pass in order to be acceptable to the customer

Application of Agile Software Development

Several of the basic practices of agile software development are applied to some degree to most of the agile methods.

Practice means a specific activity that its application supports the principle of the development approach.

The basic practices:1. Whole team2. Short releases3. Time estimations4. Measures5. Customer collaboration6. Test-driven development7. Pair programming8. Refactoring

Whole Team communicate in a face-to-face fashion as much as possible.

The practice is applied in several ways:

1. The development team is located in a collaborative workspace which supports communication.

2. All team members participate in all the product presentations to the customer. The customer requirements are active in the actual planning process.

In the Whole Team concept each team member has an additional role besides that of developer to ensures that all team members are involved in all parts of the developed software.

The distribution of responsibilities in the form of roles helps to control and manage these responsibilities involved in software development.

Cross-functional

Self-organizing

Product Owner

• Manage Economics• Participate in

Planning• Groom the Product

Backlog• Define acceptance

criteria and verify that they are met

• Collaborate with the development team.

• Collaborate with the stakeholders

Scrum Master

• Coach• Servant Leader• Process Authority• Interference Shield• Impediment

Remover• Change agent

Development Team

• T-shaped skills• Musketeer Attitude• Transparent

Communication• Right Sized• Focused and

Committed• Working at a

Sustainable pace over time

Product Owner

focused on Building the right

product

Development Team

Building the product right

Scrum Master

Helping everyone understand the Scrum values, principles, and

practices

focused on

focused on

Role Scheme

Leading Group

Coach

Tracker

Methodologist

Customer Group

User Evaluator

Customer

Acceptance Tester

Code Group

Designer

Unit Tester

Continuous Integrator

Code Reviewer

Maintenance Group

Presenter

Documenter

Installer

1- Product Owner

1. Manage Economics

Release-Level Economics • continuously makes trade-offs in scope, date, budget, and quality as a

stream of economically important information arrives during product development.

• might conclude that shipping the product early instead of continuing with the original plan if the cost to create the rest of the items is greater than the value they deliver.

• might conclude canceling the development effort even if things are going well in some cases like the country changes its laws, making it unprofitable or perhaps illegal for us to sell the product.

Sprint-Level Economics ensuring that a good return on investment (ROI) is delivered from each

sprint.

Product Backlog Economics is responsible for prioritizing the product backlog.

Responsibilities:

2. Participate in Planning

3. Groom the Product Backlog

4. Define acceptance criteria and verify that they are met

5. Collaborate with the development team.

an engaged, committed, everyday role.

6. Collaborate with the stakeholders

2- Scrum Master

1. Coach the good coach acts as “I’m not here to solve your problems for

you; instead, I’m here to help you solve your own problems.” coaches a new product owner by helping him understand and

perform his product owner responsibilities provides him with ongoing assistance for activities such as

grooming the product backlog. manage expectations, make sure the owner is providing the

team with what it needs, and listen to the owner’s complaints and requests for change and translate those into actionable improvements for the team.

2. Servant leaderA servant leader would never ask, “So, what are you going to do for me today?” Instead, a servant leader asks, “So, what can I do today to help you and the team be more effective?”

Responsibilities:

3. Process Authority doesn’t hire and fire

cannot dictate to the team what tasks it should do or how to do them.

not responsible for making sure the work gets done.

Instead, he helps the team define and adhere to its own process for making sure the work gets done.

4. Interference Shieldprotects the development team from outside interference so that it can remain focused on delivering business value every cycle.

5. Impediment Remover

6. Change Agent

T-shaped Skills:

Musketeer Attitude:

“All for one and one for all.”1. The capable person of doing the work never

says “That’s not my job.” 2. The person without the skills might be

selected to do the job with skilled one to create a team with greater aggregate capabilities.

3. The team members can organize their work to ensure a good flow through the sprint so that no one team member is overburdened.

4. Each team member is fully engaged at all times, even with speaking up with in the issues, rather than saying “Not my job; they know better than I do anyway.”

3- Development Team

Transparent Communication:

is important to avoid surprises and to build trust among the team members.

Having an individual in the team who frequently surprises the team with his results, leads to the other team members would not trusting this individual, and in turn impede the team’s ability to self-organize and meet its sprint goals.

Right Sized:

Agile favors small teams. Typically 5:9

Focused and Committed

Working at a Sustainable pace over time

Helpful Links:

Agile: An Introduction

https://www.youtube.com/watch?v=OJflDE6OaSc

http://scrumtrainingseries.com/

Attachments: https://www.dropbox.com/sh/1y28petl4g2zc4f/AA

DtQMrgPrVeIGTDPfSu-yrZa?dl=0