Agile Project Management (Workshop)

Agile Training Workshop
Majid Rafiq, PMI-ACP | Associate Project Manager

2
Workshop Agenda
• What is Agile
• Scrum
• XP
• Kanban
Majid Rafiq, PMI-ACP | Agile Training Workshop

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 Voting
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

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

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

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 Board
64
Feature to
develop Tasks in queue
Tasks 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

Agile Project Management (Workshop)

More Related Content

What's hot

Viewers also liked

Similar to Agile Project Management (Workshop)

Agile Project Management (Workshop)