PRACTICE OVER THEORY -

THE “WHY, WHAT & HOW” OF SELF-ORGANIZING

ENGINEER
EXPANDING
 Remarks: YOUR
This training CONTRIBUTION
is applicable for who youFROM AN INDIVIDUAL
are working within Agile orTO TEAM,development
Traditional WAY TO GO!
methods.

 Advice to Audiences: Attended "JIRA Foundation" Training or you have the essential usage ability on Jira.

 Trainer: SQA/SEPG (Software Quality Assurance/Software Engineering Process Group)

 Duration: 3 Hours

 Date: 9/March, TBD/April

 AGENDA

I. TRAINING INTRODUCTION – “WHAT” YOU CAN EXPECT

30 mins

II. PRACTICE OVER THEORY – “WHY ” YOU SHOULD

100 mins KNOW
III. PRACTICAL PRACTICES – “HOW” YOU CAN DO
30 mins

IV. Q & A – YOUR PIECES OF ADVICE & ACTUAL BARRIERS

SHARING
2
TRAINING INTRODUCTION –
“WHAT” YOU CAN EXPECT

3
 I. “WHAT” YOU CAN EXPECT -
PRACTICE FOR TREND
Project Schedule Management Framework Project Management Tool (JIRA)

A. Project Management Essential – Foundation

B. Project Management Essential – Advanced for Manager
C. Practice over Theory– The “Why, What & How” of Self-Organizing Engineer
I. “WHAT” YOU CAN EXPECT -
PRACTICE FOR TREND
“BEST PRACTICES” CONSOLIDATED BY PROJECT MANAGEMENT
COMMITTEE FROM 2016
TYPE 1 NO ONE TYPE 2
FITS ALL –
3 TYPES OF
PRACTICE

TYPE 3
II. PRACTICE OVER THEORY –

“WHY ” YOU SHOULD KNOW

6
 “WHY ” YOU SHOULD KNOW – A
GLANCE AT TRADITIONAL ONE
WHY & What premises are required
1. Time-sensitive: software releases and/or feature is driven by fixed date.
2. Reporting: Indication & measurement of effectiveness, progress, and deliverables.

WBS ESTIMATIO
N

DEPENDEN
CY

• Critical Path
• Floating

7
 “WHY ” YOU SHOULD KNOW –
PROCESS CONTROL
A Process (Workflow model) defines a repeatable pattern of sequenced operations used to
transform input concepts or objects into intended output concepts or objects.
DEFINED Empirical

KNOWN WATERFALL AGILE LEAN STARTUP UNKNOWN

STEPS INNOVATION
SIMPLE COMPLEX
DETAILED UPFRONT Significant aspects are visible to E.g.:
PLANNING participants and defined by a common
Transparency standard. • Common language share
• • Common definition of ”Done”

Inspect artifacts and progress towards E.g.:

• Inspection sprint goal. Inspection doesn’t Formal events prescribed:
hind/hinder the work • Sprint Planning
• Sprint Review
If the inspection reveals deviations • Daily Scrum
Adaptation outside acceptable limits then • Sprint Retrospective
•
adjustments applied.
8
“WHY ” YOU SHOULD KNOW - A TEAM &
MEMBERS
I. Self-organizing is about the team determining how they will respond to their
environment(Responsibility/Response Ability). (Managers/Leads can influence that environment)
II. High-bandwidth communication environment.

Transpare Inspec Adaptatio

ncy tion n

9
“WHY ” YOU SHOULD KNOW - GOAL,
QUESTION, METRIC
THE INCREMENTAL (GQM) RESULTS INTERNALIZE THE EMPIRICAL PROCESS
STATISTICAL
Goal Question Metric
Stakeholder: Net Promoter
How SATISFIED is our Score
Stakeholder and Scrum Team
Team: Team Morale Survey

Total Business Value Earned

Improve Is our development effort
aligned with BUSINESS?
the result of Return on Investment (ROI)
Agile
implementation Ratio of Successful Sprint
from the Are we improving the
MATURITY of the team?
business Estimation Accuracy
point of view
Velocity Release
Burnup
Are we increasing the
QUANTITY of the work? Sprint
Burndown

Defect Density
How is our QUALITY
of the work?
Severity of Fault
10
 III. PRACTICAL PRACTICES –
“HOW” YOU CAN DO
1. TOP DOWN OR BOTTOM UP
2. WBS
3. ESTIMATION
• STORY POINTS
• IDEA TIME

• People are more important than any process. Good people with a good process will
outperform good people with no process every time. – Grady Booch
• If the Agile Prime Directive is embrace “Change”, a close second is embrace
“Communication” & ”Feedback” – Agile & Iterative Development, by Graig Larman
12
 “HOW” YOU CAN DO – THE TRIPLE
“CONSTRAINTS”
• Management sets up “an environment and encourages team members have the rapid
response ability to changes”, not depend on explicit planning and monitoring workflows.

• Constraints are still important project parameters, but they are not the project’s goal. Value is
the goal and constraints may need to be adjusted as the project moves forward to increase
customer value.
CONFIDENCE LEVEL OF VALUE
VALIDATION
Fixed Scope Time Cost Value

Agil
e
Trad

Lean
.

Variable Time Cost Scope Quality Constraints

SCOPE CAN CHANGE, THE (RELIABLE, (SCOPE, TIME,
PLANNING MECHANISM ADAPTABLE COST)
13
PRODUCT)
“HOW” YOU CAN DO - A GLANCE AT
REALITY
• TRANSPARENCY
• INSPECTION
• ADAPTATION
HOW, WHEN & WHAT?

REGULAR TEAM
MEASUREMENT

14
 Scope

“HOW” YOU CAN DO – THE FUNDAMENTALS

Quality

Time Cost
• When “planning” a project/work, the 2 most common questions are:
I. What are the tasks?
II. How long will the tasks take?

• Next Question is, ”Top Down” or “Bottom up” Strategy?

Id Feature Est. Size Milestone
PRD-01 Documentation Update: Online Help and Local FAQ 10 EB2 (2017/4/30)
PRD-03 Add new values or fields in MARS query 15 EB2 (2017/4/30)
PRD-04 Change encryption from to Android supported 36 EB1 (2017/2/25)
PRD-05 Rename “Scan Facebook” card 5 EB1 (2017/2/25)
…

The estimated size The schedule

The scope of the project
Implied the resources of the project 15
of the project
“HOW” YOU CAN DO – THE SAME
CHALLENGES
Organization Environment

Project – Workplace Context

Manager Team

Person
Can I meet the commitment on time? Overall progress
Task YES NO
How worse is the gap? Predicted risks

What causes the gap?

Progress of each feature Feature progress

Workload of the team
members Existing JIRA
reporting,
More visibility …. dashboard,
16 JQLs
 “HOW” YOU CAN DO – SELF-DIRECTED
Be ready to outline the schedule(Waterfall & Agile)
”TOP DOWN” OR “BOTTOM UP” Work Package(WP, MRD)
STRATEGY • Info. on specific requiremnt
Budget Schedule • Defined by PMs(PO/JM)
• Assign the work to group or
individuals(name)
WBS
RESOURCES
Work Package Contents(Story,
Task, Sub-Task/Actionable Task) Quality: Compliance to
• Time to complete the WP. Specification and Rules Work Package Contents(PRD)
Team • Require Input from other • Task Description
Member tasks. Statement of Work(SOW): • Assignee(Res.) Project
• Dependency. Goal, Objective • Deliverables: Output, Manager
• Resource: Skill, number of Supports on tasks
people

17
“HOW” YOU CAN DO – WBS I
FORMULATE HYBRID
COMPETITION
1.1 30% B 1.2 40% B 1.3 20% B 1. 10% B
Tests 4 Service
Design Manufacturing
Verification Delivery
1.1. 7% B 1.2. 1.3. 1.4.
1 Mechanical 1 Supply Chain 1 Defect Mgt. 1 Package ship
WP 1.1.1.1
Frame
WP 1.1.1.2 FOUR-LEVEL
Brake system WBS
1.1. 8% B 1.2. 1.3. 1.4.
2 Electrical 2 System 2 Performance 2 Shipment
Assembly optimization
1.1. 8% B 1.4.
3 Control 3Unpack inspect,
test
1.1. 7% B
4 System
Integration Allocate Budget (Top-Down Process), Tasks, Skill 18
“HOW” YOU CAN DO – WBS II - A
GLANCE AT JIRA

Work Breakdown
2 JIRA Issue 3Hierarchy 4
1 Epic Story / Task Sub-task

Planning Prepare Project Plan

Project Kick off
Meetkat Message customization

Design & Coding

enhancement Ntrtscan
Firewall Config. Granular setting
apply regular
at Agent Exception usage expression
Detection log Work Package Contents(Story, Task,
Unit Test
Visibility Sub-Task/Actionable Task)
• Time to complete the WP.
Testing Test Plan
• Require Input from other tasks.
Team
• Dependency
Closing Member
• Resource: Skill, number of
people

Work Package Actionable Task

19
 “HOW” YOU CAN DO – WBS III
Tips & Tricks, Guidelines, Pitfalls
oCreate the WBS with your team – Not alone!
oWBS should have at least 3 levels – highest level is the project itself
oDon’t confuse the WBS “Work Package” to a “Task”
oName a WBS item as a noun(not a verb).
”Registration Page” vs ”Write a bad password lockout logic”
oThe WBS lists your work breakdown, the task list is the breakdown of the WBS into actions.
oThe 100% Rule. (All of the scope has been captured and that noting unnecessary is included.
oYour WBS is almost never complete or right in the first iteration.
oTasks have to be small enough to be assigned to individual resources – NOT the WBS
20
oThe 8/80 Rule: All Work Packages should be greater than 8 hours and less than 80 hours.
“HOW” YOU CAN DO –
SCHEDULE/ESTIMATION

When is the reasonable timing to estimate?

21
“HOW” YOU CAN DO – ESTIMATION

• Project Natures – Scope, Schedule driven or Multiple-Team

Project and so on which cause “Plan” needed.

• When to estimate and what unit(Story Points or Actual

Time) is suitable?

22
 “HOW” YOU CAN DO – REALITY OF
ESTIMATION
The “Cone of Uncertainty” ROI Fist

16x

2 Level planning(estimation) 23
“HOW” YOU CAN DO – STORY POINTS

• Hong long a user story will take (effort)

• Influenced by complexity, uncertainty, risk volume of work, etc.
• Relative values are what is important:
• A login screen is a 2.
• A search feature is an 8.
• Basic math properties should hold
• 5+5 = 10

24
“HOW” YOU CAN DO – ESTIMATE SIZE
DRIVE DURATION

Estimate size as a single-step deriving the duration, do these

as separate steps

Bonus to programmer who

wrote the most lines of
Story points are a relative measure of size. The are absolutely code (IBM, in the
an estimate of how long something we’ll take. seventies)

Story points as they let people or team with different skillsets

put the same relative numbers. E.g. able-bodied and who on
crutches to a building
25
“HOW” YOU CAN DO – ESTIMATING IN
STORY(ZOO) POINTS

26
“HOW” YOU CAN DO – ESTIMATING IN
STORY(ZOO) POINTS II

Key Tips:
• The first one won’t be wrong
• The comparison is relative
• One order of magnitude
• Estimate relatively gets easier over time

27
“HOW” YOU CAN DO – IDEA TIME

I can take 10 days on this work!

vs.
I can finish this work on the 10 day
th

28
“HOW” YOU CAN DO – IDEA TIME

Idea Time vs Lapse Time Ideally

• Monday has 8
• It’s all you work on hours
• No one interrupts you • EachBut Instead
week has 40
hours Each day has
• Everything you need is available something like
• This stuff never happens • 2 hours of
meetings
• 2 “How
hours long will this
of email
• 4 take?”
hours left for the
• Are you answering
project
what’ is being
 Story points are additive(common unit); time-based estimates many notasked?
be
 Story points help avoid problems with “unit confusion”

29
“HOW” YOU CAN DO – UNIT
CONFUSION
After Iteration 1., will it will be done?
1. 140/35 = 4
2. 14/3 = 4.66 ≒ 5
Product Iteration 1.
Backlog(Story
Backlog(Hours)
Points) Backlog(Hours)
As a User… 30
3 Code the UI 12
As a User… 50
5 Write tests
As a User… 50
5 8
As a User… 20
2 Code middle tier
As a User… 20
2 4 30
 “HOW” YOU CAN DO – A GLANCE AT
JIRA

Idea Time

Transparenc Inspecti Adaptatio

y on n

31
WRAP-UP
4 words: Estimate size drive duration
1 additional word: Range (One order of
magnitude)

IF YOU FORGET EVERYTHING NOW! JUST REMEMBER THIS …

THIS PACKAGE INCLUDES POST

SERVICE
32
 IV. Q & A –
YOUR PIECES OF ADVICE
&
ACTUAL BARRIERS SHARING

33
 Backup Slides

34 Copyright 2015 Trend Micro Inc.

 “HOW” YOU CAN DO – RELEASE
PLANNING
Predictive Semi-Adaptive Adaptive
Life Cycles Life Cycles Life Cycles

Pure Staged Planned Feature-Driven XP, Extreme

SCRUM
Waterfall Delivery Iterations Development Programming

Complete Release Plan before Iterative

Development Phase ( is recommended for
Release Plan…
Iteration Projects with high criticality )
1 2 3 n
Product A V
Backlog B V
(Sequenced by C V
Importance
D
E
V
V
Projects with flexibility in changing requirements
from high to low) F
…
V or release time with product backlog

35
• Estimate size drive duration & Range (key words for estimation)
Separating the planning process on project into two layers, we’re going to have one layer of planning
estimated planning at a high level where we plan something like a release or a three-month time
horizon even pretty successfully up to about a year out into the future.
We‘re gonna have one approach that we use for that longer term planning and we’ll have a second
approach that we use when we are planning a what’s from teams call a sprint so two different types of
estimating and planning going on we’re going to plan our projects at two different levels

36
• However, in a SDLC based WBS these features are not called out as separate deliverables. For
example in an SDLC based WBS, requirements definition, design specification, coded software and
test case could be called at as separate WBS elements.
• A WBS is the skeleton (structure) of a project. It organizes all of the deliverables necessary to
complete the project. The WBS is used for estimation, scheduling and monitoring project status.
From the PMBOX, the WBS is "a deliverable-oriented hierarchical decomposition of the work to be
executed by the project team to accomplish the project objectives and create the required
deliverables". Note that the structure of the WBS is driven by the deliverables that the project will
produce.
• It is possible to have a hybrid WBS, where some sub-projects or deliverables are produced
iteratively and other are produced using a different lifecycle. For example, a new system
deployment where software is produced iteratively, and the infrastructure (e.g., network, servers,
storage) is produced in a more waterfall fashion.

• http://agile-pm.pbworks.com/w/page/1526552/Agile%20WBS
37
Project 的工作 Breakdown 方式有哪些建議 ?
Project 的工作 Breakdown 方式有哪些建議 ?
• By different PDLC (waterfall, agile)
• Timing & granularity to support project management methods.
• The Granularity of WBS how to decide and trade-off?(3 months cons.
Who many checkpoints)
• The meaning unite & size to support transparency, inspection.
• By RD & QA working model
• Current PDG team: OSCE, Diamond, Dr. Mobile and so on.

38
“WHY ” YOU SHOULD KNOW - A TEAM &
MEMBERS
I. SELF-ORGANIZING IS ABOUT THE TEAM DETERMINING HOW THEY WILL RESPOND TO THEIR
ENVIRONMENT. (MANAGERS/LEADS CAN INFLUENCE THAT ENVIRONMENT)
II. HIGH-BANDWIDTH COMMUNICATION ENVIRONMENT.

Transpare Inspec Adapta

ncy tion tion

39
“HOW” YOU CAN DO –
UPCOMING
• WBS Method, activities & artifacts(Agile) & few Jira View
• Estimation Method, activities & artifacts(Agile) & few Jira View
• How quantitative progress view will create effective meetings(daily
stand up, retrospective, even spring review meeting, etc.) to
communicate with PO/JM/PM/Team.
• It all comes down to create a safety project, collaboration & working
environment by your individual self-managzing.

40
• A workflow(process) model & WBS.
• Five level WBS.
• Project Task Description – Work Packages & The Triple Constraints.

41
42
Approaches of Release Planning
A: Release Every
Iteration
Interim Interim Interim Interim
Release #1 Release #2 Release #3 … Release #n
Iteration 1 Iteration 2 Iteration 3 Iteration n

6 weeks It may not always possible for Trend Micro Project to

or Less deliver potential shippable product every 6 weeks or
less.

B: Release with Multiple

Iterations
Interim Release #1 Interim Release #2 Interim Release #n
Iteration Iteration Iteration Iteration Iteration Iteration … Iteration Iteration Iteration
1.1 1.2 … 1.x 2.1 2.2 … 2.y n.1 n.2 … n.z

43
A Team – Complex adaptive
system(CAS)
A CAS is characterized by : A dynamic network
of many agents
• Acting in parallel
• Acting and reacting to what other agents are doing

Control is highly dispersed and decentralized

From Leading a Self-Organizing Team

Chapter 4. Scrum and Self-Organizing Teams
44
A Self-Organizing Team I
Self-organization doesn’t mean that workers instead
of managers engineer an organization design. It doesn’t
mean letting people do whatever they want to do.

It means that management commits to guiding the

evolution of behaviors that emerge from the interaction
of independent agents instead of specifying in advance
what effective behavior is.
-Philip Anderson, The Biology of Business

45
A Self-Organizing Team I I
Although project teams are largely on their own,
they are not uncontrolled. Management
establishes enough checkpoint to prevent
instability, ambiguity, and tension from turning
into chaos.
At the same time, management avoids the kind
of rigid control that impairs creativity and
spontaneity.
- Takeuchi & Nonaka “the New New Product Development Game”

46
A Self-Organizing Team I I Continual
Self-organization proceeds from the premise that effective organization
is evolved, not designed. I aims to create an environment in which
successful divisions of labor and routines not only emerge but also self-
adjust in response to environmental changes. This happens because
management sets up an environment and encourages rapid evolution
toward higher fitness, not because management has mastered the art
of planning and monitoring workflows.

-Philip Anderson, The Biology of business

47
Why Estimation?
• Software releases and/or feature introduction needs to be driven by a fixed
date. fixed date release scenarios, deadline-driven motivation.
• Senior managers or executives are interested in metrics, status updates, and
reporting in order to gain visibility, transparency, and insight into
departmental initiatives, deliverables, and actions taken that are geared
towards achieving the company’s objectives and goals.
• It helps calculate time-based productivity and planning metrics like sprint
velocity.

• Estimation is a communication indicator for team members during any

together activity. (Sync-up, meeting, etc…)
48