Slide 1

Slide 1 text

the sprints Lemİ Orhan ERGİN Principal Software Engineer @ Sony @lemiorhan Review EFFICIENTLY how to agilistanbul.com

Slide 2

Slide 2 text

Lemİ Orhan Ergİn Principal Software Engineer in Sony has worked in Tüsside, BYM, GittiGidiyor/eBay and Sony as lead developer, team leader, technical coordinator and scrum master got CSM certificate from Jim Coplien year as Scrum Master sprints in 4 years as team member and scrum master experienced in agile transformation and building agile culture in teams & organizations 2001 2013 2009 1 56 agile CSM, PSM1

Slide 3

Slide 3 text

The meaning in agile how it should be held recommendations

Slide 4

Slide 4 text

So let’s check out why we prefer agile development Sotware is the product we aim to develop. for building our product

Slide 5

Slide 5 text

? Agile = ıncremental + Iterative Agile development is a group of methods based on incremental and iterative development

Slide 6

Slide 6 text

A Big Bang approach is neither iterative or incremental. Architectural components are built to full fidelity, for the full scope, and are fully integrated once at the end. bing bang Data and images are originally from “Fidelity – The Lost Dimension of the Iron Triangle” article by Karl Scotland http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/

Slide 7

Slide 7 text

The purely incremental approach builds each feature, across all components, to full fidelity, one by one. Incremental Data and images are originally from “Fidelity – The Lost Dimension of the Iron Triangle” article by Karl Scotland http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/

Slide 8

Slide 8 text

The purely iterative approach builds all the features, across all components, to the lowest fidelity, and then increases the fidelity to the highest level. ıterative Data and images are originally from “Fidelity – The Lost Dimension of the Iron Triangle” article by Karl Scotland http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/

Slide 9

Slide 9 text

An Agile approach combines the incremental and iterative approach by building each feature, one by one, at a low fidelity, and then both gradually adding features andincreasing their fidelity until the right combination is achieved. Full fidelity is not always necessary. agile Data and images are originally from “Fidelity – The Lost Dimension of the Iron Triangle” article by Karl Scotland http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/

Slide 10

Slide 10 text

design, implementation and infrastructure evolving The aim of agile development is

Slide 11

Slide 11 text

Review Meetings are organized to review the status of evolution of the product with stakeholders and customers and direct the focus on business value controlled evolution

Slide 12

Slide 12 text

Show the customers and stakeholders the work they have accomplished over the sprint reasons to conduct Inspect the sprint and adapt the product backlog for the next sprint Gather feedback and foster collaboration

Slide 13

Slide 13 text

The meaning in agile how it should be held recommendations

Slide 14

Slide 14 text

At the end of each iteration timings Timeboxed 4 hours for a 1 month iteration

Slide 15

Slide 15 text

No internet through cellphones or laptops meeting guidelines Mails should only be checked on breaks Only urgent calls are allowed common rules

Slide 16

Slide 16 text

Timing/agenda should be written on white board Agenda, timings and meeting rules should be mentioned at the beginning of the meeting Strictly give breaks and obey the timings meeting guidelines agenda, Breaks & Rules

Slide 17

Slide 17 text

Product Owner facilitates the meeting, but it not uncommon to have team members run the meeting The whole team and stakeholders attend PEOPLE the attendees The format and the rules should be explained to the ones who has no experience

Slide 18

Slide 18 text

Product Owner is the one who says ship it and gives "done!" decision Product Owner is not a customer representative PEOPLE Product Owner Product Owner identifies done and not-done items, discusses backlog and deadlines

Slide 19

Slide 19 text

No slides are allowed. Working software is reviewed The team should be prepared for the review in advance PEOPLE Development team All team members should participate in the review

Slide 20

Slide 20 text

Definition of Done should be defined and agreed by the team in advance Acceptance criteria should be defined for each story in the planning meeting Agreements that the review will be based on Let’s jump to these topics for few minutes

Slide 21

Slide 21 text

acceptance criteria

Slide 22

Slide 22 text

Acceptance criteria define the boundaries of a user story, and are used to confirm when the software is working as intended, which means the story is completed Acceptance criteria what is it? The criteria defined by Product Owner to assess completed stories. It is also be called “Conditions of Satisfaction”

Slide 23

Slide 23 text

Acceptance criteria Features of a good acceptance criteria Usability Funcitonality error handling Performance Stress tests Include measures of usability Identify specific user tasks, business processes or functions that must be in place at the end of the project Enumerate error cases and how each should be handled Test system performance from the perspective of an individual user Acceptable threasholds should be defined for stress testing

Slide 24

Slide 24 text

Acceptance criteria Example of a Good acceptance criteria As a customer, I want to order and pay for the book via a secure web-based form, so that my credit card information is safe. Description: ✴All mandatory fields must be completed before a customer can submit a form. ✴Information from the form is stored in the customer orders database. ✴Payment can be made via Amex, Master Card, or Visa credit card. ✴The system shall accurately calculate and apply sales tax. ✴The system shall accurately calculate and apply shipping charges. ✴The customer shall be able to verify the accuracy of the order. ✴An acknowledgment email is sent to the customer submitting the form. ✴Protection against spam is working. ✴The code should be deployed and running in Staging environment acceptance criteria:

Slide 25

Slide 25 text

definition of done

Slide 26

Slide 26 text

Focuses of value added steps Items should add verifiable/demonstrable value to the product Explains in what conditions a PBI is described as "done" It is used for assessing the work when it is completed It guides the team in knowing how many PBIs can be selected definition of done what is it? DoD is a checklist of valuable activities required to produce software

Slide 27

Slide 27 text

The team should decide the items in the DoD list DoD is not static, it changes over time DoD should be reviewed in retrospectives definition of done DoD is the primary reporting mechanism for team members How Related with The team?

Slide 28

Slide 28 text

DoD for a task DoD for a feature/story DoD for a iteration/sprint DoD for a release definition of done DoD is informed by the reality What kind of DOD we can have?

Slide 29

Slide 29 text

? Code is readable, it documents itself JavaDoc and inline comments are entered Code is refactored Code obeys clean code principles Code obeys naming conventions and indentation rules definition of done Not a good idea, since DOD items should be verifiable/demonstrable Clean Code Principles as DOD? Clean Code Principles are already a must

Slide 30

Slide 30 text

definition of done What can be the Dod entries? DOD for Tasks DOD for stories DOD for Sprints DOD for releases Unit tests are written CI default builds are green Integration/acceptance tests are written Design/analysis documents are written No critical bugs Code is reviewed by peers Demo scenarios are created All CI builds are green No major & critical bugs Code coverage calculated SIT is done Performance/load tests are completed Release notes are prepared Cutover plan is prepared UAT is done As the team mature, the DoD could expand for higher quality Fits to acceptance criteria

Slide 31

Slide 31 text

For reviewing the points having business value with customers and stakeholders For reviewing the points directly related with the technical improvements, refactoring, quality metrics with the team must-haves should-haves two sections split the review into

Slide 32

Slide 32 text

must-haves section of the review meeting Focuses on stories having business value Audience does not expect to have too much technical detail Acceptance criteria should pass The product should be potentially shippable

Slide 33

Slide 33 text

must-haves section of the review meeting Technical Dept (If it’s worth mentioning to stakeholders) Features/Stories with Demo (The ones the team commited to delivering) Major/Critical bugs (Could change according to DoD) Key Decisions (Could be technical, market driven, requirements and made by anyone else)

Slide 34

Slide 34 text

section of the review meeting No need to have stakeholders in the meeting Technical details could be reviewed Focuses quality of implementation and support should-haves

Slide 35

Slide 35 text

section of the review meeting should-haves Success Rates of Continuous Integration Builds Support Cases Available Bugs Test/Code Coverage Release Notes Change Log

Slide 36

Slide 36 text

All attendees collaborate on what to do next Use retrospective to improve the efficiency of review meetings All missing points should be noted to add to next iterations as new tasks or stories Finalizing the meeting

Slide 37

Slide 37 text

The meaning in agile how it should be held recommendations

Slide 38

Slide 38 text

The development teams has to be prepared in advance to the meeting. At most 1 hour preparation per sprint should be enough for the team. Problem Demo/Review is too slow. Development team spends too much time for preparing the demo. recommendation

Slide 39

Slide 39 text

Doing a simulation of the review for complex stories before the meeting will make the team be sure about the software. Problem Software is not working in the demo even though it was working before the meeting recommendation

Slide 40

Slide 40 text

Focus on reviewing what has done and do not go off the road Pre-reviews by product owner should be done by the team Team should be prepared for the review Allowing too many external audience might cause to exceed the timebox Problem Meeting exceeds timebox recommendation Let’s jump to pre-review topic for few minutes

Slide 41

Slide 41 text

Pre-review with the Product Owner

Slide 42

Slide 42 text

Whenever a story is completed (or almost completed), ask PO to spend few minutes to review all the details Pre-review with PO It is safer to review with PO before the review meeting to notice missing points and misunderstandings in advance What is it about? That increases success rates of developments, and as a side effect, the efficiency of review meetings is improved.

Slide 43

Slide 43 text

Problem Too much technical discussions recommendation DoD should cover quality standards Technical details should be clarified in the sprint before the meeting

Slide 44

Slide 44 text

Problem Some people are talking, the others are sleeping recommendation Everyone should participate in the meeting, no excuse

Slide 45

Slide 45 text

Problem People are not following the meeting, just surfing and chatting recommendation Internet should be closed in cellphones and laptops Mails should be checked on breaks Only urgent calls are allowed These rules should be mentioned in the beginning of the meeting

Slide 46

Slide 46 text

Problem The team is cheating on what is done and not done recommendation Trust is a must Everything should be transparent, including the failures No blaming, no finger-pointing..

Slide 47

Slide 47 text

Problem Chaos in the meeting recommendation Show agenda to the team and the progress of the meeting Remind the rules of review meetings to the team

Slide 48

Slide 48 text

Problem Too much negotiation with the Product Owner about accepting the stories recommendation Acceptance criteria should be defined in advance DoD should be checked by team in advance All parties should be positive and objective

Slide 49

Slide 49 text

Problem The team gives status reports to Product Owner recommendation It is not a status report of individual team members It is not a "what I did in the last sprint" discussion It is not a status meeting

Slide 50

Slide 50 text

Problem Stakeholders are bored recommendation Focus on the demo and avoid going into too much detail Separate the meeting into two sections

Slide 51

Slide 51 text

Problem Product Owner changed its mind about the predefined acceptance criteria during the review recommendation Too late for any change, stories are reviewed by the agreed acceptance criteria Product Owner adds new items to the next sprint if required

Slide 52

Slide 52 text

Photos used in the slidES http://www.flickr.com/photos/therahim/5587920310 http://www.flickr.com/photos/mesfoto/4245156422 http://www.flickr.com/photos/keysring/3493912575 http://www.flickr.com/photos/bealluc/158962685 http://www.flickr.com/photos/unclefuz/4506302304 http://i48.tinypic.com/2saghhs.jpg References Definition of Done: http://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-(dod) http://www.agilistanbul.com/2012/12/definition-of-done-nin-gucu.html Big Bang, Iterative, Incremental, Agile: http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/ Acceptance Criteria: http://wiki.servicenow.com/index.php?title=Well-Written_Scrum_Stories#Story_Acceptance_Criteria

Slide 53

Slide 53 text

Lemİ orhan ergİn [email protected] @lemiorhan @lemiorhan agilistanbul.com @lemiorhan LINKEDIN TWITTER SLIDESHARE BLOG Principal Software Engineer @ Sony Founder & Author @ agilistanbul.com flyingtomoon.com