Overview and step by step guide to Agile Development at Micro, Small & Medium Enterprises Workshop , Chennai - Syed Nazir Razik SCRUM
Overview and step by step guide to Agile Development
at Micro, Small & Medium Enterprises Workshop , Chennai
- Syed Nazir Razik
SCRUM
About :
Managing Partner at Fuente Systems Inc
Co Founder of The Knowledge Foundation and powering up events like PROTO, Barcamp Chennai, Blogcamp , MoMo Chennai, SearchCamp, WikiCamp so on
Serial Entrepreneur and been involved with many organizations like Mecosoft, Numeric Fuente, Kondagan, Fortuna Tech in creating value. Technology Adviser for some organizations like Shamail IT, Fashion Media abroad
NiXi Fellow on Internet Governance creating awareness on issues like Intellectual Property rights. ISOC Chennai Chapter campion on Online Child Safety. PMP – Project management Professional since
2005
CSM – Scrum practitioner since 2007
The Basics of Scrum
4-WeekS print
Potentia lly S hippable Produc t
Produc t Ow nerR eview
S c rumM as ter
The Team
789101112
1234
56
13
No Changes(in Duration or Deliverable)
Commitment
Da ily S c rumM eeting
R etros pec tive
789101112
123456
13
SCRUM – the SCRUM methodology coined by Ken Schwaber at 1996 OOPSLA ( http://jeffsutherland.com/oopsla/schwaber.html )
The Stakeholders of Scrum
4-WeekS print
Potentia lly S hippable Produc t
Produc t Ow nerR eview
S c rumM as ter
The Team
789101112
1234
56
13
No Changes(in Duration or Deliverable)
Commitment
Da ily S c rumM eeting
R etros pec tive
The PRODUCT OWNER – Stakeholder #1
Responsible for the overall project vision and goals Responsible for managing project ROI vs. risk Responsible for taking all inputs into what the team
should produce, and turning it into a prioritized list (the Product Backlog)
Participates actively in Sprint Planning and Sprint Review meetings, and is available to team throughout the Sprint
Determines release plan and communicates it to upper management and the customer
The Team
7 people, + or – 2Has worked with as high as 15, as few as 3Can be shared with other teams (but better when not)Can change between Sprints (but better when they don’t)Can be distributed (but better when colocated)Cross-functionalPossesses all the skills necessary to produce an increment of potentially shippable productTeam takes on tasks based on skills, not just official “role”Self-managingTeam manages itself to achieve the Sprint commitment
The TEAM – Stakeholders # 2
The SCRUM Master – Stakeholder # 3 S c rumM as ter
The Scrum Master does everything in their power to help the team achieve successThis includes:1. Serving the teamThe ScrumMaster takes action to help remove impediments to the team’s effectivenessThe ScrumMaster facilitates the team’s group interactions, to help the team achieve its full potential
2.Protecting the teamThe ScrumMaster protects the team from anything that threatens its effectiveness, such as outside interference or disruptionThe ScrumMaster will need to confront uncomfortable issues, both inside and outside the team
3.Guiding the team’s use of ScrumThe ScrumMaster teaches Scrum to the team and organizationThe ScrumMaster ensures that all standard Scrum rules and practices are followed
What The SCRUM MASTER doesn't do ?
The ScrumMaster does not manage the teamThe ScrumMaster does not direct team-membersThe ScrumMaster does not assign tasksThe ScrumMaster does not “drive the team” to hit its goalsThe ScrumMaster does not make decisions for the teamThe ScrumMaster does not overrule team-membersThe ScrumMaster does not direct product strategy,decide technical issues, etc.
S c rumM as ter
Decide task assignments among the team members and assign them
Provide coaching and mentorship to team-members
Keep track of whether team-members have done the tasks I’ve assigned to them
Surface issues to the team that they might overlook – scaling, performance, security, etc.
Make commitments on behalf of the team about how much they can get done by X date
Provide input on features, functionality, and other aspects of what’s being produced
Give direction to the team on how to do the work, so they can meet the commitment I made
Do performance evaluations and provide feedback to team-members
Convince team that the commitments made on their behalf are attainable
Provide advice and input to the team on difficult technical issues that come up
Monitor the team's progress, to make sure they stay on schedule, and aren't having problems
Plan training for team, and do career-development and planning with team-members
Conduct weekly update and 1:1 meetings with team, to surface issues, and provide direction
Stay abreast of latest developments in the technology their team uses, industry news, etc.
Recruit, interview and hire new members of the team
Plan and oversee budgets and financials, and think about tools, skills and other future needs
Fire team-members who are consistently not able to perform
Help remove impediments that the team is not able or well-placed to resolve themselves
Manager 's New Roles at Agile as SCRUM Master
The Basics of Scrum
4-WeekS print
Potentia lly S hippable Produc t
Produc t Ow nerR eview
S c rumM as ter
The Team
789101112
1234
56
13
No Changes(in Duration or Deliverable)
Commitment
Da ily S c rumM eeting
R etros pec tiveProduct Backlog
Product Backlog
Product Owner lists items in descending order of priority (highest priority item is listed first, next-highest is second, etc.)
Size estimates are rough estimates (can either be arbitrary “points”, or “ideal days”)
List of everything that could ever be of value to the business for the team to produce
Ranked in order of priority Priority is a function of business value versus risk Product Owner can make any changes they
want before the start of a Sprint Planning Meeting
Items added, changed, removed, reordered How much documentation is up to the team
and Product Owner to decide The farther down the list, the bigger and less
defined the items become ~2 Sprints worth are defined in detail
Product Backlog
Sprint Planning Meeting of Scrum
4-WeekS print
Potentia lly S hippable Produc t
Produc t Ow nerR eview
S c rumM as ter
The Team
789101112
1234
56
13
No Changes(in Duration or Deliverable)
Commitment
Da ily S c rumM eeting
R etros pec tiveProduct Backlog
Takes place before the start of every SprintTeam decides how much Product Backlog it will commit to complete by the end of the Sprint, and comes up with a plan and list of tasks for how to achieve itWhat’s a good commitment?
Clearly understood by allShared among the teamAchievable without sacrificing quality Achievable without sacrificing sustainable pace
Attended by Team, Product Owner, ScrumMaster, StakeholdersMay require 1-2 hours for each week of Sprint duration2 week Sprint = 2-4 hours, 4 week Sprint = 4-8 hours
Sprint Planning Meeting of Scrum
Sprint Planning
− Team understands the details of what the ProductOwner has prioritized on the Product Backlog
− Team decides how much productive time it has available during the Sprint
− Team decides howmany Product Backlog items it can commit to complete during the Sprint
SprintPre-Planning
Meeting
SprintPlanningMeeting
Sprint Cycle: 2-Week SprintMon Tues Weds Thurs Fri
1 2 3
6 7 8 9 10
13 14 15 16 17
20 21 22 23 24
27 28 29 30 31
SprintPlanningMeeting
First Dayof Sprint
Last Dayof Sprint
Sprint Review& Retrospective
2 3 41
6 75 8
SprintPlanningMeeting
Sprint Length 2 weeks
Workdays During Sprint
8 days
Team Member Avail Days During Sprint*
Avail Hours Per Day
Total Avail Hrs in Sprint
Tracy 8 4 32 (8 * 4)Sanjay 7 5 35 (7 * 5)Phillip 8 3 24 (8 * 3)Jing 5 5 25 (5 * 5)
Available Time During Sprint
Day of Sprint
Backlog Item
Task Owner Initial Est. 1 2 3 4 5 6
Enable all users to place book in shopping cart
Design business logic Sanjay 4
Design user interface Jing 2
Implement back-end code
Tracy 2
Implement front-end code
Tracy 6
Complete documentation
Joe 8
Unit testing Philip 4
Regression testing Philip 2
Upgrade transaction processing
module
Implement back-end code
Tracy 5
Complete documentation
Joe 6
Unit testing Philip 3
Regression testing Philip 3
Total 214
The Sprint Backlog
Sprint Length -4 weeks is standard in literatureMany teams start with 2 week Sprints
Factors in deciding your Sprint lengthLength of the releaseAmount of uncertaintyHow long priorities can stay unchangedOverhead of Sprint Planning and Review
Team and Product Owner work together to decide Sprint length
Can change during the project
The Sprint
Burndown Chart
The Sprint Review of Scrum
4-WeekS print
Potentia lly S hippable Produc t
Produc t Ow nerR eview
S c rumM as ter
The Team
789101112
1234
56
13
No Changes(in Duration or Deliverable)
Commitment
Da ily S c rumM eeting
R etros pec tive
Purpose of the Sprint Review isDemo what the team has builtGenerate feedback, which the Product Owner can incorporate in the Product BacklogAttended by Team, Product Owner, ScrumMaster, functional managers, and any other stakeholdersA demo of what’s been built, not a presentation about what’s been builtno Powerpoints allowed!Usually lasts 1-2 hoursFollowed by Sprint Retrospective
The Sprint Review of Scrum
The Sprint Retrospective
4-WeekS print
Potentia lly S hippable Produc t
Produc t Ow nerR eview
S c rumM as ter
The Team
789101112
1234
56
13
No Changes(in Duration or Deliverable)
Commitment
Da ily S c rumM eeting
R etros pec tive
What is it?1-2 hour meeting following each Sprint Demo
Attended by Product Owner, Team, Scrum MasterUsually a neutral person will be invited in to facilitateWhat’s working and what could work betterWhy does the Retrospective matter?
Accelerates visibilityAccelerates action to improve
The Sprint Retrospective
2 Common Approaches:
S P R I N TS P R I N T S P R I N T S P R I N T S P R I N T S P R I N T
RELEASEMulti-Sprint Release
S P R I N T S P R I N T S P R I N T S P R I N T S P R I N T S P R I N T
RELEASE RELEASE RELEASE RELEASE RELEASE RELEASE
Release Every Sprint
Scrum Release Cycle
Scrum Disadvantages
It’s hard! Makes all dysfunction visible
− Scrum doesn’t fix anything: the team has to do it− Feels like things are worse at the beginning
Bad products will be delivered sooner, and doomed projects will fail faster
High risk of turnover− Some people will refuse to stay on a Scrum team− Some people will refuse to stay if Scrum is abandoned
Partial adoption may be worse than none at all If adoption fails, time will have been wasted, and
some people may leave
SCRUM – Fuente Flavour
Source : http://wordpress.fuentesystems.com/?p=21http://www.scrumalliance.org/resources
[email protected]+919884208327Search “ Syed Nazir Razik “