agile project management (workshop)

Agile Training WorkshopMajid Rafiq, PMI-ACP | Associate Project Manager

2

Workshop Agenda

• What is Agile

• Scrum

• XP

• Kanban

Majid Rafiq, PMI-ACP | Agile Training Workshop

What is Agile?

4

What is Agile?

• What do you think is the purpose of this workshop?

• Difference between how to agile and being agile?

• What advantages can you state of Agile?


TRADITIONAL

Waterfall Approach

Need more time to market

Not all of the features are used by consumers:

Often/Always: 20%

Sometimes: 16%

Rarely/Never: 64%

AGILE

Iterative & Incremental

Time boxed

Focuses on Minimum Marketable Features

Continuous involvement of Customer

Open to change requests at all stages of life cycle

5

Traditional vs. Agile Approach


6

Agile Software Development

What is Agile Software Development?

Iterative and incremental development

Requirements and solutions evolve through collaboration

Teams are potentially self-organizing and cross-functional


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

7

Process and toolsIndividuals and interactions over

Following a planResponding to change over

Comprehensive documentationWorking software over

Contract negotiationCustomer collaboration over

Agile Manifesto


Agile Manifesto

Individuals & Interactions over Processes & Tools

Each person can contribute unique value

Communication is clear, effective, quick and efficient

Stronger team work

Development teams can self-organize, be more innovative and customize the processes as required

Team members take personal ownership of the project

Team members can have better job satisfaction

8Majid Rafiq, PMI-ACP | Agile Training Workshop

9

Agile Manifesto

Working Software over Comprehensive Documentation

Meeting done criteria – a measure of completion

Bare minimum documentation


10

Agile Manifesto

Customer Collaboration over Contract Negotiation

Make the customer part of the project on an ongoing basis

Develops a partnership between customer and development team

Customer gets the increment at the end of each iteration

Customer feedback is incorporated in regular intervals


11

Agile Manifesto

Responding to Change over Following a Plan

Responding quickly to customers, product users and market helps in developing relevant and helpful products


13

Overview of Scrum

What is Scrum?

Pillars of Scrum

Roles

Ceremonies/Events

Artifacts

Scrum of Scrums

Basic Concepts of Scrum


14

An Overview of Scrum



Product Catalog

Sprint Backlog

Sprint / Iteration

Daily Scrum / Standup

Scrum Master

Potentially shippable to the customer

Sprint Review

Retrospective meeting


16


A Product Owner creates a prioritized wish list called Product Catalog

During Sprint Planning, the Scrum Team identifies and pulls a small number of items from the Product Catalog, creating a Sprint Backlog

The Scrum Team then decides how to implement the items

The team has a timebox, called a Sprint, to complete its work

The team meets each day to assess the progress, Daily Standup

Scrum Master keeps the team focused on its goals

At the end of the sprint the work should be potentially shippable to the customer

The sprint ends with a Sprint Review and Retrospective meeting


17

Pillars of Scrum

Transparency:

Share common standards and nomenclatures in Scrum Team

Inspection:

Detect undesirable variances through Scrum Events

Adaptation:

Make adjustments to the process and artifacts to minimize further deviation


18

What is Scrum?

Scrum is an Agile Framework structured to support product development

Scrum consists of Scrum Teams and their associated:

Roles

Events

Artifacts

Rules


19

Product Owner

Development Team

Scrum Master

Scrum Roles


20

Product Owner

Customer/Proxy representing the stakeholders

Responsible for maximizing the value of the product and the work of Development Team

Writes User Stories

Sole person responsible to manage the Product Backlog

Clearly express the Product Backlog Items

Prioritize the items to achieve best goals and missions

Ensure the Product Backlog is transparent and visible to all

Ensures the Development Team understands the items in the Product Backlog


21

Self-organizing team of size between 3 to 9

Normally developers who turn Product Backlog into increments of potentially shippable product based on “definition of done”

Less than 3 members

Decrease the interaction

Result in smaller productivity

May encounter skill issues

More than 9 members

Require too much co-ordination

Team


22

Team

Cross-functional team with all the skills necessary to create the product increment as a team

No titles for the team members other than “Developer”

Each team member chips in and applies his/her expertise to all the problems


23

Scrum Master

Ensures that Scrum rules are understood

Ensures that Scrum rules are followed

Resolves impediments

Protects team from external interferences

Removes the barriers between development and Product Owner so that Product Owner derives the development

Empowers the development team

Improves engineering practices and tools so that each increment is potentially shippable

Keeps information on team’s progress up to date and ensures its visibility


24

Servant Leadership

This kind of leadership includes:

Creating environment of personal safety where team members may both innovate and come to friendly disagreements

Mentoring team members

Facilitating (not controlling) meetings

Guiding the team

Removing obstacles


25

Sprint

Story Writing / User Stories

Sprint Planning Meeting

Daily Scrum / Stand-up

Sprint Review

Sprint Retrospective

Scrum Events


Sprint

• 1-4 weeks long (2 weeks preference)

• Potentially shippable product

• Most common misconception:– All sprints are iterations, but all iterations are not sprints

• Ideal iteration ending date:– An iteration should not end on a Friday


User Stories

• Traditional Requirements

• User Story

• Epic and Theme


28

Traditional Requirements

Criteria to which the system or business should adhere

Generated before the coding begins

Often considered as constraints, conditions or capabilities of the system

Rarely contain acceptance criteria

Contract between business and development


29

User Story

A product feature description written by Customer/Proxy from the perspective of the end user.

It helps team understand what work is to be done

Customer/Proxy prioritizes and team estimates them

It usually follows the format:▪ As a : <Role>

▪ I want to : <Function>

▪ So that : <Desired Goal>


30

User Story (contd.)

Shifts the focus from writing about requirements to talking about them

Not a highly detailed document, rather a reminder for further collaboration

Atomic in nature

Just-In-Time Tool

A User Story should be End to End


31

User Story (contd.)

Follows the INVEST model:▪ Independent

▪ Reduced dependencies, easy planning

▪ Negotiable

▪ Details are added via collaboration and not a contract

▪ Valuable

▪ Provides value to the customer

▪ Estimable

▪ Should not be big and vague/Team should be able to estimate

▪ Small

▪ Can be done in less than a week by the team

▪ Testable

▪ Has acceptance criteria


32

Epic and Theme

Theme is a collection of related stories

Epic is a large story that can be further divided into multiple stories

For example, “A user can search for job” can be split into multiple stories:▪ Search by Location, Salary Range, etc.

▪ View Job Detail

▪ View Company Profile


Acceptance Criteria

• Final criteria to be satisfied in order to customer/product owner to accept the story

• Customer specified scenarios

• The product owner should list as many acceptance criteria as possible in order to clarify the intent of the story

Majid Rafiq, PMI-ACP | Agile Training Workshop 33

34

Definition of Done

Common Issues

Definition of Done


35

Definition of Done

Done criteria

Functional Testing by development team

Single User Story can have multiple acceptance tests

Also used during regression testing

DOD may not be added when an issue/task/story is created


36

Common Issues

Start from requirements documents in narrative format

Too much information

• Missing information• Team must understand the done criteria before committing to story

• Acceptance Criteria is confused with Test Cases

Acceptance Criteria: “How will I know when I am done with the story?”

Test Case: “How do I test and what are the test steps?”


Activity # 1• Create Stories

• Create DOD

As a : <Role>

I want to : <Function>

So that : <Desired Goal>

38

Planning

Sprint Goal

Planning Meeting

Estimation Technique – Planning Poker


Sprint Goal

A short statement of what the work will be focused on during the sprint


40

planning meeting

prioritization

• Analyze and evaluate

product backlog

• Select sprint goal

planning

• Decide how to achieve sprint

goal (design)

• Create sprint backlog (tasks)

from product backlog items

(user stories / features)

• Estimate sprint backlog in

hours

Sprint

goal

Sprint

backlog

Business

conditions

Team

capacity

Product

backlog

Technology

Current

product


Estimation Technique - Planning Poker

41

The size assigned is based on a fixed pool of numbers

Based on Fibonacci numbers

0 1 1 2 3 5 8 13 21 34 55 98

Adjusted sequence is:

0 ½ 1 2 3 5 8 13 20 40 100 α

Pre-requisite:

A standard story must be taken with size pre-allocated


42

Rules

Feature is read to the team with explanation by Product owner

Item is discussed

Each member rates it and places his vote face down

All cards are turned over at same time

If estimates are different, outliers are discussed

Repeat until consensus is reached or group can “live with” a selected size

Use Kitchen time to limit discussions


5 finger rule

43

After round of discussion, if consensus is not reached at all, use this to move forward

1. I am against this

2. I object and want to discuss

3. I have concerns but can live with it

4. I support with some reservations

5. I totally support it

Note: 1 or 2 require discussion and re-vote


Activity # 2• Lets estimate some stories!

5 finger Voting1. I am against this2. I object and want to discuss3. I have concerns but can live with it4. I support with some reservations5. I totally support it

Daily Scrum / Stand-up

A maximum of 15 minute meeting of team members

Helps synchronize effort

Status is shared

Dependencies are resolved

Commitments are made

Problems are identified but NOT resolved


Questions of Daily Scrum / Stand-up

What has been done?

What will be done before next meeting?

What are any obstacles?


Punishments for non-attendees/late comers

47

• Push-ups

• Sit-ups

• Hang a board the whole day “I came late”

• Monitory fine

• Whatever team decides


Scrum of Scrums (SOS)

48

For large project teams

One person per team attends

Frequency depends on need

Time of meeting depends on need

Pre-requisite:

All teams must be synchronized at a product or portfolio level

A backlog must be maintained

Must use a no name policy, instead use team name

Like daily scrum problem resolution should be done after the meeting


Agenda of SOS

49

What has your team done since last meeting?

What will your team do before next meeting?

Is there any impediment for you?

Will you be creating an impediment for others?


50

Team presents what it accomplished during the sprint

Typically takes the form of a demo of new features or underlying architecture

Informal

2-hour prep time rule

No slides

Whole team participates

Invite the world

Review


51

Periodically take a look at what is and is not working

• Preferable to assign responsibility at the end of retrospective

• Typically 30 minutes to an hour

• Done after every sprint

• Team/customer can participate

Retrospective


Scrum Artifacts

53

Product Backlog

Sprint Backlog

Increment – not that one!

Scrum Artifacts


Product Backlog

The requirements

A list of all desired work on the project

Ideally expressed such that each item has value to the users or customers of the product

Prioritized by the product owner

Reprioritized at the start of each sprint


55

Sprint Backlog

Sprint Backlog is the identified list of items that the team will work on in the current sprint/iteration

Features in the Sprint Backlog will be exploded into User Stories

User Stories will be decomposed to individual tasks


Increment

• A deliverable at the end of an iteration

• Can be called:– Increment

– Release

– Build


XP (Extreme Programming)

58

Roles in XP

12 Practices of XP

XP


Roles in XP

• Customer: • Create and prioritizes stories.

• Can change release date by adding/ removing stories.

• Programmer:• Estimates stories, usually works in pairs, and writes codes and tests.

• Coach:• Is preferred but optional.

• Monitors processes and mentors and helps team.

• Tracker:• Is preferred but optional.

• Monitors progress.

• A programmer can be a tracker in the same or in a different pair.


1. Planning Games

2. Small Releases

3. Metaphor

4. Simple Design

5. Test-driven development

6. Refactoring

7. Pair Programming

8. Collective Ownership

9. Continuous Integration

10. 40-Hours a Week

11. On-Site Customer

12. Coding Standards

60

12 Practices of XP


12 Practices of XP (contd…)

1. Planning games:To elicit requirements + to estimate

2. Small Releases:Begin with smallest useful feature set

3. Metaphor/Product theme:Provides easy to remember naming conventions

4. Simple design:Just enough to get the job done

5. Test-driven development (TDD):Write test before adding feature. If test runs, the job is done

6. Refactoring:Rewrite code to improve internal design


12 Practices of XP (contd…)

7. Pair programming:Work on same computer.

“Driver” writes code and “observer” or “navigator” reviews each line

8. Collective code ownership:Anyone can change anywhere

9. Continuous integration:At least once per day

10.Forty hour work week:Overtime of more than a week is considered as a serious process failure

11.On site customer:Continuous access is available

12.Coding standard:Everyone follows them


Kanban

Kanban Board

64

Feature to

develop Tasks in queueTasks in

progress

Tasks

complete

Feature

complete


• Questions?

Thank you!


67

References

• www.mountaingoatsoftware.com

• http://ketiljensen.files.wordpress.com/2009/10/kanban_board_1.png

• http://en.wikipedia.org/wiki/Agile_software_development

• https://sites.google.com/a/confiz.com/software-engineering/documents/books?pageUrlChanged=books


http://www.mountaingoatsoftware.com/

http://ketiljensen.files.wordpress.com/2009/10/kanban_board_1.png

http://en.wikipedia.org/wiki/Agile_software_development

https://sites.google.com/a/confiz.com/software-engineering/documents/books?pageUrlChanged=books

agile project management (workshop)

Documents

agile approachmajid

agilescrumxpkanbanmajid

crossfunctional majid

regular intervals majid

helpful products majid

scrum team

product users

small number of items