scrum, the agile framework

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!


3

Agile /ˈadʒʌɪl/ adjective Able to move quickly and easily.


4

Agile Ecosystem

Scrum

XP Kanban

DSDM


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/

http://agilemanifesto.org/


6

Agile: Embrace changes

Waterfall: Enforce control

Not a Binary OptionAgile vs Waterfall

1

0


7

“Changing practices is one thing; changing minds is quite another” ― Mike Cohn


8

What is a Car?


9

Le Fardier de Cugnot

source: http://youtube.com/watch?v=KP_oQHYmdRs

http://youtube.com/watch?v=KP_oQHYmdRs


10

Nicolas-Joseph Cugnot

1725-1804


11

A Carpenter and His Son

source: source: http://youtube.com/watch?v=KP_oQHYmdRs



12

Fixed Well Planned Position




13

Continuos Measurement




14

The Agile Craftsman!




15

Templated Drill Hole Tools




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/

http://managedagile.com/whats-really-different-agile-leadership/


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




18

Common Polarized View

Agile is Good

Waterfall is Bad

Agile Servant Leadership is

Good

Command & Control Management is

Bad




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




20

“Project success depends on leadership behaviors, not processes. And successful Agile projects are led, not managed” ― Brian Wernham


21

Steel Ladder vs Simple Wooden Ladder




22

The Bigger Picture




23

“It’s not about code, It’s about business” ― Development That Pays


Build The Right ThingBuild the thing right

24

Picking The Right Wall

(Business Goal)

More Important Than Perfect Ladder

(Code)




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.


LUNCH BREAK



27


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


30

379

MILLIONS24

MONTHS

Development Time

Management Framework

Budget

Attempt #12001

WATERFALL


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.



32

425

MILLIONS36

MONTHS

Development Time


Budget

Attempt #22006

WATERFALL


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.


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.



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.


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.



37

114

MILLIONS36

MONTHS

Development Time


Budget

Attempt #32009

AGILE


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.



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



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)


41

Agile Executives

source: http://www.allaboutagile.com/10-things-agile-executives-need-to-do-differently/

http://www.allaboutagile.com/10-things-agile-executives-need-to-do-differently/


42

Organizational Change

PeopleMindset Tools / Framework

Managers StaffsExecutives


43

Product vs Project

Cost Allocated OwnershipTime Limit

COFFEE BREAK



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.


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


47

Complex Product?

source: http://scrumreferencecard.com/

http://scrumreferencecard.com/


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


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/

https://calvinx.com/2014/05/22/why-scrum-why-agile-development/


50

“Customers know exactly what they want.” ― another statement from the same realm as movies: fiction


51

VS

Waterfall Scrum




52

Iterative & Incremental

source: http://itsadeliverything.com/

http://itsadeliverything.com/


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.


54

Scrum Team

source: https://www.rockstart.com/

https://www.rockstart.com/


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/

https://www.agilealliance.org/wp-content/uploads/2016/01/Self-organizing-teams-Challenges-and-Strategies_0.pdf

Have right people on the team

Led within, not managed

Understand team goals

Communicate and collaborate

continuously

Accountable for their results


57


Scrum Events



58

Common PracticesScrum don’t define agile practices & technique

Scrum XP


59

Forming Storming Norming Performing

High Performance TeamThey don’t shape in a day


60

Quality Scrum Optimize

Flexibility ProductivityCreativity


61

THANK YOU


63

Scrum Team

Scrum Master Development TeamProduct Owner


64

Scrum Team



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.


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.


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.


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.


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.


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.



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.


Milestone 3 Scaling Up make sure our mini Jakarta can host more people and produce more Inventors.


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.


LUNCH BREAK



74


75

Scrum Events




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.


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.


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.


79

Product Backlog vs Sprint Backlog




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?


81

Walking The Board to The Rescue


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.


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.


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.


85

Scrum Artifacts

Sprint Backlog IncrementProduct Backlog


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?


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.


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.


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.


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


91

source: https://confluence.atlassian.com/

Burn-down Chart

https://confluence.atlassian.com/agile/files/391087321/762876973/1/1436759811865/gh_burndown-chart.png


92

Cone of Uncertainty

source: http://www.agilenutshell.com/

http://www.agilenutshell.com/assets/definitions/cone-of-uncertainty.png


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


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.


95

Definition of “Done” Example

source: https://www.scruminc.com/definition-of-done/

https://34slpa7u66f159hfp1fhl9aur1-wpengine.netdna-ssl.com/wp-content/uploads/2014/07/Slide0881.jpg


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.

http://www.allaboutagile.com/definition-of-done-10-point-checklist/

COFFEE BREAK



98

EXAM TIME!


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

http://www.scrumguides.org/

https://www.amazon.com/Scrum-Pocket-Guide-Practice-Publishing-ebook/dp/B00GY6WRTG/ref=sr_1_1?ie=UTF8&qid=1492449430&sr=8-1&keywords=gunther+verheyen

http://www.manajemenmodern.com/

https://www.scrum.org/open-assessments/scrum-open

http://mlapshin.com/index.php/psm-quiz/

http://www.testtakeronline.com/catalog/scrum-org/scrum-master-certification-product.htm

https://www.youtube.com/channel/UCVHTu50vmvVA0OtkGBJlGPw

https://www.meetup.com/AgileIndonesia/


100

THANK YOU

Muhammad Ichsan Rahardianto PMO & Scrum Master | PRINCE2® | PSM™ I

+62817610162 | [email protected] https://www.linkedin.com/in/irahardianto/

@irahardianto

mailto:[email protected]

scrum, the agile framework

Leadership & Management