1. Effective Habits of
Development Teams
Paul Schreiber
paulschreiber@gmail.com

3. 5M

6. Central Line Insertion Care Team Checklist
Date____________________ Time____________________ Addressograph
TYPE OF LINE PLACED ______________________ REWIRE អ LOCATION OF LINE ____________________ # OF LUMENS ___________
CRITICAL STEPS
Directions: The Assistant completes this checklist by indicating with a checkmark in the
appropriate column when the task is performed. If the task is not performed, a comment
must be added. The Supervisor may also function as the Assistant who completes this form.
Yes Yes with Reminder
(If No-add a
comment)
1. Perform a time out using the informed consent form.
2. Clean hands
3. Wear cap, mask, sterile gown/gloves, and eye protection if in
contact with or crossing the sterile field *at any time during the
procedure.
a. All others entering the room during the procedure must wear
cap and mask.
4. Prep site with chlorhexidine and let air dry. (*See instructions)
5. Drape patient from head to toe using sterile technique.
6. Prepare catheter by pre-flushing and clamping all lumens not in
use during procedure.
7. Place patient in trendelenburg position unless contraindicated
(e.g., increased ICP) or if femoral/ PICC (place supine and flat).
8. Maintain sterile field.
9. Ensure grasp on guide wire is maintained throughout procedure
and removed post procedure.
អ Johns Hopkins Hospital
អ Johns Hopkins Bayview
អ Other: _______________________________

7. ➡66%

8. $175MM

9. 1500

10. Surgical Safety Checklist
Has the patient confirmed his/her identity,
site, procedure, and consent?
Yes
Is the site marked?
Yes
Not applicable
Is the anaesthesia machine and medication
check complete?
Yes
Is the pulse oximeter on the patient and
functioning?
Yes
Does the patient have a:
Known allergy?
No
Yes
Difficult airway or aspiration risk?
No
Yes, and equipment/assistance available
Risk of >500ml blood loss (7ml/kg in children)?
No
Yes, and two IVs/central access and fluids
planned
Confirm all team members have
introduced themselves by name and role.
Confirm the patient’s name, procedure,
and where the incision will be made.
Has antibiotic prophylaxis been given within
the last 60 minutes?
Yes
Not applicable
Anticipated Critical Events
To Surgeon:
What are the critical or non-routine steps?
How long will the case take?
What is the anticipated blood loss?
To Anaesthetist:
Are there any patient-specific concerns?
To Nursing Team:
Has sterility (including indicator results)
been confirmed?
Are there equipment issues or any concerns?
Is essential imaging displayed?
Yes
Not applicable
Nurse Verbally Confirms:
The name of the procedure
Completion of instrument, sponge and needle
counts
Specimen labelling (read specimen labels aloud,
including patient name)
Whether there are any equipment problems to be
addressed
To Surgeon, Anaesthetist and Nurse:
What are the key concerns for recovery and
management of this patient?
This checklist is not intended to be comprehensive. Additions and modifications to fit local practice are encouraged. Revised 1 / 2009
(with at least nurse and anaesthetist) (with nurse, anaesthetist and surgeon) (with nurse, anaesthetist and surgeon)
© WHO, 2009
Before induction of anaesthesia Before skin incision Before patient leaves operating room

11. ➡35%

12. ➡47%

14. ignorance

15. ineptitude

18. playbook

19. playbook
Understand what people need
Address the whole experience, from
start to finish
Make it simple and intuitive
Build the service using agile and iterative
practices

20. playbook
Assign one leader and hold that person
accountable
Bring in experienced teams
Choose a modern technology stack
Deploy in a flexible hosting environment
Automate testing and deployments

21. playbook
Manage security and privacy through
reusable processes
Use data to drive decisions
Default to open

22. understand what
people need

23. understand what people need
Early in the project, spend time with
current and prospective users of the
service
Use a range of qualitative and
quantitative research methods to
determine people’s goals, needs, and

24. understand what people need
Test prototypes of solutions with real
people, in the field if possible
Document the findings about user goals,
needs, behaviors, and preferences
Share findings with the team and agency
leadership

25. understand what people need
Create a prioritized list of tasks the user
is trying to accomplish, also known as
“user stories”
As the digital service is being built,
regularly test it with potential users to
ensure it meets people’s needs

26. software

27. software checklists
security
onboarding
offboarding
administrator
access
project
website
newsletter
podcast
VIP Go migration

28. software checklists
development
localization
accessibility
code review
testing
deployment
alerting
data migration

29. AA CCHHEECCKKLLIISSTT FFOORR CCHHEECCKKLLIISSTTSS
DDeevveellooppmmeenntt
Do you have clear, concise
objectives for your checklist?
Is each item:
A critical safety step and in great
danger of being missed?
Not adequately checked by other
mechanisms?
Actionable, with a specific
response required for each item?
Designed to be read aloud as a
verbal check?
One that can be affected by the
use of a checklist?
Have you considered:
Adding items that will improve
communication among team
members?
Involving all members of the team
in the checklist creation process?
DDrraaffttiinngg
Does the Checklist:
Utilize natural breaks in workflow
(pause points)?
Use simple sentence structure and
basic language?
Have a title that reflects its
objectives?
Have a simple, uncluttered, and
logical format?
Fit on one page?
Minimize the use of color?
Is the font:
Sans serif?
Upper and lower case text?
Large enough to be read easily?
Dark on a light background?
Are there fewer than 10 items per
pause point?
Is the date of creation (or revision)
clearly marked?
VVaalliiddaattiioonn
Have you:
Trialed the checklist with front line
users (either in a real or simulated
situation)?
Modified the checklist in response
to repeated trials?
Does the checklist:
Fit the flow of work?
Detect errors at a time when they
can still be corrected?
Can the checklist be completed in
a reasonably brief period of time?
Have you made plans for future
review and revision of the
checklist?

30. habits
checklists
onboarding
communication
code standards
code reviews
version control
automation
reflection

31. Onboarding

42. Code Standards

43. consistent formatting
reduce bogus diffs
catch errors
standardize

45. $ phpcs

46. WordPress standards
WordPress-Core
WordPress-Extra
WordPress-Docs
WordPress-VIP

47. FILE: wp-login.php
----------------------------------------------------------------------------------------
FOUND 759 ERRORS AND 151 WARNINGS AFFECTING 370 LINES
----------------------------------------------------------------------------------------
12 | ERROR | [x] Expected 1 spaces after opening bracket; 0 found
12 | ERROR | [x] Expected 1 spaces before closing bracket; 0 found
16 | ERROR | [x] Expected 1 spaces after opening bracket; 0 found
16 | ERROR | [x] Expected 1 spaces before closing bracket; 0 found
16 | WARNING | [ ] Detected access of super global var $_SERVER, probably needs
manual inspection.
16 | ERROR | [ ] Detected usage of a non-validated input variable: $_SERVER
16 | ERROR | [ ] Missing wp_unslash() before sanitization.
16 | ERROR | [ ] Detected usage of a non-sanitized input variable: $_SERVER
16 | ERROR | [ ] Detected usage of a non-validated input variable: $_SERVER
16 | ERROR | [ ] Missing wp_unslash() before sanitization.
phpcs

48. $ phpcbf

49. {
"require": {
"wp-coding-standards/wpcs": “^0.14"
}
}
composer.json

50. <?xml version="1.0"?>
<ruleset name="WordPress Coding Standards for Avocado">
<rule ref="WordPress-VIP" />
<config name="installed_paths" value="vendor/wp-coding-standards/
wpcs" />
<arg name="colors" />
<arg value="s"/>
<arg name="extensions" value="php"/>
<file>.</file>
<exclude-pattern>*/node_modules/*</exclude-pattern>
<exclude-pattern>*/vendor/*</exclude-pattern>
</ruleset>
phpcs.xml

52. JavaScript standards
Airbnb
Google
Crockford
jQuery
idiomatic
node
Wikimedia
WordPress

53. {
"extends": "wordpress",
"rules": {
"camelcase": [ "error", { "properties": "never" } ],
"yoda": [ "error", "always", { "onlyEquality": true } ],
"vars-on-top": [ 0 ],
"space-in-parens": [ "error", "always", { "exceptions":
[ "empty" ] } ]
}
}
.eslintrc

55. # http://editorconfig.org
root = true
[*]
charset = utf-8
trim_trailing_whitespace = true
indent_style = tab
end_of_line = lf
insert_final_newline = true
.editorconfig

56. Communication

57. Psychological
Safety

59. Low High
HighLow
PsychologicalSafety
Accountability

60. Apathy zone
Low High
HighLow
PsychologicalSafety
Accountability

61. Comfort zone
Apathy zone Anxiety zone
Low High
HighLow
PsychologicalSafety
Accountability

62. Comfort zone Learning zone
Apathy zone Anxiety zone
Low High
HighLow
PsychologicalSafety
Accountability

63. 1:1s

64. f2f + video

67. Write it.

68. 1:1

69. repurpose

70. parts

71. • What you did (saw, heard, typed,
clicked)
• What happened
• What you expected to happen

72. titles

73. Filler words
articles (a, the, than, that, of, …)
Conversational writing (“Would
like to…”, “Please add…”)
Words such as “problem,” “bug,”
or “issue”

74. descriptions

75. errors

76. repro

77. steps

78. actual
vs
expected

79. relative pronouns (it, that)
slang and informal language
(“busted,” “on the fritz,”
“acting up”)

80. nothing happened
didn’t work
does nothing

81. priority

82. P1

83. • This is urgent.
• Interrupt other work to fix this
• Call someone at home
• …wake them up
• …pull them out of a meeting

84. • Site is down
• Page layout broken and
unreadable
• JS error prevents scripts from
running
• Site security breached

85. P2

86. • This is important
• Work on this right away

87. P3

88. • Nice-to-have
• Fix after P1 and P2 bugs
• Fix opportunistically

89. Version Control

91. git extras

92. 55

93. $ git summary
project : git-extras
repo age : 10 months ago
commits : 163
active : 60 days
files : 93
authors :
97 Tj Holowaychuk 59.5%
37 Jonhnny Weslley 22.7%
git summary

94. $ git delete-merged-branches
Deleted feature/themes (was c029ab3).
Deleted feature/live_preview (was a81b002).
Deleted feature/dashboard (was 923befa).
...
git delete-merged-branches

95. $ git setup
Initialized empty Git repository in /private/tmp/
hello/.git/
[master (root-commit) 97ff7ac] Initial commit
1 file changed, 1 insertion(+)
create mode 100644 yo.txt
git setup

97. $ git obliterate secrets.json
git obliterate

99. bfg

100. 10X

101. 720X

102. $ git clone --mirror http://my.server/my-repo.git
$ bfg --delete-files secrets.json my-repo.git
$ bfg --strip-blobs-bigger-than 100M my-repo.git
bfg

104. commits

109. feature/
liveblog

110. fix/
touchstart

111. style/
navigation

112. fix/
AV-3456

113. tab completion

114. $ git clone https://github.com/tj/git-
extras ~/.dev/git-extras
$ curl -O .git-completion.bash https://
raw.githubusercontent.com/git/git/
master/contrib/completion/git-
completion.bash

115. source ${HOME}/.git-completion.bash
source ${HOME}/.dev/git-extras/etc/
bash_completion.sh
.bashrc

116. bisect

117. $ git bisect start
$ git bisect bad master
$ git bisect good 256d850
git bisect

118. Bisecting: 29 revisions left to test
after this (roughly 5 steps)
[b73f2bdaaabedf157364db3390a7adc06207c5
02] FTC newsletter: make headline and
body text links black
git bisect

119. Bisecting: 14 revisions left to test
after this (roughly 4 steps)
[745a8840c01e0ac1b85dec869f4c407ad0224e
b0] Pass data-page-url through
matchProtocltoWindow to fix extraneous
tracks
$ git bisect good

120. Bisecting: 7 revisions left to test
after this (roughly 3 steps)
[03ecb224782699a23aedaa43aee97e1d7a32c6
5a] The use of self:: outside of a
class context was causing fatal errors,
this fixes those errors for now
$ git bisect bad

121. …

122. 255c11cbc is the first bad commit
commit 255c11cbc
Author: sb
<sboisvert@dd790b09-5c1c-0410-8744-875>
Date: Wed Apr 18 16:29:03 2018 +0000
refactor quantum superpositioning
$ git bisect bad

123. $
$ git bisect reset

124. Code Reviews

125. code,
! person

126. don’t take code
review personally

127. architecture
review

128. why?

130. readability

131. culture

132. rules

135. review
before merging

136. review is
collaborative

138. intent

139. design

140. implementation

141. grammar

143. Automation

145. 3X

153. chmod

154. lintspaces

158. Reflection

159. methods of reflection
blameless postmortems
failure reports
after-action reviews

162. Action
Failure
Punishment
Reduced
Trust
CYA
Uninformed
Management
Increased
Error Rate

164. blameless postmortem
actions
effects
expectations
assumptions
understanding

165. punishment
retribution

166. how

167. descriptions

170. 2014 FAILURE REPORT
MONITORING, EVALUATING,
ANDADAPTINGTOFAILURE
28
FAILURE
REPORT2012

172. 26
AlixKrahn
Co-President,UniversityofAlbertaChapter
alixkrahn@ewb.ca
Last year, I submitted a story to EWB’s Failure Report
on the failure of communication between parts of
EWB – the failure of a knowledge management sys-
tem. In brief: in December 2010, I had a meeting with
an Edmonton MP where I discovered that he already
had a relationship with EWB at the national level. So
much so, that he was attending EWB’s National Con-
ference in January prior to visiting Ghana with EWB.
In the time since this failure was published in the
Failure Report, what has changed? From my perspec-
tive – very little. There is some movement for an MP
relationship tracking tool, but there hasn’t (yet) been
broad support for it and there is still minimal sharing
between National Office and chapters in the realm of
MP knowledge and actions.
So why didn’t we learn from the Failure Report? Here’s
a look at the process of the Failure Report, from my
perspective:
A person or a specific group experiences the failure
and the consequences of that failure. When submis-
sions to the Failure Report are advertised openly, they
may share it, and it eventually it ends up in the year’s
Report, distributed at National Conference in January
and occasionally referenced afterwards.
Within this process, I see three failures:
• The right people don’t necessarily learn from
the submitted failures. There is misalignment
between who experiences the consequences of a
failure, and who can solve for it at its root cause.
• The Failure Report emphasizes individual solu-
tions, and puts the onus on one person to learn
or “fix” the failure. This does not facilitate broad
learning from the mistake, and does not incite
institutional change to avoid the same failure.
• Very little follow-up occurs after the Failure Re-
port is distributed at National Conference, with
the exception of learning at an individual level.
Looking at the failure I submitted last year, it is the
quality of EWB’s advocacy work that suffers. In this,
FailingtoLearnfromtheFailureReport
Leadership & Organizational Change

173. After-action
reviews

177. What were our intended results?
What were our actual results?
What caused our results?
What will we sustain or improve?
What is our next opportunity to
test what we have learned?

182. Paul Schreiber
@paulschreiber

183. Many graphics from The Noun Project
Hospital by Nimal Raj; Calendar by Laurent Canivet; Computer by Azis;
Phone by Fasobrun Jamil; Password by b farias; Checklist by David;
Script by Yuri Mazursky; Okay by Akhil Komath; insect by Hopkins;
Lock with keyhole by Brennan Novak; Package by Rockicon; Snail by
aLf; Robin by Xavier Gironès; Light by Numero Uno; Stick by Blaise
Sewell; Gears by Gregor Cresnar; Search by Aneeque Ahmed; Person
by asianson.design; Surfboard by Stanislav Levin.; cycle by lipi; Return
by Robert Bjurshagen; File by Creative Stall; Star by Thays Malcher;
Ghost by Rafael Garcia Motta; running by Abraham; clock by Gregor
Cresnar; Personal by Yaroslav Samoylov; mortar board by john melven;
Thought bubble by by b farias.