Download - Scrum, The Agile Framework
SCRUM
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
2
M. ICHSAN RAHARDIANTO
PMO & Scrum Master | PRINCE2® | PSM™ I
Ichsan is a passionate person, he has strong technical background and a wide range of experience in Information Technology field. He is a software architect as well as an engineer, he has been leading teams and help them to produce great products.
He is a PRINCE2® Certified Project Management Professional and a Professional Scrum Master™ I (PSM™ I) Certified Scrum Master. He has worked extensively on Software Development Life Cycle (SDLC) and Agile Methodologies.
Hi Everyone, lets learn Scrum & Agile
Hi!
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
3
Agile /ˈadʒʌɪl/ adjective Able to move quickly and easily.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
4
Agile Ecosystem
Scrum
XP Kanban
DSDM
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
5
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we
have come to value:
Agile Manifesto
Individuals and interactions over processes and tools Working software over comprehensive documentation
Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
source: http://agilemanifesto.org/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
6
Agile: Embrace changes
Waterfall: Enforce control
Not a Binary OptionAgile vs Waterfall
1
0
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
7
“Changing practices is one thing; changing minds is quite another” ― Mike Cohn
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
8
What is a Car?
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
9
Le Fardier de Cugnot
source: http://youtube.com/watch?v=KP_oQHYmdRs
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
10
Nicolas-Joseph Cugnot
1725-1804
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
11
A Carpenter and His Son
source: source: http://youtube.com/watch?v=KP_oQHYmdRs
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
12
Fixed Well Planned Position
source: source: http://youtube.com/watch?v=KP_oQHYmdRs
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
13
Continuos Measurement
source: source: http://youtube.com/watch?v=KP_oQHYmdRs
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
14
The Agile Craftsman!
source: source: http://youtube.com/watch?v=KP_oQHYmdRs
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
15
Templated Drill Hole Tools
source: source: http://youtube.com/watch?v=KP_oQHYmdRs
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
16
Leadership Style
Nature of Problem
Management Objective
Problem- solving
Approach
Leadership Style
A good leader doesn’t have one well-defined style of leadership that he/she force-fits all situations to. • The management objective shapes the problem solving approach • The problem-solving approach determines the leadership style that may be most appropriate
source: http://managedagile.com/whats-really-different-agile-leadership/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
17
Problem-solving Approach
Empirical process control approach, means “based on observation” that both the definition of the solution as
well as the process to discover the solution will
evolve based on observation throughout the project.
Problem-solving Approach
The solution to the problem is generally well-defined in advance and the general
approach for implementing the solution is also fairly
well-defined.
Leadership Approach To encourage creativity and
innovation, you don’t want to emphasize control, you want to empower people and give them some flexibility to use their own intelligence and
judgement.
Management Objective Arriving at an effective
solution is far more important in this kind of
project than predictability. Therefore, innovation and
creativity would generally be emphasized more than
control.
Management Objective If predictability is important, having a well-defined plan and conformance to that plan are also important.
Leadership Approach That calls for a style of
leadership that naturally might be a bit more directive in order to remain on track
with the project plan.
Agile Leadership vs Traditional
source: http://managedagile.com/whats-really-different-agile-leadership/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
18
Common Polarized View
Agile is Good
Waterfall is Bad
Agile Servant Leadership is
Good
Command & Control Management is
Bad
source: http://managedagile.com/whats-really-different-agile-leadership/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
19
Effective Leader Adjust!An effective leader should be able to adjust his/her leadership style and problem-solving approach as necessary to fit any
given situation.
CREATIVE
ADVANTAGESSTYLE
There is not just one leadership style that fits all situations
Creative
Agile leadership is not really a radically different style of leadership that is totally
separate and mutually-exclusive with other leadership styles; however, it significantly
expands our definition of what “leadership” is.
Style
Leadership styles are not necessarily good or bad saying a particular leadership style is good or bad is like saying “a car is better than a boat”. Each has advantages and disadvantages depending on the environment you’re in.
Advantages
source: http://managedagile.com/whats-really-different-agile-leadership/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
20
“Project success depends on leadership behaviors, not processes. And successful Agile projects are led, not managed” ― Brian Wernham
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
21
Steel Ladder vs Simple Wooden Ladder
source: source: http://youtube.com/watch?v=KP_oQHYmdRs
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
22
The Bigger Picture
source: source: http://youtube.com/watch?v=KP_oQHYmdRs
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
23
“It’s not about code, It’s about business” ― Development That Pays
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
Build The Right ThingBuild the thing right
24
Picking The Right Wall
(Business Goal)
More Important Than Perfect Ladder
(Code)
source: http://managedagile.com/whats-really-different-agile-leadership/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
25
Lets Play Ball!
3 Minutes of planning to distribute the ball from one bucket to another.Planning
Sprint
Review
Retrospect
5 Minutes of exciting playing games, catching up with the time limit, distributing from one bucket to another.
5 Minutes of measuring your great effort doing the exercise, and get you ready for the next iteration.
7 Minutes of team self introspection, what went good or bad, and how to improve.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
LUNCH BREAK
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
27
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
28
Ad-hoc processes to share documents, photos, and other electronic media. The handling of the Oklahoma City Bombing case highlighted the deficiencies of the FBI's old technology and business procedures.
A week before scheduled date of the of the Oklahoma City bomber FBI revealed that it had not disclosed over 700 documents to the defense attorneys. The FBI had simply forgotten to send materials and in many cases had lost evidence.
The legal process was thrown into turmoil, a stay of execution of the bomber was granted. An independent investigation showed that the combination of the old computer system and manual processes were to blame.
FBI Sentinel Project
29
2001FBI came under severe criticism
after several legal processes went to turmoil. Investigation shown
the root of the problem was combination of old computer
system and manual processes. Virtual Case File system (VCF)VCF project was introduced to overcome the problem, it was a massive waterfall contract of $379m. Grand design being drawn up before work would start on the development. Testing would be carried out at the end, and the whole system would go live at once
FBI Sentinel Project
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
30
379
MILLIONS24
MONTHS
Development Time
Management Framework
Budget
Attempt #12001
WATERFALL
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project
31
9/11Growing pressure to release the project faster. Additional $78m
investment was forked to speed up delivery by 6 months with
expected deployment at December 2002. Mid 2002
The classic symptoms of waterfall project failure started to reveal themselves. Project plans were found to be unrealistic, and the oversight of project spend was inadequate.Post 2002
Work continued, and each year the deadline was put back by
another 12 months. Every year a new project executive was
appointed
Project CancelledIn 2005 Project was finally canceled.
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
32
425
MILLIONS36
MONTHS
Development Time
Management Framework
Budget
Attempt #22006
WATERFALL
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project
33
SentinelPursued the line of thought that if
more detail had been planned upfront, with a more strict set of waterfall processes, then failure
would not have occurred.
2006Lockheed Martin was appointed to take Sentinel project to be completed by 2009, With total $425m budget this time, over $120m was allocated for the FBI to oversight the work.Problem Arise
Phase one was a failure, 2 months late, 57 critical features not
delivered, the system is practically unusable. Despite this Lockheed
Martin still getting paid 100% for the phase one. Along with it, the
Audit reports somehow continued to be optimistic.
Dec 2008Chad Fulgham was appointed as the new CIO. He now planned for outputs every 3-6 months. He sees that it is very risky if phase two was to be delivered next year.
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project
34
Phase Two SlippedThe planned end-date of phase
two slipped, the cost increased by $18m. Then the new system
needed faster network, that is another $39m need to be forked.
Inexperience PMThe $120m budget was spent on inexperience PM with general administrative backgrounds that has no background of technology development. Their reports are detailed and full of statistics, but never report a problem even when the project was out of control.
Dec 2009As late as December 2009 the
FBI was still “expecting to provide capabilities to users sooner than originally planned”. However, the
more difficult tasks were left to the end. Important tasks such as
the migration processes, were left until the final segment. Migration was known to be a key problem.
and when delivered in 2010, they were still not adequate.
Phase Two StoppedOn March 3 FBI decide to reject all deliverables of final segment of phase two. Lockheed Martin was ordered to stopped the development until the problem resolved. By July 2010 FBI issued complete stop-work order.
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
35
An independent report estimated that completing Sentinel under the current development approach would cost at least an additional $351m on top of the $405m already spent, and take another six years.
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project
36
Agile To The RescueIn September 2010 FBI announce
that it would take direct management of the development
of Sentinel using Agile project approach. Trimming The Unnecessary
The existing requirements were analyzed, prioritized, and sequenced to focus on the most valuable requirements. The team also reduced from 125 to a team of 55. The original, monolithic requirements document was modularized into 670 separate user stories. The team prioritized each user story in a product backlog.
Scrum Framework21 sprints were planned to
develop all the user stories. The 10-day sprints kept the danger of uncontrolled changes to what the
FBI called “just 9 days of risk”. Previously, arguments over
change control and scope creep took up much more time and
effort than that. At the end of every sprint, all testing had to be
complete. The software had to be demonstrated to project
stakeholders.
ThrivingBy the end of 2011, only 52% of the $32.6m budget had been spent to build 88% of the system.
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
37
114
MILLIONS36
MONTHS
Development Time
Management Framework
Budget
Attempt #32009
AGILE
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project
38
June 2012revised technical targets had
been met, and two releases had been achieved. Agents were now
using the system on real cases. 13,268 agents created 623
documents and made 92,546 searches in the first quarter 2012.
Operational Capability was achieved in May 2012.
2013Final user of ACS logs off.
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
39
9 Agile Leadership Behavior Takeaway
Harness changeSatisfy the customer Be incremental
Create trust through leadership and process : ‘Light-Tight’ discipline
Encourage face to face conversation
Get business & tech guy together
Set targets and reward real progress towards a working solution
Pursue simplicity not complexity
Give the team the space they need to excel
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
40
“Agile is not just a method or a process, it’s a way of being. You don’t do Agile. You are Agile. The FBI has arranged to loan their Scrum Master to other teams to get them trained. Increased transparency has kept stakeholders in sync. Further, stakeholders would modify their expectations, based on the increased visibility of the process.” ― Jack Israel (Former VCF CTO)
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
41
Agile Executives
source: http://www.allaboutagile.com/10-things-agile-executives-need-to-do-differently/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
42
Organizational Change
PeopleMindset Tools / Framework
Managers StaffsExecutives
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
43
Product vs Project
Cost Allocated OwnershipTime Limit
COFFEE BREAK
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
45
Scrum /skrʌm/ noun A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
46
Scrum
Complex ProductScrum is used for developing and sustaining complex
products.
3 PillarsAdaptation, transparency, inspection uphold empirical
process control.
Scrum ElementsScrum consist of Scrum team and their associated roles,
events, artifacts, and rules.
FrameworkScrum is an Agile framework, its not a methodology.
EmpiricismScrum is founded on empiricism that asserts knowledge
comes from what is know.
Iterative & IncrementalThrough iterative and incremental approach, Scrum optimize
predictability and control risk.
Scrum ValueCommitment, courage, focus, openness and respect are
embodied and lived by the Scrum Team
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
47
Complex Product?
source: http://scrumreferencecard.com/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
48
3 PillarsTransparency, inspection, and adaptation.
Scrum Valuecommitment, courage, focus, openness and respect.
EmpiricismAsserts that knowledge comes from experience and making decisions based on what is known.
Scrum ValueSuccessful use of Scrum depends on people becoming more proficient in living these five values. When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.
EmpiricismThe key value that uphold empiricism
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
49
Long product development cycles, and a mismatch between a product’s business requirement and the actual resulting implementation have been the classic problem found in almost every software development. From the multi-billion FBI Sentinel project to simple web application, face the very same problem.
This illustration explains such mismatched expectations, and the consequence of long development cycles. For anyone who has been working in the software development industry for a while, you would probably have gone through the hell of the typical waterfall development approach. With an outcome where everyone in the team is demoralized and where you end up with a bunch less-than-happy customers – an unfortunate, dysfunctional outcome.
Shorter development cycles (called “sprints”) of 2 to 4 weeks and daily team meetings known as “scrums” allow the product team, the product owner and the customers/stakeholders to regularly review the incremental improvements made by the team in each sprint. This narrows the expectations gap significantly and the increased communication level between the product team and the stakeholders reinforces a shared vision for each product increment made.
Why Scrum?Why Agile Development?
source: https://calvinx.com/2014/05/22/why-scrum-why-agile-development/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
50
“Customers know exactly what they want.” ― another statement from the same realm as movies: fiction
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
51
VS
Waterfall Scrum
source: http://scrumreferencecard.com/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
52
Iterative & Incremental
source: http://itsadeliverything.com/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
53
Roles
The roles of associated Scrum Team members.
Events
Event in Scrum is a formal opportunity to
inspect and adapt something.
Artifacts
Product backlog, Increment, Sprint
backlog.
Scrum Team
Product owner, Scrum master, Development
team
Scrum ElementsScrum consist of these five elements
Rules
The rules of Scrum binds together the events, roles, and
artifacts.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
54
Scrum Team
source: https://www.rockstart.com/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
55
Faster actions and decisions – However capable and experienced the team leader, soon he becomes a bottleneck in speedy decisions & actions. This is especially true where the team members themselves are expected to take on the spot actions or decisions since they are best aware of the current situation.
Individual and team development – Self-organization takes away the protective umbrella provided by the team leader and forces the individuals and the team to take greater responsibility and ownership of their work. In such an environment, team members understand which skills & knowledge they need to acquire and go about on their own doing so. They also benefit from the support provided by their peers. I have seen both the members as well as the teams rapidly mature by facing the challenges, sort of baptism by fire.
Redistribution of work between leader and the team – In a command & control culture, a typical team leader spends most of his time planning & tracking the work of his sub-ordinates. As a result, he is left with very little time & attention to devote to the long term needs of the team and its members. As the team becomes more & more self-organized, plenty of planning & tracking tasks are taken up by the team. As a result, the team leader now has lot more time on his hand to engage in activities which do justice to his experience exposure and maturity.
Self-OrganizationSelf-organizing teams choose how best to accomplish their work
Use of full human potential – People have lot of potential of which only a fraction normally gets used in a command and control culture. When a team is self-organized, there are lot more opportunities to explore hidden or unused talents of its members.
source: https://www.agilealliance.org/
Have right people on the team
Led within, not managed
Understand team goals
Communicate and collaborate
continuously
Accountable for their results
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
57
source: https://www.rockstart.com/
Scrum Events
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
58
Common PracticesScrum don’t define agile practices & technique
Scrum XP
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
59
Forming Storming Norming Performing
High Performance TeamThey don’t shape in a day
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
60
Quality Scrum Optimize
Flexibility ProductivityCreativity
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
61
THANK YOU
SCRUM
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
63
Scrum Team
Scrum Master Development TeamProduct Owner
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
64
Scrum Team
source: https://www.rockstart.com/
65
Product OwnerThe one person driving the product
Clearly expressing Product Backlog items,
Ordering the items in the Product Backlog to best achieve goals and missions.
Optimizing the value of the work the Development Team performs.
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
Product Owner is a person responsible for maximizing the value of the product and the
work of the development team (Product Backlog and
determination of priorities).
Ensuring the Development Team understands items in the Product Backlog to the level needed.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
66
Development TeamWhere done product is produced
Consist of 3 – 9 members.
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.
Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment.
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person.
Development team consist of professionals who do the work
for delivering potentially releasable Increment of “Done”
product at the end of each Sprint. Self-organizing, cross-
functional.
Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis.
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
67
Scrum MasterThe servant leader leading the pact
The Scrum Master is a servant-leader for the Scrum Team.
Ensuring the Scrum is understood and enacted.
Ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
Helps people outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t, to maximize the value created by the Scrum Team.
Scrum Master is a person ensuring that Scrum is
understood and enacted. Sets up meetings and monitors
everything.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
68
Scrum Master to Product Owner
Finding techniques for effective Product Backlog management.
Helping the Scrum Team understand the need for clear and concise Product Backlog items.
Understanding product planning in an empirical environment.
Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.
Understanding and practicing agility.
Facilitating Scrum events as requested or needed.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
69
Scrum Master to Development Team
Coaching the Development Team in self-organization and cross-functionality.
Helping the Development Team to create high-value products.
Removing impediments to the Development Team’s progress.
Facilitating Scrum events as requested or needed.
Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
70
Scrum Master to Development Team
Leading and coaching the organization in its Scrum adoption.
Planning Scrum implementations within the organization.
Helping employees and stakeholders understand and enact Scrum and empirical product development.
Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
71
Jakarta Tech CityWhere creative people build their dreams
Tech City where developers live, shape mini Jakarta to be the dream city for smart people.
Vision
Population
Milestone 1
Milestone 2
3 Type of Population Inventor, Investor, Common Residence
Minimal Infrastructure for the Inventors to work and meet the Investor.
Higher Quality of Service provide more comfort for work and leisure.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
Milestone 3 Scaling Up make sure our mini Jakarta can host more people and produce more Inventors.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
72
Lets Play Lego!Iterate and build the city
3 Minutes of planning what to build and how to build your city.Planning
Sprint
Review
Retrospect
7 Minutes of exciting playing games, catching up with the time limit, construct your city, make it happen.
5 Minutes of measuring your great effort doing the exercise, and get you ready for the next iteration.
5 Minutes of team self introspection, what went good or bad, and how to improve.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
LUNCH BREAK
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
74
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
75
Scrum Events
source: https://www.rockstart.com/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
76
All events are time-boxed events, such that every event has a maximum duration.
Sprint duration is fixed and cannot be shortened or lengthened.
There are Sprint Planning, Daily Scrum, Sprint Review, Spring Retrospective, and Product Backlog Refinement.
Scrum Events
Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt.
Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
77
Each Sprint may be considered a project with no more than a one-month horizon.
Sprint results “Done”, useable, and potentially releasable product Increment.
Sprints best have consistent durations throughout a development effort.
Sprints
A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
Quality goals do not decrease, No changes are made that would endanger the Sprint Goal.
Scope may be clarified and re-negotiated between the Product Owner and Development.
A Sprint can be cancelled before the Sprint time-box is over. Only by the Product Owner.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
78
The work to be performed in the Sprint is planned at the Sprint Planning.
This plan is created by the collaborative work of the entire Scrum Team.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
Sprint Planning
What can be delivered in the Increment resulting from the upcoming Sprint?
How will the work needed to deliver the Increment be achieved?
This is where Sprint Goal is crafted. The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
79
Product Backlog vs Sprint Backlog
source: http://scrumreferencecard.com/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
80
15-minute time-boxed event for the Development Team to inspect and adapt.
Development team answers 3 questions for themselves :
What did I do yesterday that helped the Development Team meet the Sprint Goal?
Daily Scrum
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me from meeting the Sprint Goal?
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
81
Walking The Board to The Rescue
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
82
Four-hour time-boxed meeting for one-month Sprints.
Attendees include the Scrum Team and key stakeholders invited by the Product Owner.
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint, attendees collaborate on the next things that could be done to optimize value.
Sprint Review
Development Team demonstrates the work that it has “Done” and answers about the Increment.
The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed).
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.
Informal meeting, not a status meeting, intended to elicit feedback and foster collaboration.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
83
Three-hour time-boxed meeting for one-month Sprints.
Opportunity for the Scrum Team to inspect itself and create a plan for improvements.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
Sprint Retrospective
Inspect how the last Sprint went with regards to people, relationships, process, and tools.
Identify and order the major items that went well and potential improvements.
Create a plan for implementing improvements to the way the Scrum Team does its work.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
84
Informal event that covers the refinement of the product backlog.
Scrum Team decides how and when refinement is done.
Refinement usually consumes no more than 10% of the capacity of the Development Team.
Product Backlog Refinement
Increase visibility of product backlog that were likely to make it into the next sprint.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
85
Scrum Artifacts
Sprint Backlog IncrementProduct Backlog
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
86
Scrum’s artifacts represent work or value.
Provide transparency and opportunities for inspection and adaptation.
Maximize transparency of key information so that everybody has the same understanding of the artifact.
Artifacts?
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
87
The single source of requirements for any changes to be made to the product.
The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes.
Product Backlog
Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Higher ordered Product Backlog items are usually clearer, more detailed, more precise estimates and more likely to be included in the next Sprint than lower ordered ones.
The Development Team is responsible for all estimates.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
88
At any point in time, the total work remaining to reach a goal can be summed.
The Product Owner tracks this total work remaining at least every Sprint Review.
The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal.
Monitoring Progress Toward A Goal
This information is made transparent to all stakeholders.
Various projective practices upon trending have been used to forecast progress, like burndowns, burn-ups, or cumulative flows. These have proven useful.
However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
89
Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product.
Is a forecast by the Development Team about what functionality will next Sprint results and the work needed to deliver that functionality into a “Done” Increment.
The Development Team modifies the Sprint Backlog throughout the Sprint.
This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
Belongs solely to the Development Team.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
90
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed.
The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal.
By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.
Monitoring Sprint Progress
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
91
source: https://confluence.atlassian.com/
Burn-down Chart
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
92
Cone of Uncertainty
source: http://www.agilenutshell.com/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
93
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.
New Increment must meet the Scrum Team’s definition of “Done”.
Must be in useable condition regardless of whether the Product Owner decides to actually release it.
Increment
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
94
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means.
Scrum Team must have a shared understanding of what it means for work to be “Done”.
Guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning.
Definition of “Done”
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
95
Definition of “Done” Example
source: https://www.scruminc.com/definition-of-done/
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
96
Some More Example of DoD
source: http://www.allaboutagile.com/definition-of-done-10-point-checklist/
Code commented, checked in and run against current version in source control.
Peer reviewed (or produced with pair programming) and meeting development standards.
Builds without errors.
Unit tests written and passing.
Deployed to system test environment and passed system tests.
Passed UAT (User Acceptance Testing) and signed off as meeting requirements.
Any build/deployment/configuration changes implemented/documented/communicated.
Relevant documentation/diagrams produced and/or updated.
Code produced (all ‘to do’ items in code completed).
Remaining hours for task set to zero and task closed.
COFFEE BREAK
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
98
EXAM TIME!
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
99
Recommended Books & Other Resources
The Scrum Guide - Jeff Sutherland & Ken SchwaberScrum – A Pocket Guide - Gunther Verheyen
Manajemen Modern dengan Scrum - Joshua Partogi
Scrum.org Open Assessmentmlapshin PSM I Quiz
testtakeronline PSM I Study Guide
Development That Pays (YouTube Channel) - Gary Straughan
Agile Indonesia Meetup Community
Muhammad Ichsan Rahardianto © 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
100
THANK YOU
Muhammad Ichsan Rahardianto PMO & Scrum Master | PRINCE2® | PSM™ I
+62817610162 | [email protected] https://www.linkedin.com/in/irahardianto/
@irahardianto