Agile Training March 2015

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |

Dev/QA/PMAgile (Scrum) Training

March 10, 2015

Oracle Confidential – Internal/Restricted/Highly Restricted

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted

Agile Principles and TheoryLean Software Development

2

• Core Agile Concepts• Scrum Mechanics• Release Mechanics: Making Scrum Work• Conclusion

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |

Where does this information come from?How do I know this might actually work?

• Training:– RallyDev professional scrummaster training– Salesforce Adaptive Development Methodology

scrummaster training– Key books such as Mike Cohn’s “Succeeding with

Agile”

• Experience:– Four companies moved from waterfall to agile– Zero G Software, OpenTable, SAY Media, Oracle

50% training, 50% experience

Oracle Confidential – Internal/Restricted/Highly Restricted 3


Core Agile Concepts• Eliminate Waste

• Partially done work, extra processes, extra features, task switching, waiting, defects• Map your value stream (value added time, wait time)

• Amplify Learning• Feedback, Iterations, Synchronization• Set-based development (multiple options, communicate constraints, let the solution emerge)

• Decide as Late as Possible• Concurrent development, Options thinking, The last responsible moment.• Making decisions (simple rules, or “the ruler”)

4


Core Agile Concepts• Deliver as Fast as Possible

• Bias towards shipping, Queuing theory (cycle time, SML batch), Cost of delay

• Empower the Team• Team makes the decisions, Self-determination, Clear leadership

• Motivation emerges if everyone has belonging, safety, competence, progress

• Build Integrity In• All testing automated (possibly use test driven development)

• Keep architecture healthy, Refactoring

• See the Whole• Systems thinking (Apple example), Measurements (perf, others), Contracts

5



6



Scrum Mechanics (the practical parts)• User Stories

• As a user, I (take specific action) and then (get specific outcome)

• Acceptance criteria: how would a reasonable person evaluate when it is done

• Stories often broken down further into tasks for tracking

• Architectural work is normally built into the estimate for each story

• Unless it isn’t

• Features, Epics• Epics broken down into stories (many PM ‘stories’ are epics)

• Break down stories into smaller components (absurdly if need be)

• New stories added to backlog to integrate elements and get them to work together

7


Scrum Mechanics (the practical parts)• Backlog

• Series of stories in priority order

• Stories at the top have been groomed (broken down to fine levels of detail)

• Stories at the bottom tend to be epics

• Product Owner is responsible for grooming the backlog

• Product Owner is the only one who can change priority, and must approve any new story to be added

• Team negotiates with Product Owner to get their stories moved up the list

• Note: Only add items to the backlog if they are well defined!• It is not for note-taking, idle ideas, “gee we gotta do that one of these days”, requests from upper management

• Even PM is not allowed to add stuff without working with dev leads to define it

• Track those requests elsewhere (I recommend Excel)

8


Scrum Mechanics (the practical parts)• Planning Board

• Tracks status of stories (and tasks) in “swimlanes”

• Kanban concept (stages of progress: accepted, in progress, in QA, done)

• Scrum Team Purpose• All of us, as a group, agree to do the work we sign up for

• We help each other and learn from each other

• Self-determination: we decide how much work it is, and how much we can accept into a given sprint

• Ownership: if we accept five stories and three of them aren’t done at the end, they are red, not green, and that is OK

• Only the team (participants) can add stories to a sprint; PM cannot, managers cannot

9


Scrum Roles and Team Size• Scrum Team Roles

• Product Owner: grooms and maintains the backlog, creates stories and acceptance criteria, accepts stories as done

• Scrummaster: Leads planning meetings and standups, tracks progress

• Developer, Quality Engineer, Documentation:

• Contributes, estimates, does task breakdown

• Scrum Team Size• 4-9 developers (critical mass)

• QA at 3:1 to 5:1 ratio (depends on nature of the work)

• PM or Product Owner

• Doc (may not participate as strongly in early phases, but very welcome)

10


Sprint Ceremonies• Two to three week period of development called a “Sprint”

• All teams working on a propduct and suite must use the same sprint length and sprint name, because of dependencies

• Planning day at the beginning• PM defines the priority and what the stories are

• Engineering and QA estimate how long each story will take

• Daily Standup• What did you do? What will you do today? What is blocking you? (help one another)

• Update the status of each story or task (instant global daily status update)

• Demo (Celebration)• Each engineer (qa or dev) shows their work; all stories can be demonstrated, team chooses

• Retrospective (Feedback)• What went well, what went badly, what one thing do we want to change

11


Sizing Stories

12


Estimation• Story points are estimated up front

• Typically a Fibonacci series (1, 2, 3, 5, 8, 13, 21…)

• Conceptually, arbitrary units; intended to prevent obsession with schedule

• Humans map to things they know; consider using days

• Planning Poker (Per Story)• Hidden until everyone shows at once

• Discussion with outliers (smallest, largest)

• Team has to agree unanimously or investigate

• Task Breakdown• Separate out elements required to implement

• Can be estimated (controversial)

13


Estimation• Raw Capacity (for this sprint)

• How many developers, QA, doc available for this sprint

• How many days this sprint they are available

• Take out one day for planning, and one day for demo and retrospective

• X-Factor (for this sprint)• Escalations, backports, non-scrum-meetings

• Typically assume 20%; more than 50%, impacts ability to participate

• Calculate True Capacity; Use as Budget (for this sprint)• Consider using days per sprint for the whole team, including fractions

• Use up capacity with story points; stop when full

14



15



Why do teams fail at agile?• #1: No clear idea of the goals of the release

• All successful teams work out in advance roughly what they want to do and where they want to go• As part of this, they define what they do NOT want to do• High level estimates are a requirement

• #2: No documentation of designs and architecture• Teams think scrum means no documentation, just code away and get feedback as you go• Must have clear architectural designs written in word docs or PPT• Must have multiple levels of peer review of those designs• Must have a clear chain of technical decisionmaking

• #3: Not putting the user first• Making feature choices based on team self interest

• Classic example: I want to use Node/Angular/The Cloud/Big Data, so we will do feature X

• Design first methodology: you must have storyboard visual mockups of what the user experience is before you start coding• Only exception is pure low level architectural code, which requires a peer-reviewed design spec

16


Broader Scrum Concepts• Release

• Series of sprints designed to meet milestones that fit a theme

• Broad guidelines

• Quality is 100%, time is how long it takes; features are the variable

• Scrum of Scrums• Resolves dependencies one team has on another

• Accepting Change• Don’t change what you’re doing in the current sprint

• Eat change for breakfast: Can we do this? Sure, next sprint.

17


Scrum Board

18


Tracking• Velocity

• The number of story points completed by the team in a sprint

• Useful for planning the next sprint

• Burndown chart• Track the total story point count remaining

• Accepting Change• Don’t change what you’re doing in the current sprint

• Eat change for breakfast: Can we do this? Sure, next sprint.

19



20



Three take-aways• Agile Theory

• Eliminate Waste

• Delegate Authority

• Scrum Mechanics• Ceremonies are IMPORTANT

• Practical tips are rarely found in books

• It’s OK if you screw it up, as long as you use the retrospective

• The Team is the Key• Trust, Reasonableness, Ownership

21


Agile Use Case: WebCenter Portal• The Problems

• Dev teams organized by component rather than pixel-to-metal feature ownership

• Dev, PM, QA all siloed; antagonistic relationship with QA cast as blockers to progress

• Lack of specifications or architectural review; any review was too slow and ineffective

• Poor planning, lack of ownership of end to end use cases

• High level of escalations and bugs, consuming up to 50% of all teams’ time

• Breadth rather than depth in features

• Fundamental architectural issues on persistence, page request handling, and UX

23


Agile Use Case: WebCenter Portal• The Solution: An Action Plan

• Shut down 20 of 22 ongoing projects that had no hope of completing with quality

• Deliver a major bugfix-only release with limited fixes to UX and developer experience to stem the losses

• Move from 21 component teams to 7 feature teams, each with embedded PM, QA, Dev, and Doc

• Pave over all code in main with latest stable release

• Deprecate 40% of all features in the product

• Architectural review, with each (new) team presenting use-case driven designs and mockups• Move to REST, JSON, Twitter Bootstrap, using database for data instead of MDS

• Adopt a scrum of scrums weekly review focused on handling dependencies between teams, ideally eliminating them

• Adopt a milestone map across all teams

• Adopt a resource map per team

• Follow agile scrum process to the letter

• Deliver milestone demos that anyone can attend

24


Clinical Pearl #1: The Milestone Map• Each Team Owns a Set of Features, Completely

• Sketch out using high level estimates a map of the features by sprint

• A feature is one to three epics; each epic is a fully functional usable end to end experience

• Secret: An epic is a project, and you cannot finish a project in one sprint

• 5 projects, minimum of 10 sprints

• Propose the first draft of the milestone map for all teams• It’s easier to react to something than fill a blank page

• The duration may be wrong

• Every three sprints is a milestone• Since nothing is totally completed in one sprint, show progress at milestone boundaries

• All-teams demo with coordinated end to end use cases anyone can attend including management

• With smaller teams, can do this every sprint

25


Clinical Pearl #1: The Milestone Map (Mar 2014)

26


Clinical Pearl #1: The Milestone Map (Oct 2014)

27


Clinical Pearl #2: The Resource Map• Make estimates based on dev, not QA

• Engineering drives all change

• No code change, no QA required

• QA has multiple overlapping tasks; easier to simply use QA ratio and assume scrummerfall

• Estimate Dev Effort in Person-Sprints• Tie it back to real people

• Your estimate will be wrong, so don’t agonize; just call it

• Map out resources to epics• Keep within your dev budget

• It’s like lego blocks

• The “bar” of what is in/not-in a release is instantly obvious

28


Clinical Pearl #2: The Resource Map

29



30



31


Who else has this process worked for?• Documents Cloud Service

• Uses Jira, OSN Collections, OSN Conversations, DOCS

• Middleware Cloud Provisioning• Uses Jira, OSN Conversations, DOCS, Confluence

• Sites Cloud Service• Uses Jira, OSN, DOCS, Confluence

• Notable: Teams from Webcenter Content, Webcenter Sites, Webcenter Portal all participate• Collaborative model without ego or conflict

• Clearly defined lines of responsibility

• Co-ownership of architectural review; collegial atmosphere

• You?

32

Agile Training March 2015

Documents

Transcript of Agile Training March 2015