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)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (18)

Ähnlich wie Agile Project Management (Workshop)

Ähnlich wie Agile Project Management (Workshop) (20)

Agile Project Management (Workshop)