Prince2agile Preview

Passing the Prince2agile
Practitioner Exam at Your First

Attempt
Simon Harris, pmp, p2, p2a, cgeit
2015 Simon Harris, pmp, p2, p2a, cgeit
Contents
0 Hello and a very warm welcome. . . . . . . . . . . . . . 1

Lesson 1 Your Journey with Presenter: Simon Harris
PRINCE2 P2A CGEIT PMP IPMA-D . . . . . . . . 1
Lesson 2 TITLE= Our Topic: PRINCE2 Agile . . . . . 4
Lesson 3 TITLE= Navigation & SubSections - Ss0 s3. . . 11
1 Introduction & Context . . . . . . . . . . . . . . . . . . 15

Lesson 4 TITLE= Introduction & Context - Section Overview
: 5 slides - Ss1 s4. . . . . . . . . . . . . . . . . . . 15
Lesson 5 TITLE= Course Objectives : 1/5 - Ss1 s5. . . . . 20
Lesson 6 TITLE= About yourself : 2/5 - Ss1 s6. . . . . . 24
Lesson 7 TITLE= About the manual : 3/5 - Ss1 s7. . . . . 26
Lesson 8 TITLE= About the exam : 4/5 - Ss1 s8. . . . . . 30
Lesson 9 TITLE= Exam structure : 5/5 - Ss1 s9. . . . . . 34
Lesson 10 TITLE= Online content only. . . . . . . . . . 37
2 Overview the basics. . . . . . . . . . . . . . . . . . . . . 39

Lesson 11 TITLE= Overview the basics - Section outline
: 0of10 - Ss2 S11. . . . . . . . . . . . . . . . . . . 39
Lesson 12 TITLE= Project or Business_as_Usual (BAU)
: 1/10 - Ss2 s12 . . . . . . . . . . . . . . . . . . . . 41
Lesson 13 TITLE= The difference between project work
and BAU work : 2/10 - Ss2 s13 . . . . . . . . . . . 46
Lesson 14 TITLE= Baseline Exercise-0: What is Agile? -
Ss2 s14. . . . . . . . . . . . . . . . . . . . . . . . 48
Lesson 15 TITLE= An overview of agile : 3/10 - Ss2 s15 . 50
CONTENTS
Lesson 16 TITLE= The Agile Manifesto : 4/10 - Ss2 s16 . 52

Lesson 17 TITLE= Waterfall or Iterative & Incremental
: 5/10 - Ss2 s17 . . . . . . . . . . . . . . . . . . . . 54
Lesson 18 TITLE= Agile basics : 6/10 - Ss2 s18 . . . . . . 57
Lesson 19 TITLE= Beyond a basic view : 7/10 - Ss2 s19 . 61
Lesson 20 TITLE= Agile Frameworks : 8/10 - Ss2 s20 . . 63
Lesson 21 TITLE= Paper_1 Qn_3 - Ss2 s21 Question
Analysis. . . . . . . . . . . . . . . . . . . . . . . 65
Lesson 22 TITLE= Agile behaviours concepts & tech-
niques : 9/10 - Ss2 s22 9/10 . . . . . . . . . . . . . 66
Lesson 23 TITLE= The PRINCE2 Agile view : 10/10 - Ss2
s23 10/10 Recap. . . . . . . . . . . . . . . . . . . . 68
Lesson 24 TITLE= When you want support - Ss2 s24
11/10! . . . . . . . . . . . . . . . . . . . . . . . . 71
Share your study aids? . . . . . . . . . . . . . . . . . . 72
3 Tailoring prince for agile. . . . . . . . . . . . . . . . . . 73

Lesson 25 TITLE= Tailoring prince for agile : 7 - Ss3 s25. 73
Lesson 26 TITLE= PRINCE2 Agile blending PRINCE2 &
agile together : 1/7 - Ss3 s26 . . . . . . . . . . . . 75
Lesson 27 TITLE= What does PRINCE2 Agile comprise
of? : 2/7 - Ss3 s27 . . . . . . . . . . . . . . . . . . 79
Lesson 28 TITLE= 8 Guidance Points : 3/7 - Ss3 s28 . . . 83
Lesson 29 TITLE= Beware of prejudice! : 4/7 - Ss3 s29 . 86
Lesson 30 TITLE= The PRINCE2 journey with agile : 5/7
- Ss3 s30 . . . . . . . . . . . . . . . . . . . . . . . 87
Lesson 31 TITLE= Recap of PRINCE2 : 6/7 - Ss 31 . . . . 89
Lesson 32 TITLE= The PRINCE2-Agile Procedural Flow-
Chart : 7/7 - Ss3 s32 7/7 . . . . . . . . . . . . . . . 91
Lesson 33 TITLE= RevisionAid & q33: Lets do some
quizzing :-) to consolidate what we have covered
(T2.2, 7.4, T3.4, 3.6) . . . . . . . . . . . . . . . . . 97
4 Fix time & cost to flex scope & quality to achieve the
5 targets. . . . . . . . . . . . . . . . . . . . . . . . . . . 100
CONTENTS
Lesson 34 TITLE= Fix time & cost to flex scope & quality
to achieve the 5 targets : 8 - Ss4 hdr s 34 . . . . . . 100
Lesson 35 TITLE= Online content only . . . . . . . . . . 102
Lesson 36 TITLE= The Hexagon - 1/8 - Ss4 s36 . . . . . 103
Lesson 37 TITLE= Revision Aid . . . . . . . . . . . . . . 106
Lesson 38 TITLE= Revision Aid . . . . . . . . . . . . . . 107
Lesson 39 TITLE= EqA: Paper_2 Qn_8 - Ss 4 s39. . . . . 108
Lesson 40 TITLE= The 5 targets : 2/8 - Ss4 s40 2/8 . . . . 110
Lesson 41 TITLE= Be on time and hit deadlines : 3/8 -
Ss4 S41 . . . . . . . . . . . . . . . . . . . . . . . . 111
Lesson 42 TITLE= Protect the level of Quality : 4/8 - Ss4
S42 . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Lesson 43 TITLE= Embrace change : 5/8 - Ss4 s43. . . . 115
Lesson 44 TITLE= Keep teams stable : 6/8 - Ss4 s44 6/8. . 117
Lesson 45 TITLE= Accept that the customer doesnt
need everything : 7/8 - Ss4 s45 7/8. . . . . . . . . . 120
Lesson 46 TITLE= Exam Question Analysis: Paper_2
Qn_25 - Ss4 s46. . . . . . . . . . . . . . . . . . . . 122
Lesson 47 TITLE= The appropriate balance : 8/8 - Ss4 s47. 124
Lesson 48 TITLE= EqA: Paper_1 Qn_25 - Ss4 s48. . . . . 127
Lesson 49 TITLE= MoSCoW prioritisation . . . . . . . . 129
Lesson 50 TITLE= Case-Study-1: What Is Chestertons
Investment? - Ss4 s50. . . . . . . . . . . . . . . . 130
5 Where agile plugs into PRINCE2. . . . . . . . . . . . 132

Lesson 51 Where agile plugs into PRINCE2 Section
Overview - 2 - Ss5 s51 . . . . . . . . . . . . . . . 132
Lesson 52 TITLE= Agile and the PRINCE2 Processes -
Ss5 s52 . . . . . . . . . . . . . . . . . . . . . . . . 133
Lesson 53 TITLE= Relating agile processes to PRINCE2
processes: Simple Backlog and Sprint - Ss5 s53 . . 136
processes: Stages with Releases - Ss5 s54 . . . . . 138
processes: Planning & Review Events - Ss5 s55 . . 141
CONTENTS
Congratulate your self!. . . . . . . . . . . . . . . . . . . 143
6 Principles & P2A Behaviours & PRINCE2 Themes. . . . 144

Lesson 56 TITLE= Principles & P2A Behaviours & PRINCE2
Themes Section Overview - 4 - Ss6 s 56 . . . . . . 144
Lesson 57 TITLE= PRINCE2 Principles : guidance 1/4 -
Ss6 S57. . . . . . . . . . . . . . . . . . . . . . . . 146
Lesson 58 TITLE= Principles and behaviours 2/4 - Ss6 S58. 149
Lesson 59 TITLE= PRINCE2 Agile Behaviours 3/4 - Ss6
S59. . . . . . . . . . . . . . . . . . . . . . . . . . 151
Lesson 60 TITLE= Paper_1 Qn_7 - Ss6 S60. . . . . . . . 153
Lesson 61 TITLE= Agile and the PRINCE2 Themes 4/4 -
Ss6 S61. . . . . . . . . . . . . . . . . . . . . . . . 155
Lesson 62 TITLE= Exercise-6: Rank the 5 behaviours -
Ss6 S62. . . . . . . . . . . . . . . . . . . . . . . . 156
Lesson 63 TITLE= Lunch . . . . . . . . . . . . . . . . . 157
Lesson 64 TITLE= End of The Introduction, Now for a
Change of Scale . . . . . . . . . . . . . . . . . . . 158
7 SU & IP {{Starting up a Project}} and the Initiation

Stage: (Getting a project going). . . . . . . . . . . . . 164
Lesson 65 TITLE= SU & IP : getting a project going
Section Overview - 3 - Ss7 s65 . . . . . . . . . . . 165
Lesson 66 TITLE= Starting up a Project and Initiating a
Project 1/3 - Ss7 S66. . . . . . . . . . . . . . . . . 167
Lesson 67 Starting up a Project and Initiating a Project
2/3 Ss7 s67. . . . . . . . . . . . . . . . . . . . . . 171
Lesson 68 Starting up a Project and Initiating a Project
3/3 - Ss7 S68. . . . . . . . . . . . . . . . . . . . . 174
8 Cynefin : (Pronounced Kuhnevin). . . . . . . . . . . . . 177

Lesson 69 TITLE= Cynefin Section Overview : 3 - Ss8 s69 177
Lesson 70 TITLE= Cynefin 1/3 - Ss8 S70. . . . . . . . . . 179
Lesson 71 TITLE= The Cynefin Framework 2/3. . . . . . 181
Lesson 72 TITLE= Cynefin 3/3 - Ss8 S72. . . . . . . . . . 185
CONTENTS
Lesson 73 TITLE= Case Study: Classify Chestertons

Project - Ss8 S73. . . . . . . . . . . . . . . . . . . 187
9 The Agilometer . . . . . . . . . . . . . . . . . . . . . . . 188

Lesson 74 TITLE= The Agilometer - Section Overview:
2 - Ss9 s75 Agilometer. . . . . . . . . . . . . . . . 188
Lesson 75 TITLE= The Agilometer : a focus area 1/2 -
Ss9 s75 . . . . . . . . . . . . . . . . . . . . . . . . 189
Lesson 76 TITLE= The Agilometer 2/2 - Ss9 s76. . . . . 192
Lesson 77 TITLE= EQA - Paper_1 Qn_16 - Ss9 s77 . . . . 194
Lesson 78 TITLE= Exercise-7: Apply the Agilometer -
Ss9 s78. . . . . . . . . . . . . . . . . . . . . . . . 195
10 Business Case Theme . . . . . . . . . . . . . . . . . . . 197

Lesson 79 TITLE= Business case theme Section Overview
- 3 - Ss10 s79. . . . . . . . . . . . . . . . . . . . . 197
Lesson 80 TITLE= Defining value 1/3 - Ss10 S80. . . . . 199
Lesson 81 TITLE= Business Case : general view of agile
2/3 - Ss10 S81. . . . . . . . . . . . . . . . . . . . . 204
Lesson 82 TITLE= Business Case : guidance 3/3 - Ss10 S82. 205
Lesson 83 TITLE= EqA Paper_1 Qn_8 - Ss10 S83. . . . . 208
Lesson 84 TITLE= EqA Paper_1 Qn_31 - Ss10 S84. . . . 210
11 The Risk Theme . . . . . . . . . . . . . . . . . . . . . . 212

Lesson 85 TITLE= The risk theme Section Overview : 1
- Ss11 s85 . . . . . . . . . . . . . . . . . . . . . . 212
Lesson 86 TITLE= Risk 1/1 - Ss11 s86. . . . . . . . . . . 214
Lesson 87 TITLE= EqA Paper_1 Qn_9 - Ss11 s87 . . . . 217
12 Feedback & Lean Start-Up . . . . . . . . . . . . . . . . 219

12 Lesson 88 TITLE= Feedback & Lean Start-Up Section
Overview: 3 - Ss12 s88. . . . . . . . . . . . . . . . 219
Lesson 89 TITLE= The Feedback Loop 1/3 - Ss12 S89. . . 221
Lesson 90 TITLE= Lean Start-up 2/3 - Ss12 S90. . . . . . 223
Lesson 91 TITLE= Lean Start-up 3/3 - Ss12 S91 . . . . . 224
CONTENTS
Lesson 92 TITLE= Back@WorkSkill Builder CaseS-

tudy: Identify the MVP - Ss12 S92. . . . . . . . . . 226
Lesson 93 TITLE= ShortBreak . . . . . . . . . . . . . . . 227
13 Requirements (focus area) user stories & prioritisation 228

13 Lesson 94 TITLE= Requirements (focus area) user
stories & prioritisation - Section Overview : 6 -
Ss13 s94. . . . . . . . . . . . . . . . . . . . . . . . 228
Lesson 95 TITLE= Requirements and User Stories 1/6 -
Ss13 S95. . . . . . . . . . . . . . . . . . . . . . . . 230
Lesson 96 TITLE= User Stories-1 2/6 - Ss13 S96 2/6. . . . 232
Lesson 97 TITLE= User Stories-2 3/6 - Ss13 S97. . . . . . 234
Lesson 98 TITLE= Requirements Prioritisation 4/6 - Ss13
S98. . . . . . . . . . . . . . . . . . . . . . . . . . 236
Lesson 99 TITLE= MoSCoW and ordering 5/6 - Ss13 S99. 238
Lesson 100 TITLE= Using prioritisation 6/6 - Ss13 S100. 240
Lesson 101 TITLE= Back@Work Case Segment: Re-
quirements - Ss13 S101 (Ex-3). . . . . . . . . . . . 243
Lesson 102 TITLE= Back@Work Case Segment Exercise-
4: MoSCow The Requirements List - Ss13 S102. . . 244
Lesson 103 TITLE= EQn Paper_1 Qn_41 - Ss13 S103. . . 245
14 The Change theme . . . . . . . . . . . . . . . . . . . . 247

14 Lesson 104 TITLE= Change theme - Section Overview
: 3 - Ss14 s104. . . . . . . . . . . . . . . . . . . . . 247
Lesson 105 TITLE= Change : Agiles general view of
Change 1/3 - Ss14 s195 . . . . . . . . . . . . . . . 249
Lesson 106 TITLE= Change : guidance 2/3 - Ss14 s106. . 251
Lesson 107 TITLE= Agile Change Guidance 3/3 - Ss14 s107 253
Lesson 108 TITLE= Eqn Paper_1 Qn_10 - Ss14 s108. . . 255
15 Organization theme & servant leadership . . . . . . . 257

Lesson 109 TITLE= Organization theme & servant lead-
ership Section Overview - 9 - Ss15 s109. . . . . . . 257
CONTENTS
Lesson 110 TITLE= Organisation : general view of agile

1/9 - Ss15 s110. . . . . . . . . . . . . . . . . . . . 260
Lesson 111 TITLE= Organisation : guidance 2/9 - Ss15 s111 264
Lesson 112 TITLE= Organisation : adjustments 3/9 - Ss15
s112 . . . . . . . . . . . . . . . . . . . . . . . . . 265
Lesson 113 TITLE= Organisation 4/9 - Ss15 s113 . . . . 268
Lesson 114 TITLE= Organisation The Delivery Tean 5/9
- Ss15 s114. . . . . . . . . . . . . . . . . . . . . . 270
Lesson 115 TITLE= Organisation: Project Structures 6/9
- Ss15 s115. . . . . . . . . . . . . . . . . . . . . . 272
Lesson 116 TITLE= Servant Leadership 7/9 - Ss15 s116. . 275
Lesson 117 TITLE= incorporating a Wider Customer
View 8/9 - Ss15 s117 . . . . . . . . . . . . . . . . 276
Lesson 118 TITLE= Working Agreements 9/9 - Ss15 s118 279
Lesson 119 TITLE= Case Study-5: Assign Roles - Ss15 s119. 281
Lesson 120 TITLE=EQn Paper_1 Qn_29 - Ss 15 s120. . . 283
16 MP {{Managing Product Delivery}} . . . . . . . . . . . 286

16 Lesson 122 TITLE= MP Section Overview: 3 - Ss16
s122. . . . . . . . . . . . . . . . . . . . . . . . . . 286
Lesson 123 TITLE= Managing Product Delivery 1/3 -
Ss16 s 123 . . . . . . . . . . . . . . . . . . . . . . 288
Ss16 s 124. . . . . . . . . . . . . . . . . . . . . . . 290
Ss16 s 125. . . . . . . . . . . . . . . . . . . . . . . 292
Lesson 126 TITLE= Work Packages 4/4 . . . . . . . . . . 294
Lesson 127 TITLE= Eqn Paper_1 Qn_13 - Ss16 s 127. . . 295
17 Frequent Releases (focus area) . . . . . . . . . . . . . 298

17 Lesson 129 TITLE= Frequent Releases (focus area)
Section Overview: 2 - Ss17 s129. . . . . . . . . . . 298
CONTENTS
Lesson 130 TITLE= Frequent Releases : focus area 1/2 -

Ss17 s130 . . . . . . . . . . . . . . . . . . . . . . 300
Lesson 131 TITLE= Frequent releases 2/2 - Ss17 s131 . . 302
Lesson 132 TITLE= Exercise-12: Release Plan - Ss17 s 132
Exercise. . . . . . . . . . . . . . . . . . . . . . . . 304
Lesson 133 TITLE= Paper_1 Qn_44 - Ss17 s133 Eqn. . . 305
18 Scrum theory & practice & artefacts and events . . . 308

Lesson 135 TITLE= Scrum theory & practice & artefacts
and events Section Overview - 6 - Ss18 s s135 . . . 308
Lesson 136 TITLE= Scrum : what is it? 1/6 - Ss18 s s136. 310
Lesson 137 TITLE= Scrum theory 2/6 - Ss18 s137 . . . . 312
Lesson 138 TITLE= The Scrum team 3/6 - Ss18 s138 . . . 313
Lesson 139 TITLE= Scrum events 4/6 - Ss18 s139. . . . . 315
Lesson 140 TITLE= H Scrum animation . . . . . . . . . 317
Lesson 141 TITLE= The 5 Scrum events 5/6 - Ss18 s141. . 318
Lesson 142 TITLE= Scrum artifacts 6/6 - Ss18 s142. . . . 322
Lesson 143 TITLE= Case-8: Critique a Work-Package -
Ss18 s143. . . . . . . . . . . . . . . . . . . . . . . 326
Lesson 144 TITLE= Back@Work-SkillBuilder-9: Build-
ing Lego Animals - Ss18 s144. . . . . . . . . . . . 327
19 Kanban Method . . . . . . . . . . . . . . . . . . . . . . 328

19 Lesson 145 TITLE= Kanban Method Section Overview:
8 - Ss19 s145 0/8 . . . . . . . . . . . . . . . . . . . 328
Lesson 146 TITLE= Kanban and the Kanban Method 1/8
- Ss19 s146. . . . . . . . . . . . . . . . . . . . . . 332
Lesson 147 TITLE= The 6 general practices of the Kan-
ban Method 2/8 - Ss19 s147. . . . . . . . . . . . . 334
ban Method 3/8 - Ss19 s148. . . . . . . . . . . . . 336
ban Method 4/8 - Ss19 s149. . . . . . . . . . . . . 338
CONTENTS

ban Method 5/8 - Ss19 s150. . . . . . . . . . . . . 340
Lesson 151 TITLE= Kanban : further guidance 6/8 - Ss19
s151.. . . . . . . . . . . . . . . . . . . . . . . . . . 344
Lesson 152 TITLE= Cumulative Flow Diagrams (CFDs)
7/8 - Ss19 152. . . . . . . . . . . . . . . . . . . . . 347
Lesson 153 TITLE= Cumulative Flow Diagrams (CFDs)
7/8 - Ss19 153. . . . . . . . . . . . . . . . . . . . . 352
Lesson 154 TITLE= Kanban hints 8/8 - Ss19 s154. . . . . 353
Lesson 156 TITLE=Case Exercise-15: Kanban - Ss19 156 . 357
20 Plans theme & estimating . . . . . . . . . . . . . . . . 358

Lesson 157 TITLE= Plans theme & estimating Section
Overview - 3 - Ss20 157 . . . . . . . . . . . . . . . 358
Lesson 158 TITLE= Plans : General view 1/3 - Ss20 s158 360
Lesson 159 TITLE= Plans : guidance 2/3 - Ss20 s159. . . 362
Lesson 160 TITLE= Estimation 3/3 - Ss20 s160. . . . . . 364
Lesson 161 TITLE= Exercise-10: Estimating . . . . . . . 367
Lesson 162 TITLE= Eqn Paper_1 Qn_30 - Ss20 162. . . . 368
21 Progress theme . . . . . . . . . . . . . . . . . . . . . . 370

Lesson 163 TITLE= Progress theme Section Overview: 4
- Ss21 s163. . . . . . . . . . . . . . . . . . . . . . 370
Lesson 164 TITLE= Progress : General view 1/4 - Ss21 s164 372
Lesson 165 TITLE= Progress : guidance 2/4 - Ss21 s165. . 375
Lesson 166 TITLE= Burn charts 3/4 - Ss21 s166. . . . . . 378
Lesson 167 TITLE= H Burn charts . . . . . . . . . . . . 380
Lesson 168 TITLE= Information Radiators 4/4 - Ss21 s168. 381
Personal Progress Check-Point!. . . . . . . . . . . . . . 382
22 Quality theme . . . . . . . . . . . . . . . . . . . . . . . 385

CONTENTS
Lesson 171 TITLE= Quality theme Section Overview:

0of3 - Ss 22 s171. . . . . . . . . . . . . . . . . . . 385
Lesson 172 TITLE= Quality : General view of Agile
Quality 1/3 - Ss22 s172. . . . . . . . . . . . . . . . 387
Lesson 173 TITLE= Quality : Guidance 2/3 - Ss22 s173 . 390
Lesson 174 TITLE= Quality How to test 3/3 - Ss22 s174. 392
Lesson 175 TITLE= Quality in relation to Scope 4/4 . . . 396
Lesson 176 TITLE= Exercise-11: Advert QC - Ss22 s176. 397
Lesson 177 TITLE= EqA Paper_1 Qn_18 - Ss22 s177. . . 398
23 CS {{Controlling a Stage}} . . . . . . . . . . . . . . . . 400

Lesson 178 TITLE= CS Section Overview : 5 - Ss23 s178. 400
Lesson 179 TITLE= Controlling a Stage 1/5 - Ss23 s179. . 402
Lesson 180 TITLE= {{Controlling a Stage}} Guidance -
Ss23 s180. . . . . . . . . . . . . . . . . . . . . . . 405
Lesson 181 TITLE= Retrospectives 3/5 - Ss23 s181. . . . 407
We are at the 80% point! Perhaps you too should take a
retrospective. . . . . . . . . . . . . . . . . . . . . 408
Lesson 182 TITLE= {{Controlling a Stage}} - Ss23 s182 4/4. 410
Lesson 183 TITLE= A26-Work Packages & Interface
from PM to Teams - Ss23 s183. . . . . . . . . . . . 411
Lesson 184 TITLE= EqA Paper_1 Qn_35 - Ss23 s184. . . 413
24 SB {{Managing a Stage Boundary}} . . . . . . . . . . . 415

Lesson 185 TITLE= SB Section Overview: 3 - Ss24 s185 . 415
Big messages from chapter 21 are:. . . . . . . . . . . . . 416
Lesson 186 TITLE= SB What you may Find 1 /3 - Ss24 s186 417
Lesson 187 TITLE= SB What To Do 2/3 - Ss24 s187. . . . 419
Lesson 188 TITLE= SB How it might look 3/3 - Ss24 s188. 421
Lesson 189 TITLE= Back@Work Exercise-13: Retro-
spectives - Ss24 s189. . . . . . . . . . . . . . . . . 423
25 CP {{Closing a Project}} . . . . . . . . . . . . . . . . . 424

Lesson 190 TITLE= CP Section Overview: 3 - Ss25 s190. 424
CONTENTS
Lesson 191 TITLE= Closing a Project: What you may

find - Ss25 s191. . . . . . . . . . . . . . . . . . . . 426
Lesson 192 TITLE= Closing a Project 2/3 - Ss25 s192 . . 427
Lesson 193 TITLE= Closing a Project 3/3 - Ss25 s193 . . 430
Lesson 194 TITLE= Eqn Paper_1 Qn_34 - Ss25 s194 . . . 432
26 DP {{Directing A Project}} . . . . . . . . . . . . . . . . 433

Lesson 195 TITLE= DP Section Overview: 3 - Ss26 s194. 433
Lesson 196 TITLE= Directing a Project 1/3 - Ss26 s195. . 435
Lesson 197 TITLE= Directing a Project 2/3 - Ss26 s196. . 436
Lesson 198 TITLE= Directing a Project 3/3 - Ss26 s197 3/3. 437
Lesson 199 TITLE= eqn Paper_1 Qn_14 - Ss26 s198. . . . 439
Lesson 200 TITLE= H Agenda for Day 3 . . . . . . . . . 440
27 Agile Contracts (focus area) . . . . . . . . . . . . . . . 441

Lesson 201 TITLE= Agile Contracts (focus area) Section
Overview : 1 - Ss27 s201. . . . . . . . . . . . . . . 441
Lesson 202 TITLE= Agile contracts 1/1 - Ss27 s202. . . . 444
28 Appendix A and B . . . . . . . . . . . . . . . . . . . . 447

Lesson 203 TITLE= Appendix A and B : 2 - Ss28 s 203. . 447
Lesson 204 TITLE= PRINCE2 Management Products
and Roles 1/2 - Ss28 s204. . . . . . . . . . . . . . . 448
Lesson 205 TITLE= Tailoring of the PRINCE2 Products
2/2 - Ss28 s205. . . . . . . . . . . . . . . . . . . . 453
29 Rich Comms . . . . . . . . . . . . . . . . . . . . . . . . 455

Lesson 206 TITLE= Rich Comms Section Overview: 3 -
Ss29 s206.. . . . . . . . . . . . . . . . . . . . . . . 455
Lesson 207 TITLE= Rich communication : focus area 1/3
- Ss29 s207. . . . . . . . . . . . . . . . . . . . . . 457
Lesson 208 TITLE= Rich communication 2/3 - Ss29 s208. 459
Lesson 209 TITLE= Workshops 3/3 - Ss29 s209. . . . . . 461
Lesson 210 TITLE= Exercise-14: Preparing a Workshop
- Ss29 s210 . . . . . . . . . . . . . . . . . . . . . . 463
Lesson 211 TITLE= Paper_1 Qn_43 - Ss29 s211. . . . . . 464
CONTENTS
30 Apdx C: Health Check . . . . . . . . . . . . . . . . . . 467

Lesson 213 TITLE= Apdx C: Health Check Section Overview:
1 - Ss30 s213 . . . . . . . . . . . . . . . . . . . . . 467
Lesson 214 TITLE= Health Check (Appendix C) 1/1 -
Ss30 s214. . . . . . . . . . . . . . . . . . . . . . . 468
31 Apdx F & G: Transition & Project manager guidance . 470

Lesson 215 TITLE= Apdx F & G: Transition & Project
manager guidance Section Overview : 2 - Ss31
s215 Apdx F Tranisation & G; Guidance to newly
Agile PMs 0/2 . . . . . . . . . . . . . . . . . . . . 470
Lesson 216 TITLE= Transitioning to Agile 1/2 - Ss31 s216. 472
Lesson 217 TITLE= Advice for a Project Manager using
agile 2/2 - Ss31 s217. . . . . . . . . . . . . . . . . 474
32 Whole Course Summary . . . . . . . . . . . . . . . . . 476

Lesson 218 TITLE= Course Summary - 0of1 - Ss32 218 . 476
Lesson 219 TITLE= In summary - Ss32 s219. . . . . . . . 481
33 Contact Details . . . . . . . . . . . . . . . . . . . . . . 482

33 Lesson 220 TITLE= Contact Details - Ss33 s220. . . . 482
Lesson 221 TITLE= Contact - Ss33 s221. . . . . . . . . . 483
Lesson 222 TITLE= Who Are Logical Model Ltd (LML)?
- Ss33 s222. . . . . . . . . . . . . . . . . . . . . . 484
Lesson 223 TITLE= Links To Evaluation & Free for
Personal Use Course Materials - Ss33 s223. . . . . 485
AND. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
We sell our courses like this one via online platforms.
Often B-2-C. . . . . . . . . . . . . . . . . . . . . 487
Lesson 224 TITLE= Help! - Ss33 s224. . . . . . . . . . . 488
34 The Exam . . . . . . . . . . . . . . . . . . . . . . . . . 490

Lesson 226 TITLE= The Exam - Ss34 s226. . . . . . . . . 490
CONTENTS
If you havent already booked an exam . . . . . . . . 491
35 End of slide deck . . . . . . . . . . . . . . . . . . . . . 492

Lesson 227 TITLE= End of slide deck Section Overview
- Ss 35 227. . . . . . . . . . . . . . . . . . . . . . 492
Lesson 228 TITLE= Who Are Logical Model Ltd (LML)?
- Ss 228. . . . . . . . . . . . . . . . . . . . . . . . 495
0 Hello and a very warm
welcome.
#
Hello, welcome to this training course. - Ss0 s1 Welcome.
Lesson 1 Your Journey with Presenter:

Simon Harris PRINCE2 P2A CGEIT PMP
IPMA-D .
Hi, I am Simon.
Ill be your host and trainer on your journey. I fully support this
course. To contact me; in email use p2a@logicalmodel.net or call
+44 (0) 84 52 57 57 07. Or join the courses discussion forum where
0 Hello and a very warm welcome. 2
youll find peer support from fellow learners for case study work
and community.
For many years Ive worked as a freelance contractor. Contracts
have taken me to many organisations and industries. All of them
have cultures and norms that have given me alternative perspec-
tives and different insights.
As course host Im going to share all those insights with you and
use them to explain the benefits to you of all the ways of working
that the axelos prince two agile manual contains.
If you are curious about agile this course gives you a hype-free and
pragmatic tour of the mind-set, frameworks and techniques.
If you curious about what prince might offer you as an agile practi-
tioner then this course explains how prince and agile complement
each other. The synergies are greater than the parts.
Used with understanding rather than dogma its a great win win.
Pretty soon we must cover a few ins and outs of the navigation
through the available course materials. Your reading this! you can
also listen to it as .mp3 or watch as .mp4 perhaps in an online
learning management system (LMS). Appart from sentences like
this one they are all identical after that. So sometimes a comment
is platform specific and not relevant to your current platform.
For example if your following the course in an app then some apps
will stop till you
Podcasts and eBooks give you the video sound tracks of a whole
section of lessons as a unit. So you can relate the references to the
visual elements I have included the full set of the large-scale slide
images and these notes in the Courses Download unit. The full
downloads also include all the axelos official practice exam papers,
but more on them later.
A Story.
Let me start describing how this course benefits you with a short
story. I remember a past project where we were struggling with
deadlines. Our 2nd project manager in 4mths announced one day
he had a new job. Within a week he had said good bye and he had
actually left. In that last week I went to my PMs boss to ask for the
newly empty role. He basically told me if I wanted it Id take the
actions that fixed the issues and it would be mine.
I was team leader at the time, I knew I had a good team and that
the best chance of success would be to rely on all our capabilities.
As a team we sat together, knew what we had to deliver, who was
good at what and we had two large white-boards on our walls. In
that week we broke the work down into small pieces; about a day
or twos effort each and wrote the work to be done on the white
boards. Probably more often than daily we discussed who would
take the next item as we came to the point where something was
ready for assurance or someone was ready for a new task. Over a
few weeks our joint efforts resolved the delays and we settled into
a regular pattern of incremental deliveries.
As the major deliveries were completed I asked the customer,
a manager in another department to take the lead in telling us
what we should deliver each month. We developed a stable and
productive regime.
About a year into enjoying this new role I left to broaden my
experience. Other organisations since then have all taught me a bit
more about how to create a delivery culture by harnessing team
ability and focussing the customer on value to them.
Ok are you ready for introductory breadth to give some overview
before we embark on depth in later lessons?.
End.
TITLE= Our Topic: PRINCE2 Agile
Lesson 2 TITLE= Our Topic: PRINCE2

Agile
In this course we will explore together AXELOS definition of agile
ways of working.
We cover how to tailor PRINCE for use with agile techniques and
frameworks, concepts and behaviours.
PRINCE2
prince is a project control structure. It proudly declares that it

applies to any project of any size in any industry and any context.
It is right too. I personally know of a multi-billion dollar LNG
project run to prince even though the prince name does not appear
anywhere in the companys in-house documentation.
PRINCE2 is a registered trade mark of AXELOS Limited.
In fact they use standard Oil industry terms like assess, select,
define, execute, operate but the heartbeat is p2. prince terms like
Corporate or Programme Management dont appear in in-house
standards but a group called the Investment Committee perform
exactly that role. But lets stay on the agile prince topic.
Agile is sometimes seen narrowly as an approach for software
development and it works great there. Partly because software has
no physical deliverable and its suits the human ability to excel
through a refinement based approach. Consider for example how do
world class athletes get to be world class? Refinement or in athletes
vocabulary practice.
The truth is any work based on skill, intellectual property or
knowledge and service delivery can be equally flexible in approach
and so can easily benefit from agile practices. So can work with
physical results, but aspects like iterative & incremental working
may be harder to install.
Agile offers the most advantages where there are high degrees of
complexity for example from novelty situations and or from a need
to get many elements interacting. These challenges are true of many
many fields of activity and an agile approaches suit them all.
Avoiding fragile agile and seeking robust agile with adequate
control isnt a trade-off. We dont have to compromise agile ways
of working to add governance.
The insights about how to combine prince and agile create synergy
without either compromising the other. It really is fine marriage.
An aside:
In text PRINCE2 and prince2agile peppered across a page is

pretty dominating of the text so from now axelos prince2agile
guidance is P2A or just p2a, agile is agile and prince2 is plain prince.
PRINCE2 Agile is a trademark of AXELOS Ltd]
P2A follows princes 7 principals and tailors the application of the 7

processes and 26 templates and 9 roles and the 7 themes so you can
adopt agile in as broad a choice of settings as you can imagine.
Ie in every project irrespective of its industry, size, specific nature
or its context.
I have been using and teaching the concepts and techniques of agile
and adaptive project management in broad industry contexts for
many years.
(Its probably more than 20 years since I delivered my first project
management training class and Ive worked in projects and pro-
grams for over 30 years).
Through out that time Ive followed or created and rolled-out many
governance, control and management structures by incorporating
best of breed ideas. Both P2A and I are focussed on how we use
agile and complex adaptive systems principles without being bound
to an IT world.
It is important to say right from the start that this course is focussed
on passing AXELOS practitioner exam.
Before I go further be aware that while there is a lot of practitioner
value in this course sitting the exam requires you already hold the
prince practitioner certificate. If you dont yet hold the PRINCE2-
Practitioner certificate then we have course materials for that too
: details on our website http://learn.logicalmodel.net/prince2exams
and in the course resources.
The Official PRINCE2Agile Manual.
The exam is wholly based on axelos official manual whose contents

is illustrated here.
The bullet pointed slide contents and base graphics from the official manual on
lessons with AXELOs logo are AXELOS Limited 2015 All rights reserved. Material in
this document has been sourced from [PRINCE2 Agile 2015]. Materials is reproduced
under license from AXELOS. Everything else is Logical model Ltd 2015 all rights
reserved. No part of this document may be reproduced in any form without the written
permission of both LogicalModel Ltd and AXELOS Limited. Permission can be requested at
www.logicalmodel.net and licensing@AXELOS.com.
Your Benefits.
Passing the exam is often a differentiator for selection in job

interview and promotion situations. Proposing qualified staff in
bids may not be a contract clincher but proposing unqualified staff
always weakens your potential.
The investment you have to make tells future customers, promotion
boards or potential employers that you invest in capability devel-
opment.
We have made plenty of samples of these course materials freely
accessible so you can confirm their quality before committing your
precious time. Its the time cost more than the money. You can
never get the time back. We believe that as a bonus we are also
the cheapest source of qualification. Invite us to price match if you
find something cheaper what ever their quality.
Understanding agile concepts will give you the confidence to talk
and act from the position of knowing a broader, proven personal
toolkit of techniques for personal and company success.
It is unlikely an exam pass on its own gets you a promotion or job
offer but so often in selection for interview its the certificate not
the long resume of experience that gets the interview invitation.
Sitting the exam requires that you have a sponsoring Accredited
Training Organisation (known as an ATO). We automatically be-
come your exam sponsor when you follow our course materials.
2 Contact>
Dont forget I fully support your journey to exam success. Visit

Http://www.logicalmodel.net/prince2exams for details of booking
exams. eMail, p2a@logicalmodel.net for help or comment in the
eLearning community & disqus streams. Whatever your platform
or app there will be resources links somewhere!.
Exam.
For most people an online exam, perhaps taken at home and

proctored through a web-cam is most convenient.
If you have a group of people and want a live instructor led
training and exam event then we can support that too. It requires a
conversation to explore the details.
3Fone>
Our uk local rate number is +44 (0)84 52 57 57 07. Also contact us if

you would like badged materials loaded to your own LMS.
Course Media Choices and Their Navigation.
Lets advance to the next lesson and Ill cover the housekeeping of
navigation.
End.
TITLE= Media, Navigation & SubSections - Ss0 s3
Lesson 3 TITLE= Navigation &

SubSections - Ss0 s3.
You have a number of choices for course media. The pros and cons
and navigation vary a bit with delivery platform.
You could be watching and listening to an app showing animated
narrated lessons on a smart fone or computer or following videos
in an online LMS; Learning Management System or reading a mobi
or pdf file on ipad or kindle (so currently your reading text! 99% the
same words as in the videos).
Small navigation challenges we need to address are Smartphone
& ebook reader screens versus diagram detail like our whole of
manual overview a few pages back.
eBook materials, Apps and online learning systems support down-
loading of materials, include search functions and legible slide im-
ages and a lot more resources besides and all designed to make this
course self-contained. Free previews can access less than students of

the full course materials. Everything is accessed through either your
original platform, eg leanpub, kindle/ amazon, or by going back to
the source http://learn.logicalmodel.net.
On this slide is the list of subsections and their slide counts. Note
Ill call the courses collections of topic related lessons, revision aids
and quizzes subsections and the official manuals chunks chapters
to help make explanations clear.
The first slide of each section signposts what is coming in this
section and section 32s text summarises it all. There is an argument
for doing lesson 219 from section 32 next as overview.
Whether you are following these materials by watching videos on
an in-house Learning Management Systems or an internet delivered
Open Online Course or an app etc somewhere there will be a
transcript of the narrations, the very useful capability; the search
box in apps & text readers helps targeted revision. 99% of lessons
text links the lesson to the exam syllabus and 100% of exam
questions link to the syllabus. A useful bridge for checking where
to revise more. Details later.
Also somewhere on your platform will be a link to the wealth
of additional online resources such as revision aids, quizzes and
preparation exams. Some course material is to counter issues of di-
agrams on small smartfone screens, some to ensure comprehensive
coverage for exam preparation, some to listen to on a spincycle or
on the commute to work to optimise otherwise dead-time.
The app works across iOS, Android and Windows. A single touch
then wait works reliably for me, its better on faster wifi. If this
slide is links then you have other controls for example to access
downloads directly and to skip back and forth in the narrations and
timeline. It wont be links on most video delivery platforms.
5andThese>
In apps the yellow home button on the slide, top left corner brings
you here and the U shaped button takes you back to where you
were. On some platforms its a toggle between two places and on
others it chains back and back through your page history.
If you have thumbnails they are headings that will expand or
collapse for overview or detail.
In formats like youTube youll have to navigate serially and wont
have everything Im describing until you subscribe to the online
LMS for full access.
[[What ever your access route perhaps for this section just follow
the introductory audio. The animations will run automatically upto
end of slide.]]
(Whether online open course, video or app you will see
Another Navigation angle is the structure and content of these
materials. We, Logical Model Ltd have augmented and tailored
axelos base material for our training deliveries.
That tailoring includes dividing them into 36 short sub-sections.
The first 4 and section 19 on Kanban are the longest and even then
all are 10 lessons or less. Most are 4 lessons long or less. All are
comprehensive. Many bite sized chucks that together in total are
exhaustive. Some will reward you if you visit them twice.
In video and narrated app Ive used one of two conventions when
on the lessons axelos provide that are mostly text so you can link
narration to slide content.
I highlight or reveal the bullet points as they become relevant to
the discussion either as the topic starts so as to introduce it or
ends to summarise it. A little variety to avoid monotony without,
I hope bewildering change. The purpose is so you can focus on the
narration & linked text. Reading one bullet point while listening to
words explaining another weakens your later recall. There is logic
to my order which may stray from starting at the top and finishing
at the bottom of bulleted lists.
Our, Logical Model Ltds materials include the lessons that axelos
supply and are common across many training companies but we
also supply this text and the videos in which every word and
animation is totally unique to our production, the text of the
narrations which is downloadable on a per section basis as text and
.mp3 pod-cast, the mock exam papers in the course resources are
axelos official preparation material but our examiners analysis of
answering strategies is unique to our course. As are the revision
aids within many of the courses 36 sections.
The revision aids are designed for you to read through more than
once. 1st pass tells you details you wont always have covered in the
narrated videos : eg reading out tables mapping agile artefacts to
prince2 management templates. Subsequent use tests if you recall
the facts. You must ask yourself for each entry if you understand
where items fit in the whole picture, where links between items or
sections exist etc.
Use your results from practice exams and from reviewing revision
materials to guide you on where to revisit topics and dip into the
materials a second or maybe even third time because of doubts and
errors, or where there was discovery through the exam preparation
aids. Also dip back into the materials where you have any confu-
sion. The syllabus references in exam questions and the lessons text
helps. I have not narrated the cross references.
1 Introduction & Context
Introduction & Context
Lesson 4 TITLE= Introduction & Context -

Section Overview : 5 slides - Ss1 s4.
Being focussed on the exam has pros and cons.
1 Exam>
My reason for stating it right up front is so you appreciate what

we cover in these AXELOS supplied course materials is what the
AXELOS manual says.
1 Introduction & Context 16
Neither your nor my opinions nor experience with other routes to

successful projects counts in the exam.
Ill use experiences to illustrate points, Ill sign-post many additions
and alternatives but in this course I wont include any argument
with the manual because that does not help an exam pass.
To give the best added value while staying true to an exam focus
I will highlight where there are sources of more information than
the exam focus demands.
Check-out our non-exam courses for the best insights from all
sources, compiled without fear or favour to specific exam boards.
The damage done here if adding details of other opinions is that
anything that is not what the manual says is not the source of a
pass and is potentially confusing to you at exam time. You would
have to remember is that exam answer or real world?
Tough Exam.
The exam is really tough so we need to be really focussed.

Widest insights normally make the best courses but not in this case;
however this material is an excellent and pre-requisite foundation
for those wider influences and ideas.
Details of non-exam courses are in the course resources, at the end
of the course within the video/ eBook and on the web-site.
2 Man&Addy>
The exam is based on the official manal. The books list price is
99quid, 99gbp , We have discounted it to 69 plus pnP. if you
want copies visit Http://www.logicalmodel.net/shop and head for
management books.
Ive tried really hard in this course to be exhaustive so that you
dont need to also read the manual as well as study this course.
If Ive succeeded that saves you time and money straight off.
Because of that if Ive succeeded Im making an early adopters
offer for those willing to take the plunge, study from just the course
and then give me feedback.
We know for sure that people use our standard prince materials and
pass without needing that manual.
See the platforms text resources for details of the early adopters
offer.
Repeat! It Is A Tough Exam.
While your thinking about whether you need the manual I want to
repeat to you as of now, the exam is tough.
Ive taken the exam. This course is full of my lessons learned for
your guidance. I think I can claim good insight. Once upon a time
I was a prince examiner. Im not now because now everything
is marked by scanning tick-sheets but it taught me how exam
questions are structured when created and Ill share that for you
as insight into how they are decoded.
To pass the exam you really are going to have to understand P2As
reasons for its contents. That stands you in good stead for real world
use too.
Good understanding is required to be able to make fine distinctions
about how it applies in reality and so how to get the practitioner
exams questions on use right. It is a good exam but none of that
exam success stuff is in the 99 book. But it is in these course
materials.
A tough exam should be good news. If you pass the exam it will
confirm that you know this stuff at a much deeper level than just
reading the manual. If the exams reputation is that it is tough it
will count for something in the market place.
Passing the exam means you know what agile behaviours and
techniques to instil in your project participants and you know how
to use them yourself.
So while the Official manual has a 99 quid list price tag, probably
75 to85 from us by the time you add pnp. The official manual
isnt a training aid and this course is. That should be an argument
justifying not buying the manual BUT to be balanced.
The exam is open book. The manual has at least 45 wholly blank
pages on which you can make notes. It might be expensive note
paper but its a sure-fire way and the only way to take a crib-sheet
into the exam!.
So if you are cautious or your memory is like mine I think you
should buy a copy. If you do that I recommend a paper copy
rather than a pdf version. You cant use the pdf version in the web-
proctored exam although you can print it and take the printed copy
in with you then the proctor wants to check you havent added
anything to it. Better to buy a paper book and a highlighter.
To buy either version of the manual from me, see the course
resources tab or visit www.logicalmodel.net/prince2exams Alter-
natively go to amazon and other online sources.
Specialist book sellers have a faster but less personal despatch
processes than me and some sell it with free shipping. I don think
any match my discount.
What I do know booksellers cant match is they cant be your
sponsoring ATO or reserve you an exam or support your study
:By you following our course materials we are automatically your
sponsoring ATO.
Lets prepare to explore course Objectives by considering some
points of overview.
The first point to note is that in giving you overview Ill use a few
terms ahead of their detailed explanations.
Ive made the assumption youll cover the materials in order. If

so then explanations build on each other so that everything is
introduced gentle to start and is treated in detail before the end. The
overview gives breadth. All the depth is methodically explained as
we go.
The overview point that really deserves to be first is that P2A is the
whole of P2. Nothing deleted and lots added.
3 Next>
By added I mean two things.
TITLE= Course Objectives : 1/5 - Ss1 s5

Lesson 5 TITLE= Course Objectives : 1/5 -

Ss1 s5.
What is added is the interpretation of the whole of the prince

method.
P2A tailors prince to work with an agile mindset. The mindset is
[[behaviours, concepts, techniques and frameworks]] : internalise
that set of 4 items.
The manual and hence the exam dwell on three frameworks; scrum,
kanban and lean-startup, their values and beliefs. Other approaches
get a mention but not a lot more.
Sometimes the interpretation given is in ways that many of us will
say of course that is the sort of common sense Ive been applying
since I passed my prince practitioner exams and used prince for real.
Each time that is your reaction then great. But any time you catch
yourself saying the equivellent Thats not how Id do it put that
thought aside till after your through earning your qualification.
1 Flow>
If your prince is rusty because you havent thought about it much

since your practitioner exam then that is an extra few degrees in
the gradient of your learning curve.
It isnt a huge additional issue over the challenge of the P2A content
to the exam. Ill refresh it for you as seems relevant and I have
revision support aids for you to download.
We will explore this prince on a page graphic later. P2As obvious
focus is the 6 boxes middle centre, Three yellow facing off to three
brown, {{Controlling a Stage}} to {{Managing Product Delivery}}
It is the key interface. But P2A is a lot more than the obvious
interface. Key messages are about infusing the agile mindset into
everything up to and through the project managers and Project

Boards behaviours too.
Let me also tell you here that Ill make many key points as we go.
When introduced as quotable or a big message or when you hear
something being repeated you should recognise it as key.
When I use these sign-posts youll know what to make notes
about. My guess is everyone except those people with exceptional
memories or those people who are very clear on their own study
methods are going to need to make notes. Since the exam is open
book and the manual has a huge number of blank pages that is the
best place to make your notes if you spend the extra 99
1txt & yellow P1>
To succeed you will have to understand behaviours, concepts,

techniques and frameworks considered more or less agile.
Lots of details as we go. Youll come to appreciate how agile
provides a product delivery focus : ie a focus on doing the work
that creates business outputs and so enables the benefits or value.
We might call it the technical specialists work as opposed to the
managers control work.
Technical work is activity like building a bridge, running a market-
ing campaign, arranging a concert tour, or developing a new prod-
uct with multiple work-streams spanning concept development and
perhaps also including a marketing campaign as a workstream with
its own team manager. Agile gives us focus on the products that the
business needs to generate value.
pt 2>
Prince gives us a light-weight, un-intrusive and adaptive control

structure.
Yeah that might not be its reputation but when used correctly
it is actually the truth. P2A might just be the mechanism that
raises peoples appreciation to be well-informed rather than miss-
informed.
Combining prince and agile creates synergy. prince is already fully
agile enabled, note the phrase and this one nothing is removed
from prince to use it in agile ways & with an agile mind-set.
pt 3>
The P2A official manual is 28 chapters and 8 appendices. The last 5

chapters are called focus areas.
In reverse order the focus area are: How to do contracts in an agile
world, The concept of frequent releases for incremental delivery
and A focus on rich communications like burn charts and infor-
mation radiators. IRs are high visible status boards on the walls of
the delivery teams work-place. Wall displays are lo-tech and tactile,
and the team keeps them updated in real-time.
The last 2 focus areas are Agile techniques for the expression of
requirements such as user stories and firstly (recall Ive done this
list in reverse order) a 6 scale Suitability metric called under the
very 1980s style sobriquet the AgiloMeter.
The Agilometer highlights any risk we should consider responding
to that is created by choosing to use an agile mindset and the
business readiness to actual do what being agile requires, for
example to trust and empower people .
pt-4>
P2A takes princes 6 dimensions of flexibility or tolerance.

Now here is a small test: (Can you recall those?, Maybe hit pause
before I give you a hint).
5Hint Arrow>
Heres a hint on the 6 tolerances.

Maybe hit pause to have thinking time?.
They areTime, Cost, Quality, Scope, Risk and Benefits. P2A says
T & C are baselined so changing them is a big deal involving
change control. Treat them always as fixed. But scope and quality
are treated as fully flexible to accommodate constraining time and
cost.
Actually this isnt draconian or a daft decree or an excuse for poor
quality but Ill need to explain the P2A view of the mechanisms and
concepts that are the application of Agile to prince and application
of Prince to agile.
6 pt-5>
P2A is princes 7 principles, 7 themes, 7 processes, 9 roles, 12

baselines, 6 sets of records and 8 pre-defined reports (these last
three sets being the 26 entries of appendix A that have always
been called document templates but are now information sets. P2A
reinterprets all the principles etc. So the 26 information collections
of Apdx A dont have to be documents they can be lo-tech, tactile
wall displays.
7 pt-6>
Through out Ill introduce exercises and exam question analysis.

They give you a break from theory input mode.
Exercises are important so that you consider the meaning of and
relationship between the things I explain to you. Exercises test your
practical understanding.
Ill also pose and then analyse practice exam questions through out.
They will show you the exam style. You will have to get into the
head of the question setters to answer the questions.
8 fade>
In my real exam there were about a dozen questions I was sure of

the answer the examiner wanted, about 25 that had some ambiguity
and about a dozen where the scenario could be interpreted in so
many ways I ended up guessing.
Informed guesses from a deep understanding of the P2A manual
perhaps but never the less still ending with a need to play the per-
centages split across more than one seemingly reasonable answer.
We have plenty of practice exam questions to come where I can
illustrate the points .
Take comfort in the fact that the pass mark is only 60% and its 2-1/2
hours for 50 mc questions so 3mins per question and open book : if
you spend the 99.
**
Lesson 6 TITLE= About yourself : 2/5 - Ss1

s6.
For classroom based courses we can all introduce ourselves in
person.
Here we do it through the LMSs facilities. If your on http://learn.logicalmodel.net
then the disqus forum is automatically linked to materials. Other-
wise the details of how to join the support group are https://disqus.com/home/forum/
.
In this medium Ill introduce me.

I live in Edinburgh Scotland with my wife Lea and my adult
returned to the nest daughter and son Jessica & Toby who enjoy
a low overhead rent free existence : at least for now.
I started work as a programmer and then project manager and have
worked across many organisation as divers as GE the UN, banking,
oil and gas and defence. Clients are an alphabet soup of global blue-
chips through to small niche companies.
During that time Ive run projects, troubleshot operational de-
partments, been a prince2 examiner and taught a wide variety of
project management training courses from prince2 and PMP exam
preparation to Effective team development and communication and
more besides.
My consulting activities focus on improving the state of the art in
project management Something an agile mindset combined with
openness to adopt, adapt and integrate the best of ideas from all
sources greatly enhances.
TITLE= About the manual : 3/5 - Ss1 s7
Lesson 7 TITLE= About the manual : 3/5 -

Ss1 s7.
The P2A Manual is 342 pages long.

Actually it isnt anywhere near that bad. 100 pages are either
completely blank or just a chapters header page devoid of content.
Another 91 are 50% or more white space, picture or otherwise low
to no value illustrations.
But We have 150 pages left and I will give detailed guidance about
them.
1 pgi-xv>
After the official manuals initial pages that list the chapters, figures
and illustrations are three major SubSections Parts 1 to 3 and then
the 8 appendicies.
2 HiLt>
The first part is Introduction and overview. Its 40 odd pages.
3 Manual>
It looks like this in over view. Here Ive removed the 17 content free
pages from the illustration.
The second section is P2As guidance on using quote agile be-
haviours, concepts & techniques and on tailoring prince : this is
where all the how-to will be covered after the rather conceptual
start : sorry about that but bear with it you do need the concepts as
foundation for practitioner insight that is coming.
4 Mid>
Part two includes guidance on applying P2As view of agile tech-

niques. This second section is just about 100 pages worth of detail
excluding blanks, chapter headers and filler pictures.
In here we get an explanation of how agile works, mostly from the
perspective of three frameworks: scrum, kanban and Lean Start-up.
The middle and last section are the two place where we will spend
the most time.
The middle section starts with a chapter on the 7 prince2 principles
then gives us one chapter for each of the 7 prince themes, then 6
chapters for the 7 prince processes (the su and Initiation Stage are
combined).
Finally the P2A manuals middle section ends with a chapter on
tailoring prince2s 26 appendix A management products or infor-
mation sets .
By the time we have covered part 2 we mostly know what P2A
considers to be agile and what P2A tells us we need to do to
tailor prince and blend the best of two heritages for the strongest
synergies.
Each the theme and processes chapters have a similar structure.
5 Ovals>
First of all we get a reminder of what the standard prince manual

says.
This is not examined and these AXELOS supplied official training
slides omit the contents. Qualified p2-practitioners are assumed to
know it : Ill refresh it before we get to section 4 of these slides. I
also have some revision aids that may help. And recall the course
is instructor supported, just ask if you need more support.
After the normal prince bit of each chapter we get an interpreta-
tion or explanation of agile concepts and techniques followed with
discussion of the practicalities.
Finally a summary which includes acknowledgements and further
reading.
Further readings - like following up on my added value observations
- are not required for the exam because the exam is based on
the Manual but further reading is useful if you come to the topic
and want more background or detail in the agile concepts being
discussed.
I suggest saving exploration outside the course and manual for after
the exam. You dont want alternate opinions in your head till after
youve answered the exam questions.
6 FinalChs>
The third section is the focus areas which is the next 50 pages
and then the appendices which are the last 70 or 80 pages. These
approximate counts include the blanks.
Do you recall the 5 focus areas that I mentioned in reverse order

earlier?
Maybe Hit pause to think? Is this Welcome Back after the pause?
They are 1) Agilometer to measure risk from using agile, 2) Require-
ments; the mindset and techniques for the evolution of scope, 3)
Rich communications; a focus on face to face, the use of models and
pictures and workshops over documents and eMails, 4) Frequent
releases of capability for early generation of both project feedback
and business benefits, and 5) the treatment of contracts in agile
situations.
The appendices also deserve itemising.
They are first a precis of the regular Apdx A) Template information
set, B) is Role descriptions for prince and P2A roles, C) is a pj
health-check questionnaire, D) the pbp example reproduced from
the prince manual, E) the agile manifesto and a largish list of the
values and principles of many agile frameworks, F) Thoughts on the
transition when increasing organisational project agility, G) Advise
to PMs using agile which is excellent and Apdx H) is a reprint
of Sutherland & Schwabers Definitive Guide to Scrum. Apdx H
includes a number of points the P2A manual omits as well as not
saying a lot of things that the P2A manual does define, say, suggest
or even decree.
TITLE= About the exam : 4/5 - Ss1 s8
Lesson 8 TITLE= About the exam : 4/5 -

Ss1 s8.
All these mentions of the exam will reduce when we get past this
initial stuff. But to illustrate our target so we can stop mentioning
it quiet so much! Here is a little more detail.
The exam is 150 minutes for 50 open book multiple choice questions.
The first 7 are likely to be a test of your memory but nothing more.
Since the exam is open book if you bought it then youll have time
to look them up!.
The next 43 are a test of your memory, comprehension, sanity and
more.
There are two official sample exam papers within the course mate-
rials put together by the same team that sets the live exams.
You are going to need to study them carefully! You need to learn
to read from them the Role and or Timing and or other relevant
element such as which theme or process the answers must match.

It takes practice but Ill guide you.
An exam papers structure is three parts .
While studying we have a fourth part : the answers!.
1 Scenario>
First is a scenario that tells a story. It looks like this. The story is di-
vided into information that applies to all questions and information
that is relevant to sections of questions only.
When doing the exam at home the proctor will give you opportunity
to print the scenario at the exams start (and outside the allotted
question answering time).
When on paper the second part is the answer blank.
If you do a paper exam we will cover that then not now.
2 Qn35>
And third the question paper with the 50 questions. They look like
this. Each counts one mark, there is no negative marking for those
questions you have to guess at and you will have to guess some.
The pass mark is 30 out of 50 or 60%.
A rule of thumb might be that about 10-15 are bankers, the answer
is something you can be confident of if you have studied.
This includes the first 7 straight fact questions. Ace these so you
have 20 minutes extra in your time bank.
Check-out the course resource - revision aids. They will help you
get fluency and thus speed here.
Back to rules of thumb. Maybe 25 Qns have a justification you can
describe even if its not a black-and-white choice and 10 are too grey
to call one way or the other.
Check-out Qn 36 maybe hit pause to consider it (and 35)? Maybe

welcome back? Qn 36 is a banker the answer is C : If it isnt so clear
dont worry we will discuss question analysis in context.
Qn 35 is definitely A or B (C & D are factually wrong) but youll
have to recognise that only B explains why we use retrospectives
as opposed to how we set them up. Youll have to learn to read the
question stems. In this case how well requires that the explanation
answers why.
Ill show you truly ambiguous ones later : you need more context
for the discussion to be useful.
I suggest we use paper 1 while you sequentially study new materials
and reserve paper 2s questions for when you get to the end of your
full pass through materials as a full mock exam and to spot where
revision will be most useful the use the extra questions from the
revision aids.
A simple but vital rule is always give the manuals opinion. Know-
ing how to find that is going to take study of all the resources you
have, particularly the practice exams.
3 ExamQn>
Ive inserted official questions from paper 1 with their rationales at

the end of most sections for discussion of exam technique.
There formatting looks like this. These are the official mock ques-
tions just reformatted.
Maybe Hit pause if you want to try this one because the answer
is coming in a few seconds. This question should be a banker. Ill
explain in a moment.
Welcome back?
4Ans>
The red section is the chief examiners rationale. This is the fourth
part of the exam only available in the training course. Something
youll never get for the live exam!
In this qn we are told of requirements. A recurrent idea in P2A is
that scope is traded for deadlines.
The mantra is Always be on time. We are further told youTube
is a must-have, instagram is a should have and facebook is mostly
irrelevant so.
Answer A) doesnt make youTube zero tolerance : another way of
saying it is a must have,
b) requires you appreciated the significance of the question stems
detail that say acceptance criteria for where the video is available
c) makes all the delivery platforms equal importance when the
question stem tells us they are not equal and .
d) is a close match for the sentiment of the marketing teams beliefs
so the answer we need.
Hopefully you appreciate that the words in the question need to
be paid close attention! Perhaps you also see that understanding
of P2As expression of mindset : here that we sacrifice scope to hit
deadline : is key and together the wording and concepts are the core
of this question.
Youll be able to ace these questions before you get to the exam.
Maybe you aced it already and based on the right rationale.
TITLE= Exam structure : 5/5 - Ss1 s9
Lesson 9 TITLE= Exam structure : 5/5 -

Ss1 s9.
1 OB>
Hey did I give you the good news already! The exam is open book!!
And the not so good.
Hmm but only if you spend an extra 80-odd quid or 99 plus
shipping if you buy at full price (Why would you!?)
During the exam it is useful to refer to pages 40 & 41, 50, 58 & 59,
maybe 84, 138 definitely 205-8 and 216, and highly likely are those
like 147 & 164. Ill give further advise as we go. There is a lot in the
materials including the revision aids when we really get going to
ensure you know what is required to pass the exam.
Hmm, also if you are trying to look up lots in that open book then
150 minutes is likely to be what you need.
2 OTE>
I spent just on 2hrs.

But I was still working out the exam style and I studied from the
manual not from training materials. It may be an OTE made up
of Multiple choice questions but weve seen the potential answers
given need careful reading, reference to the principles and wording.
Its for this reason youll get the number of quotes coming your way
as we go. As well as careful reading of questions in the exam you
might need some teeth sucking and chin stroking before plumping
for an answer.
During study you might want to summarise each chapters key agile
points - as opposed to the prince refresher material.
Looking out for quotable phrases that can crop up in exam ques-
tions, Ill give lots to you as we go and the revision aids in the course
resources are specifically aimed at helping here, but in essence
as you follow my lead listen for decision making discriminators,
definitions and facts, sequences and roles etc. By etc here and
everywhere else I just mean this is not a complete list. When etc its
not at the end of a list I believe it is complete. These materials are as
rigorous as I can make them after multiple iterative and incremental
edits.
Here is the standard disclaimer These materials are offered as is
without promise of suitability for any specific purpose. The user
should satisfy them selves as to their suitability for specific purpose.
No liability is accepted for error, omission or addition nor for any
consequences arising from use.
For sure you need to practice the exam questions and chase down
their rationales for all those you get right or wrong.
Yep rationales for what you get right and wrong is the way to
prepare because the rationales reveal the style of the question setters
and the manuals author.
Expect to be tired after the exam, and expect to use the time.
3 50qn>
But also expect that study will reward you with 30 or more correct
answers and the 60% required to pass.
The number of questions available to you, but perhaps without
exactly the manual authors style is extended by the questions I
have created to support your training journey. Check-out the course
resource downloads for details.
Included in these questions are ones like what does this quotable
phrase convey? These questions are my way of drawing your
attention to what matters.
Ill cross reference the study resources. Ultimately my intention is
that the course is self-sufficient. Let me know if Im there yet.
I will do my level best to tell you everything material that the official
manual says. The question of purchasing to use the official manual
remains Ultimately your risk.
Obviously this AXELOS slides reference to a third day .
4 3day>
assumes an in-class event of three days!.

If your not inclass then you will need to book an exam via us as your
sponsoring ATO and the most likely route available to you is an
anywhere 24x7 anytime online booking. All you need is a computer
with web cam speakers and microphone : but not a headset : and a
clear desk or table in a quiet room.
Through the link in the course resources to make a booking (for the
community not using an app it resolves to http://www.logicalmodel.net/prince2exam
youll also find the exam questions and all other resources through
this link or on http://learn.logicalmodel.net.
Time now for section 2
TITLE= Online content only
Lesson 10 TITLE= Online content only.
Who provides practitioner certification? (Select all that are correct)

AXELOS are the certifying body The exams are administered &
proctored by our appointed Examining Institute Course materials
are provided by Logical Model Ltd heavily augmented from AXE-
LOS official template materials
How much of prince is used in p2a? 100% p2a just uses agile ideas
based on the principlesDeleteEdit
What are the manuals major chunks (Select all that are correct)?
Early chapter - Basic understanding and drivers Mid chapters
- What you may find & do for each of the prince Principles,
Themes, Process_activities and Products(Information sets) Final
chapter - 5 focus areas [ Agile risk assessment, Requirements, Rich
comms, Frequent releases, Contracts] and Appendices A-H [A:Info-
sets, B:Roles, C:Health check, D:PBP, E:Agile manifesto, extract,
F:Transition, G:Advice to PMs, H:Scrum-guide]
Exam facts - Select all that are correct Duration 150 minutes
Number of questions 50 Scenario based First 7 questions simple
facts Remaining 43qn tough interpretation of BEST application of
the manuals Available online 24 x 7 x 365 Proctored by a live proctor
through bespoke exam management software
What are the courses quotable phrases? Fragments and concepts
from the official manual that have a probability of turning up in
exam questions
2 Overview the basics.
Overview the basics : 10 - Ss2 S11 Hdr
Lesson 11 TITLE= Overview the basics -

Section outline : 0of10 - Ss2 S11.
Time to dive in and start the detail. Axelos have given us 10 slides
on which to base our lessons.
Here is the preview of what is coming in this section Im flagging
up the following points about what you should absorb.
Projects are not business as usual but bau is agiles original home.
2 Overview the basics. 40
The agile manifestos has 4 key points of what we prize over 4 other
important but less important points. All 8 items are still necessary
but one half are not as significant as they other half.
We introduce iterative product developments nature and compare
it to sequential technical phases.
We see what a mature agile environment has over a purely bau agile
context (Mature is the manual authors term for well functioning
agile projects).
We get the merest mention of a slew of agile frameworks; the
manual and exam will major on just three; Scrum, Kanban and
Lean start-up. But you still need to recognise the others from their
descriptions.
I hope that youll memorise the concepts, behaviours and tech-
niques common in agile : note here in agile because later (actually
chapter 7 paragraph7.4) they get slightly re-expressed as those
specific to P2A.
In general be sensitive to when I describe something as related to
agile versus as defined by P2A. P2A makes its own bold assertions
and it is these opinions that the exam questions need to score a
point.
In summary we are starting with the manuals chapter 1 and 2
PrinceTwoAgile intro and an overview of what do we mean by
agile?.
After that well do chapters 3 to 6 which will conclude the official
manuals Part One : we will have reached slide number 64 by then
: also note slide numbers always go up but not always by just 1 at
a time : dont worry nothing is missing its to aid production across
different media and versions : strictly when we get to the topic;
these are variants in Configuration Management terms.
1 Axelos>
Axelos are using their own advice. This link takes you to a short
video that tells their tale, told by their own project team members
rather than the methods authors.
End.
TITLE= Project or BAU : 1/10 - Ss2 s12
Lesson 12 TITLE= Project or

Business_as_Usual (BAU) : 1/10 - Ss2 s12
Learning Outcome 1. Assessment Criteria 1.2

This slide starts us on the official manual at Chapter 1 section 1.1
and the next slide ends chapter 1. We will have covered it all.
1 Bp1 >
Key messages here are that this manual tells us * how to configure
prince for use with agile on projects*.
We dont have a new method, we have a tailored one. Everything
from p2 is retained, sometimes reinterpreted like the need for a
highlight report could be met by the Project Board reading an
Information Radiator (aka Big Visible Chart : BVC) aka what is
displayed on the wall in the teams work space.
The chapter also gives us an opinion on what agile is and the how,
when who etc of using agile.
That is an opinion but it is THE answers in the exam.
Primary from this section is that agile can be used on routine
business as usual work and we must recognise that BAU is not
project work.
Thus for our P2A purposes we are only interested in using agile in
a project context. The manual tells us emphatically that P2A is a
projects only approach and tool-set.
This is not a position that is worth debating on the journey to
qualification so Im repeating it to you as a fact and we will move
on.
We also get told later (pg 216 in fact) that there is no such thing as
either an agile or non-agile project.
All projects are agile to a degree, it is just that the degree varies.
Remember this; it will very likely discriminate two exam answers :
no such thing as a totally non-agile work-package.
Table 1.1 & section 1.2 sets out the distinguishing characteristics
of Bau versus project. So do the revision materials in the course
materials.
2 Qn>
It leads to exam questions like this one. Do you want to click pause
to examine it?.
Welcome back? This Qn ask which option lists a project charac-
teristic : is it A stable teams?, B even says its bau and I just told
you emphatically that isnt project, C stable teams again or D team
created!.
3 Ans+ManRef>
I hope the answer is obvious!.

Manual Section 1.2.2 tells us projects are complex enough that
someone needs to exercise coordinating control to manage them
and that we often need to gather a team.
An example of a project might be that bridge building example I
used earlier or quote a project might be created by taking a batch
of bau product refinements together.
To me that sounds quiet IT oriented but P2A is suitable for non IT
use. Many of the official manuals examples are centred in IT. You
need to look past it. Ill extend the discussion with non-IT examples.
Across the manual there are a lot of concepts coming our way. Im
going to introduce them now to help position your exploration.
There real explanation will come as we get to each one. I think
knowing these ideas are coming is helpful even though Im not fully
decoding the jargon here.
4 Up-C>
The first is the idea of evolving an accurate product. This is a

product whose definition really does match what the customer
needs and wants.
We might contrast that with what the customer initially asks for.
Accurate products emerge by refinement : The message is deliver
early, inspect and adapt.
Another concept is Change is of two levels:
minor which should be dealt with quote dynamically as it arises
normally by some local trading of scope or quality within the
development team and through the product owner or as P2A calls
them the customer subject matter expert CSME. The second level of
change is major change which changes a baseline : standard prince
mandates that baselines are agreed so major changes need a fresh
agreement to be forged through change control.
Next idea:.
In the fore-front of our mind should be TCO or total cost of
ownership not just project based cost of acquisition.
Also:.
The agile approach taken by development teams inhabiting the
manage product delivery process can be timebox based like scrum
or flow based like kanban (or an integration of the two like scrum-
ban). If the names are meaningless dont worry the ideas behind
these frameworks will be explained at an appropriate moment.
Ditto the jargon about to come your way.
Next:
Agile is most appropriate in disrupted context. that is where there
is non-linearity. Where prescriptive approaches (otherwise known
as best practice) dont apply .
if the jargon flew by you dont worry just be atuned to listen hard
when the topics arise later. But if you do know complex adaptive
systems what you know is relevant : like wise if you know us DOD
5000 smart acquisition you are way ahead of much that makes up
the manuals content but now Im guilty of straying into the real
world again and sounding very non-agile. In fact all this stuff is
very agile but not well understood for its agility).
The premise Disrupted contexts.
(like the industrial revolution, the impact of the internet or Enter-
prise 2.0, the promise of 3d printing etc) is that Novel unpredictable
situations call for action, inspection and adaptation, Ready Fire Aim
in that order as Tom Peters puts it in the 80s management classic
in Search of Excellence or Requirements, Code Design in that order
as Martin Fowler has said.
Lastly for this little fore-sight of coming concepts .
agile focusses on creating value, prince calls value benefits. Value
or benefits arise from outcomes.
Quotably.
Outcomes are beyond a suppliers ability to create in isolation; sup-
pliers create outputs. If you know program management then agile
aspires to a scope matched to a programs view of tranches : agile
just calls them by a different name (eg Release) and divides them
into things with different names (EG sprints). Infact somewhere
schwaber said a sprint is a project. Agiles aspiration isnt translated
into tools or steps beyond delivery from technical teams but its
thoughts are in the right direction.
Up-Coming:.
Accurate product.
2 levels of change.
TCO.
Timebox or flow.
Agile excels where predictability is low.
Agile and prince focus on business results (Value or Bene-
fit)
TITLE= The difference between project work and BAU work : 2/10 - Ss2 s13
Lesson 13 TITLE= The difference

between project work and BAU work :
2/10 - Ss2 s13
Syllabus Area Learning Outcome 1. Assessment Criteria 1.2

The manual tells us a point to note about agile is that it omits or
assumes someone else has thought about what comes before the
technical work. IE agile is a bau not a project tool.
Recal these are exam facts.
1 xit>
In contrast a project or mature agile context (more exam speak)

is where pre-project work defines the objective, sets direction and
secures approval.
Also a project (in theory) starts with a clear view of its finish while
agile may not. Agile runs in perpetuity fuelled by a list of new
feature needs that evolves as a product or marketplace evolves.
As well as a project knowing when it will end it exists over
three management layers: direct, manage and technical delivery
while agile is just technical product creation. In agile the teams
membership includes an intimately involved and single business
decision maker with absolute authority. An assumed and required
grand simplicity.
Once again we are reminded that:
P2A is only suitable for projects.
P2A uses agile behaviours, concepts, frameworks and techniques
that can also be used in BAU.
Project on the left, layers and structure from pre-project to closure.
Operations on the right, perpetual, rolls on and on, only at the
delivery level.
Is it time for a change of pace?.
End.
TITLE= Baseline Exercise-0: What is Agile? - Ss2 s14
Lesson 14 TITLE= Baseline Exercise-0:

What is Agile? - Ss2 s14.
We havent actually defined agile beyond the now oft repeated

fragments that Ill put into a phrase here. You do need to have in
your mind.
P2A is a mindset comprised of Concepts, Behaviours and Tech-
niques as applied by some frameworks.
By framework we definitely mean descriptions of procedures and
may also mean descriptions of roles.
By framework we equally mean method or approach.
You might pause now and ask yourself.
What, perhaps if anything, do I believe agile is?
In the context of a live class based course its a discussion intended
to survey the wide range of views.
Typical ones range across; its a way of seeing and being, its a
mindset to obviously it is scrum. Full-stop.. The normal debate
typically raises another view. Agile is a religion or at least some
people are as passionate and bigoted as the strongest religious cults
can create.
P2A is sensitive to ideas such as anyone with the title manager
implies lack of trust. P2A still says a Project Manager is mandatory.
Perhaps because of that the longest chapter is the organization
theme as it attempts to blend and weave prince roles with agile
concepts.
Some reflection on what is agile might help you before we move
on.
Also think beyond the exam. By the way have you booked your
exam yet. The commitment of booking will help you succeed.
Define a time box and be successful in delivering to time.
eMail me p2a@logicalmodel.net and Ill share a template revision
diary with 20 mini-milestone for you to assign your self targets and
rewards for each achievement on the way to success.
End.
TITLE= An overview of agile : 3/10 - Ss2 s15
Lesson 15 TITLE= An overview of agile :

3/10 - Ss2 s15
Learning Outcome 1 Assessment Criteria 1.1
While chapter one was 2 pages chapter 2 is 5 pages. It sets out some
history. It says that there is much debate and passion expended in
arguing what agile is and why it is so good and why waterfall is so
bad.
Note P2A does not say waterfall is bad just that that is the opinion
of some. P2A says waterfall has its place.
To slip into the real world once again, but for good purpose.
The manual tells us the plusses of agile and the minuses of other
approaches but it does not balance that with explaining agiles
weaknesses or design-first approachs strengths (or even to cor-
rectly position waterfall, predictive planning or many other jum-
bled concepts).
Also there are some outrageous slanders in places. For example the
imagined treatment of quality control in non-agile environments.
Also problems are described whose solutions have been well known
for decades in other contexts : I will note them in passing so
potentially you can link to your existing knowledge and so you have
further avenues to explore when using P2A for real.
Topics include the two Ive mentioned like DOD 5000 and Complex
Adaptive Systems (CAS). I hope linking outwards facilitates the
potential for the added value I promised so that where you have
the background you can make useful linkages or you can explore
other great resources but without diffusing your exam prep efforts.
In general agile leverages many sources of insight but they are often
included without reference their sources.
There is an enormous amount in scrum for example that comes from
complex adaptive systems. The insights of many people like Tom
Gilb are included without their names being mentioned.
Its irrelevant to the exam, its relevant to the post exam challenges of
integrating a real worlds status quo, challenges and opportunities.
Something Id love to help you with after your qualified. Drop me
an eMail .
The headline is agile means different things to different people. So
to cut through the ambiguity P2A gives us a foundation stone.
Lets repeat P2As start point. P2A says agile is a mindset. That
mindset embraces Methods or Frameworks or approaches plus Be-
haviours, Concepts, and Techniques . Its the mindset that matters
though and at every level of deliver manage direct and the Agile
manifesto comes closest to encapsulating the definition.
End.
The Agile Manifesto : 4/10 - Ss2 s16
Lesson 16 TITLE= The Agile Manifesto :

4/10 - Ss2 s16

The manifestos last two lines are as important as the preceding
ones.
There is value in both sides of the set of points. There is RELATIVE
value in all the points, not good versus bad.
P2A also says .
Agile arose as a result of pressures to respond swiftly to market
place needs in ways older approaches struggle with and.
All things are relative : it is about balance and.
The manifesto says software but the word product fits just as well
and is more inclusive.
Agile is used in large and complex contexts well beyond its roots
in, note the phrase : single product, single owner, single team
environments.
Agile is now mainstream and all organisations should have some
strategy for adoption or exploitation.
The manual sees two levels of use of agile.
Basic and mature.
By mature the manuals author means the most detailed work is

done in line with a top level product road map or vision. Project
governance is in place and P2A may not offer a lot over what has
been implemented.
It might help some to know that even though the P2A manual
doesnt make the link Program management also labels the same
things vision and roadmap or product blueprint as agile does. Same
concepts sometimes slightly different vocabulary .
Agile and program management are happy to start with a vision
and stop when we recognise that further benefit is subject to
diminishing return.
Agile is program management is agile : opps thats not exam focus
that is real-use focus.
End.
Waterfall or Iterative & Incremental : 5/10 - Ss2 s17
Lesson 17 TITLE= Waterfall or Iterative &

Incremental : 5/10 - Ss2 s17

Traditionally project management grew out of engineering.
The inescapable truth is delivery is after construction is after
specification.
Quotable it is a sequence of phases.
1 Xit>
After the inescapable is the choice; there are two ways to slice and
dice the technical phases over the total scope required and the time
available.
The diagram here (Fig 2.2 page 10) shows us on the left that we can
do each technical phase of a products lifecycle to 100% of the scope
before moving on or .
2 halfXit>
on the right we can do the tasks of each phase to the smallest subset
of scope over and over again.
Both approaches have strengths, weaknesses and risks. The left is
design first or predictive, the left is iterative and incremental and
exploratory.
Being iterative gives the chance to make partial delivery early
and thus start generation of value early but more importantly get
feedback from the customer about whether what they are receiving
matches want they want and or need. Part of how we achieve
accurate products.
Iterative means we repeat the technical phases over and over while
incremental means we deliver a bit more each time.
Imagine building an office block. As floor 6 is cast from concrete
so floor 4 is glazed, floor 2 wired and plumbed and the ground
floor decorated. When floor 8 is cast floor 2 is in decoration and
the ground floor sold and occupied.
Agile started in software development where an iterative and
incremental approach is easily employed.
It has spread to many domain. An iterative and incremental ap-
proach is very often possible but we may have to think harder to
identify how to achieve iterative and incremental.
There are three words to examine here.
Waterfall) is the label applied to an approach where each technical
phase is employed in sequence and the results of each feed the next
phase. Nothing is delivered until the end.
Iterative) is the label for an approach where the waterfall is applied

many times over and incremental) is the distinction between an all
at once approach implied in the word waterfall versus a bit at a time
build-up towards a complete final solution.
I might redecorated my house incrementally with a different room
being my focus each year. The work on each room will follow a
broadly similar pattern or iteration of the decoration life-cycle. It
might be; Decide the new look, clear the furniture, apply decoration
like fresh paint and finalise by shifting the furniture back in.
Quotably each cycle delivers an increment.
Lets look in more detail.
A basic approach starts with a todo list
End.
Agile basics : 6/10 - Ss2 s18

Lesson 18 TITLE= Agile basics : 6/10 - Ss2

s18

That ToDo List is a prioritised wish-list called a Product Backlog.
There are a lot of terms we need to define. They will all get covered
but not all immediately.
1Wishlist>
The items in the list are User Stories and Epics or Fine-grained and
Course grained Requirements.
Only stories are Ready for detailed development work. However
even Stories are generally not detailed enough to design and build
from.
2 Ready>
A quote is a story is a token for a conversation.

Epics need refinement aka decomposition to break them down into
stories. Stories must trace to acceptance criteria or a clear definition
of done. A good practice is to start by defining the Acceptance
Criteria as specific tests that will be applied to the deliverable result
of the teams short term work or sprint.
3 Sprint>
The top backlog items that fit within the teams sprint capacity are
selected for work.
That short term capacity is a time limited or time-boxed duration
during which selected work items will be completed and shippable.
The chunk of time is generically called a time-box; The very
influential agile method scrum calls the short timeboxes a sprint.

Selection of the results to be delivered within the sprint happens in
the
4 Meet>
SprintPlanning Meeting. In the Sprint Planning Meeting (spm) the

product owner sets out the Sprint Goal. Supporting user stories are
selected. The selected items are worked on during the fixed-time by
whizzing through all the specify, build, integrate test, deliver cycle
steps. Sprints are normally 10 to 20 working days long.
5 10d Dev>
If as we go we find that capacity isnt equal to finishing the selected

items then some items are de-scoped or built to less demanding
criteria.
Here we come to one of the most important foundations of P2A. We
set aside scope and adjust quality criteria so that what we can do
inside deadlines has had all the right steps applied to ensure what
we deliver matches its specification.
The subtler point is that sometime acceptance criteria can be
expressed as a range eg dinner is at 8pm, I was going to cook 3
courses, as it happens Ive only done2. By leaving out the starter
Ive allowed time to ensure 2 fantastic courses rather than 3 poorly
cooked courses (or as an alternative how about I went to McDs
drive-through. I didnt super-size because a regular meal meet my
essential needs).
The structure we are describing here is a timeboxed one. It fits the
definition of Scrum (we will cover flow based approaches later).
6 Scrum>
I hope you can see that what we are describing is a highly structured
procedure.
Scrum is very prescriptive of the development process. In this
process structure the development team meet everyday to discuss 3
questions between themselves (What is Just done/ What to do today
and any Blockages).
The Daily Scrum is a stand-up meeting internal to the team.
Normally 15 minutes or less. Normally next to that Information
Radiator we already mentioned. It is neither a management meeting
nor a reporting mechanism.
Once upon a time it was referred to as a pigs and chickens meeting
to recognise who is just involved versus who is truly committed.
The inspiration here being a bacon and egg sandwich. Only the
inner circle of development team members are allowed to talk.
While not a management meeting it may escalate actions to clear
blockages to management. Topics raised in the daily scrum that
need further discussion are relocated to appropriately focussed
workshops. Maybe immediately after the daily stand-up.
7 Product>
The sprints entry condition is that the development life-cycle-steps

finishes something that can be delivered and creates value.
At the end of the 2-4 week timebox the product produced is
demonstrated versus its definition of done. The term Done has
particular meaning (We could fairly say that the agile movement is
reinventing or importing earned values every element except the
vocabulary).The DoD expresses an holistic and provable expression
of the products acceptance criteria.
8 SprtRvw>
We confirm something is done by reviewing it. A Sprint review is

a product oriented assessment : classically called Quality Control.
The product at the end is shippable but that does not mean it has to
be deployed into operational use.
9 Reto>
At the end of a timebox or sprint if we use scrum terms, the whole

of the projects participants hold a learning from experience review
of the development process.
The session is a Sprint Retrospective. Its purpose is to examine
the processes in use during the sprint : Classically process oriented
quality work is called Quality assurance. The P2A manual muddles
the accepted definitions of the terms QC and QA. Ill point out the
manuals specific usage when we get there in case your background
includes the widely known definitions.
A Sprint or Release Retrospective is exactly the sort of workshop
required to contribute to a prince end stage report.
10 Again>
Then the cycle repeats and repeats.
11 Clear>
To recap in under 10 seconds; This basic approach might be called

Backlog and sprint. The to-do list is sorted by the business for
the best stuff to do next, its done by the technicians, checked and
shipped. The team asks What lessons should we apply to the next
cycle?, and then recycles and so on ad infinitum.
End.
Beyond a basic view : 7/10 - Ss2 s19
Lesson 19 TITLE= Beyond a basic view :

7/10 - Ss2 s19

In the process model we have just walked through there are many
terms such as the Definition of Done used to label the concepts of
Scrum for example The Daily Scrum.
A read of Apdx H will reference others such as Backlog Refinement.
BR is under the care of the PO and consumes less than 10% of a
sprints effort. Scrum is highly proceduralised and strictly process
bound. Much stricter than p2!.
Strict rules include: The team select the work, the team estimate
the work, the team includes the customers representative known
in some agile frameworks as the product owner and in others as an

ambassador. And in P2A as the C-SME. Only work that is ready can
be selected, the sprint runs for the exact time specified. Once started
the team cannot (without major upset) be stopped or re-directed nor
can they overrun. But because a sprint is really short : typically 2-4
weeks long that shouldnt create a business impacting problem.
P2A defines the backlog and sprint cycle we have just walked
through as basic agile, suitable for BAU and simple projects.
Even in simple projects we would have to question where did the
backlog come from? If this is a project we probably needed to create
it aligned to some objectives or road-map.
1 Fig24>
P2A says mature agile has a longer-term vision, the road-map for
the product that the sprints are extending and refining.
Also that mature agile uses extend well beyond agiles beginnings
in information technology and business as usual.
Agile is now mainstream in projects, including projects of all kinds.
As we will explore later continuing maturity often means agile
environments move beyond time-boxes to embrace flow-based
working and now some irony; with descriptive genius mature agile
is .
2 xit>
summarised but not explained as A wider mindset.

End.
Agile Frameworks : 8/10 - Ss2 s20
Lesson 20 TITLE= Agile Frameworks :

8/10 - Ss2 s20

P2A highlights for us that there are many agile frameworks : agile
isnt just scrum although scrum is an example of an agile approach.
1 Page>
The P2A manual identifies and sketches an outline in table 2.1 of

many frameworks.
2 HiL>
Scrum, kanban and lean-start-up all get further treatment through-

out the manual.
You do want to be able to recognise the quotable phrases here like

delivering products of the highest possible value.
This one is in the entry for scrum. Check-out the revision aid within
the exam preparation materials for more.
The exam syllabus expects you to at least recognise the approaches
listed in table 2.1 from the descriptions given. The first 7 questions
ask questions at this sort of level.
There are more details in Appendix E and the revision aids.
3 Clear>
Some of the frameworks listed here are IT only but P2A is squarely
aimed at agile in any context.
Paper_1 Qn_3 - Ss2 s21 Question Analysis

Lesson 21 TITLE= Paper_1 Qn_3 - Ss2 s21

Question Analysis.
Here is our first example of a question. There isnt much question

analysis needed here. Its from the first 7 questions which are quiet
routine.
What we do need to start to establish is a routine for exam question
explainaitions. Ill show you the question. You should pause to
consider it and what you think about each of the 4 possible answers.
Then Ill show the chief examiners answers and you should review
each to contrast to your own thoughts on each of the 4 answers and
then Ill attempt to cast some extra light on the thinking for most
questions. It isnt always necessary .
For this question decide; Which answer is describing an agile
framework listed in table 2.1 after shifting the words around? Pause
if you want to consider.
Welcome back?.
Body>
Pause again to consider?.

Now in reverse order for reasons that will be obvious
D - Long term vision is the concept of a road map. It isnt attached
to any specific framework.
C : existing operational products is a reference to Bau and we are
P2A so only interested in projects.
B : anything with quotable phrase sequence of phases isnt going
to be agile in the manuals viewpoint.
A ahha limiting WIP and visualisations : thats table 2.1s summary
of Kanban.
We have not covered enough to necessarily be equal to the question

yet but I hope the general feeling is the specific words and phrases
determine the answer wanted, they will need to be recognised by
the time you are exam ready.
The revision aid will help here.
End.
Agile behaviours concepts & techniques : 9/10 - Ss2 s22 9/10
Lesson 22 TITLE= Agile behaviours

concepts & techniques : 9/10 - Ss2 s22
9/10

Here is some key information for answering

questions.
The tables contents needs memorising.

Table 2.2 ILLUSTRATES typical .
1 Circle>
agile behaviours,
2 HiLt>
concepts and techniques.

The boundary between terms is loose and a framework could be
called a method or approach.
P2A uses any agile approach. Its the mindset that matters.
3 NB>
table 2.2 relates to agile in general while later 7.4 will give a slightly
different list that are specifically defined as P2A.
I dont know for a fact if the distinction between the two lists will
ever be tested but the exams questions are detailed so note there
are two items that 2 overlaps and some items unique to each list.
4 Qn>
Here is a question on the table, pause perhaps?.

Welcome back perhaps?.
5 Ans>
The table tells us a timebox is a technique. Perhaps 80 for an open

book exam or study to internalise. Still your choice.
6 xit>
End.
The PRINCE2 Agile view : 10/10
Lesson 23 TITLE= The PRINCE2 Agile view

: 10/10 - Ss2 s23 10/10 Recap.
Thats our survey of chapters 1 and 2 over, next up is chapter 3
We have seen a few concepts but also a lot of lists that we need to
be able to find in the manual or better yet be able to recall.
Lets try!.
What are the agile behaviours? : hit pause if you dont want the clue
straight away.
1 Behave>
Here is a clue.
Hit pause if you dont want the expansions before youve had a
chance to try to recognise them.
BC is Being collaborative, SO Teams self-organise, Be Customer
Focussed, Empowered/ empowering, and Trust not blame.
Pause before I give you a concepts clue? Pause before I expand each.
2 Concepts>
Ready?.
Prioritise delivery, Work iteratively & incrementally, Dont deliv-
ery everything be time focussed, Inspect and Adapt, Use Kiazen or
continual improvement, Limit Work in Progress.
Yes I know some of this is unfair, you cant recall what we havent
mentioned. That doesnt detract from your need to internalise this
or know where to look it up under time pressure.
Have you checked-out the Revision Aids?.
3 Fwk>
Frameworks; You need to be thinking wider than just these three

for recognition of the descriptions.
4 Techq>
Another we havent discussed them but they were in that table.

Pause maybe.
Welcome back maybe.
They are burn charts, User Stories, Retrospectives, Timeboxes and
Measure flow.
5 Sum>
Here is a summary extended to 7.4 and the focus area chapters.

What is your best approach to internalising its contents?.
agile Behaviours 2.2 - Collaborative, Self-Org, Customer Focus,
Empowered, Trust not blame.
P2Agile Behaviours 7.4 - Transparency, Collaboration, Rich Comms,
Self Org, Exploration.
Concepts : Prioritise delivery, Wk Iter & Incr, Not Delivery All, Time
focus, Inspect/Adapt, Kiazen (CPI), Limit WIP.
Techniques : Burn-C, User-S, Retro, TimeBox, Measure Flow.
Focus : Agile-Risk, Reqts, Rich Comms, Freqt Releases, Contracts.
End.
When you want support - Ss2 s24 11/10!

Lesson 24 TITLE= When you want

support - Ss2 s24 11/10!
Hi,.
10 percent of the way through. Mini milestone. Celebration maybe?.
Time to ask yourself a few questions. One question is Have I
thought about the time that has to be invested to get a pass? You
might find a study diary useful.
If you ask then Ill send you a template of the topics and milestones
divided into bite-size chunks. You can then put your own target
dates against it. I hope we all realise that nothing gets done till the
last moment, that is why scrum ensures there are so many of them.
In scrum there is a new last minute every two weeks for example.
My study diary template helps you assign incremental achieve-
ments by iterating around the study cycle. Agile learning in action.
Ill give you daily milestones, well not literally every day but youll
see if you email and ask.
As a reminder the address is in the title above. In some formats it is
a hyperlink, what could be easier!?
A key question is have you reserved your exam?.
Booking the exam is the point at which you recognise for your self
that you have actually made the commitment . It is commitment
that drives successful conclusion.
The process runs like this;
1) go to the website maybe via a resource tab? www.logicalmodel.net/prince2exams,
follow the link to Reserve an exam and complete the purchase.
2) I send you a voucher-code that allows you to reserve an exam
slot. It is good for a year by default but Im expecting youll have
used it within a week or three.
3) Follow the registration instructions, enter the voucher code to

reserve an exam at a date and time of your choosing 24hrs x 365
days of the year.
Popular times like UK Saturday afternoon fillup further in advance
than times like Monday 4am CET. There are hundreds of topics
being examined so dont think Ill book late, how many people can
be sitting this exam at the same time as me? the answer is very
few but the question should have been: how many people are sitting
exams of all possible topics at the same time as me. Very different
answer.
Share your study aids?
Most people doing exam prep create study aids. Ill share with credit
those that you want to send me. I might also spot clarifications and
additions to yours that I can advise you of.
>
Dont forget to contact me with your support needs as you go

Id love to think the whole course is crystal clear on every topic
for everyone but that just is not at all likely so where you need
something : ask!.
3 Tailoring prince for agile.
Tailoring prince for agile : 0of7 - Ss3 s25
Lesson 25 TITLE= Tailoring prince for

agile : 7 - Ss3 s25.
Here we go with the manuals Chapter 3.

Like ss2s hdr here Im advising you what to take note of as you
traverse the contents of section 3s 7 lessons.
If you havent already done so I recommend you stop and prcis
section 2. Summarising in your own words builds recall. Also use
the study aids for recap and quizzing yourself on what is or isnt
fully and correctly absorbed.
3 Tailoring prince for agile. 74
The four big messages of the upcoming section

are..
First.
prince brings direction that will link agile activity to business

strategy.
That road map stuff we have just considered.
plus prince also brings management so as to coordinate with the
rest of the organisation.
Together Direction and Management provide the organisation with
governance while Agile gives a variety of product development
lifecycles that get stuff done and deliver outputs.
Together Governance and agility create synergy. The manuals
quotable analogy at the end of chapter 3 and this section of lessons
is that a military jet fighter is highly manoeuvrable because its
instability is coupled with reactive controls.
The second big message is to position P2A relative to the project
management market place for methods.
The precis or summary is:.
P2A is primarily for communities who know prince and want to
add agile.
Its secondary target is to give agile practitioners practices that help
link product development to project management and business gov-
ernance that is also agile in outlook if youre an agile practitioner
in a cumbersome company then give your bosses boss the link to
the course. A big p2a\ message is the senior management have to
be agile too.
Third we will examine what is in agile, its parts, its components or
if you prefer the elements of which it is comprised.
Fourth are the 8 guidance points.
8 quotable quotes for you to internalise or at least book mark. Im

sure you realise how much exam question setters love lists like 8
guidance points. We get them twice.
Once explained in Section 3.6 and then reduced to bullet points in
table 3.4 : you get them several time because they are in practice
questions and revision aids too.
The revision aid will test how well you recall them. After several
runs of the revision tool the chances of good recall are high.
End.
PRINCE2 Agile blending PRINCE2 & agile together : 1/7 - Ss3 s26
Lesson 26 TITLE= PRINCE2 Agile blending

PRINCE2 & agile together : 1/7 - Ss3 s26

Returning to the quotable we are blending and weaving. Mixing the

metaphors its a layer cake across direct manage deliver.
prince and agile both bring strengths.
1 DM>
princes is direct and manage, but prince is weak in development

advice because its heritage of be able to be applied to anything
compartmentalised all the development in the {{Managing Product
Delivery}} process.
The whole of P2A is effectively populating mp with ideas and
linking up the interfaces like Checkpoint Report-A3 and Work
Package-A26 and Communications Management Strategy-A4 and
Configuration Management Strategy-A6 and Lessons Report-A15s
etc but the influences have to spread outward and upward.
2 Del>
Agiles strength is in development.

Agiles weakness is in direction and management (if your about to
disagree you have stepped off the certification path. Id follow you
but it doesnt help achieve the objective here so let me bring you
back).
The journey is what does the official manual say? at the end we
can enjoy a retrospective that sets the world to rights : maybe over
a beer or a cup of tea.
P2A raises concerns such as.
maybe the project board wont embrace the idea of prioritise the
objectives to get highest value fastest even at the consequence of
omiting some scope.
P2As second concern is that the delivery teams wont be happy to
accept any degree of management; axelos trainer delivery notes ask
are the delivery teams happy that a project manager even exists as
this will be an issue for many in the agile community.
Those same notes Quotably express the synergy from blending
and weaving all the ingredients together to create something greater
than the sum of the parts.
At the end of pg17 is a crucial message.
Its a blend not two parallel streams. Those directing and managing
must also adopt the agile mindset if we are to be successful.
Flow>
P2A isnt just a case of slot the agile development into the space MP
gives and connect up the interfaces.
Success rests on the organisations management also changing their
approach to projects to be agile, recognise their own behaviours
and responsibilities. The Agilometer in Ch 24 and appendix Fs
Transitioning to agile guides what constitutes success as response
to this wider challenge.
To summarise a slew of tables in the manual.
P2A provides guidance aim primarily at prince organisations look-
ing to extend their project toolkit to be more agile.
Alternatively you might have neither project management nor agile
in place at the moment or have one of the two in place.
In these cases P2A has something to offer.
If you already have both in place and working then it is doubtful
P2A offers much to you beyond a fresh perspective.
So the primary audience is a prince project environment that wants
to add agile.
1 Summary>
To summarise this slide in 17 seconds;

P2A is guidance to prince organisations who want to benefit from
agiles strengths.
Success requires a blending of agile into management mindsets, its
an evolutionary take-over where the sum is greater than the parts.
If you are already a mature agile projects environment P2A might
not offer much. If your agile without projects P2A has something
to offer you but youll.
End.
What does PRINCE2 Agile comprise of? : 2/7 - Ss3 s27

Lesson 27 TITLE= What does PRINCE2

Agile comprise of? : 2/7 - Ss3 s27

PRINCE2 Agile is 100% of P2 plus the elements that are agiles
essential additions. The quotable idea here is nothing is removed.
So a potential exam answer that says We dont need manage stage
boundaries isnt ever going to be a right answer.
P2a adds to standard prince. Whats added are techniques, concepts,
frameworks, behaviours and focus areas. Each of those headings
expands to a list.
Lets test your recall .
1 Box>
maybe pause while you expand the initials or look up any that dont
come readily to mind.
If they are not yet sinking in now is the time to write out a list. Ill
give you the expansions to facilitate copying them out before the
end of this slide.
All the details in the manual are in the lesson slides and revision
aids so we will get to detailed discussions of them all as we go.
Ill introduce the focus areas now. They are .
2 OM Cntnt>
the 5 chapters from 24 onwards to the end of the book.

3 Aom>
Ch 24 covers the assessment of concerns about our ability to

actually be agile. Its called the agileometer The 6 scale measurement
tool is a maturity model. Chapter 24 describes maturity level 5 :if
you know Carnegie Mellon Universitys Capability Maturity Model
created 30 or 40 years ago by Watts S Humphries where level 5 is
the most mature that will be good relevant background. Otherwise
a research note for your after exam further reading .
Next are requirements & User stories.
4 Req>
in Chapter 25.
The concepts here are firmly but invisibly rooted in decomposition
so entirely aligned to princes product breakdown and the pm bok
or pmbok guides workbreakdown structures.
p2a gives us an analogy of starting with boulders which are broken
into rocks broken into gravel and a vocabulary of Vision decom-
posed to Epic to User stories to DoD to tasks in the sprint. I dont
think the official manuals author was sentencing us to hard labour.
It all maps nicely to p2s Project Product Description-A21 and
its composition section then Product Description-A17 then Work
Package-A26.
A major theme of the chapter and the whole of P2A is the priori-
tizing of requirements in ordered lists or using the Must/Should/-
Could/Wont hierarchy often refered to by the mnemonic Moscow.
Where possible product attributes are defined as mandatory or
optional or on scales. Maybe my watch will be splashproof, or
waterproof to 1m 10m or 1,000m
Guidance covers good and poor user stories and makes clear they
are a step along the journey to clear requirements not the end of
the requirements definition journey. Backlog Refinement doesnt

get a mention in this chapter. It is in appendix H : schwaber &
Sutherlands definitive guide to scrum.
5 RC>
Rich communications is chapter 26 and is easily summarised as

face-to-face is best and everything else has its place so the need
is a correct blend.
Workshops are great if set-up properly and that takes 5 steps and
there are at least 9 techniques named in the official manual that
we could use to facilitate them from Brainstorming to Dr Edward
DeBonos 6 Thinking hats and dont forget the Yellow Sticky Notes.
6 FR>
next are Frequent releases, What Tom Gilb called Evo and Barry
Boehm called Spiral methods in early software lore.
The aim of feedback is to facilitate early corrections or adaptation
from the customer so we can align the activity of the development
team with the intent of the customer.
Frequent releases should also start value streams earlier so that
benefits flow is improved. There is no mention of net present value
or DCF/ Discounted Cash-Flows anywhere in the P2A manual but
they are both expressing exactly where we are in business terms.
Finally.
7 Contracts>
Contracts in Ch28. Its a shame to finish on a weaker chapter. Much

better practice than is described here has been known for a very
long time. PMBoK-g section 12.1.1.9 sets out contract types and any
online search for integrated product team will generate lots of

sources. I got almost 50m hits! Mitre.orgs Start-up guide is a good
source. Maybe it was the inspiration for the agilometer?.
Note this stuff looks a long way away from agile but is infact all
totally aligned in spirit just not vocabulary or development lifecycle
structure. IPTs and much more are part of something called Smart
acquisition or dod 5000 which mostly presumes design first but that
isnt a requirement at all.
Finally returning to all those headings and reminder initials do you
want to hit pause to recall before I share an expansion? Here it is.
8 BBCTF>
I wont read them out, be ready to hit pause to study and note it
will be an advantage to be fluent to recall these, and even more
important is to ask and answer How is use of prince affected by
each, how are agile ways of working applied? ok so pause then
Move on when you are ready.
Agile Behaviours 2.2 - Collaborative, Self-Org, Customer Focus,
Empowered, Trust not blame.
P2A Behaviours 7.4 - Transparency, Collaboration, Rich Comms,
End.
8 Guidance Points : 3/7 - Ss3 s28
Lesson 28 TITLE= 8 Guidance Points : 3/7

- Ss3 s28
Here are the 8 points on which PRINCE2 Agile is based.
1 Manual Table>
We wont debate them, just internalise them, Section 3.6 takes

a whole page to explain them fully. Table 3.4 reduces each to a
summary sentence.
It adds up to.
two 1+2>
1st and 2nd prince is a control structure not a sequential product

development model.
prince says 1st we get going, thats the SU process and the initiation
stage then cycle through as many plan, do, review, plan, do, review
as needed until plan, do close.
There is nothing Requirements, Design, Build implicit or explicit in
this at all.
{{Managing Product Delivery}} can be plan do review of one tech-
nical phase in waterfall or an agile release or sprint or releases or
sprints.
There is a great diagram in the RUP manual by the son thats Walker
of waterfalls author Winston Royce. (Winston has been massively
misquoted because he said right back at the beginning you have to
be iterative).
three 3+4>
3rd n 4th Agile and P2A apply to any context where an idea, need
or want has to be shepherded from concept to routine operational
use : ie a project or program or any size of change or development :
The phrase Business change includes everything that can be created
or amended so that includes IT - Iinformation Technology but it
isnt defined as being just IT.
four 5+6>
5th n 6th Agile is a wide variety of frameworks and opinions, far

wider than scrum.
What scrum has going for it is great marketing of its IP that spread
its name far and wide so it is better known. Kanban has the how of
TPS and lean behind it. If you want to explore lean then Womack
and Ohnos names are good start points for an internet search.
five 7>
7th P2A says agile is the family of frameworks and the basket of
adjectives they bring with them of which there is a huge number
laid out in Appendix E.
Words like empowered and transparent.
Since the syllabus says everything in the manual except the shaded
as-is descriptions of prince2 can be examined you probably need to
browse over them or the revision aids.
And.
six 8>
point 8 P2A says everything is agile to a degree. There is no such

thing as an agile project because that allows for a non-agile project
and non-agile does not exist. Thus agile is always a consideration
of How much.
End.
Beware of prejudice! : 4/7 - Ss3 s29
Lesson 29 TITLE= Beware of prejudice! :

4/7 - Ss3 s29
P2A is inclusive but prince may be misunderstood and seen as the
enemy.
Some members of the agile community suffer a significant degree
of NIHS Not Invented Here syndrome.
1>
A good sentiment is revealed by an online search for Alistair

Cockburns Oath of Non-Allegiance.
Time for an integrated PRINCE2 Refresher with agile overtones :
The P2A official manuals chapter 4 is our next area of exploration.
End.
The PRINCE2 journey with agile : 5/7 - Ss3 s30
Lesson 30 TITLE= The PRINCE2 journey

with agile : 5/7 - Ss3 s30

The graphic at the foot of the page is from the prince official manual
not the P2A manual. Its called the PRINCE2 journey
1 p2om pg>
Here it is in context. Blending and weaving prince and agile

together can be done in many ways.
The P2A manual is a way, not the way, both here and in each
chapter, topic, section and discussion to follow. The factors to
consider always are the culture of the organisation and the nature
of the challenge embarked upon.
prince suggests activities (there are 40 of them like [ Appoint the Ex-
ecutive and the Project Manager [ 12.4.1 ] through to [ Recommend
project closure [ 18.4.5 ] paired with [ Authorize project closure [
13.4.5 ]) grouped in processes of which there are 7. prince says these
activities and thus processes always need tailoring.
Tailoring for P2A is in large part the interface to the development
team.
Primary then are the Work Package-A26, the Checkpoint Report-A3
Quality Register-A23 etc.
In an agile context the probably tailoring is that they become
information on an Information Radiator-IR. Tailoring of duties like
the role of team manager and product owner or C_SME needs much
discussion and if agile is to permeate into prince then the Highlight
Report-A11 and End Stage Report-A9 are also transfigured to be
entries on BVCharts and informal flows.
End.
Recap of PRINCE2 : 6/7 - Ss 31
Lesson 31 TITLE= Recap of PRINCE2 : 6/7

- Ss 31
Learning Objective AC?.

Earning the P2A qualification requires that you already hold the
P2-P badge.
Lets try a few quizzes.
1 7of>
prince is made up of 7s : what are they? Hit pause perhaps before I

share the lists.
2 7Principles>
I dont know what order you did princes elements in but there are
7 principles. What are they? , Hit pause? Ill give you a clue in a
second.
3 7p-Clue>
Hit pause if you need time to expand these. If you recall it is better
for you than listening to me tell you. They are .
4 manual clip>
a continuous business justification, always Learn from Experience,

Define Roles & Responsibilities, Manage by authorised Stages,
Manage those stages by Exception against tolerances, Focus on the
Products and lastly always Tailor for context.
5 7t>
Themes shouldnt be so hard if your reading the slide you can pause
before I give the reference to the manual.
6 Manual>
pause ? and move on when ready : Recall I said earlier that p50 is a
good one to refer to in the exam. Here it is. It summarises the next
7 chapters of the P2A manual.
Seven 7Proc>
What are the 7 processes in their sequence of use?.

Ill take you through the 40 activities on the next slide. Pause to
think?.
eight 7p hint>
Ill explore these in the next slide.

The 10 seconds summary is startup, seek approval, initiate and plan
a stage, seek approval, run a stage containing a number of releases,
perhaps some, one or none, repeat that till close.
End.
The PRINCE2-Agile Procedural Flow-Chart : 7/7 - Ss3 s32 7/7
Lesson 32 TITLE= The PRINCE2-Agile

Procedural Flow-Chart : 7/7 - Ss3 s32 7/7
Im going to explain the whole journey through PRINCE2 in an

agile world : its all prince structure but with the agile mindset in
place.
The core of a prince project is the journey from SU to CP. This is

a journey from business strategy : grey to products and outcomes
blue and back again to grey at the end as we close. Red by the way
is development activity and yellow is quality focused activity at the
heart of so much. Ill be consistant in colour use across this and all
our courses.
It all starts with an opportunity or a business threat. Someone has
a light bulb moment that triggers a
1Mandate>
mandate from outside the project.

{{Starting up a Project}} defines and one or more Senior Users engage
stakeholders and considers viability, probably in workshops. The
Project Brief-A19 grows with recording of the details. Maybe as
stuff on a display board.
The brief includes the project approach where our use of agile
behaviours like self-organising teams and empowerment are de-
scribed. The briefs key elements also states the Vision (right where
there is a space for the A21-Project Product Description) and the
required feature set or initial backlog. At least in terms of Visions
expansion to Epic Course Grained Requirements.
The P2A official manual is explicit that Start-up and initiation are
two processes in P2A. The guidance is the same for both so there
is only one chapter in the manual. Agile environments might draw
less distinction or even eschew the whole idea of upfront work as
predictive rather than emergent.
So if we can distinguish a discussion that is [ Authorize initiation [
13.4.1 ] we will know that the Project Board considers it worthwhile
and the Project Manager is authorised to run the Initiation Stage.
In the Initiation Stage as much as possible is done via workshops.
Workshops include the customer and recognise that uncertainty
means we dont know everything. If the workshops arent happen-

ing then by default 1341 concluded All-Over. Not worth it.
Not knowing everything means our thinking is on How do we
learn enough to proceed?
What communications do we need between and with whom? The
answer is in part defined by some MVPs or Minimum Viable
Products. An MVP in P2A is not necessarily a Minimum Marketable
Feature Set but is the Lean-Start-Ups view. In Lean Start-U an MVP
is anything in any form that is enough of a prototype to learn-
something. A sketch on a caf paper napkin of a layout for our
new kitchen that get the spouses nod and a smile is a suitable MVP.
It can be a releasable , initial product a Minimum Usable Feature Set
or MUST but it might be just a model or a thumbnail.
Through the early steps we set controls and strategies such as the
Communications Management Strategy-A4, we refine the business
case and secure funding.
By the end we have established the project plan and the release
plan and first stage plan. Release and project plan are developed
by or with the business. By the end we have the Benefits Review
Plan-A1, the Project Product Description-A21, and its expanded
composition section in a Product Backlog of many user stories or
in prince vocabulary Product Descriptions-A17.
These will probably be called Vision and Epics instead of a21 and
major composition. We fully expect that the definition could be
incomplete and that what is identified lacks detail and that not
everything that seems necessary now will ultimately be delivered.
We know the rough and relative priorities of most things.
The whole is posted to the projects Information Radiator-IR. Tradi-
tionally it would be called the PID. Project Initiation Documentation-
A20 but D for document is an assumption of format.
2 toCS1>
From these beginnings Come the Subsequent Delivery Stages.

If the results of arriving at a point to decide Are we ready?, Is
it worthwhile? are Yes its viable and we are ready then work
assignment starts by collaboratively with the development team
: which includes the product owner or as P2A calls them the
Customer Subject Matter Expert (C_SME) holding sprint planning
meetings to select the sprint backlogs items from the release back-
log. The team sprints towards the sprint review meeting, holds daily
stand-up meetings, updates its Information Radiator-IR, trades
scope and attribute quality levels for timeliness of completion of
well made products. There is much we have to discuss to add
Quality Control, monitoring, the time-bound relationship between
sprints, releases, work-packages and stages etc to this thumbnail
sketch.
When a release occurs then prince has the supporting activity
description.
3 toMP3>
for control of project and product, for example Highlight Report-

A11 and Configuration Item Record-A5s .
4 SB>
The stage boundaries process cycles us to subsequent stages or.

In part the end stage activity might, more or less be relabelled
Release planning for subsequent releases although the agile concept
of release is linked to technical maturity of products while the
prince concept of stage is linked to the project control concept of
authorisation to proceed. Close but not identical.
Agile Stage boundaries major on reporting what products and
features have been shipped, what benefits are flowing and the level
of change.
In multi-workstream environments (as opposed to single prod-
uct, single owner, single team basic agile) the staging normally
aligns to some dominant technical streams release pattern and
cuts across others. If your background includes understanding of
the models like cadmid the UK MODs product cycle or the Oil
and Gas industries Assess/Select/Define/Execute/Operate lifecycles
then that is all relevant insight into how the decision support or
gating processes that integrate coordination between engineering
and governance work.
5 CP>
the {{Closing a Project}} process tidies up.

I say tidies up because the frequent releases focus area expands a
concept that prince has always supported of [ Deliver a Work Pack-
age [ 16.4.3 ] happily delivering to the customer. it is interpreted in
P2A as meaning there probably isnt any further handover to do at
the project end.
There is the need to confirm that what is of value has been
completed. You can sense that P2A wants to say that the project
fizzles out but has to say there is a clear and defined end. It wouldnt
match princes definition if it drifts to closure but that might in some
contexts be a better explanation and better operational handover.
Like a program a P2A endeavour might end by recognising weve
done enough. This is a natural consequence of starting with a
vision that we allow to crystallise as we go. Its a concept central to
program management.
At close-out the backlog of stories passess to a support and mainte-
nance team and the project retrospective is held. Historically it was
called [ Evaluate the project [ 18.4.4 ] CP4.
6 ExSB>
What we have left is the exception handling process.

Any externally triggered alteration to do with a sprint is an ex-
ception. Mostly team internal alterations are emergence and self
organisation and flexing to protect what is fixed. The term is
dynamic change.
The reaction to exceptions will probably be a workshop to collabo-
ratively determine the best course of action to respond.
Exceptions versus tolerance need specific discussion in P2A since
we flex what we deliver so delivery always occurs to deadline. The
give and take is in the volume of result not its quality nor in one
sense the date of delivery. We will discuss it later but to precis if I
intend to deliver A, B and C on Friday then Friday will be the day
I deliver but it might be A and C or B and C. The agile mindset
guarentees the date and uses best endeavours on the scope. We will
see when we get to table 6.2 but there is an elephant in the room.
To illustrate; If I deliver A and C then clearly B wasnt delivered on
its date. There is an unresolved gap that P2A sort of overlooks!.
7 ExCP>
An exception normally triggers investigation of what a new Project

Plan-Plan-A16, Release-Plan, Benefits Review Plan-A1 and Busi-
ness Case-A2 look like.
It is also possible they trigger premature closure.
End.
Online content only
Lesson 33 TITLE= RevisionAid & q33: Lets

do some quizzing :-) to consolidate what
we have covered (T2.2, 7.4, T3.4, 3.6)
Read the summary then check your recall with the quiz questions
below
Agile behaviours from 2.2
Be collaborative
Self organising
Customer focus
Empowered/ empowering
Trust not blame ###PRINCE2-Agile behaviours from 7.4 T-
ransparency
Collaboration
Rich communications
Self-organising
Exploration
Concepts
Prioritise delivery
Work iteratively and incrementally
Accept we wont deliver everything (Customer does not need
everything)
Time focus
Inspect and adapt
Continuous improvement Kaizen
Limit Work-In-Progress ###Techniques
Burn charts
User stories
Retrospectives
Time_boxing
Measure flow ###Focus areas
Agile risk and the Agilometer
Requirements and user stories. epics etc
Rich communications
Frequent releases
Contracts in an agile context ###8 Guidance points
1. PRINCE2 is already agile enables
2. PRINCE2 works for any project and is not traditional
command and control
3. P2a is for any project, not just IT
4. P2A mentions IT only frameworks
5. Agile is more than just scrum
6. Common agile includes scrum and kanban
7. P2a says agile means behaviours, concepts, frame-
works and techniques
8. Agile is never yes/ no but more or less (how much)
###4 Steps in P2 journey
9. Pre-project
10. Initiation stage
11. Delivery stage(s)
12. Final delivery stage
7 Themes, 7 Processes & 7 Principles
Change, Progress, Business case, Organization, Quality, Plans,

Risk
SU, IP, DP, CS, MP, SB, CP
1. Continuing business justification
2. Learn from experience
3. Define roles & responsibilities
4. Manage by stages
5. Manage by exception
6. Focus on products
7. Tailor to suit the environment
4 Fix time & cost to flex
scope & quality to achieve
the 5 targets.
Fix time & cost to flex scope & quality to achieve the 5 targets - Overview :
0of8 - Ss4 hdr s 34
Lesson 34 TITLE= Fix time & cost to flex

scope & quality to achieve the 5 targets :
8 - Ss4 hdr s 34
Next we have 8 lessons from AXELOS that explain Chapter 5s

Concept of what to flex in order to achieve business constraints
4 Fix time & cost to flex scope & quality to achieve the 5 targets. 101
of Cost and Delivery date .

Have you summarised ss3. Youll know your own study strengths.
Are you balancing movig ahead with consolidating what you have
heard so far?.
When we get to the end we will have covered the P2A manuals
Part 1.
At that point Ill summarise the journey so far.
First in here we describe the fix n flex options and then we describe
the fix n flex reason or purpose.
There are maybe 2 major chunks on fix n flex here:.
First; prince describes 6 tolerances. In P2A we set time and cost
tolerances to zero and Scope and Quality take up the tension to
create a capability to deliver on time and to agreed quality targets.
2nd The Reasons or purpose are described to us as 5 targets.
Really we have two targets; On time and To quality and 4 enablers.
Fix n flex.
Embrace change.
Keep the team stable.
Sacrifice low value requirements.
But you need to internalise them as 5 Targets:.

1) time & Quality 2) Fix n Flex 3) Change 4) Teams 5) Sacrifice or
trade.
The really key message here is many exam questions are of the form
Considering the 5 targets what is the best action here or if you
took this action is your affect on target x good because or bad
because?
My view is these questions can be hard to interpret and having Table

6.2 the text of 6.4.1 to 644 in your head or available to consult at
exam time is helpful.
Lets explore all that detail.
End.
Online content only
Lesson 35 TITLE= Online content only .
End.
The Hexagon - 1/8 - Ss4 s36
Lesson 36 TITLE= The Hexagon - 1/8 - Ss4

s36

PRINCE2 highlights that a project has degrees of tolerance in many
dimensions and that to some extent they are in tension.
The fix n flex concept is in pursuit of five targets.
Certainly the targets are linked. In a world defined by P2As pink
hexagon we hold the finish date of sprints and releases fixed, We fix
quality in terms of to specification and we fix scope in terms of
Musts and wonts. We flex scope in terms of the shoulds and coulds.
1 Three Levels>
In the sort-term at least we hold the team stable so working

relationships and labour costs are also fixed.
The hexagon effectively recognises that to match reality where hope

and intention can be confounded by luck and will, something has
to be a dependant variable.
The principle here is that hard decisions are needed during project
release planning and sprint planning. And then also during sprint
execution. If we set aside lower priority elements of scope and
higher targets for quality criteria then we dont skimp on the
development steps to end up delivering everything but poorly
finished.
We might express the target as 80% of intention excellently done
rather than everything 80% finished.
2 Pg>
The six tolerances are set-out in Table 6.1 and the revision aid (BTW
the pink hexagon is figure 6.1).
The manual tells us the rational for starting with time fixed is the
21st century paradigm shift in how quickly people want products
and services these days.
The mid-level of the hexagon makes explicit that characteristics like
benefits depend on scope and quality so flexing scope has a flexing
affect on benefits.
As much as possible we seek to absorb variation between aspiration
and capability into scope and quality. Dates are locked down scope
flexes as a consequence.
3 WhyHiLt>
P2A is very clear that it is important to understand and embrace

the concepts of the hexagon, not just know the mechanics.
Absorbing variation into backlog scope and feature set isnt a purely
mathematical equation.
Benefit assessment is often a balanced judgement across many

scope and quality factors. This is in large part why we need the
customer in the development team. As an example what phone do
you have? Is it windows, iOS or android, How big is the screen and
how long is the battery life and what payment plan is it on?.
All these factors are a trade-space. The concept of trade-space is a
mature one in defence procurement where integrated product teams
and incentive based contracts are also part of the operation of the
decision making that the hexagon is illustrating.
An online search for Cost As An Independent Variable easily
throws-up more than 5million hits and a search for caiv trade
space will zoom in on a lot more good stuff around this topic. So
will Voice of the customer and Voice of the engineer.
It is probably an after your qualified avenue of research You dont
need it for the exam.
4 Five Targets>
The fix n flex concept is in support of five targets.

Before we explore each some further points to note are that It is
definite within a sprint that we use the tolerances in a so that time
and cost dont flex, it is probable that a releases date is fixed by
flexed scope and quality level, but ultimately at stage/ release level
planning we may vary the number of stages, releases, sprints so
there is flex at the macro even if not the micro level.
Another point to raise is that Risk flex is also called Risk Appetite
IE it is the amount of risk we are willing to be exposed to.
5 clear>
In the next slide we will apply the above thoughts to a typical exam
question.
What to fix and what to flex
Lesson 37 TITLE= Revision Aid .
Learning Outcome 4 , Assessment Criteria 4.1

Tolerance guidance
Lesson 38 TITLE= Revision Aid .
End.
Learning Outcome 4, Assessment Criteria 4.1

Paper_2 Qn_8 - Ss 4 s39 Exam Analysis
Lesson 39 TITLE= EqA: Paper_2 Qn_8 - Ss

4 s39.
First of all dont worry that s37 & 38 are not included.
They cover admin for a Tea break in instructor Led Classes. Your
welcome to take a break now too!.
Full treatment of this Questions topic isnt till we get to chapter
25 but we have just covered the essence of flex some aspects to
achieve what is fixed.
Recall that process for questions we started at slide 21. Bit more
meaningful here, first Hit pause so you can read the question. Then
consider the merits and reason for each answer, why the right one
is right and the others are wrong. The restart the video, ill show you
the chief examiners view, hit pause so you can consider them then
resume the video and Ill offer some commentary on the question
and the rationales.
So pause for the question.

Is this welcome back?.
Are you ready for discussion of the chief examiners answer?
Otherwise pause again.
ans>
Scope is expressed in terms of what is and isnt vital.

The stem tells us requirements have been prioritised so we know
there is greater tolerance on non-delivery. Tolerances allow or
facilitate Manage By Exception.
If we have to compromise anything to hit the deadline the lower
priority item is omitted to ensure what we do deliver is of good
quality and on time.
None of answers B, C, and D recognise we are flexing scope to
achieve zero time tolerance. B restates the challenge, it does not
doesnt empower but A does.
This question focuses on item one of the 5 targets that are our next
discussion.
End.
The 5 targets : 2/8 - Ss4 s40 5 Targets 2/8
Lesson 40 TITLE= The 5 targets : 2/8 - Ss4

s40 2/8

The word Target isnt wrong but it might well be replaced with
the word concept.
For example number 4 Keeping teams stable is a very sensible step
when seeking to achieve deadlines. So it is an enabler and so thus
should be a target of the project manager or perhaps scrum master.
The targets explain the rationale behind the hexagon and trade-
spaces.
End.
Be on time and hit deadlines : 3/8 - Ss4 S41
Lesson 41 TITLE= Be on time and hit

deadlines : 3/8 - Ss4 S41

P2A defines on-time as a the overriding concern of projects with
major benefits of huge significance.
To quote the official manual Time is one of the most powerful
weapons in agile.
Hit pause and ask yourself Why does on-time matter? Ill give you
6 reasons when your ready.
1>
Not meeting your own promises or deadlines you have agreed

damages what people think of you while honouring promises
creates good reputation.
2>
And when things run on they normally ramp up the costs and delay
the benefits, so on time often equals on cost.
3>
On time means benefit flows can start, and the earlier the better.
4>
if timings mean nothing then planning, or at least scheduling is

useless. Schedules are for coordinating activity. They can only be
useful if what is scheduled actually happens as it is scheduled, ie on
time!.
5>
Being seen to do what you say youll do improves peoples willing-

ness to trust you and improves your own confidence and morale.
6>
Ok Im really not sure about this one, if Id written the list it

wouldnt be here! Maybe it means dont miss your wedding an-
niversary or the tide turns whether your ready or not.
Lets move on!.
End.
Protect the level of Quality : 4/8 - Ss4 S42
Lesson 42 TITLE= Protect the level of

Quality : 4/8 - Ss4 S42

Maybe hit pause and consider.
what are the causes and consequences of poor quality? We
are using quality in the every day sense here without particular
differentiation between grade, absence of variation, conformance
to specification or fitness for purpose.
P2A notes that overall a consequence of poor quality is that own-
ership or through life costs are higher. The whole DOD 5000 caiv
smart acquisition idea is about optimising the whole through life
costs as opposed to just focussing on acquisition cost : search online
for TCO.
When we
1>
Dont test then faults are found by the customer where cost of
remedy is both cost to fix and reputational.
2>
when we dont document and or train well then later amendments

are harder. Also simply using available capability is hampered;
maybe even impossible. Thus value is never realised and may
actually be destroyed.
3>
If we dont deliver to standards required for the definition of done

there will be consequences for acceptance and for benefits (and if
the standards didnt matter why where they there in the first place!)
4>
As time is squeezed in ways that hit testing and documentation it

often also hits design and there again are causes of higher future
TCO.
End.
Embrace change : 5/8 - Ss4 s43 Embrace Change 5/8
Lesson 43 TITLE= Embrace change : 5/8 -

Ss4 s43.

The target here is to embrace change and the concept is in part the
evolution of an accurate product.
The first thing we need to embrace with the P2A view of change is
it occurs at 2 levels.
The lower-level is change that can be dealt with situationally
within the development teams, probably by an empowered product
owner who evaluates the trade-space and make a decision.
More significant change is that which renders baselines, or agree-
ments challenged.
The art of agile development lies in expressing requirements that
make fixed only what is essential to fix and to leave open everything
else to be as flexible as possible for as long as possible.

P2A gives us three observations.
1>
First change is the only constant, a wonderful oxymoron and ironic

statement. Is that recursive or self referential? I dont know but it
matters that you recognise agile is driven by the certainty of change
and thus the need to cope with it rather than try to outlaw it.
The point is change will happen so we have agile mechanisms in
place to deal with it.
2>
Do you recall we got through {{Starting up a Project}} with a Project

Product Description-A21 that is possibly only visionary.
Its composition is in terms of epics and stories not detailed spec-
ifications? As progress towards a destination is made so acuity of
vision rises and we can describe in better and better detail what is
really wanted and needed.
I like the mental image of a sculptor starts with a rectangular block
of rock, that becomes roughly figure shaped, and then features are
one by one wrought in increasingly fine detail until eventually the
whole is perfectly shaped and eventually highly polished.
3>
The accurate product concept is in my head with the same mental

model.
Over time the project adds and subtracts items to the backlog and
refines details of those items. Understanding grows so we end-up
delivering what is truly needed and to high standards.
End.
Keep teams stable : 6/8 - Ss4 s44 6/8 Stable Teams
Lesson 44 TITLE= Keep teams stable : 6/8

- Ss4 s44 6/8.

Nowt so strange as folk as an English saying from Yorkshire goes.
And nothing more strange than the behaviours of groups of people.
There is a whole branch of science in sociology.
A simple summary might be to say teams have social dynamics
that take time to evolve to a point where the team spends its
energy being productive rather than concentrating on interpersonal
influences.
P2A says dont change teams mid-sprint, better yet dont change
teams.
But.
1 When>
Teams often do need change over a projects lifespan So when is

best?.
Actually one answer p2a exams like is to say dont change a teams
members, instead add a new team. But the answer to the question
as asked is
2 AtBoundry>
If you have to then change teams on stage or release boundaries and

expect a decrease in productivity.
Fred Brooks Jnr wrote lots on the effects of adding people to teams
to catch-up late delivery. His conclusion is late teams plus new
people equals even later completion for a whole host of reasons.
The axelos slide here summarises a few of Brooks points.
3 Timelost>
Brooks first observation is capable people are diverted from creating

results to brief new team members.
4 >
Second is the communication overhead rises.

This is Brooks Law of the number of communication paths in a
team. It is (n2-n)/2. If you want to search for it Brooks excellent
book is the Called the Mythical Man Month. He was project director
for IBMs os360 and early mainframe operating system.
5 >
The key reason for stable teams is Bruce Tuckmans observations on

the dynamics of small groups, You may know it as forming storming
norming performing and mourning.
4>
Lastly is one Im less worried about as a pm, perhaps Im too much

the PM focussed on my projects goals or maybe P2A assumes
all resources are acquired by shuffling internal seats so where the
resources are acquired from may now have a deficiency with project
impact perhaps?.
Lets do the last of the five targets then try an exam question next.
End.
Accept that the customer doesnt need everything : 7/8 - Ss4 s45 7/8 Cus-
tomers Wants
Lesson 45 TITLE= Accept that the

customer doesnt need everything : 7/8 -
Ss4 s45 7/8.

Customer needs target.
The premise here is that customers ask for things they dont truly
need and omit things they really do need.
Sometimes that is true, but not always. The challenge addressed
here is the one at the core of the never ending debate between an
approach rooted in the ideas of Philip Crosby and iso 9000 which is
to prize conformance to specification versus Joseph Jurans opinion
which is deliver what is Fit for purpose.
Too often the suppliers view is conformance to specification in
preference to properly understanding the customers need for fit-
ness for purpose. A vexed topic full of confusions. Summarised as
Caveat Emptor or buyer beware.
So P2A gives us guidance with an honest intent. That guidance
distils to Create a culture that acknowledges that requirements get
refined over time, that what is specified at the start.
1>
is often from a position of least real knowledge and what happens

as we go is we discover and refine so we should be able to drop and
add at least within tolerances.
The result in P2A terms is quotably a more accurate product.
Plainly sensible and facilitated by integrated product teams and the
rest of dod 5000s smart acquisition ideas.
2>
We do however have to be careful about who is deciding what to

omit or include.
If its the agile product owner or in P2As vocabulary the customer
subject matter expert (C_SME) then the authority and knowledge
is coming from the right place. We might be safe.
3>
flexing scope where we are sure the items are marginal value does
help being on time to a good quality so
4>
it also has potential to speed up the most important, by not holding

it up behind the trivial, but this is prioritisation rather than deletion.
Finally.
5>
P2A tells us as a fact flexing requirements is the safest compromise

to protect value or continued business justification.
Next I have another exam question for you to examine.
End.
Paper_2 Qn_25 - Ss4 s46 : Exam Question
Lesson 46 TITLE= Exam Question

Analysis: Paper_2 Qn_25 - Ss4 s46.
This is a really illustrative question of many that I had on the live

exam. It asks which statement best accords with the five targets.
Recognise that Best means they could all or none accord but we
still need the isolate one with maximum fit.
Maybe hit pause then Ill walk through the options and answers.
Welcome back?.
So here is some thinking.
Option a) looks plausible it says do more scope by being flexible
about the grade (degree of quality) of the solution.
b) Says new team members plural while the question stem says a
social media expert and the scrum guide in appendix h says teams
under 3 people lose effectiveness but otherwise this definitely keeps

the team that currently exists stable and that is paramount.
c) Says let the team decide. Thats certainly collaborative and
empowering etc. Is it up to teams though to decide how much
resource is assigned to how much scope of delivery and thus
business benefit? Hmm? No it isnt.
And D says the team would only be five so thats fine but it is
changing the team make up that is disruptive (Team numbers in
the range 3 to 9 have justification in various parts of the manual.
So which answers are in and out? A) is plausible, B) has an yes and a
no element and an inconsistency in wording, C) might not be what
is intended by self-directed teams and D) seems spurious.
The given rationale is.
Answers>
So A) is out It seems maybe P2A sees flexing scope as recovering

from problem not exploiting opportunity.
C) Is out because the team directs its assigned work and adding
people will without doubt contradict the keep the team stable
maxim.
And D) is out what ever the chief examiners rationale means.
Right answer was B) despite the inconsistency.
In all I think this is less clear cut than Id hope and expect exam
questions to be but it is very faithful to the character of my real
exam.
Thus its the level of thinking you will have to develop some comfort
with.
A last though for this question is the pass mark is 60% not 98%
The appropriate balance : 8/8 - Ss4 s47 8/8 balance
Lesson 47 TITLE= The appropriate

balance : 8/8 - Ss4 s47.

We can say The Summary of the five targets and 6 factors to fix and
flex is all about balance, all about achieving an holistic view.
PRINCE2 Agiles view is that being on time and at the required
quality for a subset of the requirements that evolve as we go is the
best proposition for the customer.
The alternative is Create everything that was asked for at the
start and now the scope performance risk of is in danger of
being mitigated by the quality of results delivered or delivery date
achieved.
On balance are the 6 tolerances and 5 targets best for customer or
supplier? I leave you to ponder that one.
What we should conclude with are.
Quest>
First) when the customer attempts to nail down detailed require-

ments and detailed costings up front then quoteable the appearance
of control is often an illusion. Much pm guidance claiming to be
best-practice says clear and agreed requirements are a necessity
before we start. Clearly an unworkable constraint in many situa-
tions. Later in ss8 s69 et seq we will see the KuhNevIn cliff-face
transition from inappropriate use of best-practice to chaos.
And second.
Can you recall the five targets, the six tolerances or aspects of a
project, the 5 focus areas, the techniques, frameworks, concepts and
behaviours?.
Maybe hit pause and Have a go before I list them out for you.
Things to recall>
Here they are : if youve not internalised them yet then maybe write
them out to help recall?.
How about creating a mnemonic and eMailing me your best ideas
p2a@logicalmodel.net. Or post to the disqus forum. Ill add all those
that are truly inspirational to the courses downloads with full credit
to you. If you havent yet booked your exam then you should give
it serious consideration. Your coming up on the 25% mark. Time to
get the admin of the exam done too. Agile has a concept weve yet
to meet called team velocity. Its the rate at which progress is made
and is used as a predictor of completion. At the 25% mark what does
that mean for you in terms of effort and date at completion. Mail
me Id like to gather some statistics, Ill mail you back some extra
practice questions as a thank you.
Ive got another exam question for you right now too, its on the
next slide.
A Behaviours 2.2 - Collaborative, Self-Org, Customer Focus, Em-
powered, Trust not blame.
P2A Behaviours 7.4 - Transparency, Collaboration, Rich Comms,
6 Aspects : Time & Cost : Fix, Benefits & Risk : Fix/Flex, Quality
Criteria & Scope Flex.
5 Targets : Be on time/ Hit deadlines, Protect quality, Embrace
change, Stable teams, A customer who accepts flexing scope.
Create what can be delivered to FFP quality in priority order.
End.
Paper_1 Qn_25 - Ss4 s48 Exam Qn
Lesson 48 TITLE= EqA: Paper_1 Qn_25 -

Ss4 s48.
Have a look at the stem and available answers.
Standard procedure for exam questions should be emerging. Pause,
read, consider available options, return and Ill show the chief
examiners answers, pause to read then return and Ill attempt to
rationalise the rationale.
Ok read the question?.
Ready for answers?.
Ans>
The project schedule shows 5 work streams.

We dont know which week we are curently in, maybe it is week
zero!.
Looking at the options.

A is true, team members should be able to cover for each other to
some degree, chapter 10 on organisation will tell us about T shaped
people, breadth and specialism : its course section 15.
B is also potentially true, avoid unneeded costs and cost is an aspect
we dont flex.
C is also true if we are in the short term but otherwise across the
duration of any decent sized project this is bound to be impractical.
and D is also true but is this answer anything to do with the 5 targets
of on time, on quality, change, stable teams, and customers real
needs.
Clearly from the answer given the chief examiners view is the best
answer reflects teams being flexible and being able to support each
other.
End.
MoSCoW prioritisation
Lesson 49 TITLE= MoSCoW prioritisation

.

Behaviours 2.2 - Collaborative, Self-Org, Customer Focus, Empow-
ered, Trust not blame.
Behaviours 7.4 - Transparency, Collaboration, Rich Comms, Self
Org, Exploration.
6 Aspects : Time & Cost : Fix, Benefits & Risk : Fix/Flex, QC & Scope
Flex.
5 Targets : On time/Deadlines, Protect Q, Embrace d, Stable Team,
Customer does need it all.
End.
Exercise-1: What Is Chestertons Investment? - Ss4 s50 Case Study
Lesson 50 TITLE= Case-Study-1: What Is

Chestertons Investment? - Ss4 s50.
The exam questions weve examined so far are like all p2a exams
based on a scenario.
Scenario>
For convenience here is the text. Depending on your device it might

be legible. The download is crystal clear, and here is the schedule.
Gantt>
If the details onscreen here are illegible then look in the resources-
downloads for the Chestertons Cheese scenario.
Have a read and ask your self.
What is the project?.

Hit pause till your ready for some thoughts.
Welcome back.
The business driver is to streamline operations and boost market
awareness.
Attractive results might include diverting some phone traffic &
replace as web-site traffic so that employee time is freed to be spent
on more valuable business development.
If you dont sell more cheese is it a success? Yes if the cheese is sold
at a lower level of staff time per sale.
With the right focus and maybe some luck a web-site might also
increase sales. Making the right luck will involve some epics about
marketing and promotional activity.
Consolidating premises also creates efficiencies, Brand building
increases turn over which even wit out efficiencies should boost
profits but is doubly helpful if cost of sales are also reduced.
End.
5 Where agile plugs into
PRINCE2.
Where agile plugs into PRINCE2 - Ss5 s51
Lesson 51 Where agile plugs into

PRINCE2 Section Overview - 2 - Ss5 s51
Earlier we explored the simple backlog and spring model of scrum

in a bau setting.
Also we explored the standard prince framework that runs start,
initiate, deliver, close.
5 Where agile plugs into PRINCE2. 133
Now we are going to fit the backlog and sprint idea into the prince
framework .
Then expand the detail of the simple scrum approach to a more
mature one inclusive of a Release Plan or Product Road-Map (or
if your existing knowledge includes programme management then
the term blue-print is a suitable synonym for road map).
End.
Agile and the PRINCE2 Processes - Ss5 s52
Lesson 52 TITLE= Agile and the PRINCE2

Processes - Ss5 s52

The P2A manual gives us a schematic view of the whole of prince

in Figure 16.2
It shows us that the {{Controlling a Stage}} & {{Managing Product
Delivery}} processes are a neat boundary where we can insert
the mechanics of releases and flow based or sprint based product
development.
1>
Crucial to repeat is that we are not just inserting a development

cycle into mp we are infusing all of prince with agile thinking.
This illustration and 16.3 just show the mechanics of the insertion
and the Appendix A management products related to the interfaces
between direct manage and deliver levels of P2A governance.
{{Starting up a Project}} creates the Project Brief-A19 to say how
agile will be used. Use is most obviously the interface between
{{Controlling a Stage}} and {{Managing Product Delivery}} via Work
Packages-A26 with Product Descriptions-A17 but hese may be
called sprint backlog and user stories with a definition of done. The
interface is also Team-Plans-A16, Checkpoint Reports-A3 and the
Quality Register-A23 and Configuration Item Records-A5
When we insert frameworks.
2 Fmwk>
we can use any and all of the ones from table 2.1 or any others.
Projects with multiple workstreams will likely use more than one
product development cycle concurrently.
3 Expnd>
the result of inserting agile product development frameworks be-

hind the links fronm {{Controlling a Stage}} to {{Managing Product
Delivery}} is not prescriptive of the way work is organised to deliver

results to the business.
It may be that a stage contains releases plural and the release
contains sprints plural. Equally a sprint could encompass releases
plural.
4 >
so this is illustrative of a-way not the way.
5 fade>
End.
Relating agile processes to PRINCE2 processes: Simple Backlog and Sprint -

Ss5 s53
Lesson 53 TITLE= Relating agile

processes to PRINCE2 processes: Simple
Backlog and Sprint - Ss5 s53

This slide represents a bit of a turning point.
From here all the way to the end of the course we will now be
definitive. Well as definitive as it is possible to be.
The top half of the diagram is the backlog and sprint structure we
have seen but now we will plug it into a prince structure and add
some details omitted earlier.
1 Maturity>
Then below we will do it again for an environment that is more

mature in the manuals view. The detail builds.
2 V+B>
the pre-project and Initiation Stage develops vision, epics and user
stories for at least the most obvious needs, prince activity names
would be those like [ Prepare the outline Business Case [ 12.4.4 ], [
Create the Project Plan [ 14.4.6 ] and [ Plan the next stage [ 17.4.1 ]
3 splan>
The scrum name would be a Sprint Planning Meeting.

Before we finish this slide we will explore the Sprint Planning
Meeting and dissect it. Appendix H The Definitive Guide To Scrum
suggests expected durations for events like the SPM - but back to
the structure for a few minutes.
The result of the SPM is items that met the definition of ready,
are within the development teams estimated sprint capacity and
support the sprint goal are selected as components of the sprint
backlog.
4 Srum>
The team work away and each day hold their daily stand-up
discussion of those 3 questions; done, do next and blockers.
5 Srevw>
At the sprints end the team and invited stakeholders hold a Sprint
Review.
Plain prince2 might be calling this [ Deliver a Work Package [ 16.4.3
] or part of several of the activities of {{Managing a Stage Boundary}}
The SRw demonstrates the product versus its DoD.
6 Sretro>
The team also hold a Sprint Retrospective.

Plain prince definitely calls this activity within {{Managing a Stage
Boundary}} such as [ Report stage end [ 17.4.4 ]
7 Cycle>
Now we know the journey from SB to SB we can see it repeat across

stages.
Recall we dont know if the release strategy is like Googles, and
eBays with multiple releases every day or maybe only one release
per stage or even less.
End.
Relating agile processes to PRINCE2 processes: Stages with Releases - Ss5 s54

processes to PRINCE2 processes: Stages
with Releases - Ss5 s54

Lets now look at what P2A calls a mature environment.
Now there is vision and a product road map probably also exists.
1 V+B+End>
vision is defined in the Pre-project activity and the backlog comes

into existence with linkage to business value from target shippable
products.
Note shippable here is from the dev. team to the projects customer.
For Chestertons the vision is the future new premisies, the web-site,
brand identity and marketing capabilities not a packet of cheese in
some final customers shopping basket.
2 RelP>
Our pre-project and Initiation Stage activity sets out the Project
Plan-A16 and Release Plan.
We have now a Release Backlog from a definition of ready that suits
business discussions about strategic direction.
If youre a PMP holder you will know this via the non-prince
vocabulary of Rolling Wave planning or continuous elaboration.
3 SptPlan>
The sprint planning meeting creates a sprint backlog from the

release backlog then the sprint runs, the team meet in a daily stand-
up.
4 Spt in Stage>
indeed the structure of the stage might cycle around multiple sprints
until the release plans backlog is exhausted. Each sprint ends with
sprint reviews, retrospectives and planning meetings per sprint.
5 StagEnd>
Then the prince stage ends with a Release or Stage Review and
Release or Stage Retrospective.
6 StgPlan>
A stage boundary not only looks backwards in retrospectives but

forwards to create a new Release Backlog.
What we have not considered so far is that in a project context we

probably have multiple teams.
7parallelSprints>
so sprints for different teams would then be running in parallel.

All the exam papers Ive seen show clearly that sprints are running
in parallel and all my experience is of multiple concurrent teams.
8 etc>
and so it continues.
End.
Relating agile processes to PRINCE2 processes: Planning & Review Events -

Ss5 s55

processes to PRINCE2 processes:
Planning & Review Events - Ss5 s55

The Sprint Planning Meeting (spm) actually has a pre-cursor and
has two internal parts.
1 SP>
The first internal part is the What part.

The agile product owner or customer subject matter expert (C_-
SME) in P2A vocabulary sifts through the stories that are ready and
selects those they would like delivered by the up-coming sprint. I
will explain what we mean by Ready before we move off this slide.
Scrums definition tells us the p.o. selects, the team estimates,
and together they negotiate what they think fits in the sprint.
Estimating is a complex topic. We will examine the agile techniques
for estimating later.
2 SP How>
The second internal part is the how part.

The development team discuss and agree for this story what do we
need to do to get detailed requirements so we know its complete
Definition of Done. Then what do we do to build it and verify and
ship it.
The Definition of Done is the product or features Acceptance Cri-
teria. In XP and similar software worlds we define the acceptance
tests in executable form before we create the software.
If we are making a waterproof camera we might fill a bucket with
water right now!.
The full set of questions the team answers to be clear on require-

ments and the definition of done depends on the product to create
but must include at least )Who do we interview, )what models do
we build or shippable products do we deliver? )What are all the
build and test activities. )What information sources are inputs )what
results are outputs and are we clear on how to demonstrate that.
There is lots in here that an open minded environment can learn
from PMBoK and traditional sources of quality insight.
3 BKlgRef>
the pre-requisite step to a Sprint Planning Meeting is Backlog

Refinement.
This is the activity that brings backlog items to the state of ready.
POs and their dev team colleagues and the scrum master (is this our
first mention of the scrum master!? Well explore this roles duties
soon. For now we will say they are the expert in agile methods
and the teams coach). So PO & team apply a little time and effort
throughout a sprint to bringing epics to user story level and user
stories to ready. Ready means we have good understanding of the
story, and estimates for its value and for its development effort.
4 RelP>
Like vision and road-maps Release planning, Release Backlogs,

Release Reviews or Release Retrospectives do not exist in the Scrum
Guide.
They are found in places like XP; as an aside Beck and Fowlers
Planning Extreme Programming is a really good book, definitely in
my top ten irrespective of your industry. The title P-XP might
be off putting if your from outside software but it isnt about
programming its about project management.
I have a key point to reiterate from the descriptions Ive been

sharing.
This is p2a and it is all prince2. Its prince interpreted for and applied
to agile practices. It is a prince skeleton with agile heart, mind and
flesh on the prince bones.
With the addition of a little procedural guidance like Kanban and
measurement tools like burn charts we will be done.
Congratulate your self!.
In one sense weve done the 80%. The next 80% adds detail but
doesnt expand the length and breadth of what we have now
completed.
End.
6 Principles & P2A
Behaviours & PRINCE2
Themes.
Principles & P2A Behaviours & PRINCE2 Themes - 4 - Ss6 s 56
Lesson 56 TITLE= Principles & P2A

Behaviours & PRINCE2 Themes Section
Overview - 4 - Ss6 s 56
If your on an exam track the as a prince practitioner I sure hope we

know Prince is based on 7 principles, 7 themes, 7 processes etc.
6 Principles & P2A Behaviours & PRINCE2 Themes. 145
Well now we are about to start exploring the processes and with
them the themes.
For example it makes sense when considering the {{Starting up a
Project}} process to also consider the Business Case theme even
though the Business Case runs throughout the project and hand
in hand with the Risk theme.
Just 4 lessons to this last section of training materials covering the
official manuals part one. Before considering the processes and
themes in detail we must position the 7 prince principles and outline
the themes.
Big messages here are:.
1 P2A uses 100% of what prince provides; nothing is removed.
2Every agile framework has a set of principles and values and or
behaviours. They all use different vocabulary so the official manual
summarises what various frameworks say in Appendix E and gives
us a set of behaviours for P2A behaviours that compliment the agile
behaviours you memorised previously.
Lets explore.
End.
PRINCE2 Principles : guidance 1/4 - Ss6 S57
Lesson 57 TITLE= PRINCE2 Principles :

guidance 1/4 - Ss6 S57.

Prince principles are listed in 5.2 but explained in table 7.1. 7.1 tells
us.
1>
1 That prince talks of benefit where agile talks of value. The two
are close but not identical. In P2A the search for value may use a
mvp. MVP in p2a is as defined by Lean Start-Up; it is a model or
other representation perhaps even a fully operational solution that
establishes quickly and or reconfirms that we have a viable business
proposition.
1>
2 Learning from Experience is the Kiazen, continuous process

improvement cycle.
In agile we seek to make the cycle as short as possible. Its customer
face is the mvp and sprint, release etc review. Its team cycles are
through retrospectives all these cycles are the inspect and adapt
concept. An online search for David Kolb is worthwhile on the
absorbing aspect of really Learning fE .
3>
3 R&R is a big topic in the manual as it seeks to grapple with an

area it maybe didnt see with great clarity.
prince provides management roles. Some in Agile dislike man-
agement agile is always delivery team- focussed. The angst is all
about how to interface technicians and creatives to management.
Left brain meets right brain perhaps : left & right brain is my
back@work tm speculation, nothing to do with the manual!.
4>
prince principal 4 is Manage by stages.

it would on the face of it be simple. A Stage is a big time-box it can
contain smaller timeboxes that can contain smaller timeboxes thus
sprint, release and stage makes a set. This thinking mostly works
except a stage is a time bound unit of authority to expend resources
and a sprint is a commitment to deliver product and a release is
also a commitment to deploy product. Also a sprint may contain re-
leases or a release may contain sprints. In general short time-boxes
suit Learning from Experience for highly uncertain environments
where close attention to the Continuing BJ is required. The principle
resurfaces in tools like cynefin and procedure like sprints and what
to fix rather than flex.
5>
p5 Manage By Exception is quotably the heart of empowerment.

Setting boundaries or tolerances can be re-expressed as empowering
complete freedom within the boundary.
6>
6th A product focus has always been central to projects and prince
has said so for a long time.
Agile repeats the need to define the product in acceptance terms
through Quality criteria aka Acceptance Criteria. P2A says make
the a/c scalar where ever possible to allow delivery of less de-
manding targets. The Guide to the Project Management Body of
Knowledge (PMBoK-G) calls the same concept grade.
7>
Finally the vital role of tailoring has always been central to all
framework based methods but is often ignored by those looking
to make a quick derogatory jibe.
End.
Principles and behaviours 2/4 - Ss6 S58
Lesson 58 TITLE= Principles and

behaviours 2/4 - Ss6 S58.

Principles and behaviours are a big deal in p2a & in the lives of
millennials and Gen-Y.
Life as a whole has been very different in many ways for those
entering the work force now, those moving into management now
and those moving out of the workforce now.
P2 and p2a reflect a changing work culture from a changing
demographic.
Formative events such as 9/11, and enron versus pre-computer
baby-boomers whose parent knew food rationing but not McDs
drives a tsunami of principal and behaviour based opinion.
P2A groups all the adjectives to describe the whole ethos of values/
attitudes etc as behaviours and itemises 5 that are specific items to
monitor in the use of p2a.
Apdx E>
Many more from various agile frameworks are set-out in Apdx E.

I dont know for a fact but Ill guess separating out each frame-
works specific terms in your own mind is unneccassary because
P2A gives us its own 5 in 7.4. hopefully your recall is sound : Agiles
5 from lesson 22 and table 2.2 are be collaborative, sel organise,
customer focus, empowers & trusting not blaming and p2as 5
from 7.4 and our next 2 lectures are still collaboration and self
organisation but now the other three are transparency, rich comms
and exploration.
End.
PRINCE2 Agile Behaviours 3/4 - Ss6 S59

Lesson 59 TITLE= PRINCE2 Agile

Behaviours 3/4 - Ss6 S59.

In 7.4 the official manual explains each behaviour in detail.
Quotably The Project Board and project management should be
constantly vigilant for these traits although no advice on response is
included. Note too they should display the behaviours themselves
too. If behaviours are all in place we get the best results whether
we are highly or only slightly agile : These behaviours are not an
agility discriminator but in general influence project performance.
Transparency equates to openness rather than just visibility of
information. Data and analysis, whether good or bad, is in plain
sight and accessible to enable speed, clarity, engagement and to
reduced surprises.
Collaboration means synergy evolves. A team of motivated, mutu-
ally respectful people delivery more than the sum of their individual
capabilities. The team is an IPT, that is customer and developers
whose collaborations extend outside the immediate team and who
support and help each other as they can.
Rich comms covers replacing a documentation orientation with
communications that pick the best channels, so emphasis face-2-
face meetings, visualizations & models, fast and free exchanges.
Clearly linking to ideas of transparency, trust and commitment. It is
still key to have the means to record things for purposes of memory
so documents etc still have an important place. Maybe a summary
of the message is stop eMailing when you could talk to people.
Self-Organisation is a widely used term in Complex Adaptive Sys-
tems (CAS) but P2A uses it perhaps a little differently. P2As view
is SO is inclusive of the goal, the work and the teams relationships.
P2A wants the people closest to and most knowledgeable about

work to be the ones who plan the work as well as do the work so
they have buy-in to intentions.
Self organisation embraces mutual respect in the team inclusively
from Project Board members downwards. SO means trusting people
to be motivated to do a good job. It is a re expression of Manage By
Exception means freedom.
It needs attractors to use a cas term, agile perhaps assumes en-
joying the work is the attractor anyway p2a makes no mention of
developing visible or perhaps that should be visceral answers to the
participants whats in it for me questions.
Table 2.1 says projects are difficult.
By definition they are not routine so learning is a key need to clarify
known unknowns and discover previously unknown unknowns.
Learning from Experience in chaotic and complex environments
is the only possible way to achieve results. To do that requires
experimentation to explore what we suspect or hope or even just
discover by serendipity. An experiment might be jargonised as a
Spike; an attempt to model or prototype something to understand
an aspect of requirements or solution better. More when we get to
Lean Start-up.
The shorter the feedback loop the better; the more small experi-
ments that accumulate insight the more the learning in total about
what constitutes an accurate product. Exploration is best when
everyone whether customer or dev team member is involved.
Lets have a look at how this might turn up in an exam question.
End.
Paper_1 Qn_7 - Ss6 S60 Eqn Title
Lesson 60 TITLE= Paper_1 Qn_7 - Ss6 S60.
I know the qn stem says using the additional info and youll have to
refer to the supporting course materials for that but it isnt actually
necessary to answer and that should be a learning moment about
the exam for you.
Pause, Read the question. Ill share the chief examiners answer
then pause read the rationales then return and Ill offer some
commentary.
I did the whole of my first mock without reading the scenario
at all as a test of its indispensability. Not reading the scenario
or additional info didnt seem to make much difference to many
questions but was necessary for a few.
On balance if the scenario is relevant in places then you are going
to have to read it eventually. Maybe then its best to read it first.
My current Examining Institutes online proctor service allows you
to print the scenario at the exams start : obviously you need a

connected printer at that point in time, if it isnt a direct connection
youll have to show the proctor its a plain printout : same need
applies if you use a manual printed from a pdf.
Returning to this questions, pause to read it. Ill put the answers up
in a moment.
ans>
We are told we have a brand recognition issue and have made

a recommendation to fix it in future thus we are Learning from
Experience.
End.
Agile and the PRINCE2 Themes 4/4 - Ss6 S61

Lesson 61 TITLE= Agile and the PRINCE2

Themes 4/4 - Ss6 S61.

I Have quoted it often enough I hope P2A is 100% of p2, we just
interpret it all, such as the themes for how they interplay with, for
example self organising emergence etc.
1>
So we need all the themes, what we have to consider is how they get
used. For example agile environments often make scope decisions
later; the backlog is never frozen, some aspects of uncertainty about
is the baseline the best choice for benefits? are naturally managed
day by day rather than ever being seen as specific risks.
In generally agile is more risk aware and less driven by procedu-
ralised risk management. Likewise a young software team bent on
churning out code may be some what less explicitly Business Case
driven even if their leadership team follows formalised approval via
gating procedures.
2>
We will explore all these from a P2A perspective in the lessons to

come as each has a chapter in the official manual, so Ill move on
now.
End.
Exercise-6: Rank the 5 behaviours - Ss6 S62
Lesson 62 TITLE= Exercise-6: Rank the 5

behaviours - Ss6 S62.
As well as passing the exam we need to build back@work real world

skills if the exam pass is to really be useful.
Since we have covered agile and p2as list of behaviours you should
explore their implications.
It might help to do a simple recollection test first. Actually not so
simple. See how you do to recall these. If recall is still a challenge,
which is fair enough, then list them out from the answers hit pause
to think then Ill fillin all the blanks. Welcome back?
Ans>
Here is that reminder of the two sets of behaviours and a whole

bunch of other things we have covered.
Lets now consider .

Trace the implications of the 5 behaviours in the context of P2A to
actions and attitudes of the role holders around you in your current
working environment. Are they what p2a calls for. Why and why
not. How could they be improved, whats in it for each stakeholder.
You may choose to send me your suggested answer or Join the on-
line discussion of what do the descriptions mean, which behaviours
matter most, which are hardest, when and in what context?.
End.
Lunch
Lesson 63 TITLE= Lunch .
End.
Change of Scale
Lesson 64 TITLE= End of The

Introduction, Now for a Change of Scale
.
s64 Change of Pace.

Youve done it all : Celebration.
All at high level anyway,.
1 ESA pic>
we have to fill in a lot of detail but in essence we have no more

world to see.
Before we explore the detailed map I will summarise the globe.
P2A defines agile as a mindset whose 3 principle parts are;.

1) Agile Behaviours or Principles or Values and they are; ) Being col-
laborative, )self-organizing teams, customer-focused, )empowered,
)trusting not blaming.
2nd) Concepts or Fundamentals; )Prioritizing what is delivered,
)Working iteratively and incrementally, )Not necessarily delivering
everything asked for, )Time-focused delivery, )An inspect and
adapt approach, )Kaizen or CPI, and )Limiting work in progress
(WIP).
3 Techniques or Practices or Tools; Here our list is )Burn charts,
)user stories, ) retrospectives, )timeboxing, and )Measuring flow.
All projects are agile to some degree, the right degree is context
dependant .
Also there is relative value in the four principles of the agile
manifesto; )Individuals and interaction over process and tools,
)Working products over comprehensive documentation, )Customer
collaboration over contract negotiation, )Responding to change over
following a plan.
P2A says.
Agile on its own is suitable for Business as Usual. With help it is
good for projects too. P2A is projects only.
Projects need a manager to coordinate them because Projects are
temporary, difficult, uncertain, and a team is created to deliver
them. Projects have early steps; pre-project, initiation and late
steps which are the close-out activities . The early and later stuff
surrounds the delivery stages.
Projects operate over management 3 levels. At the top is Direct,
supported by manage to enable the Delivery level (prince describes
Management at Corporate or Programme level as a fourth level
above the project).
P2A is most directly of value to prince organisations wishing to

ennhance their agile capability.
Synergy arises from blending and weaving prince with agile,. We
are not running them in parallel.
Prince brings strength in direction and management, agile brings
delivery strength in development activity.
P2A consists of techniques, concepts, frameworks, behaviours and
focus areas.
The focus areas are 1) Risk FROM agile measured on the Agilometer,
2) User Requirements capture, 3) Rich communications, 4)Frequent
Releases and 5) Contracts.
The 8 key points are:.
)PRINCE is already agile enabled, )prince isnt a traditional water-
fall project method, )P2A is not just for IT, Agile is not just Scrum,
, )Common agile :on its own- isnt suited to projects, )Agile in P2A
means behaviour, concept, framework and techniques, )Agile in
projects is not yes/no but how much?.
The 6 aspects with tolerance are Time and Cost : which is set to zero
tolerance (is that an oxymoron?), Quality targets and scope (Fully
flexible) and Benefits and Risk (Which may flex).
The 6 aspects are managed to ensure the 5 targets are met : what
matters is knowing why we flex and fix.
The 5 targets are Be on time and hit deadlines, Embrace change,
Keep teams stable, Accept the customer doesnt need everything.
Scrums framework includes .
The product backlog, the sprint planning meeting (in two parts,
story selection and definition of the development steps : the what
and the how), the sprint backlog, the Daily Scrum a stand-up
meeting that asks 3 questions, What is Done, Next, Blockers in
under 15 mins. Each sprint creates shippable product. Delivery of

product is a release.
Instead of scrum we can use flow based methods to progress work.
The journey is.
Pre-project & Initiation Stage : Focussed on defining a Release
plan. Focussed on feature/ product, All management levels fo-
cus on estimating & planning, Customer is in the team, every-
thing is timeboxed, created collaboratively, accessible eg displays
rather than documents, The Project Product Description-A21 ex-
presses the mandatory through desirable project deliverables, Prod-
uct Description-A17 may be stories or epics that we recognise are
to be flexed in number and expanded in detail as required., the
Benefits Review Plan-A1 embraces frequent early releases to access
value asap. Comms includes feedback loops such as enabled by an
MVP. The Project Brief-A19 says how agile applies in this project.
Delivery stages deliver in customer priority order from teams that
self-organise, practice transparency honesty, openness and trust,
progress is measured via burn charts, reviews and demos, scope and
quality are the focus of tolerances.
Stage boundaries focus on what is delivered, the benefits enabled
and the level of change.
Requirements are written to enable flexing variable product at-
tributes.
Reporting is lo-tech, tactile, stuff stuck to a wall display and updated
in real time.
At the close what has been delivered vs what was envisaged at the
start will have omissions and extras, the customer will be using
delivered artefacts and features to generate value, tidying up is easy
because handovers have been happening all the way through.
RedCircle>
PS I live Here.
http://eclipse.gsfc.nasa.gov/transit/TV2004/Earth-Great1b.jpg)
http://www.esa.int/Our_Activities/Observing_the_Earth/Earth_from_-
Space_United_Europe.
Original Message
From: Nadia.Imbert-Vier@esa.int [mailto:Nadia.Imbert-Vier@esa.int]
Sent: 31 July 2015 09:42 To: Simon@LogicalModel.Net. Cc: Roberto.LoVerde@esa.int.
Subject: Fw: use of image - ESA REFERENCE : ESA HQ PHOTOS
20150731-00824 Importance: High. Dear Simon Harris,. Thank you
for your e-mail and for your interest in ESAs activities. Further to
your request, we authorise you to use the image http://www.esa.int/spaceinimages/Im
united_Europe_from_space. for educational purposes only. Please
note that the full copyright line has to be indicated : ESA. We
hope this e-mail answers your request. I remain at your disposal
for further information you might need. Best regards. SERCO for
ESA - European Space Agency. Nadia Imbert-Vier. Multimedia
Officer. Communication Department. Headquarters. 8-10 rue Mario
Nikis. 75738 Paris Cedex 15, France. nadia.imbert-vier@esa.int |
www.esa.int. T +33 1 53 69 7249 | F +33 1 53 69 7690
These photographs may be reproduced free, on the following con-
ditions:. They may not be used to state or imply the endorsement
by ESA or one of its employees of a commercial product, process
or service, or used in any other manner that might mislead. If
recognisable persons appear in this photograph, use for commercial
purposes may infringe their rights. If these photographs are to
be used in advertising or any commercial promotion, layout and
copy must be submitted to ESA beforehand for approval. The full

copyright has to be indicated. Official P2A manual follows prince
OMs structure. Course follows project journey.
7 Processes, 7 Principles, 7 Themes.
Each process; 3 parts : agile context (find), agile actions(do), the look
(& feel).
7 SU & IP {{Starting up a
Project}} and the Initiation
Stage: (Getting a project
going).
image_title
7 SU & IP {{Starting up a Project}} and the Initiation Stage: (Getting a project
going). 165
Lesson 65 TITLE= SU & IP : getting a

project going Section Overview - 3 - Ss7
s65
Having covered the manuals chapters 1 to 6 in order, the logic now

is that we will follow the sequence of a projects execution.
We are departing from the chapter sequence in the official manual
as that matches the PRINCE2 manuals order. Neither manual is
a training aid!.
Our sequence from here is sort of as a project progresses.
So we start with {{Starting up a Project}} and then the Initia-
tion Stage. That means we must explore the BC & Requirements,
Change, Organisation, Working Agreements, prince principles, prince
behaviours, Risk and The Agilometer .
The next project step then centres on {{Managing Product Deliv-
ery}}, Scrum, Plans & Estimating, Progress, Quality, {{Controlling
a Stage}}, Releases, {{Managing a Stage Boundary}}, {{Directing A
Project}} and Contracts, before needing to cover {{Closing a Project}}
Throughout all of that are the topics we then cover by looking at
the official manuals focus areas & appendicies.
Apdx A+B templates & roles, ch Comms, Kanban, Lean Start-up,
HealthCheck, Advice on the transition to agile practices before
considering some good advice for project managers adopting agile
practices.
Within each manual chapter and each course section what we
consider starts with what may be in place where agile is in use
but not under a P2A structure, then P2As specific guidance and
observations on agile steps, agile roles, agile techniques and agile
artefacts used or created.
In places there will be other agile and integration aspects to explore.
going). 166
Thats summary of everything still to come in every section.

Key messages in just this immediate section are.
1 Success is enhanced if getting started is a controlled process.
Success is also enhanced when the get-go is highly interactive
between all stakeholders and communications are very visually
oriented.
2 Getting going is two processes in P2A just like in prince, even
though the P2A manual merges the guidance. Some agile practi-
tioners may decry any upfront work as being predictive. They have
some good justification and we need to explore when they are right
versus when they or we are arguing poorly from dogma.
3 Kick-off meetings use learnings from previous retrospectives and
the Product Owners input to frame vision, identify the product
backlogs contents, do release planning and define done.
4 The Kuhnevin (Cynefin) framework categorises the project in
ways that help decide where a highly or slightly agile approach is
relevant.
5 The end results that we could deliver are prioritised.
It is understood and accepted by all levels of the organisation that
requirements lack inappropriate detail (if detail is created early on
when agile is actually needed then its often an illusion of detail).
6 The manual also says requirements will be measurable and clear
(17.5) , uncertainties recognised and agiles suitability assessed and
agreed.
Add lib, this tie, legacy of a piss-up in a brewery.
End.
going). 167
Starting up a Project and Initiating a Project 1/3 - Ss7 S66
Lesson 66 TITLE= Starting up a Project

and Initiating a Project 1/3 - Ss7 S66.

Agile practices and vocabulary for the activity at project start-up
varies.
The approach may be a JFDI, just do it, dive in without preparation
one.
1 hiL>
There may be a step called Discovery or Sprint zero where we seek

to bring everyone into alignment through workshop to define the
desired end point, perhaps we get busy creating the workspace and
gathering resources.
The open question is how much, if any preparation is warranted?.
going). 168
2>
Lets explore emergence and what it means when we truly need it.
Imagine your on a TV survival show.
Four of you have been dropped somewhere on the edge of a wooded

area, in the dark, its wet and a little windy, your hungry, there is a
small pile of un identified stuff under a waterproof sheet. Are you
going to sit around and discuss camp site design?.
Probably not, you dive in by taking the sheet off the pile, high level
goals are clear. Shelter, food, sleep. Removal of the sheet reveals
rope, a hand axe, a small shovel, a freshly shot rabbit & dry pasta,
some tin plates, spoons, dry tinder, a sparking steel and a tin kettle.
What next? Someone says Ill cut some branches from the trees and
lash the sheet with the rope to make a shelter.
Someone else says best way to make a fire in these conditions is
to dig a shallow hole. They grasp the shovel, the steel and the
tinder. The immediate discussion has to respond to the fact that
the fires placement anchors the camps placement. Discussion is if
we have the fire there and the shelter here facing the trees well
get the least wind the most shelter and the most warmth. This is
emergence.
Our shelter builder returns with branches and says to the fire
builder I brought these back like this so when I cut the side branches
off you can have them for the fire. Someone else says, I need the
axe, its our sharp implement and the rabbit needs some preparation
before I can cook it and we need water for the pasta tree cutter
says There is a stream cook says Im going to put the pasta and
the rabbit into the kettle together any better ideas?
Emergence continues.
The activity is somewhat chaotic actually exploratory, try, observe,
adapt, retry. The goals are clear and each person contributes as
going). 169
best they can. They task switch as their hands become free or a
previously unseen dependency emerges.
3>
Returning to P2A projects. {Starting up a Project}} and the Initiation

Stage can be combined in some situations.
Perhaps needs are obvious and overriding, perhaps the project is
small scale. P2A is clear that {{Starting up a Project}} and the
Initiation Stage are two steps and that the general rule is they are
separated by a project board decision on ongoing viability.
Su prepares information to answer is the cost, time and trouble
of initiation worth-while? The Initiation Stage does the same to
answer is the project worthwhile? Both are answered by creating
& refining the Business Case-A2. The purpose is as much to halt
the bad idea as promote the good.
The manual tells us agile applies best in disrupted environment,
those where best practice doesnt apply because cause and effect
are uncertain.
If creating a detailed BC is easy & complete we are probably in a
context where some of agiles elements are optional or maybe sub-
optimal.
4>
However much we know we always need team rules, a target and

agreed first actions. These are Charter and vision. Perhaps created
via a collaborative workshop.
If we know a lot then we can be predictive. When applied in
an appropriate environment with good will and skill then being
prepared is ultimately quicker, cheaper and lower risk. In the wrong
environment false preparations are an illusion that masks disasters
proximity. Kuhnevins cliff.
going). 170
Predictive development approaches suffers from late discovery that

the actions of the builder dont match the needs of the customer.
When this happens late on then all the money is gone but there is
zero that is deliverable for it : waterfalls critical weakness.
6>
Some in the agile community believe everything should be emer-

gent and empirically adapted to changing needs.
Key is to always refer to the behaviours (Collaborate, Self-Organise,
Customer focus, Empowered & Trust not blame) and to adopt the
concepts and techniques to the degree needed.
When the need is to be highly iterative to explore emergent scope
it probably means SU/IP/DP merge together and become fluid
because a segmented approach relies on cause and effect under-
standing . Fine if we know in advance, we can be less exploratory.
Otherwise we should be more agile and so manage based on
accepting we will discover as we go.
What is enough preparation is a balance and it is the focus of Eric
Riess Lean Start-Up that we will touch on later.
End.
going). 171
Starting Up a Project and the Initiation Stage
Lesson 67 Starting up a Project and

Initiating a Project 2/3 Ss7 s67.
1 UnC>
Assessing uncertainty is best done by assess certainty and if there

is a problem because of dont knows then we have uncertainty.
2 Kuh>
The Khunevin framework gives 5 labels and some conclusions or

thoughts about appropriate resultant approaches. Its a categorisa-
tion scheme not an assessment tool : Details of it in the next section
and of the Agile-O-meter which is an assessment tool in the section
after that.
going). 172
3 Lvl>
In determining the Right Level for all our needs to cope with
uncertainty requires we ask.
What outcomes are required? Not what solutions or development
process are we going to follow. Recall the 1st half of the Sprint
Planning meeting asks What and the same is true in Release or
Stage and Project Planning meetings. The meeting might now be
called a vision or kick-off workshop but it still focuses on what is
the backlog, what items have highest value?
Recall Backlog items contain an estimate of their value. Note also
talk of a workshop session here might be a series of events across
time.
4 Rway>
What ever the session is called the result in prince template terms is
a Project Product Description-A21, also known as a Vision by p2a.
The vision sets out our end-point in ways we can describe in coarse
grained requirements or Epics.
These Epics outline future operational scenarios. They are expected
to evolve flexibly as detail emerges through the course of the
project.
5>
A way to achieve Define things in the right way is by expressing

Quality criteria versus scales Eg should my watch be waterproof to
a depth of 1m 10m or just splashproof?.
6 SetUp>
the pre-project process {{Starting up a Project}}s most important

two activities are to staff the projects roles, who will manage, who
going). 173
will do development work, this is Activity 1 and 3 , they run in

parallel with defining the end-point and its value in the Business
Case-A2.
The most debate in p2a occurs around the discussion of how to
integrate agile roles and prince roles.
P2As biggest chapter is the organisation one because some people
in the agile world are rather reactionary to the label manager.
P2A insists management adds value. There is a need to tread
diplomatically to overcome sensitivities.
Among other start-up and Initiation Stage activities we establish
the Communications Management Strategy-A4.
In any context the Project Board dictate their comms needs. In
P2A we expect that they will, for example embrace the idea that
their need for a Highlight Report-A11 is satisfied by reading the
BVC display on the walls of the project teams hub of activity.
The BVC or Information Radiator-IR might have to be replicated
electronically if the team works over several sites. A web-cam
permanently trained on the Information Radiator-IR perhaps?.
Note the agile approach was to keep the lo-tech display and not shift
all the data into base-camp, or p6 or Microsoft project or SharePoint.
End.
going). 174
TITLE= Starting up a Project and Initiating a Project 3/3 - Ss7 S68 su 3/3
Lesson 68 Starting up a Project and

Initiating a Project 3/3 - Ss7 S68.

As much as possible as we get going we need to involve everyone
appropriately.
There can be a mountain to climb here. The adoption of P2A is
more about the infusing of agile mindsets into the behaviours and
outlooks of the organisations leadership than about the adding of
a project manager to the development team.
Our aim is for control to be effective rather than the bureaucratic
illusion that is more common than it should be.
Rather than the quotable informal a better description is decision
making delegated to those with time and understanding [[blog
going). 175
creating reports is a control illusion easily delegated, taking action

is control, p2a seeks to delegate that too]]
Communication is via workshops and models even when people are
dispersed.
1 Table 17.1 & 2>
How we merge prince and agile on a per activity basis is set-out

on pages 147 and 148, also in coming sections of the course, in the
revision aids and the coming list which summarise some key points
of getting going, aka sprint zero, discovery su and the Initiation
Stage etc.
The Project is defined in output terms.
Requirements are hi-level and captured to lo-tech media such as a
list on the wall.
Our Quality Management System is implemented by working to-
wards clear definitions of done.
The Organisation structure is defined by mapping prince and agile
roles, & as far as possible co-locating everyone and giving thought
to how to maintain comms when people are geographically dis-
tributed.
Timebox length is decided and the release pattern agreed between
everyone affected such as operations, maintenance, finance etc.
When we havent got much foresight just vision and aspiration then
Greater uncertainty makes for a shorter start-up; pitch in and do
something, see what the fall-out is and adapt.
KuhNevIn, the Agil-O-Meter and Lean start-up are three appropri-
ate sources of inspiration.
Lean-start-up tells us; when the context is one of high uncertainty,
then look widely for inspiration, adopt a fast cycle time for feed-
back. The mantra or quotable quote is fail-fast to learn fast.
going). 176
Key qn in the P2A manual is is agile suitable something dsdm has

always said needs asking.
A better question is which project work-streams need what degree
of agile techniques and which development approaches.
What are typically called agile frameworks are development life-
cycles. Development lifecycles are specific to their product or
industry. For example the development cycle of a restaurant menu
is very different to that of an office block.
Agile working flows from a back-log, but where did the backlog
come from?.
In a P2A world the backlog is created through the pre-project
{{Starting up a Project}} process and Initiation Stage activities.
In pure agile worlds the processes before developing products may
be weak or non-existent. This indicates a routine Business as Usual
setting.
In summary Getting going is a short activity to gain a basic
understanding of the projects purpose & success criteria, visualise
the end and create a suitable workspace with people in roles.
End.
8 Cynefin : (Pronounced
Kuhnevin).
TITLE= Cynefin : 3 (Pronounced Kuhnevin) Section Overview - Ss8 s69

Cynefin
Lesson 69 TITLE= Cynefin Section

Overview : 3 - Ss8 s69
Project get-go (ie the {{Starting up a Project}} & Initiation Stage

timeframe is when we seek to understand the level of certainty
affecting every aspect of the project.
8 Cynefin : (Pronounced Kuhnevin). 178
The Kuhnevin framework categorises how to respond to levels of

uncertainty.
It doesnt however tell us how to assess the degree we are faced
with.
In my experience once you can express your uncertainties your
9/10th of the way to managing them.
P2A us the Agile-O-Meter as a starting point for assessing uncer-
tainty.
Ive used a different but in many ways identical structure for more
than 2 decades. I wont reproduce it here.
[[The I info button top left takes you to the route to find it. Or for
online lms look towards the end of the resource list for our other
courses]]
There arent really any big messages here, Just the introduction of
a categorisation structure.
We might speculate that its a random pet topic of the official
manuals author. We have 3 lessons and a practical exercise with
which to explore KuhNevIn.
End.
Cynefin 1/3 - Ss8 S70
Lesson 70 TITLE= Cynefin 1/3 - Ss8 S70.

Kuhnevin is a model used by Welsh Catholic Ex Marxist 1970s
disruptive university student Dave Snowden to explain when best
practice is or isnt safe.
Since then Dave has become something of an establishment thinker.
Snowden defined the framework whose name is welsh and means
my place of multiple being and which echos the irony that that
which is engrained within us is impossible for us to see.
1 Refs>
There is a lot more to KuhNevIn than the P2A manual covers. There
are also lots of youTube videos of Dave talking at various agile
events. Here are two.
P2As author says use of KuhNevIn isnt mandatory. Its purpose in

the manual is to show that new problems need new solutions.
Einstien said something similar by you cant solve a problem with
the same thinking that created it.
In the Secret Leaders Handbook Eddie Obeng has a relevant and
simple 2x2 matrix.
His four quadrants range from Clear problem with hi skill team to
unclear problem and no relevant skill.
An unclear problem and high skills is the classic Blue-Sky research
set-up while Clear problem and no specific skill absolutely matched
to the problem might be illustrated by the search for a cancer cure
where we are Knowledgeable in relevant topics but have not yet
found the solution.
When cause and effect are well know predictive planning is easy
and appropriate.
Here is where best practice lives. Where its usefulness is greatest
for beginners or highly audited environments like nuclear power
plants. When cause and effect are just suspected then act, observe,
adapt approaches are required. Where cause and effect are un-
known then the only approach is to take action, hope we get lucky,
learn from our mistakes.
Kuhnevin frames the exploration.
End.
The Cynefin Framework 2/3 - Ss8 S71
Lesson 71 TITLE= The Cynefin

Framework 2/3.

Agiles heritage is a reaction to people working in complex or
complicated environments being dictated to use Best Practice.
Best practice requires an environment where cause-and-effect and
cause are well known, predictable and have been analysed for the
responses that are plausible and the best of the possible responses
isolated. Perhaps mathematical analysis or just long experience.
1 HBR>
Snowdens explanation of the danger of best practice in inappropri-

ate contexts was published in a 2007 HBR.
2 DisO>
How to approach delivering change depends on knowing where

we are on the tried & trusted versus experient and discover scale
: something the Agilometer might help with. Until we know which
of kuhnevins quadrant we are in we are in disOrder.
When cause and effect are well known then a scripted approach can
be written and relied up.
3 Order>
The instructions on a ready meal with timings for your 750w

microwave oven are a great example.
These problems are labelled obvious, a better label might be de-
terministic. Arriving at a great result does not require freedom of
choice of actions or any observation and judgement. Just wait for
the popety-ping (PS that is welsh for microwave : I kid you not).
Problems arise when best practices highly constrained scripted
solutions run into novel situations. We fall over the diagrams cliff
into chaos. More in a moment.
4 Complicated>
In complicated contexts there is no such thing as best practice.

There are best results. They occur when an expert makes fine
judgements based on situational observation about the interaction
between factors.
Our experts apply good practice that has been developed situation-
ally over time and experience. They operate within boundaries or
constraints.
Maybe you have bought a fresh chicken to roast, the oven tem-
perature is 185o. You inspect it after 45 minutes to discover the
oven cooks unevenly so you cover half with foil or turn the dish
90o every 20 minutes until cooking is finished and you extend the
overall cooking time by 10 minutes and adjust when you will put
the vegetables on to cook.
5 Cplx>
In a complex environment you have to make it up as you go.

Lets go back to our TV survival competition, you have a freshly
shot rabbit but no experience as a butcher, no oven but a hole in the
ground and the means to make a fire and some knowledge of how
to cook chickens and microwave ready meals. Existing knowledge
is mostly irrelevant but might help in observing and learning .
With some trial and error by the end of the week youll be dead
good at cooking rabbits.
Tonights results might range from rare to burnt. The first challenge
is likely to be how to get the cooked rabbit out of the kettle (if you
are diving in and out of the lessons without taking them in order
this last analogy may be a little lost on you : I recommend following
in order! We are extending an example from section 7)
6 Chaos>
Creating chaos is a good deliberate ploy when breakthrough is

needed.
Phrases such as Necessity is the mother of invention bear wit-
ness. Chaos is bad when applying best practice to an unsuited
environment. Unsuited arises when fundamental cause and effect
relationships do not exist as they are assumed to by the scripting
being imposed or chosen.
When we arrive in the chaotic by falling over the cliff the immediate
need is to stabilise. Situational assessment, crisis management,
search for pattern and repeatability. Many games are based on the
journey Im describing.
As pattern emerges we can manage as for complexity. Complex
Adaptive Systems theory applies. Agents as groups and individuals
acting in networks and individually based on attractors and feed-
back loops.
Imagine, you stumble on a website selling laptops for 600 cents
instead of 600 dollars. You buy three and tweet all your friends who
rush to do the same. I think it was Dell did something like this.
People respond to the what is in it for me : attractors, and they
behave based on interactions in ways that emerge from those
interactions.
Agile rarely mentions its roots.
One is CAS : Complex Adaptive Systems. Good thinking here can
be found by looking for Complex Adaptive Leadership and in my
non P2A offerings.
End.
Cynefin 3/3 - Ss8 S72 3/3
Lesson 72 TITLE= Cynefin 3/3 - Ss8 S72.

The P2A manual suggests the kuhNevIn framework helps know
when work is complex etc.
Tools like the agile-o-meter certainly do.
1simpl>
there are also plenty of resources online.
2complx>
that help to interpret the nature of the framework.

3xit>
As work approaches chaotic so the value of agile techniques in-

creases while the potential risks from agile at least stay the same
and may even decrease.
Also certain is that the use of prescriptive methods in complex and
complicated situations is why the agile movement grew up.
Where agile meets bureaucratic frustration arises and value is
destroyed not enhanced.
End.
Exercise-2: Classify Chestertons Project - Ss8 S73 Case Study

Lesson 73 TITLE= Case Study: Classify

Chestertons Project - Ss8 S73.
Returning to developing real world skills as well as passing the

exam.
Consider the Chestertons scenario.
Apply the KuhNevIn structure, perhaps by asking how to categorise
the aspects of the scenario.
Where would you place Chestertons?.
Why?
As a result how should we apply agile (that is Behaviours, Concepts,
Techniques and Frameworks) to the conduct of the project?.
What actions are you as Project Manager going to take?.
Hit pause to think.
Welcome back?.
So how did you decide where to place the scenario on the scale? In
the next section we will look at the Agil-O-Meter to see how that
will help.
End.
9 The Agilometer
The Agilometer : 2 - Ss9 s75 Agilometer
Lesson 74 TITLE= The Agilometer -

Section Overview: 2 - Ss9 s75 Agilometer.
The Agil-O-Meter is a tool to assess every projects unique elements

based on six scales.
It is presented in the P2A official manual as a maturity scale with
descriptive cameos of what it is like in a level 5 organisation.
You are left to calibrate it to your organisation.
End.
9 The Agilometer 189
The Agilometer : a focus area 1/2 - Ss9 s75
Lesson 75 TITLE= The Agilometer : a

focus area 1/2 - Ss9 s75
Learning Outcome 3, Assessment Criteria 3.1 and 3.2
1 HiL>
The Agil-O-Meter asks questions that characterise the risk arising

from applying agile to a given project.
Every organisation and every project will have to tailor the example
of scales and assessments that is given here. You need to ask the
questions that are right for you and then to map the answers to
responses that suits local needs. A maturing that is likely to require
a few of your projects to run through a few stages.
2 PM through>
The P2A official manual tells us the project manager facilitates the
reappraisal of the score throughout the project.
Retrospectives such as release, stage or even sprint are great times
to reassess.
You should assess based on what has just ended and what is
just about to start. Depending on timing results are recorded in
the Project Brief-A19, the Project Initiation Documentation-A20,
End Stage Report-A9 and End Project Report-A8 to inform any
stakeholder but especially the Project Board.
Assessment seeks the opinions of key stakeholders, either individ-
ually or in workshops.
3 Aom>
As given the Agil-O-Meter uses independent scales to asks; Does

the Senior Leadership Team understand the idea that they decide
what to deliver next based on value, that the question will be asked
repeatedly and that as deliverables are complete they will or can be
transitioned into use?
And that this repeated questioning therefore means that manage-
ment have to be available, also frequent releases means operations
will be disrupted repeatedly although perhaps only in minor ways
as they get used to frequent deliveries. In total people are going to
need some training.
To do the flexibility and iterative bit needs easy communications
and high levels of interaction between teams and between direct,
manage, deliver levels. Decisions evolve as scopes definition be-
comes clearer and settles down to be stable.
If the above is in place then agile will work. If agile frameworks are
used when the above isnt in use will move us towards the kuhnevin
cliff edge.
Assessments might suggest the project should be regarded as in

Exception and the degree of use of agile is too fragile so should
reduce.
To assess the placement on the KuhNevIn landscape you might add
questions , perhaps like.
Can anyone state with clarity what we want? Have they? Does
everyone with political power agree? Do they agree from a position
of complete understanding?.
Can anyone state with clarity how to get it? Does everyone with
an opinion agree? Do they agree from a position of complete
understanding?.
The answer to agree with understanding is normally most likely
to be yes when the development of the target or the solution is
developed collaboratively through visualisations and face-to-face
discussion.
Imp>
Each Agil-O-Meter area of concern is scored against what the

manual calls a slider scored 1-5.
Low scores suggest risk and cause us to ask what can we do to raise
the score and so improve the chances of agile success? while high
scores suggest governance needs less focus or time spent.
5 Fade>
When we have some scores for each axis the manual repeatedly
says dont average.
You might pause to consider why. Welcome back? Of course the
answer is the if one area is a 5 and another a 1 then neither is a 3!
The one needs action, the 5 may create opportunity to capitalise on.
You might aggregate though. A score of 25-30 should be a cause for
more optimism that an aggregate to 6!
End.
The Agilometer 2/2 - Ss9 s76
Lesson 76 TITLE= The Agilometer 2/2 -

Ss9 s76.

A mature organisation is one where training and experience means
at least 6 things:.
1 Flexibility: which we can expand as - People are change friendly,
we know details change and we know how to trade to allow change
and quotably avoid squeezing tail end tasks, scope & details gets
added, needs and wants are in order of priority as we see it today
so some stuff slips below the line of what will get done.
2 Collaboration: explained quotably as Culture is of one-team

in partnership, where everyone pitches in as best they can, trusts
and supports everyone else, recognises that mistakes will occur, are
fixed, are a source of learning and we move on.
3 Comms use visual media where possible, all available information
is shared as widely as possible with as much single-site working as
possible and exploitation of technology where it isnt, comms are
swift, low latency, high bandwidth and informal, useful to know
over need to know.
4 Iterative and incremental working is supported via experimen-
tation, learn and adapt, decomposition of targets into stand-alone
features quotably delivered little and often, always early delivery
of things of value, and quotably summarised as think big start
small and build customer confidence.
5 Environment; team members are full time and the team member-
ship is stable. Members are multi-skilled perhaps with specialisms,
well trained, experienced and always well equipped with the right
tools and unhampered by valueless red-tape.
And 6 Acceptance in mature environments means those involved
know how agile benefits them, they know and agree the agile
philosophy and the values which are made known through training
and experience matched to their involvement however they touch
the project.
How about an exam question?.
End.
Paper_1 Qn_16 - Ss9 s77 EQ
Lesson 77 TITLE= EQA - Paper_1 Qn_16 -

Ss9 s77 .
Hit pause to read?.
Welcome back?
I hope that was easy, Perhaps it seems a little off topic!? It certainly
crosses topic boundaries.
The stem tells us we assessed risk from agile and at the end decided
that we had got it wrong. If you spotted the key words in the
question it will have been easy in the project review.
Here are the rationales and the answer.
Ans>
The only one that relates to a project review is the End Project
Report-A8.
End.
Exercise-7: Apply the Agilometer - Ss9 s78
Lesson 78 TITLE= Exercise-7: Apply the

Agilometer - Ss9 s78.
Our exam scenario is Chestertons Cheeses journey to expand their

business and shift some of their interactions to be web based.
It provides us with a common story for you to develop practitioner
skills as well as practice exam questions.
Return to Chestertons scenario and consider.
What evidence is there that affects the value for each aom\ slider.
Pair the facts in the scenario with the sliders definition & illustra-
tions.
You can use a fact in more than one sliders influences.

Decide the values youll assign, They may vary by work stream.
Decide the actions you could take to promote agility and reduce
execution risk.
A way to structure you analysis is with a matrix.
Place the 6 scales on one axis, the projects factors on the other and
their interaction in the intersections.
Responses and responsible person could also go in the intersections.
If you want clarification, confirmation or feedback then send me
your analysis when youve done it.
End.
10 Business Case Theme
Business case theme Section Overview - 3 - Ss10 s79
Lesson 79 TITLE= Business case theme

Section Overview - 3 - Ss10 s79.
The first of the themes in detail. 6 key massages covered in 3 lessons

and with 2 practitioner exam question to analyse.
The P2A manual takes each theme in turn and reminds us of vanilla
prince, then provides P2As guidance on the topic in hand, then
explains agile concepts and techniques that are useful.
10 Business Case Theme 198
Key Messages here are:.
1) prince is about benefits and agile about value, P2A says they are
a not identical.
Projects should really have a Business Case to explain why the
investment and trouble is worthwhile, the official manual suggests
it is prince that has helped many organisations rise to that level of
maturity.
2) Many agile environments dont itemise a Business Case be-
cause they have a permanent team on the payroll adapting and
perfecting software. For them it is bau and so does not raise a
Business Case need. Neither Scrum nor kanban include the concept
directly although both are constantly driven by maximising value
as expressed for each backlog item.
3) P2A says the Business Case is mandatory, that writing good ones
is hard so a skilled person or team is required (Good is quotably
Coherent, Accurate, Complete and Aligned to strategy),
4) An agile Business Case must be written with understanding that
scope evolves so benefits are perhaps unpredictable at the start, )that
the Business Case is closely linked to the vision which is the agile
name for what prince calls the Project Product Description-A21 and
that when well created a Business Case enables ongoing assessment
of project desirability and viability throughout the project.
Key 5) We must also be mindful of the Benefits Review Plan-
A1 which is guidance to the Senior User(s) on how to measure
benefits and product performance. The Benefits Review Plan-A1 is
the schedule of when to make post-project benefits assessments.
6) An important function of the Business Case is to provide the
information that alerts us to know when to stop a project : a need
of particular relevance in an agile world where we might conclude
at a Release/Sprint/Stage Planning Meeting (spm) that what is left
on the backlog isnt worthwhile maintaining a project to deliver it.
Just three lessons in this section plus 2 exam questions from paper
1 to analyse. If you have not yet started to explore the other course
resources then you should.
If you havent already then drop me a email to tell me what your
rate of progress is. Recall I have a study milestone diary for those
who request it.
End.
Defining value 1/3 - Ss10 S80 Value 1/3
Lesson 80 TITLE= Defining value 1/3 -

Ss10 S80.

Value: you might hit pause for a moment and consider what are
value and benefits.
How are they different? In a second Ill show you the definitions
from the glossary pg 325 and 334 later you can test yourself with
the courses revision aids.
Pause > Welcome back?
1 Glos>
Benefit is what we receive and value is its relative merit versus cost
to acquire.
2 ROI>
Note the acquisition cost may only be partly money, benefit re-
ceived may be wholly non-financial. When discussing company or
governmental non-financial benefits the measurements are in terms
of Social-ROI. There are plenty of online resources around SROI.
3 Text Line125>
Of course value is always relative and subjective, in the eye or

perhaps the heart of the beholder.
Benefits occur on many scales such as happy customers and repeat
business, revenue received or margin earned.
Revenue is a benefits measure while margin is truly a value mea-
sure.
Make sure you see the difference, benefits is what we receive, value
is our surplus over cost. Sometimes a hard to make comparison.
Techniques for estimating value in ways that accommodate rela-
tivism and subjectivity include assigning arbitrary values, perhaps
points on a scale between 1-10 or adjectives such as uninspiring,
of some interest, keen, to earth-shattering. 10 point scales are often

hard to discriminate eg a 7 from 8.
Scales of 4 levels have the advantage of no middle fence value to
sit on, results are either and either strongly or weakly. Also we
need to note that simply estimating doesnt encourage the world to
deliver our estimate[[D4]].
Even when benefits are delivered measuring them and determining
their value may still be hard or even impossible to agree.
The P2A manual quotably suggests that benefit calculation is easiest
and most likely performed versus high and mid-level requirements
rather than detailed requirements. By High and mid-level we are
covering Vision, Epics and User Stories. Stories in the backlog must
have a value to qualify as ready for selection during a sprint
planning meeting.
The manual further says it is unlikely that detailed requirements can
be directly translated to benefit flows from feature releases because
it is hard to put a value on a low level feature.
Estimates are always easiest where historical data is available
but then agile is most indicated in novel, disruptive situations. In
this case estimates are best repeated and confirmed or adjusted
empirically from customer feedback from early releases.
The manual warns us (pg66) to pick measures with care as they
change behaviours and to benchmark at project start to give a
comparison value at project end : Steve Jenners book Managing
Benefits has some good insights .
4 L43>
A central theme of P2A is that agile is concerned with value from

outcomes.
Outcomes are what a vision describes. Outcomes describe business
end-points where as development teams in traditional projects are
normally concerned with outputs. Outputs are the products the

project develops whether implemented and used or not while out-
comes are the results that follow when products are in operational
use.
Im on record for pointing out that outcomes take a lot more than
agile describes but that is a fork in the road that takes us off the
exam path. The I info button top left offers the route to explore
if your in an app, or just about our last video holds details too. If
your in a mooc or LMS the course downloads and links hold details
otherwise just start on the logical model home page or search online
harris asapm tuning the engine.
There is an irony in the prince principle of focus on the products.
The real need is really focus on the value of the benefits.
Agile helps here because the team make-up maintains a focus on
the outcome not the product. Agile says a development teams roles
include not only developers and a coach but crucially the product
owner.
The product owner is the business brain that should be continuously
envisaging the vision. Imagining everyone they represent in the
future so that what is built by the team is fit for purpose in
operations.
I know from personal experience the focus in billion pound oil and
gas projects on exactly this. This is also the dod 5000 concept of ipt
and is greatly aided by the agile behaviour of Being Collaborative
the one-team culture etc.
5 last>
A Business Case in an agile world needs to be mindful of the project

value chain.
Value results from benefits & costs which result from outcomes
from outputs from development effort from a prioritised backlog
whose really useful content probably arrives after the first release
has been made into operations.
prince would often have us move the Business Case on from outline
before we have adequate insight to make a solid job of knowing
what he Business Case-A2 should contain. Recall the Business Case
is an outline in the Project Brief-A19 and if not yet finalised then at
least baselined in the pid.
A P2A projects Business Case probably should be more realistically
incomplete at the start and more realistically volatile as we progress
than is perhaps the normal expectation. Harvard professor Micheal
C Jensen and Oxford Said Professor Bent Flyvbjerg are entertaining
sources of radical opinion on these topics. Bents family name is F-
L-Y-V-B-J-E-R-G
End.
Business Case : general view of agile 2/3 - Ss10 S81

Lesson 81 TITLE= Business Case : general

view of agile 2/3 - Ss10 S81.

Value is an important word in agile communities.
But if you are immersed in business as usual your view of value is
likely to be deliver the maximum every sprint and release. It isnt
likely to be linked to a documented business case. If your routinely
busy you dont stop to justify being employed next month.
Since projects struggle through birth to come into existence they do
need to start with their justification.
A mature agile project environment formulates Business Case,
Vision and product road map together as a strategically aligned
justification of the trouble and expense about to be incurred.
When we can crystallise the vision, product road map and Business
Case the P2A manual tells us Release Planning follows.
Another observation on why agile frameworks make relatively little
mention of an upfront business case is because agile assesses the
individual value of the features in the backlog rather than assesses
the benefits from the whole in total.
The Product owner prioritises the rest of the development teams
effort based on selecting relative value and stops when benefit
versus cost is of insufficient value.
The Business Case is desirable & needed in agile contexts but a bau
team might just assume it exists as implied by the prioritisation of
the Product Backlog.
If agile defines a Business Case then .
It is most likely the activity to define it starts in sprint zero/
Discovery/ Iteration zero/ Visioning and the Business Case evolves
as the Product Backlog is managed. But there is no universal
standard for iteration zero. While some see it as a + others see it

as predictive and non emergent so not in my backyard.
End.
Business Case : guidance 3/3 - Ss10 S82 BC 3/3
Lesson 82 TITLE= Business Case :

guidance 3/3 - Ss10 S82.

The benefits described in the Business Case depend on several
factors that the Business Case will have to explain.
We can or maybe that is should only include what we know in
a Business Case. If we dont know much because we are in a
disruptive context, close to chaos then it wont take long at the start
to say this is a gamble. It will take longer later to describe what

we have discovered although the P2A manual doesnt reflect that.
1>
One factor the Business Case must explore is that delivery of

outputs are subject to scope & quality flex since cost and time
tolerance are set to zero, thus if benefits are derived from delivery
flexing scope also flexes benefits.
Quotably costs and benefits and thus value should be described in
the Business Case using familiar three-point ranges from best to
worst case based and clearly linked to feature count.. By best and
worst the manual means magnitude but timing is also relevant.
Three more quotables .
1) that in a range estimate the Expected-value is often not the mid-
point.
2) the worst case value must still indicate a viable project if we are to
continue and Worst case must be still be viable at acceptable levels
of risk.
3) the business case should touch on the Configuration Manage-
ment Strategy-A6 topics of the Business as Usual disruption that
Frequent Releases can cause.
The Big-Bang delivery approach has advantages as well as draw-
backs, The little and often drip feed of agile also has competing
pros and cons.
2>
Value or net benefit is also affected by timing.

Early delivery = early benefits even before we add interest rate
issues such as DCF and NPV : Ill not explore these project appraisal
methods in this course as it isnt needed for the exam. Coverage is

in our other courses.
Early delivery equals early benefits which quotably may be the
revenues needed to support later releases. A linked point is that
all the benefits after all the invested effort may not be viable.
Many NPD : New Product Development projects depend on early
revenues to build the later product feature set.
3>
With the idea that the Business Case evolves as we discover more
so to must we recognise the effort needed to experiment or spike.
One of P2As hot trio of agile approaches; Lean Start-up is very
focused on the quotable idea of do the minimum to learn the
maximum and as quickly as possible.
This is the Lean Start-up MVP. To many people the mvp is a MMFS-
Minimum Marketable Feature Set or MUST (Minimum Usable
SubseT). In Lean Start-up and thus also in P2A it isnt. It is anything
including mock-ups and diagrams that generates learning about
maximising value.
Note that the P2A official manual says the V of MVP isnt the
projects viability although the two are linked. The project must
be seen as viable to be in a position where we are spending effort
with an mvp to better understand the Business Case.
Hmm Im left thinking the distinction isnt huge or even reliable.
Lets do a couple of exam questions.
End.
Paper_1 Qn_8 - Ss10 S83 Eqn
Lesson 83 TITLE= EqA Paper_1 Qn_8 -

Ss10 S83.
Regular process, pause to read and form opinion on each answer,

then give the answers, pause to read then Ill suggest how to decode
it.
1st Welcome back?.
The stem tells us we are answering from a Continued Business
Justification perspective and the manual says get your MVP out to
establish viability.
Ans>
second welcome back?.

A) Says it helps and thats good : plausible.
B) is waffle. We need to be CBJ aligned not make agilesomehow

nicer.
C) Checks we actually understand P2As view point by stating it
the wrong way around. The MVP isnt the same as project viability
but is linked.
D) If we have doubts about viability then experimenting to deter-
mine the logos suitability is exactly what the CBJ principle will
demand so can hardly be poor support of the principle. Note that
you need to be careful that the answers heart is good but the
assertion that this is poor use could be overlooked when you are
under pressure. Its good use so the wrong answer.
I hope the given rationales make sense. These reveal exactly the
chief examiners thinking so absorb them.
Lets do another eqn.
End.
Paper_1 Qn_31 - Ss10 S84 eqn


Ss10 S84.
As in all the exam questions the context is based on Chestertons

cheese .
If you need to consult the background it is in the course downloads
.
In this course section we have covered the official manuals chapter
9 The Business Case exhaustively. This question should be some-
thing you can answer from that coverage.
Pause and consider each possible answers reason for being right or
wrong before I display and discuss the ces answers.
Ans>
Here are the chief examiners rationales.

Pause and read or ther might be benefit in waiting till ive been
through them with you.
In the stem of the question we are told about preparation of a best-
case scenario. That will be best benefits and least costs for highest
resulting value.
We also have the PM asking for details such as delivery time and
billing address. These are detailed requirements. The manual (pg
65) tells us benefits are easiest to define on high and mid-level
requirements such as capture customer details. The manual does not
give specific guidance on ease of effort estimates versus granularity
but general practice holds that bottom up or detail is a good way
to estimate well. As for forgot my password maybe that is a mid
level requirement .
A) is true after the because, we should do best and worst case bene-
fits but not benefits versus detailed level, gravel type requirements
and we probably should do best and worst effort cost estimates

against detail.
B) sounds plausible if we ignore level of requirement. Indeed best
case is often when all features are delivered but it doesnt link to
the PM asking for effort estimates .
C) is a mostly a quote from the manual but also sort of irrelevant.
The Project Board probably should focus on the expected but the
question asks about the specific technique of estimating effort using
a range so this answer is off-topic.
D) exactly matches the sentiment expressed in the manual IF its
referring to the preparation of the business cases assessment of
benefits and value BUT.
The stem says the suppliers team have been asked to estimate effort
and the business case expresses value. Value is benefit minus cost
so the teams effort is necessary but only a component of the final
figure.
Again Im left saying the exam is less clear cut than I think it should
rightly be but that passmark is 60% not 98% and the time allowed
that seemed initially a leisurely 3m per question isnt so leisurely
when faced with questions like this one.
On balance I dont think it reopens the do I want the manual for
the exam debate as chasing down this sort of question probably
isnt practicable without electronic search facilities.
End.
11 The Risk Theme
TITLE= The risk theme : 1 - Ss11 s85
Lesson 85 TITLE= The risk theme Section

Overview : 1 - Ss11 s85
Business case and risk are two sides of one coin.

Well that is true for half the risk, the risk related to the question
are we doing the right thing?. This is business risk. Agile reduces
right-thing risk by never freezing the backlog and always selecting
the most valuable items from it.
There is also risk of the Will we be above or below baseline
targets? this is development risk and agile resolves some of this by
11 The Risk Theme 213
frequent deliveries meaning we always deliver the most valuable

fastest.
Key Messages from chapter 13 (Illustration on

next slide) are:.
The P2A manual tells us that risk is a smaller topic in agile worlds
than elsewhere because agile behaviours, concepts, techniques, and
frameworks like iteration, experimentation and feedback, and late
decisions about what is in and out of scope decrease threat, and
enhance opportunity naturally.
Agile risk management is a team based activity, everyone is on the
lookout for risk and takes ownership and action.
The most important factors are the 5 P2A behaviours. Note P2A
behaviours; )transparency, )collaboration, )rich comms, )self-or-
ganisation and )exploration combined with ongoing prince risk
management .
P2As risk thinking is aligned to AXELOS other publication MoR .
The biggest message is that agile brings its own set of risks from the
fact that not everyone understands and embraces the mindset.
The risk from agile is what the Agil-O-Meter measures with ques-
tions like Is the customer engaged, likely to stay focussed and
capable of making required decisions? Are the team together or
dispersed over time-zones?, is incremental delivery possible?,
Will products be available early and so accelerate training needs
but also accelerating delivery of benefits : a positive risk.
One slide and one exam question to analyse.
End.
TITLE= Risk 1/1 - Ss11 s86 Risk 1/1
Lesson 86 TITLE= Risk 1/1 - Ss11 s86.

You might like to pause and consider What is the difference in
nature between risk in agile and other contexts?
Its possible we need to cover more for you to reach good conclu-
sions. If you paused then Welcome back
I think the official manuals favourite risk example is agile wants a
high-degree of involvement from those outside the direct develop-
ment team.
The risk then is that it might not happen or involvement might fade
away and either cause will reduce the accuracy of the product and
therefore erode the value delivered .
I have already shared most of the points in this section in previous
discussions.
1>
1 Agile talks less about risk as a topic because addressing threat

(and opportunity) is built into the steps like daily stand-up meet-
ings, short timescales, iterative refinement, re-prioritisation of the
backlog and using LfE through retrospectives.
2 om 107>
2 What prince brings are the steps of Risk Management; Identify,

Assess, Plan, Implement and Communicate (Note pg 108 is one of
those completely blank pages and a great place to make notes).
Within identify and assess will be activity such as spiking (that
is lean start-up jargon for experiments, prototypes and proof of
concept etc) aimed at reducing uncertainty.
3 pg111>
3 The P2A manuals guidance is probably under a page in length

after the picture is discounted.
4 StndUp>
what it tells us is .
Daily stand-ups identify and raise the profile of blockers (or issues)
and potential blockers (the may happens or risks) and the responsive
nature of flexing scope and quality, of adding to the backlog as
we need to, of holding retrospectives, of a team tha includes the
product owner and a methods coach all provide risk responses to
many threats and opportunities. An assigned Risk manager role
isnt needed.
5 appropriate>
P2A formalises risk to an appropriate level. In part that is by asking

that a Risk Register-A25 is maintained but it may be a few columns
of details hand written onto the teams Information Radiator-IR
or a globally accessible specialised analysis and record keeping
system (Like Predict). In part it is the quotable instruction that the
teams risks at the delivery level are the responsible/accountability
of whoever manages the team and the project manager is responsi-
ble/accountable for managing risk at the project level.
The manual also notes risk burn-down charts .
It attributes them to JohnBrothers and Mike Cohn but these have
been around in defence circles for decade as risk retirement curves.
An online search seems impossible because retirement and finan-
cial management hits drown project risk hits.
We will explore them and the note about expected value alongside
other burn-charts in the progress chapter. Risk retirement and
expected value is a dangerous topic to misunderstand!.
Thats the risk topic nailed as far as the manual goes, lets look at an
exam question!.
End.
TITLE= Paper_1 Qn_9 - Ss11 s87

Ss11 s87
Hit Pause to read?.

Welcome back?.
Another easy when you spot what to look for question. The stem
tells us that the Senior User is the approval authority.
Ready for the answers?.
ans>
Welcome back?
D says that the approval authority might not be available. Thus
a potential impediment or a risk. This is in fact a rewording of
a specific example of the Agil-O-Meter that access to business
people is required to make progress, although previously maybe not

couched in quiet the way this example is .
This question should be obvious after you see which words to focus
on and which words are otherwise obscuring or obfuscating a clear
and easy question.
The technique for all questions is read the stem searching for;
)Timeframe like delivery stage or position within procedure like
end of sprint, )for roles involved, )the theme eg Business case, ) the
Information Set required, )decision pending, )the prince principal
and or p2a behaviour. When you have People, Process, Product,
Principle, theme, behaviour, framework and technique cross match
to the answers and reject fragments of truth in the wrong context,
factually wrong options and if it comes down to an unclear choice
go with your first gut instinct.
Overthinking and changing answers is rarely a good strategy.
End.
12 Feedback & Lean
Start-Up
Feedback & Lean Start-Up : 3 - Ss12 s88
12 Lesson 88 TITLE= Feedback & Lean

Start-Up Section Overview: 3 - Ss12 s88.
{{Starting up a Project}} and sprint 0 aka Discovery are where we

start thinking about uncertainty and its potential to impact us.
We need to continue to think about uncertainty throughout the
development work that prince controls through {{Managing Product
Delivery}}.
12 Feedback & Lean Start-Up 220
P2A draws some significant elements of its inspiration about how to

Do then Inspect then adapt from Eric Ries Lean Start-up (there
are quiet a few references in the P2A manual ) but the main one
is 20.4.2 in the {{Managing Product Delivery}} chapter. Probe sense
respond are the KuhNevin lables for essentially the same concept.
The obvious parallels between KuhNevin, Lean Stat-up and projects
are that business and projects are new ventures stepping into the
less known than is the norm with proven business as usual practices.
Ries insights and principles are thus highly relevant.
The best way to absorb the relevant big messages in this topic and
reflected across the manual are via an exercise to define an mvp
Ive two suggestions for you at section end. The key message in this
section is just this .
If your going to fail, then release early and Fail fast so you get the
earliest learning and either adapt to release again (frequent releases)
or stop without great loss.
This is Build/ Measure/ Learn and Fig 14.2 Feedback loops. Ideas of
particularly importance to disrupted environments where previous
rules-of-thumb or best practice no longer applies : think kuhnevin
again.
Apdx E gives Lean Start-ups 5 principles;.
1 Entrepreneurs are everywhere, 2 Entrepreneurship is manage-
ment, 3 Validated learning, 4 Build-measure-learn, 5 use Innovation
accounting.
End.
The Feedback Loop 1/3 - Ss12 S89
Lesson 89 TITLE= The Feedback Loop 1/3

- Ss12 S89.
Pics>
Feedback loops are fundamental to so much in projects, here are

two illustrations one from Ch 14 Change and 1 from Ch 20 {{Man-
aging Product Delivery}} and actually explaining the treatment of
feedback in Lean Start-up.
They show the same idea that is known by 101 names. The ooda-
loop might be one you have hear of. Its one of the best names. I just
like the sound of if. OoodaLooop. ?
xit>
The p2a manual focusses strongly on the agile concept of feedback

by emphasising Lean Startup.
Lean Start-Up insists that the feedback loop with the customer
should be as short as possible in order to iterate and learn fast and
use iterative and incremental delivery.
So many other observers have described identical ways such as
walter shewarts pdca loop made famous by w Edwards demming,
by the DMAIC loop of six sigma and the others on the slide.
End.
Lean Start-up 2/3 - Ss12 s90

Lesson 90 TITLE= Lean Start-up 2/3 - Ss12

S90.

Ries quotes many examples in his book. For example
he was tech director for a silicon valley start-up and wrote 40k
lines of software over 6 months to release a product that nobody
wanted.
He laments that his big loss was five months of learning that he
could have got in the first week by talking to his target audience.
There are a few core concepts 1st is grasp every opportunity to learn
but 2nd and related to that is how many pivots do we have time for?.
A pivot is a change of direction.
It isnt so much fail fast as learn fast, to do that create the MVP. The
MVP shortens the feedback loop.
BML>
The loop is do something, gather data, analyse it and so validate

your learnings. There is a lot behind Build Measure Learn and its
roots are IT but it isnt limited to IT.
T>
There is more to Lean Start-up than we will cover but there are
loads of resources around.
xit>
The real message is shorten the feedback loop, but if your going to
fail then sooner rather than later is presumed to be better. We have
already defined the Lean Start-up view of an MVP; its anything
you can learn from and ranges from actual product to any sketch
or mock-up.
& lets add loads on youTube - just search!.
End.
Lean Start-up 3/3 - Ss12 S91
Lesson 91 TITLE= Lean Start-up 3/3 - Ss12

S91

What Ries has done includes taking Goldratts ideas about Theory
of Constraints .
Ries has reposition TOC in the context of the Idea factory and
re-applied throughput accounting to the concept of learning to be
adaptive.
An adaptation is a called a Pivot in Lean Start-up,
A pivot is a major change, in prince terms an exception that
affects the Project Product Description-A21, Business Case-A2 and
Benefits Review Plan-A1 or in P2A terms the vision and or epics
but still the business case & benefits plans.
We have covered all the other points.
End.
Exercise-16: Identify the MVP - Ss12 S92 Back@Work

Lesson 92 TITLE= Back@WorkSkill

Builder CaseStudy: Identify the MVP -
Ss12 S92.
Here we are in the midst of a training course. Ill need to consider

is it viabile? What is my MVP.
To carry out the exercise consider;.
what are the questions that I need answers to?.
How could I validate learning about each question?.
Here is a question to start you off; is the audio sufficiently loud that
someone listening during a journey too/ from work can hear easily
over their ambient background noise?.
You might like to consider Chestertons web-site as an alternative?.
1. Step one : what questions?.

2. Step two : How to construct a test?.
3. Step three : How to gather data?.
4. Step 4 : How to analyses and synthesis meaning?.
5. Step 5 : What resultant action ?
Either recycle or implement into the evolving/ finalised(?) product

offering.
ShortBreak
Lesson 93 TITLE= ShortBreak .
End.
13 Requirements (focus
area) user stories &
prioritisation
TITLE= Requirements (focus area) user stories & prioritisation : 6 - Ss13 s94
13 Lesson 94 TITLE= Requirements

(focus area) user stories & prioritisation
- Section Overview : 6 - Ss13 s94.
Big topic, 6 lessons, two exercises and some practitioner question

analysis.
The hardest thing in projects might just be correctly understanding

what the customer wants.
Or it might just be knowing what you want when you are the
customer.
So P2A gives us a focus area in Chapter reminds us people are not
well served by written or spoken language when trying to convey
needs and wants. Indeed is the right word requirement or feature
or user story or function or acceptance criteria. We will call them
all requirements for now. They must, eventually all be expressed as
acceptance criteria if something delivered is to be confirmed against
its verification tests to show the project has met its obligations .
P2A normalises the vocabulary in table 25.1 which Ill show in this
section.
Big messages in here are.
Requirements are hard to know, to express, to convey and to
confirm.
Start big and decompose to an appropriate level of granularity (this
is also EXACTLY what the PMBoK says).
Always prioritize requirements, accept that priority is ephemeral
and changes.
A great mechanism for arriving at the definition of done is the
Requirements hierarchy; Vision, Epic, User story, Requirement.
Well also examine the Definition of Done and of ready.
To be selected for work in a sprint a requirement must be Ready,
Ready is a defined state.
End.
Requirements and User Stories 1/6 - Ss13 S95
Lesson 95 TITLE= Requirements and

User Stories 1/6 - Ss13 S95.

In {{Starting up a Project}} the vision is defined. Vision is a picture
of an operational future. Often a word picture. It shows people a
future state of bau, so is better if its a video or rich picture than a
block of text.
Tab25.1>
As the project progresses the vision is decomposed to epics and epics

decompose to user stories and user stories are refined to individual
requirements and their acceptance criteria that satisfy the need to
be able to say clearly what does done look like? Every agile term
has an equivalent prince element in the A21 or A17.
The agile way is to accept the requirements will evolve in breadth

and depth and priority : change is the one constant. The backlog is
only ever the current list of wants and needs.
tab 25.2>
The levels correlate to timeframes. Maybe pause to read the table?

A requirement may at first be understood as an epic (We are losing
market share , we need to rebrand the business).
Levels of decomposition influence the Margin for Error or precision
of estimates. Boulders might have a MoE inj the range 50-100%,
Rocks may allow precision matching a range around the expected
value of -20% to +40% and gravel should improve our ability
further. Perhaps -10% to +20%. Exactly the same concept is PMBoKs
estimate precisions like ROM 7.2 pg 201 in the 5th Ed.
wbs>
becomes a collection of stories : product group in prince speak.

Maybe rebranding stories include one about House style expressed
as say fonts/logo/ colours/ staff uniform/ phone greeting/ social me-
dia presence and finishes as details deep within Product Description-
A17s Quality test as Arial 18 pt pantone or RGB code 0, 0, 255.
Timeframes are not necessarily pre-project, initiation delivery.
Thats illustrative of the effect of effort over time is to clarify
what we want. Clearly these are relevant timeframes but the
requirements evolution may run across stages. Will start at times
like when we pivot.
Imagine we are Chestertons. Recal a workstream is to move premises.
We discover the access to the new site is so limited that we now have
a new epic Build access road with a technical user stories like gain
planning permission.
End.
User Stories-1 2/6 - Ss13 S96 2/6
Lesson 96 TITLE= User Stories-1 2/6 -

Ss13 S96 2/6.

All of us are powerfully influenced by what we see. A user story is
a word picture. It describes someone in a context taking an action
to achieve a result.
As a P2A trainer I want regular coffee breaks so students find it
easy to stay focussed.
Of course this leaves open the debate does coffee break mean
we can only drink coffee? How much coffee in what time frame?
which bean should be used, should a choice be provided, how
should the bean be roasted and what parameters apply to the
grinding. How is the coffee brewed? Is milk forbidden or allowed

with quantity decided at the time of serving? Maybe coffee break
was a euphemism for toilet, text messages and eMail check with
what ever beverages are to hand?.
As 25.6.1.7 tells us when a user story is ready it is sufficiently well
defined by the product owner then we all know its value. When it
is sufficiently defined by the team then we know its development
effort. That also means it is decomposed to a granularity that
matches the teams position with this problem on the KuhNevin
model.
The work of previous sprints brought the story to ready.
The work of this sprint will decompose the story to the level
required to define done, then the sprint will make it done and
demonstrate the fact at the review meeting.
The story is three Cs a Card : borrowed from XP where one side is
the story and the back are the AC, a Conversation where the story
and third C or back of the card Confirmation are agreed & recorded.
And now we have positioned Invest next to CCC we will cover it
on the next slide.
End.
User Stories-2 3/6 - Ss13 S97
Lesson 97 TITLE= User Stories-2 3/6 -

Ss13 S97.

The lower illustration is an example of how not to do it.
Stories express a role, in a future operational context performing
a value laden activity for a purpose at a level that informs others
what to deliver. A degree of specific ness is needed.
As a P2A trainer I explain the US topic so students can use the
technique themselves in the future, earn pay-rises and makes their
customers happy.
1 TechUS>
All user stories depend on infrastructure. As a pilot I want to land

my airplane requires someone had a story As airport facilities
manager I want a runway Technical stories use words that often

end in ility like reliability, speed and capacity. They are often
added to the backlog by the team recognising a need on the ultimate
end users behalf.
INVEST.
Writing individual requirements is hard. I could spend all day

exploring the ins and outs with you. Writing a collection is even
harder; we need to consider factors like not mutually exclusive etc.
A neat mnemonic for the key points is INVEST : Starting with I
Each is Independent of the others or stand alone, so each occupies
its own trade-space like the depth to which a watch is waterproff 1,
10 or 1000m which enables us to prioritise quality which required
collaborative working across the mixed C/S team and means we can
fix and flex to achieve the first of the 5 targets: Be on Time.
Each is V valuable, that should perhaps be first so we need a new
word that starts in V! Each must be estimate-able which really says
something about its granularity so S for small and finally each must
be demonstratable for acceptance and ultimately contract purposes
so we end with T for Testable.
25617>
Together Estimated, Testable and Valued make up the definition of

Ready.
p327>
Epics we have discussed.

Now is a good time to try writing and sharing one or two.
End.
Requirements Prioritisation 4/6 - Ss13 S98
Lesson 98 TITLE= Requirements

Prioritisation 4/6 - Ss13 S98.

This section covers the manuals view on prioritising requirements.
Some solid insight, eg Moscow mixed, I think with not so solid
arguments. Ill give it too you as the manual dictates.
First solid and Quotably prioritizing is at the heart of that key
Target: Deliver on time through flexing scope and quality.
To be effective in flexing scope and quality we need to know what
is vital and what is sacrificable and what if any delivery sequence
is required.
Importance does not always indicate to us the priority order. It

is not always the case that all the musts are first. What is most
important may need enabling products and features created first. A
fast car needs good breaks. Breaks need a firm chassis on which to
be mounted. The breaks may be most important but the chassis is
sequenced ahead of them.
table>
When we consider priority in an agile development then we need

to match what will, might and wont get done to the deadline we
face and the uncertainty of the work before it.
Here is where the mnemonic MoSCoW helps. It stands for Must of,
Should of, Could of, and Wont for now, not by the deadline. The
deadline being considered may be project, stage, release or sprint.
MoSCoW is quotably applied at higher levels of requirement and
over longer timescales. It accommodates groupings of deliverables
that recognise interdependency and sequencing and is the default
as it matches the need to fit work to finite timeboxes.
Moscow is the default approach, the approach for use with boulder
sized product and feature requirements. Used more at project stage
and release levels. Ordering is more gravel level consideration of
technical activity.
Quotably ordering is primarily at the lower, technical activity level.
Ordering is a simple technique. We might score all backlog features
on a 1 to five scale and then rank all the ones against each other etc.
Quotably ordering is most useful when requirements are broadly
independent and not naturally grouped.
Prioritizing is something done continuously, not just at the start.
End.
MoSCoW and ordering 5/6 - Ss13 S99
Lesson 99 TITLE= MoSCoW and ordering

5/6 - Ss13 S99.

Users often define all their needs as musts.
That is fine. Simply ask of the musts what is top and bottom of the
list. Somwhere we will be able to draw a line between Cant live
without Here is a slightly silly example I hope it makes a point.
Your customer wants a airplane. Clearly it must be able to take-off
and it must be able to land safely. Landing safely is highest on my
list. It is also only needed if the take-off feature is met. Id also like
a toilet and a kitchen, they are only ever optional but they rise in
my list as aircraft range extends. If I want a long range aircraft then
the width of the Altalntic might establish my Must-Have for fuel
capacity.
Equally if my pen has no ink it is useless but it doesnt need a cap.

If it has a cap then the cap must have a an anti choking hole.
An example in the manual is also worth citing. Electric windows
are a must in a luxury car but only a could in a budget car. The
projects vision affects the MoSCoW assesment.
Also worth exploring here is the manuals example of a washing
machines programmes. The manual says but you only use a
couple, so this shows you dont need everything and that has some
truth.
But the two programmes you use and that I use are likely to mean
that between us we use 3. If we include the whole customer base
every programme is in someones 1 or 2. Thus 2 programmes might
be all the end customer needs but which two? The supplier may
need to offer 16 in order to appeal to a wide buying community.
If my two, your two and everyone elses two overlap on the 30o
easycare short wash, spin, & dry then that may be a must while the
Silk and Rayon programme maybe the lowest must.
Must Busting.
wbs>
When everything is a must in the customers eyes then return to

the decomposition.
Decomposing another level or two often shows lower level compo-
nents, features and sub-products have varying degrees of need on
the MoSCoW spectrum. The decomposition may be as a node of
the breakdown structure or may just be in the composition of the
Product Description-A17 or in the text and notes to the User story.
End.
Using prioritisation 6/6 - Ss13 S100
Lesson 100 TITLE= Using prioritisation

6/6 - Ss13 S100.
Requirements & Quality.
Customers arrive at projects with expectations. Their CQE or

Customer Quality Expectation. In prince we translate cqe to Quality
criteria in agile the phrase is Acceptance Criteria Criteria cover two
expressions of acceptance, F() and NFR()
Boy>
The function of a car is to take you and the spouse and kids from
A to B, or maybe it is to impress your mates. Non-functional
requirements for the pictured car might be 0-40 in 2.2 seconds.

Typical in-town street racer needs.
Requirements like speed or fuel efficiency or leather seats are called
non-functional requirements.
The non functional are crucial. Consider how long would it take
to acquire a car like this? Maybe hit pause and thing how could I
acquire, for each potential solution what is the cost and timescale?
come back when youve an answer.
Welcome back?.
Lspd>
Now consider how approach, cost, time and tasks would change if
the non-functional characteristics matched this car.
Prioritisation.
deadlines>
We must have MoSCoWd our requirements FR() & NFR() before

we can be Ready in a sprint or release backlog sense so that we
know what is sacrificable versus dedlines.
P2A defines two levels of change. Baseline which is serious, like
a Pivot. This level of change needs Change Authority approval for
example from the Project Board.
Baseline change might change a Product Description-A17, Recall
prince baselines them at stage start or delegation of a work-package.
The other level is Detailed change.
This level is within the tolerances owned and operated by the
product owner. Recall the product owner is a development team
member. Detailed change is handled dynamically, day to day by the
project team as they execute a sprint. Moscow thus helps us know
what to drop from a sprint if time becomes tight. Moscow and sprint
deadlines establish a trade-space. For example the customer adds a
requirement that does not change the Project Product Description-
A21 expression of Vision then the final project product will now be
more accurate and the need is handled within the team.
The teams key test is if we now outlook exceeding any tolerances
by the dynamic change, a change within a time-box then the
customer sme drives the answering of two questions.
1) what priority is the new feature/ need/ want and if high then
2) what lower priority items or features in this trade-space can be
sacrificed to accommodated the dynamic change? The idea of scope
creep is banished to be scope swapped and traded.
Empowered teams that Self organise their roles, tasks even goals
are created by clear tolerances and effective Manage By Exception,
perhaps better expressed as management within tolerances.
End.
Back@Work Case Segment Exercise-3: Requirements - Ss13 S101

Lesson 101 TITLE= Back@Work Case

Segment: Requirements - Ss13 S101
(Ex-3).
Time for some back@work skill building.

Try writing some User stories.
In class I suggest write several in pairs, debate and share you best
with the class and then class critique.
Here Ill suggest that if your in a MOOC with community then post
them for comment otherwise eMail me p2a@logicalmodel.net and
Ill respond.
End.
Back@Work Case Segment Exercise-4: MoSCow The Requirements List -

Ss13 S102
Lesson 102 TITLE= Back@Work Case

Segment Exercise-4: MoSCow The
Requirements List - Ss13 S102.
Chestertons cheeses have a requirements list.

For convienience here it is but if your device has a small screen then
the list is in the course support materials.
Ignoring the estimates column sort the requirements into Must/
Should/ Could/ Wont at the project level and if you wish the Stage
level.
In class.
Obviously we debate the musts.
As you are listening to this your not in a face-to-face class so post
to the forum, comment on other peoples posts or send me your
analyses with a rationale and Ill comment.
That email again is p2a@logicalmodel.net.
End.
EQnP aper_1 Qn_41 - Ss13 S103
Lesson 103 TITLE= EQn Paper_1 Qn_41 -

Ss13 S103.
A suitable exam question might be this one from paper 1, Qn 41.

You have two 50 qn papers in the materials. The online app allows
you to search and every slides notes tell you its Learning Outcome
number and Assessment criteria. Looking at a slides assessment
criteria and an exam questions syllabus topic allow you to target
questions at the topics you are studying.
The familiar pattern would be if you hit pause, consider the question
and its possible answers, Ill share the chief examiners rationale
that you should study too then Ill brief you on the interpretation .
First Welcome back?.
>
Second welcome back?.
The Question Stem.
The stem tells us Move the production lines, I wonder how many,
Where too, what power requirements do they have?.
A) Suggests this might be the vision of the project but the scenario
told us long ago they are seeking to consolidate and rationales
several years of growth with stuff like logos and new market
penetration so moving production lines is unlikely to be the vision.
B) Suggests this is a rock or gravel but we dont know the production
lines placement or power needs etc so it is not detailed enough for
gravel.
C) Suggests the same as B a user_story and a Product Description-
A17 are pretty much similar.
D) says as a component of the composition section of the Project
Product Description-A21 which accords with being a significant
work-stream in the Gantt chart.
Yeah I know this is agile so I cant call a timescaled visual of a
schedule a Gantt chart -
Too much xenaphobic NIHS. Embrace Alistair Cockburns oath of
non-allegiance.
End.
14 The Change theme
TITLE= Change theme : 3 - Ss14 s104
14 Lesson 104 TITLE= Change theme -

Section Overview : 3 - Ss14 s104.
We have probably done all of section14s 3 lessons in the context of

other topics but repetition is important for recall we will finish this
section with analysis of an exam question.
The agile approach to accurate products is to get a rough idea and
use feedback loops to refine it. That isnt change that falls under
baseline control; its dynamic change.
14 The Change theme 248
Thus 4 Big messages here might start with :

1) Change is at two levels; baseline and dynamic.
And perhaps 2nd) Requirements decompose from Boulders to Rocks
and Gravel or they decompose from Vision to Epic, to Story,
to Acceptance criteria or they decompose from Project Product
Description-A21, to Product Description-A17 and then quality cri-
teria and testing method.
3) Agile is change friendly, embracing change is not a concept or
behaviour, or technique or focus areas but it is one of the 5 key
targets (from table 6.2) and one of the 4 more important values in
the agile manifestos list reproduced in Fig 2.1 and one of the 12
principles of the agile manifesto.
4) Feedback loops go by many names such as Plan Do Review. We
already saw Lean Start-ups Build Measure Learn : different words,
same sentiment.
XX ToDo: 14.4 isnt B/M/L its PDCA so is the lsu\ stuff correct.
End.
TITLE= Change : Agiles general view of Change 1/3
Lesson 105 TITLE= Change : Agiles

general view of Change 1/3 - Ss14 s195

Simple message; Change happens, deal with it.
The agile approach says the backlog is open to new items at all times
and each Release planning and Sprint planning meeting selects
the highest priority items to work on. As we work through the
workpackages of a stage or sprint we trade requirements so as to
respond to emergent needs and deliver by the deadline.
Additions to, and or changes to- the scope and quality arise as
unknowns become discovered or surface.
Embracing newly emerged changes leads to a more accurate prod-
uct. This sort of change is to be valued as positive.
If the change challenges the Business Case justification, for example

we are pivoting due to a significant omission or miss understanding
then quotably this may not be so positive : that isnt the Lean Start-
up view where all learning is good and its maybe not PRINCE2s
view where early project termination is a victory in saving further
use of resources.
Talk of change in agile is normally about product change.
Talk of change in prince2 is change to any aspect of the project that
is subject to baselines and tolerances.
Staffing levels for example. Agile would just adjust the current
sprints results, reorganise the team and continue : unless a must
was challenged in which case we are in exception even for an agile
project and a sprint might be stopped : a big deal.
Another quoteable example of prince items subject to change con-
trol are plans, perhaps we mean schedules and budgets and Product
Description-A17. Mainly because these affect the Continuing Busi-
ness Justification.
End.
TITLE= Change : guidance 2/3 - Ss14 s106
Lesson 106 TITLE= Change : guidance 2/3

- Ss14 s106.

Within the concept of change; Agile embraces it, prince controls
it. So a quotable phrase for the synergy in P2A is harnessing the
benefits of positive change while providing governance.
Actually both a and p2 enable it by tolerances. Tolerances vary in
width even within the same project.
In princes case Control is attempted by means of a change authority
and Configuration Management. CM and version control are topics
software and hardware engineering are familiar with.
In Configuration Management we create baseline product defini-
tions, sometimes called bill of materials, then populate them with
finished components that are integrated to a whole, demonstrated

and then shipped.
Thats simplistic and incomplete but essentially correct.
When the definition of a baseline changes we need to apply controls
to remain, in control! Control does not mean bureaucratic proce-
dures that kill energy and cause unneeded costs but like any control
peoples reaction to change control is often less than welcoming.
The reasons are way-off piste here but if your interested go search
online for Hertzberg and hygiene factors for some insight.
Remaining on topic recall that the timing of any MVP, MMFS-
Minimum Marketable Feature Set or MUST-Minimum Usable Sub-
seT affects benefits so potentially the trigger for an exception.
14.5 summaries get the product definition level and the matched
degree of controls right at the start.
we set-up contro in the Initiation Stage. In the IS and in pre-
project we capture vision and requirements. Premature detail and
premature solution later leads to lots of baseline change to bring a
wrong baseline to useful state. On the opposite side omitting what
we do know and can rely on hampers the best subsequent decision
making and progress.
Sometimes detailed specification is vital. To the micron perhaps
if your building the hubble space telescope. Sometimes a broader
range is acceptable. If you visit McDs the beef in your burger is
weighed to the gram but the ice in your coke isnt
End.
XX ToDo: ??
TITLE= Change : Agile Change Guidance 3/3 - Ss14 s107
Lesson 107 TITLE= Agile Change

Guidance 3/3 - Ss14 s107

Getting the degree of tolerance right aids easy and elegant project
delivery. It is hard to embrace change when requirements are
infelxibly polarised black and white.
Of particular and related note is the skill to specify requirements as
a range of attribute values rather than yes/no specification where
possible.
Imagine I wish to buy a car. Im binary about whether I want left or
right hand drive and two, three or four (or more) wheels. For fuel
capacity and miles per gallon (is that kilometres per lite). Maybe
Im happy with a range between 400 and 800 km between fill-ups.
1432>
The Change theme includes Configuration Management (some

authorities say it the other way around but prince puts cm in
change). It is only possible to manage change with respect to a
reference point or baseline. prince covers it all via the Configuration
Management Strategy-A6 and Configuration Item Record-A5s.
As change occurs so its ripple effects have consequences when not
well tracked. In fact the greater the agility the greater the need
for automated support of CM. The s/w world is awash with CM,
testing, bug tracking and related tools. Search online for Jira and
configuration management but expect to be overwhelmed (or you
didnt need me to tell you what to look for, maybe your into
subversion and tortoise!?)
We should also note that Risk Management asks what could happen
and how should we prepare to capitalise and compensate.
An appropraite Risk Management Strategy-A24 means we consider
change and plan for it.
Across the four strategies and the controls that the {{Initiating
a Project}} process first 5 activities deal with it is important to
establish delegated levels of authority so that baseline and dynamic
change are handled at the best level. Self-organising, empowered
teams actually need the time, authority and expression of tolerance
to make decisions and clarity of how to escalate outside tolerances.
P2A suggests we track changes by type such as suppliers off-specs
and customers Requests For Change.
Before leaving chapter 14 Ill remind you that Agile embraces
feedback loops.
We looked in the context of Lean Start-up t fig 14.4 or Plan
Do Review. Exploration leads to customer feedback that drives
decisions about what to deliver and when. Lean Start-up is all about
accelerating this loop. Forums where the feedback is created include

Sprint Review (srw) and Release Reviews.
Time for an exam question.
End.
TITLE= Eqn Paper_1 Qn_10 - Ss14 s108
Lesson 108 TITLE= Eqn Paper_1 Qn_10 -

Ss14 s108.
Standard procedures apply and Ive highlighted stage 4 in case the
gantts text is too small to read and Ive highlighted the branding
work-stream.
You pause and analyse, then Ill interpret then you can ponder the
official rational.
Pause? Welcome back?.
All>
The stem refers to a branding decision made after the related sprints
are over and refering to All marketing materials.
A) is ok if this doesnt affect a baseline so the question is are we
being told of a baseline change, EG when closed workpackages need
to be reopened?.
B) Sounds ok expect it says do all the work so we better decide if
we are authorised to or not. IE is is at baseline change or not.
C) Ahh hmmm ahhhh, The questions asks how should Brand-U-
Like manage this. They are a dev team so they are not going to
raise an exception to the Project Board but the project management
might when they hear what the status is.
D) describes a response taken by a technical team when they have
a change outside tolerance. B-U-L are a technical team and they are
faced with a change affecting workpackages that are already closed.
OK so D is reasonable and trumps B) which would have been ok if
we were in tolerance.
Got it?.
If so move on, if not re-read the prince manual! We are supposed
not to be examined on basic 2 but this question is arguable.
End.
15 Organization theme &
servant leadership
TITLE= Organization theme & servant leadership - 9 - Ss15 s109
Lesson 109 TITLE= Organization theme &

servant leadership Section Overview - 9
- Ss15 s109.
The biggest chapter in the book!
Manual>
And also supported by an appendix.

15 Organization theme & servant leadership 258
It is also arguably the chapter with the least crisp, clear messages.
Its length and muddiness arises because the word management is
anathema to some in agile circles and P2A tries to be sympathetic.
To be clumsy would be damaging where there is an existing and
sensitive agile community.
We might partly diagnose the clash as prince is about project
management while agile is about products & leadership[[blog]]
Key Messages here are:.
prince says we need management. Fervent agile practitioners (can

be heard to say) all management is evil and redundant and damag-
ing. The P2A manual notes that role titles must be considered care-
fully and terms like reports to, assigned to may create negative
impressions.
What we need by the time we have finished this chapter is to know
how to blend the pastor of fun, the Project Board, the other prince
role holders and the agile roles holders into an integrated happy
self-sufficient and appreciative community.
Agile is right that happy focussed skilled equipped people can
deliver astonishing productivity. We need to foster that.
Roles we have from agile are the coach who in scrum would
be called the scrum master. They are the expert in the process
rather than the product, they facilitate the teams journey through
planning meetings, daily stand-ups, reviews and retrospectives. We
also have the product owner who is the empowered full-time sole
point of contact for the business. And we have the developers who
are the skilled and flexible workforce that create results in a spirit
of mutual support and dependency.
When we blend and weave prince with agile then it is the organiza-
tion theme that is where we consider how to get the right interface.
All the angst comes down to how do we add a manager to an agile

team. P2A gives three options.
1st ) we dont, the pm interacts with the team members as needs
suggest.
2nd ) we suggest a point of contact, a new development team role
of liaison. Maybe that person also holds the coach/ scrum master
role but they could be any team member.
3rd ) we actually appoint and install a team manager and the
development team are kewl with that.
A factor that affects the considerations is how big is the project
headcount? If the project is pm plus 6 that is different from PM
plus 26 or 126.
Role Names.
Agile has a role called product owner but P2A renames them the
Customer subject matter expert (C_SME) and supplements them
with Customer representatives, Supplier subject matter experts (S_-
SME) and Supplier representatives.
Guiding Thought.
Agile creates self-organising team. The team members determines

how to carry out eh work that achieves the sprint goals as each is
agreed with the product owner. Prince provides overall or top level
direction that determines what the intended journeys end looks
like.
Agile works well when there is a single product owner and single
team that thus does not need coordination out-with the team. Agile
is self-sufficient. The challenge arises when cross team coordination
is needed.
Cross-team technical cooperation is handled by a scrum of scrums.

In P2A we add a Project Manager : which is not trying to fulfil the
same role.
Axelos has given us 9 lessons against which to examine the details.
End.
TITLE= Organisation : general view of agile 1/9 - Ss15 s110
Lesson 110 TITLE= Organisation :

general view of agile 1/9 - Ss15 s110.

An agile value and a key source of agiles strength is that the team
debate and decide together.
The degree to which the organization structure and roles are

formalised varies by framework. EG kanban omits roles entirely.
Scrum is minimalist and presumes a single team P2A adapts scrum.
1 Xit YrExp>
Involvement and empowerment generates motivation. Quotably

the Dev Team feel collectively responsible.
A time view of the procedure that creates motivation is that the start
of the cycle is really the retrospective at the end of the last chunk,
sprint, release, stage of work. Then fired with new insights for im-
provement we do planning, then execution with daily meetings that
formalise the cycle of Experience, Reflect, Hypothesise, Adapt. A
daily discipline helps the forward momentum towards the groups
targets at the best rate the collective talent pool can generate.
2Rs>
This collaborative context is created by three roles; the first is the

developers who have skills in depth and breadth. Between them
they cover everything needed to acquire or create the target of
the sprint goal. [[Agile assumes create over acquire]] They dont
bring expertise in the running of teams or in the defining of what
is wanted.
Running Teams.
The role in scrum that knows the running teams process is the
scrum master. The product owner is quote the pivotal role and key
stakeholder that knows what the desired end point is.
The SM facilitates the scrum process, for example by coaching the
team to keep the daily stand-up under 15m, helping the product
owner to refine the backlog so items are ready at the next Sprint
Planning Meeting (spm) and Facilitating the workshops that are the
spm or Sprint Review (srw) etc.
The Sm also takes the teams blockers to the rest of the organisation
for action to remove them.
The SM role is not one of accountable for the team. P2A sees that
as a gap that must be filled.
Deciding Direction of Travel.
The role that decides direction or what is wanted is the product

owner. Scrums simplicity is the po is a mandatory, full-time role
and the the teams Single Point of Contact with the business.
Re>
One issue with the simple arises when project size means there is
more than one team. A 2nd issue is when the po cannot replicate
the skills of a requirements analyst. There is a lot written on the
web about the po role being given to people without the skills to
carry it out.
Simple>
With a single product single vision a single team is great. P2A

assumes that projects need a broader mix of opinion. P2A also
notes some organisations have a Super PO or Product Manager who
coordinates multiple product owners. In p2a this might be a Senior
User.
P2A New Roles.
prince Team>
P2A gives us 5 new role names for the presumed broader need. They
are 1) C_SME who is analogus to the po. The role is set-out in apdx
B. Ill just position it now but we will explore the detail shortly.
The CSME is in the team and an empowered representative of all
stakeholders on the Senior User(s) behalf.
Role 2) are C_Reps who arrive and depart as needed and bring
deeper specialism to bear.
The next two are the S_SME and S_Rep and the last role is Delivery
team Quality Assurance : sic : This last role is what is classically
called Quality Control. I guess as a role parallel to what prince calls
Project Assurance the naming got confused PA is about process
as is the widely used definition. Delivery team Quality Assurance
is about product so pa is correctly named its process related but
Delivery team Quality Assurance isnt as its product related So it
would classically have been Delivery team quality control.
Other Roles.
A single team, single product team with a process coach and a

direction setter doesnt need other roles. As cross skilled technicians
the ability to gather requirements and build results sits in the team.
The software heritage seeks to remove the Chinese whispers issue
of one person gathers requirements another does design a third does
the code a fourth tests and a fifth accepts.
It leads to not having a specific business analyst role. A valuable
aim and a harder concept to replicate in some disciplines.
Take eg oil terminal design, manufacture installation and com-
missioning. The industrys structure in terms of organisational
specialisms and hence capability boundaries are set in places that

everyone in the industry understands. It is industry heritage and
thus culture. A globally shared implicitly understood context that
is reflected in contract types and role descriptions.
Finally; to repeat, summarise or emphasis : a single team environ-
ment has less need of a manager, more need of leader and coach.
End.
TITLE= Organisation : guidance 2/9 - Ss15 s111

guidance 2/9 - Ss15 s111

P2as organisational guidance says If we have a single team with

a single understood product and market place then simple is suffi-
cient. Otherwise we must add the prince project management team
to the agile delivery team roles.
The target is of course that roles cover communication needs and
timely decision making.
Pause to study the graphic or consult the revision aids.
End.
TITLE= Organisation : adjustments 3/9 - Ss15 s112

adjustments 3/9 - Ss15 s112
Learning outcome 5, Assessment criteria 5.5

P2As start point is the agile worlds norm of no management is

not best for projects.
Agile may not need a project manager because the assertion is
that if the vision is broken down to products and their features
at a low enough level of detail then the development and delivery
work becomes a bau sausage factory continuously producing and
frequently delivering. Fine for single product, single team.
Some management helps even here but is particularly useful as size
increases. P2A takes on bigger initiatives than pure agile might.
There is more to be coordinated if there is more than a single
team. P2A says the PM is a mandatory role. We do of course
want a balance neither too lax but also we are avoiding centralised
command and control in favour of federated, local decisions.
1 bp2>
We still want and need to provide the team with coaching and
leadership.
Robert Greenleafs term Servant Leader is often quoted. To describe
Greenleafs concept we might talk about inverting the organisation
structure; the role of managers is to enable their reports to create
great results by clearing problems and providing resources : more
in a few lessons time.
2 bp4 pm>
P2A mandates someone represents the project, thats the PM, and
that someone represents the team.
Each of these two roles takes accountability for delivery at their
level. Agile normally considers responsibility to be collectively the
teams. Teams at Tuckmans Performing level typically have a
collective responsibility ethos.
As we outgrow single product, single team within the project then

the increasing likelihood is the role we need with accountability for
the teams delivery is that of Team Manager. Introducing a team
manager role where there is existing agile teams needs to be done
with due care.
Mostly that will mean discussion of the pros and cons with the team
to ensure 5 areas are covered.
First ) planning which might mostly refer to work and resource
scheduling and would normally fall to the team collectively with
product owners input on priority 2) Monitoring status as might
normally be done by a scrum master. The next 2 might also be done
by the SM too, 3rd) External liaison, 4th) Ensuring risk and issues
are managed. Lastly 5th) Product acceptance is achieved and the
product handed over : typically the product owners job in agile
teams. The manual summarises it in table 10.2 which well look at
on the next slide.
End.
TITLE= Organisation 4/9 - Ss15 s113
Lesson 113 TITLE= Organisation 4/9 -

Ss15 s113
Tab10-2>
The manual gives three options for linking delivery team to the
prince organization structure so that the 5 items of table 10.2 are
covered. None is preferred over the others and the Project Board
may dictate or they could encourage debate.
The most agile option is to entirely adopt the agile default.
This is ok if everyone is clear who owns what part of table 10-2 and
the pm liaises with everyone,
2nd is) a less agile approach where we leave agile alone but add a
PoC role for the project management to liaise with.
The POC may be the scrum master or coach, they may be the
product owner or they may be a nominated team member and the .
3rd) is considered least agile. Create a team manager role with
responsibility for the team and accountable for the teams outputs.
5 Xit10.2>
The relationship between pm and team is ratified or defined team

by team in the Work Package-A26.
It is suggested in general for the project as a whole in the Project
Initiation Documentation-A20
The P2A manual quotably summarises it as .
the pm shouldnt meddle or interfere with the team but does need
to be aware of their inner workings.
End.
TITLE= Organisation: The Delivery Tean 5/9 - Ss15 s114

Lesson 114 TITLE= Organisation The

Delivery Tean 5/9 - Ss15 s114.

The result of integrating agile roles and the prince organisation
should be:
) someone has the role to lead the team : the team may select this
person situationally and it does not imply seniority [[pg85]] ) one
or more roles represents the customer including maintaining the
backlog, ) at least one role-holder assures the products, ) someone
coaches and ) everyone contributes in one or more ways to product
creation.
Team size should be in the famous 5-9 people range that derives
from Millers 1959 paper on the magic number 7 2 (appendix H
says not less than 3). The manual suggests teams are split if they
grow too big.
generalising specialist.
P2a notes team memebers may be Generalising specialists. These

are sometimes quotably referred to as T shaped people.
Meaning they have a wide but shallow knowledge surrounding a
deep but narrow expertise. That profile means they can help each
other to a degree : able to speak the same language.
Successful Agile teams like need to be truly multi-skilled if they are
to succeed in KuhNevins 2nd, 3rd and 4th quadrants. Of course
this leads first) to the debate about whether all-star teams are best
versus well isnt a balance actually better and second) it is not just
agile teams that benefit from adaptable and capable people.
What we perhaps should say is that the kuhnevin framework shows
us that best-practice is for situations where cause and effect are
well-know so procedure works thus skill is less critical but in

complex environments skill is indispensible.
The P2A manual also tells us all stakeholders must know their roles
duties. The Communications Management Strategy-A4 as approved
by the Project Board should explain the experience, education
communication etc needed.
The official manual says a RACI chart in any of many formats might
be a good way to record and share the necessary relationship of
people and roles, behaviours, duties etc.
End.
TITLE= Organisation: Project Structures 6/9 - Ss15 s115

Lesson 115 TITLE= Organisation: Project

Structures 6/9 - Ss15 s115.

Earlier we saw the organisation structure that might suit a single
team and multi-team, multi work-stream project.
The diagrams include some roles which are fully defined in Ap-
pendix B
C_SME>
The C_SME is the P2A role that more or less matches the product
owner but with consideration of several factors. If we have multiple
workstream there will be multiple C_Smes. Also in a P2A context
they take coordinating guidance from the Senior User(s) on the
Project Board. Some agile shops have a super user or product
manager.
C_SME is a full time role that represents everyone with an interest
but most importantly is an informed empowered decision maker.
c_Rep>
CSMEs may be accompanied by part-time experts in narrower

fields. These are C_Reps.
Sup>
A mirror image are the S_smes and S_Reps. The S_SMEs are the full
time technical expertise assigned to the development team while the
S_Rep is a consultative role partially assigned to the team or Senior
Supplier(s).
A team may include more than one C & S SME and reps. Between
them all they can explore options and perform assurance activities
from start to finish.
QA>
Apdx B doesnt define the Coach for us. None of the 22 refences
to coach in the P2A manual do more than say the role holder may
hold other roles and the Project manager, Team manager and Scrum
master should coach the teams as part of their daily duties. The
manual tells us those who hold QA roles provide a pragmatic and
independent check that the products meet Quality criteria and are
Fit For Purpose from customer and supplier perspectives. The QA
role advises how products will be checked. IE in anticipation of
development work.
p2>
Recall P2A is the whole of prince, 100%, so all the traditional

prince roles still apply. Let me know if you need a refresher. Recall
instructor support is accessed through p2a@logicalmodel.net
, the online course forum or via www.logicalmodel.net/prince2exams
[[Preview].
The variations to the standards prince roles for

P2A are:.
The Project Board will know agile means and the organisations
degree of familiarity with agile. They understand blending prince
with agile, through for example accepting prioritised delivery and
setting tolerances for Manage By Exception.
The exec may be called sponsor; they will understand value and
benefit. The Senior User(s) may be super product owners, they
will be able to prioritize for value. The Senior Supplier(s) is as
per vanilla prince, the project manager isnt the scrum master but
is fully agile able, can deploy it correctly for example through
relevant team training, the team manager is the development teams

main interface to project manager, the change authority will also
understand how change works with agile teams. Project Assurance
will assure that the project manager is being agile and that Manage
By Exception is working, Project Support may be the agile coaches
to project management team and or development teams. Finally
Corporate Management or Programme Management will be agile
aware and have a cross organizational view of agiles adoption and
or exploitation.
The whole project community will be collaborative with manage-
ment facilitating others to be successful. The term often used is
servant leadership.
End.
TITLE= Servant Leadership 7/9 - Ss15 s116

Lesson 116 TITLE= Servant Leadership

7/9 - Ss15 s116.
Learning Outcome 5, Assessment Criteria 5.5 /5.6

Greenleafs servant leadership has two key words in the title and a
lot of insight in his book.
Servant leaders exhibit a long list of qualities like empathy and
listening. They provide their people and teams with time to de-
velop. They develop people individually and the team as a unit
through various techniques such as coaching, consensus building
and encouraging team members to be open to asking for, offering
and receiving help from each other.
A lot of Greenleafs insight gets simplified out of the more pas-
sionate opinions that are argued. Greenleaf believed like Lao Tzu
that great leaders facilitate success for their people by supporting
the team to be successful. The P2A manual says prince is in some
degree of conflict with Servant Leaderships ideas and we might
say that some agile exponents are extreme proponents of all things
servant leader.
Servant leaders look after their people. A happier team is more
productive. The ideas are sometimes described as facilitative or
collaborative leadership. Note SL and agile both focus on a team
that decides together and delivers together. Facilitation helps peo-
ple be collaborative and reinforces empowerment. P2A is neutral
about the Project Managers style but still notes that leading and
managing are necessary so the Project Manager isnt 100% servant.
Equals.
Several other points of note 1) all the prince roles from the Project
Board out can adopt collaborative leadership as a style, 2) Auto-
cratic, dictatorial, authoritarian styles are perhaps less motivational
than leadership that values people with an equal voice. 3) while

leadership and management overlap leadership is about vision and
the right thing, management is about work and following standards.
End.
TITLE= incorporating a Wider Customer View 8/9 - Ss15 s117
Lesson 117 TITLE= incorporating a Wider

Customer View 8/9 - Ss15 s117

Scrums visibility to the non-agile community is very wide so
Scrum is often seen as defining what agile is. scrum seeks to be
basic and simple .
Since Scrum defines the role of product owner.
Hi-Si>
the product owner role is often seen in simple terms. But in fact
it is a very demanding role. It needs the skills to communicate
complexity with clarity and the skills to resolve political opinions
about business strategy and choice. PeeTwo A tells us the role holder
needs appropriate training and support. We might just say not alf.
An excellent tool but outside the scope of this course is dialogue
mapping for wicked problems search online for Horst Rittels, IBIS
and jeff with a J conklin.
Hi po>
Returning to p2a then - Through scrums simple lens the devel-

opment team has a single all knowing authoritative, accountable
decision maker who has the last word on the product. That doesnt
quiet translate for p2a when the product owner is a customer subject
matter expert (C_SME) with a reporting line to a product manager
or Senior User(s).
Basic agile must have someone in the dev teams who has Care for
the backlog to ensure epics become stories with clarity, value esti-
mates and effort estimates, also priority, visibility and transparency
to all. Transparency includes shared, correct understanding.
As organisational maturity with projects grows the product owner
might also bring product and business vision, a product roadmap,
the Business Case justification and will have broad and deep busi-
ness acumen eg as an influencer, a clear communicator, skilled in
expressing requirements etc. 10.5.2.1 gives a laundry list including
always available. Ill support the list through the revision aids but.
That long list of factors includes predictable adjectives; traits like
consultative and others that are learned skills like requirements
gathering. The P2A manual notes its tough to find suitable role
holders and training is likely to be needed.
HiWide>
A Project is likely to need a number of them to be representative

of the wider range of views prevalent. Quotable p2a says a single
product owner may not be the best way
HiSU>
thus P2A gives us the customer subject matter expert (C_SME)s to

be the voice of the customers detail and the Senior User(s) to be
ultimately accountable at the higher and wider level and the exec
to be responsible for the Business Case.
HiReq>
Ultimately requirements capture may be best supported by engag-

ing business analysts and requirements engineers.
[[Preview]]
End.
XX ToDo: CapCase?.
P2A widens some agile viewpoints - A single PO is simple, SPoC
but
SU ultimate accountability.
C-SMEs & C-Reps.
End.
TITLE= Working Agreements 9/9 - Ss15 s118
Lesson 118 TITLE= Working Agreements

9/9 - Ss15 s118

Many times now Ive repeated the P2A manuals frequent refer-
ences to multi-skilled, empowered, self-organising teams.
Their creation takes time, effort and some agreed ground-rule that
cover, for example how to resolve conflicts, values such as always
be honest, the start time of the daily stand-up etc.
The P2A manual calls these elements of agreement team guidelines
and working agreements. You might already known the idea as
a team charter. The purpose is to encourage good behaviours.
Guidelines are typically posted by the team on their Information
Radiator-IR and updated when new circumstances are discovered.
Teams might literally sign-up to their charter and many avoid the
word rules as too prescriptive.
Key is they are built by the team as needed for the teams internal
smooth running. Aspects the P2A manual illustrates are being ok
to say opps I got that wrong, no dumb questions, show respect,
listen, ask dont tell, escalate swiftly etc. working agreements are
typically referenced by Work Package-A26
We started this section with a reference to the pastor of fun.
Section 10.5.3.4 tells us the team could have a social secretary :
you dont have to give them the pastor of fun title but someone
to organise team social events. Work hard and play hard, work
together play together.
Among many other factors a team is a group who want to work
together because they recognise the value of other peoples contri-
butions. Time spent in non-work contexts helps too.
Big section : lets try to apply it to the case study in support of
post exam real-world use and also see an exam qn in support of
achieving recognition for your study effort. Back@Work(tm) Case
Study first.
End.
TITLE= Case Study 5: Assign Roles - Ss15 s119
Lesson 119 TITLE= Case Study-5: Assign

Roles - Ss15 s119.
Chestertons Cheese need people assigned to roles.
1 x>
Here is the background information [[PreView]] and.
2 People>
thumbnail sketches of the stakeholders.

Considering the characteristics of the roles that enable projects in
P2A to succeed.
Read the word pictures of peoples skills and outlooks. Who should
be assigned to what role and why?.
In Physical and Virtual classes we can discus.

In off-line situations eMail me or use the course platforms facilities
and Ill respond.
End.
XX ToDo: RM Ans?.
Exec-MrsC, SU-MrC, Jake-C_SMR, Kerry-Mimi-Sanjay-C_Reps.
MrsC anti internet- doesnt matter, Mimi brings important i/p, can
be 2 C-SME.
End.
TITLE=EQn Paper_1 Qn_29 - Ss 15 s120

Lesson 120 TITLE=EQn Paper_1 Qn_29 - Ss

15 s120.
Application is where the real value lies to your business. Personal
value may well be linked to the resume or CV.
CV Resume building depends on the exam. If you subscribed to the
course then we have given you access to 100 mock questions written
by the chief examiner and accompanied by answer rationales.
Recall all the discussion in the first dozen lessons about the exams
quirks and challenges : tough questions that require we understand
how to read the stem to extract the answer?.
Try this one.
Standard practice applies. If you are 100 lessons into our journey
now then you probably already paused, read, decided and have
come back to see the answer.
>
so here they are, Pause again to absorb them.

Welcome back?.
The stem tells us the team are using an agile approach (even if you
dont know what Kanban is because youve followed the course
materials in order and I have not covered it yet you should recognise
it from table 2.1. The questions purpose is to know if we can
apply what we have absorbed about the organization theme to the
Chestertons project but for maybe the first time in the questions
Ive used in the course materials we actually have to read the
scenario to place the Golden Clog Project.
Golden Clog is a synonym for the whole scenario. Chestertons are
competing in a Dutch Cheese Awards : I cant understand why
when the worlds most respected are Cheese awards are held by
the Guild of Fine Food in the UK!.
Ans A) says stick to p2. I suspect an answer designed to confuse

with an approach of just stick to what agile says. With chapter 10
being so big we only need old p2 isnt likely.
B) suggests the Scrum Master become TM. A potentially excellent
idea if the team used scrum but they dont the stem tells us clearly
they use Kanban. If this is obvious now Ive said it and was entirely
opaque before I said it I hope the learning point stays with you
through 50 real questions.
C) Showing an org chart on an Information Radiator-IR seems a
good idea but the kanban board is focussed on managing the work-
flow : Its fair enough if your response to this question stumbles on
this point : we have yet to see kanban .
D) is a pretty wishy-washy sort of well obviously they need
to work closely together but then that is exactly what a good
organisation strategy promotes so lets go for it as the answer.
[[Preview]]
End.
End.
16 MP {{Managing Product
Delivery}}
TITLE= MP : 3 - Ss16 s122 MP
16 Lesson 122 TITLE= MP Section

Overview: 3 - Ss16 s122.
Here is the {{Managing Product Delivery}} process. Not as long as

the organization theme chapter and it would be trivial if it didnt
also cover Kanban and Lean-startup .
Before we start in with MP you might like to congratulate yourself
on having passed the half-way point in that last subsection.
16 MP {{Managing Product Delivery}} 287
Returning to MP.
Ill speculate that the rational for the mp chapter including two out
of the three agile approachs in P2As focus is that mps internal
conduct can be quiet independent of how the rest of prince operates
so long as we maintain the boundary through Work Package-A26,
Configuration Management and reporting.
Whether the work is time-boxed or flow based suits prince either-
way. The flow-based approach is Kanban and its cousin Lean-Start-
up. The other focus technique is time-boxing; it is covered in the
introduction to the processes chapter (Chapter 16)
It doesnt matter but if you are attempting to learn by using the
manual structure as a guide to topic linkage then just accept its a
minor irregularity or inconsistency.
Key Messages here split into two themes.
1) As a process MP is the container or wrapper for the agile

development teams activity with all the interface needs that the
organization chapter has been establishing roles to look after and
second) really deserving of a separate chapter Here is lean stuff.
Lean or perhaps more generally Taiichi Ohnos T.P.S. or Toyota
Production System. TPS is a huge topic and a huge inspiration to
agile communities.
TPS has inspired many working practices in many organisations.
Kanban Method to be more descriptive is a specific extract of TPS
described by David J Anderson while Lean Start-up that we explore
when thinking about Business Cases is Jeff Riess book.
If we are going to be complete I should mention Womaks HBR
article that brought TPS to the mainstream attention of US
industry and you might want to follow-up with his subsequent
books. An online search for womack and lean throws up half a
million of hits.
XX ToDo: book refs.

End.
TITLE= Managing Product Delivery 1/3 - Ss16 s 123
Lesson 123 TITLE= Managing Product

Delivery 1/3 - Ss16 s 123

Project development teams create new capabilities Ie create prod-
ucts. Agile frameworks manage the development process. This is
a key point. Team eauals do products, framework = process of
controlling team.
Agile development teams turn requirement into shippable product
(which doesnt have to be physical items but could for example be
a brand image or a service offering like insurance). Agiles roots is

creating software, Toyotas is building cars.
Agile development typically implies the team creates but we should
also include acquisition in our mindset. You can buy and integrate
instead of design and build. At the extreme you can buy a whole
solution. Generally called a Turnkey project. We are straying off
the exam path here but there are a raft of contract types to support
the many variations. Our PMI aligned courses cover that territory
for exams and our non exam course cover it for the real world.
The P2A manual is clear that agiles focus on product delivery is
distinct from its management of the delivery process. For example
scrum tells us Hold a meeting and select ready items to be worked
on and thus produce results and then later hold a meeting and
show the result is ready to ship. It is prespcriptive of process but
devoid of product development or engineering details and steps.
Car production might say weld part A to part B and website
development guides could say establish a navigation scheme or a
default combination of fonts, colours and layouts.
Scrum is manage development not do development. P2 is a control
framework into which scrum can slot like bullets into a gun or a
jigsaw piece into the surrounding puzzle.
End.

Delivery 2/3 - Ss16 s 124.
Learning outcome 5, Assessment Criteria 5.5 /5.6

The central theme or to use the word pivot in a different sense to its
use so far, the pivot point of P2A is the interface that prince supports
with the Work Package-A26.
When the project manager in activity [ Authorize a Work Package [
15.4.1 ] and the team manager in activity [ Accept a Work Package
[ 16.4.1 ] negotiate a piece of work we can and perhaps should use
agile behaviours and practices.
That is the work is understood in workshops, there is transparency.
When the development team then weld steel or write style sheets,
headlines and body text they can/ should also be using the be-
haviours techniques etc. In both cases the scope of this week or
months work can be drawn from a backlog. The stages or releases

work is drawn from a project backlog, The Work Package-A26s
contents is drawn from the stages backlog and is the development
teams current sprint or release backlog.
Manual>
Quotable the CS/MP interface is the glue that joins project manage-
ment to product delivery or prince procedural management guid-
ance to agile product delivery guidance or to mix our metaphors
the boundary is a mutual handshake.
Ive included in this courses section on CS the detail slide from
our standard p2 course that exhaustively itemises the elements of
the interface. You should study the interface artefacts and events to
ensure familiarity.
On a different note; Quotably the P2A manual suggest the MP
process is less about {{Managing Product Delivery}} than about
managing the interface to those who really are Managing Product
Delivery. The Work Package-A26 is really managed by the team
manager within the team.
End.

Delivery 3/3 - Ss16 s 125.

Key points about the Work Package-A26 are it is.
1 HiC>
1) defined by discussion : perhaps in sprint and release planning

meetings creating stage/team plans,
Hi-R>
2) it establishes the approach to reporting , updating of logs and

registers and all needs for stakeholder communications. Maybe the
Checkpoint Report-A3 is verbal, maybe the project manager reads
the teams Information Radiator-IR, maybe the Quality Register-

A23 and Risk Register-A25 are columns and tick boxes on the
Information Radiator-IR. Visual and visible reporting in realtime is
preferred, it is probably lo-tech like a white-board and handwritten
with drywipe pens and variously coloured sticky-notes. All stake-
holders needs are included.
3) tolerances are known and there is understanding of how team
plans evolve with the prioritization and flexing .
4) any helpful agile guidance is included 5) Product Description-A17
whether prince templates or user stories state what and avoid how
so the team can design and flex as much as possible : to paraphrase
solution free or what not how .
6) uncertainty is discussed, ownership of responses and monitor-
ing understood eg prototyping may becomes the agreed approach
where solution uncertainty is high 7) Timebox size is agreed .
8) The disposition of results is agreed, for example will they be
released straight to operations or to a staging area? This idea clearly
has product specific or industry specific connotations. New drug
straight to the public? I dont think so.
Hi Wide>
We must also be mindful to ensure that all relevant stakeholders

affected like particularly ops, training and maintenance are in the
loop at all stages.
And finally 9) is the last but perhaps most important topic of
product development; it is the determination of who does what
testing and demonstration versus the definition of done and when.
End.
Work Packages 4/4
Lesson 126 TITLE= Work Packages 4/4

End.
Paper_1 Qn_13

Ss16 s 127.
Standard procedure.
Pause?
Welcome back?.
The stem tells us that we have dependencies between work packages
and work-streams outwith the individual teams responsibilities.
The question is about a development teams response when accept-
ing a Work Package-A26. The exam isnt supposed to ask vanilla
prince questions butr Id argue this is. Also not we answer from
Brand-U-Likes perspective.
>
Here is the chief examiners opinion on his own question. Ill take
you through my thoughts next,.
Pause?
Welcome back?.
A) suggests this is a risk. It probably is but it isnt Brand-U-Likes
duty to manage cross stream. They may report against it as the
source but risk between work streams is the project managers
worry.
B) is definitely what a Work Package-A26 should include and we
can verify on the top of page 276
C) Product purpose should be part of each Product Description-A17
and it could be their duty to create these as we get into the details
but does that respond to the dependency even within their work
stream? Probably not.
D) They do need to prioritise work based on their backlog but does
that say enough about cross work stream dependency when the
Interfaces entry is specifically appropriate?.
Hmm so B is definitely correct but steps outside the exams specifi-
cation, C is improbably and D has a dubious argument to its favour.
Ans>
Here is the chief examiners official explaination, I leave you to

ponder if Cs rational is a sentence.
End.
End.
17 Frequent Releases
(focus area)
TITLE= Frequent Releases (focus area) : 2 - Ss17 s129 FreqRel
17 Lesson 129 TITLE= Frequent

Releases (focus area) Section Overview:
2 - Ss17 s129.
Agile environments deliver as soon as something can generate

feedback.
Being agile means frequent releases, hence scrums mantra of in-
spect and adapt or KuhNevIns of probe sense respond, hence Lean
17 Frequent Releases (focus area) 299
Start-ups Build Measure Learn and hence P2A includes frequent

releases in its list of focus areas.
Focus areas are places where P2As author says there is not suffi-
cient guidance with-in prince because of its focus on project control
rather than product development.
1 ManPg>
This sections big messages will be:.

Early delivery starts to release value and means when we run out
of time or money or focus a legacy of value delivered is left.
To release frequently the total scope needs to be capable of being
delivered in pieces; for example you cant deliver an airplane with
only one wing or a car without the brakes but you can deliver a
meal like tapas, many small plates sent from the kitchen as soon as
each is ready.
Quotably Kanban and Lean start-up relentlessly pursue frequent
release to an ultimate goal of continual releases.
Lets go explore axeloss two lessons.
End.
TITLE= Frequent Releases : focus area 1/2 - Ss17 s130
Lesson 130 TITLE= Frequent Releases :

focus area 1/2 - Ss17 s130
Outcome 3, Assessment Criteria 3.2

Some views of agility correspond to how frequently releases are
conducted.
To be able to release frequently takes good coordination across
people in different roles and good Configuration Management. You
need both in any environment.
1 Advt>
Agile requires that each time-box concludes with value created for
a long list of advantages; early benefits, early feedback so better
chance of realising what the customer wants asap\ and so better
opportunity for creating the right product , visible results creates
confidence, delivery fuels good feelings and engagement in the team

which in turn helps delivery. Also the trauma of change is lessened
by many small releases rather than one big one.
The P2A manual suggests the release strategy needs careful con-
sideration of the tradeoffs but doesnt set-out the competing argu-
ments.
Key here is that waterfall projects deliver everything at the end
when it is too late to cost effectively rectify many errors and funds
are likely to have been exhausted. Of course even in a waterfall
world releases can be phased.
It is important to distinguish another quotable idea.
2 pbp>
Agile isnt phase based it is releasable feature oriented, based on

decomposing the final solution into coherent chunks. (yes that
sounds like bs to me too but it is quotable.
What is true is that princes Product Based Planning is an ideal
technique to complement to agiles release planning.
The target destination of the release is another topic to discuss, lets
see the next slide.
TITLE= Frequent releases 2/2 - Ss17 s131
Lesson 131 TITLE= Frequent releases 2/2

- Ss17 s131
1 IntoOps>
With a very s/w oriented viewpoint the P2A manual says its best
when the release is straight into operations.
The reasoning is here is where real feedback and benefits arise.
But
Its hard to put an aircraft engine into operation when the wings are
still being built or put another way the integration order determines
what is possible for the release strategies.
Planning of what to create in what order and when is crucial. This
brings us back to technical stories because in part they determine

release planning.
2 Opinions>
Releases planning must have a business input to link to value

and a technical input to link to some constraints of reality. There
may also be capacity and contract inputs, testing and regulatory
concerns that limit release flexibility. For example new feature
linked business disruption at financial year end or predictable times
of peak customer activity are normally unwelcome .
3 Plan Lvls >
What features are to be releases when should be clear in the

project plan or product checklist and on shorter more detailed time
horizons the stage plans.
The Project Board set stage boundaries by their involvement in
Initiation Stage workshop and the DP activity [ Authorize the
project [ 13.4.2 ].
The Senior User(s) and Customer subject matter expert (C_SME)
plus Supplier subject matter experts (S_SME) feed into release,
stage, team and timebox plans.
The release plans are tightly linked to benefits flows.
It is important the Project Board and all stakeholders participate
in planning. It is common in npd that early stages generate the
cashflow to support later stages. Lean Start-up particulary considers
the release strategy to quotable be the cadence of the business.
Balance the business ability to absorb change in operations with
the benefits released by new capability.
Next up: Case study and exam study.
What is the journey of a new drug?.
End.
TITLE= Exercise-12: Release Plan - Ss17 s 132 Exercise
Lesson 132 TITLE= Exercise-12: Release

Plan - Ss17 s 132 Exercise.
When you signed up for the course we supplied you with the exam
preparation materials so you know what Chestertons 60 days of
effort look like from the backlog.
The question now is what makes a sensible release plan and why,
consider business benefits and technical dependency?.
If you mail me your solutions Ill respond.
Next an Exam question.
End.
TITLE= Paper_1 Qn_44 - Ss17 s133 Eqn
Lesson 133 TITLE= Paper_1 Qn_44 - Ss17

s133 Eqn.
Standard procedure,
Pause?
Welcome back?.
The stem tells us we have achieved something .
Lean Start-up says any time we do something it is so that we learn
as much as possible as soon as possible.
The chief examiners rational is here.
Ans>
Pause.
Welcome back?.
Frequent releases support benefits flow.
A) is nice and visible progress is good so this is not really wrong .
B) a duplicate at the level of significance of A) we couldnt really
pick between them .
C) Thats feedback and important to rectify. Definitely Learning
from Experience but is it frequent releases? Well yes because that
is why Lean Start-up does them.
D) Well have to check the scenario but even so it will be temporary
while the old sites are consolidated so isnt The MOST useful.
Have you noticed how many questions give multiple possibly
correct answers and want the BEST or MOST (etc). Maybe you
should be ramping up to do the whole of paper 1 under time
pressure? At this point we do still have a significant number of
topics to go but less than we have already done.
[[ See exam three : its the chief examiners question from paper 1
that cover what we have covered but not what we have not covered.
I suggest keeping paper two till you have covered everything ]]
End.
18 Scrum theory & practice
& artefacts and events
TITLE= Scrum theory & practice & artefacts and events - 0of6 - Ss18 s s135
Lesson 135 TITLE= Scrum theory &

practice & artefacts and events Section
Overview - 6 - Ss18 s s135
We covered this chapters mechanics long ago in section 5 Where

Agile Plugs In.
At the start of project and stage we select backlog items and refresh
the release plan.
18 Scrum theory & practice & artefacts and events 309
At the CS/MP boundary that authorises and accepts a Work Package-

A26 we select backlog items into a backlog, work on then, hold daily
stand-ups which in the scrum method are called daily scrums and
at the end of each sprint, release, stage, and the whole project we
hold reviews of products and retrospectives of process.
The P2A manual includes Schwaber and Sutherlands most recently
updated Definitive guide to scrum. It was last updated in Jukly
2013. Ill point out that it is the most recent definitive guide for
two reasons; 1) because its publication was in part a reaction to
their own plethora of guides released over a decade whose contents
show scrum terminology and practice is evolving. 2) Because even
this versions front cover says it is being sustained which means its
evolution is still in progress.
A precedence that says you should also be bold and adopt, adapt
and adjust. There are plenty of people using ideas that are built
on agile foundations like scrum. For example scrumban combines
scrum and kanban .
Downloading a copy of the Definitive Guide in your native lan-
guage is simple. It is on scrumguides.org in lots of languages .
End.
TITLE= Scrum : what is it? 1/6 - Ss18 s s136
Lesson 136 TITLE= Scrum : what is it? 1/6

- Ss18 s s136.

Scrum is the implementation of an observation published a thou-
sand times in different vocabulary.
KuhNevIn says when cause and effect are not clearly linked in an
understood fashion then the best approach is act, reflect, consider,
act.
Lean Start-up said Build Measure Learn, Shewart and Demming
said plan do check act, six sigma says define process and process
measures, analyse process behaviour, improve the process based on
observation, control or consolidate the useful changes into constant
future practice. Six sigmas procedure is called DMAIC.
Kollb>
David Kolb said Experience and Record, Reflect and Hypothesis,

Integrate to existing ideas and experiment. Really now we are back
to experience so either consolidate or adjust.
Many people call it LfE; Learning from Experience. We have a
complete and short course on LfE. Have a look at the instructor
led course preview on http://learn.logicalmodel.net. Or check out
the details in about 90 lessons time or if your platform supports it
click the link in the support materials.
Scrum is a framework specifically designed to implement the learn-
ing cycle in a team developing products. Scrum sets out procedure
: the definitive guide is sub-titled Rules of the Game, that deliver
results through events and artefacts. It assigns people duties within
those procedures. Its a process management structure not a product
development one but the processes it manages are product develop-
ment processes.
The principle to repeat once again is:.
when you are trying to do something that is challenging, something
that requires a team to act in a coordinated way then you face
multiple challenges, social challenges of getting on together and
challenges of understanding what is wanted and what is easy or
hard to do and you have to make it up as you go or you would be in
kuhnevins simple quadrant. The Scrum process directly addresses
these challenges by saying do something then inspect it and adapt
and do it with concern for the people and their feelings and well-
being. If your leading these people to a goal you have set them then
your job is to make them successful : as leader youre the servant of
the team .
End.
TITLE= Scrum theory 2/6 - Ss18 s137
Lesson 137 TITLE= Scrum theory 2/6 -

Ss18 s137

To adequately address the topic axelos have given us here - scrums
theory - We could have a deep philosophical discussion about
Nonaka & Taguchis book.
that was probably schwaber & Sutherlands original inspiration as
it likens Japanese industry to rugby and western business to relay
races, also Socrates, Descart, Nietzsche and other philosophers,
about Rationalism, Empiricism and even Epistemological solipsism
which is the basis of the film the Matrixs idea that maybe the world
is just a figment of my imagination. Wikipedias philosophy page
is as good a start point as any and takes you to the Empiricism and
the Rationalism page.
Note the definitive guide is explicit that scrum is not a product

development process or technique and that it is lightweight, simple
and difficult to master.
End.
TITLE= The Scrum team 3/6 - Ss18 s138
Lesson 138 TITLE= The Scrum team 3/6 -

Ss18 s138

Every one of these points has already come up in our coverage so
far but there are thoughts to add. For example we have said nothing
about burn charts and team velocity yet or labour spent remedying
quality failures : what software calls bug fixing.
The team is fluid, selecting the work to be done and who should do
it moment by moment. Collocated and in constant dialogue about
how to proceed. Scrum based product developments depend on the
people with best expertise and social skills because together they
have to make-it-up as they go.
>
There are a minimum of three clear roles; Someone to manage the

backlog, someone to make the cycles of the process revolve and the
multi-skilled experts who create the results the backlog describes .
End.
TITLE= Scrum events 4/6 - Ss18 s139

Lesson 139 TITLE= Scrum events 4/6 -

Ss18 s139.

The process creates a routine and it is the scrum masters job to run
that effectively.
The Definitive guide tells us the sequence of steps and even pre-
scribes their durations.
PO>
Assuming we are mid-project or standard bau then we start with

the product owner and the backlog.
SM>
The scrum master convenes the team to hold the 2 part Sprint
Planning Meeting (spm).
dvt>
and the team do the development work over typically 10-20 working
days with the scrum master and product owners constant involve-
ment and support.
dpm>
and each day the scrum master convenes the daily stand-up with
every team members answer to the lfe questions just done? and
do next? Part of the consideration needs also to be at what rate
are we progressing? Or to use the technical term what is the teams
velocity. When velocity is 100% we are delivery results at the
excepted rate. When we are 1.1 we are fast and when we are .9
we are slow compared to expectation : all this is earned value with

alternate vocabulary.
Deliver>
the sprints delivery is reviewed which may put new items onto the
backlog either maybe as Hmm Now Ive seen it can we or Opps
its not supposed to do that.
Retro>
and then the scrum master convenes the Sprint Retrospective (srpv)
to talk about Learning from Experience and then the Sprint Plan-
ning Meeting (spm) to merge the lfe and the backlog and so the
cycle continues.
We need to talk about how to handle quality defects in product or
process.
End.
TITLE= H Scrum animation
Lesson 140 TITLE= H Scrum animation .
Syllabus area.
Learning Outcome 1
Assessment Criteria 1.1
Speaker notes:.
At this point it may be a good idea to talk through the whole
diagram to explain how the five events, the three roles and the three
artefacts combine together.
End.
TITLE= The 5 Scrum events 5/6 - Ss18 s141
Lesson 141 TITLE= The 5 Scrum events

5/6 - Ss18 s141.

The Definitive guide tells us there are 5 scrum events and that.
1>
Each sprint may be considered as an individual project that delivers

an Increment to the business capability. Each sprint is a maximum
of one calendar month long. It creates an increment that is Done
by following a plan and a design, both of which are flexible. Once
the sprint starts its duration and all other critical factors (like team
composition) are fixed against anything less than a force majeur.
Only the product owner can cancel but they may be persuaded by
other stakeholders. The sprints quality level is fixed but the scope is
negotiated between product owner and developers. Sprints follow

each other immediately. Each consists of Sprint planning, Daily
Scrums, the development work, Review and retrospective. These
events are formal inspection points at which adaptation is expected.
Omission of any of the events compromises opportunity to succeed.
A sprints virtues include two things 1) we definitely get to inspect
project direction and relevance at least monthly and 2) our cost risk
is maximised at a months costs. On cancellation the review and ret-
rospective are held, incomplete work is re-estimated and returned to
the backlog and complete products are generally accepted and used.
Sprint cancellation should generally be strongly avoided. Mostly
whatever is an argument to cancel can wait till the next natural
break otherwise we have replanning costs which are all extra effort
without any reward.
2> Sprint Planning Meeting (spm).
The scrum master ensures the whole team take part collaboratively
in the Sprint Planning Meeting (spm), & provides coaching as
needed. The Sprint Planning Meeting (spm) is time-boxed to 8hrs
maximum for a 1mth sprint. It addresses 2 topics perhaps in 2
separate parts 1) What will we deliver and 2) How will we do it.
Part one is a forecast or prediction so needs estimates; a topic we will
address in the section after next (next is KanBan, then estimating).
The Sprint Planning Meeting starts with the product owner en-
suring the team understand the Sprints Objective and progresses
with the team deciding what they can achieve based on current
backlog, last increment and recent performance. The objective is
then expressed as a Sprint Goal. A collaboratively created, short
phrase that serves as the teams reference point of why this sprint
exists.
At a larger scales Kennedys I believe this nation should commit
to send a man to the moon and return him safely by the end of this
decade is a great example of what a sprint goal should look and

sound like. The quotable phrase is it helps the team be coherent.
The Sprint Planning Meeting (spm)s Topic # 2 is how will we
create the results that satisfy the Goal to a Done state? The sprint
backlog is defined as the sum of the backlog items and the plan
to deliver them. Backlog items might be function or technology
infrastruture. Imagine a user story As a car driver I want to be
able to stop safely. Obviously we need the breaks! To be safe we
also need the infrastructure elements of red tail lights, seatbelt and
maybe the airbag.
By the end of the Sprint Planning Meeting (spm) the sprints first
few days must be planned to sufficient detail for the team to be
productive : around the day long task limit. Further planning
occurs throughout the sprint. PMBoK calls this style of planning
RollingWave.
Planning requires some degree of design so the spms second topic
normally starts with design discussions and either makes design
decisions or identifies spikes that is prototyping activities to inform
deferred design decisions. Recall tom peters ready fire aim and
Fowlers requirement code design in that order. The Sprint Plan-
ning Meeting (spm)s second topic should end with the developers
explaining to the scrum master and product owner how they are
going to organise and work to deliver the sprint goal and deliver
the increment.
People with expertise are invited to participate in sprint planning
as needed P2A calls these people C_Reps and S_Reps .
3> Daily Scrum.
The scrum is a daily inspect and adapt meeting. It uses the last
24hrs achievements and translation to velocity for assessment of
what we can do in the next 24hrs. It is held as a stand-up meeting
at which only developers speak but others may attend as observers.
The focus is how did we support the sprint goal, how will we
contine to address the goal and what impediments do we foresee.
It is often followed by the team workshopping how to organise
for continued progress, often this is further sprint planning and
identifying required experimentation.
The stand-up scrum is the development teams meeting but the
scrum master ensures it happens and that it follows the rules.
4> Sprint Review.
At the end of the sprint we inspect the Increment and adapt the
backlog as needed. All relevant project stakeholders attend, the
session is informal, collaborative, aimed at sharing feedback and
lasts a maximum of 4 hours for a one month sprint. It is not a status
meeting. The scrum master ensures the meeting occurs within the
rules and coaches as needed.
The agenda typically starts with the product owner explaining what
is done and not done and when we will finish everything given
the current rate of progress. The developers demo the increment,
answer stakeholders questions and explore the sprints problems
and happy accidents. Everyone present discusses the current com-
mercial context and therefore how the continuing pursuit of value is
maximised. Eg what dates and contents are appropriate for releases
and the next sprint.
5> Retrospective.
A Retropsective is where the development team inspects itself

and identifies how do we improve ourselves? This is where we
really test peoples maturity as individuals and as a team rather
than a group. An online search quickly throws up the multitude
of challenges. It is a lot easier to say lets have a full and frank
discussion than it is to get a group of people to actually hold one.
Especially in most corporate environements.
To return to the ideal as given by Sutherland and Schwaber the

retropsective is a maximum of 3hrs. It occurs between the review
and the Sprint Planning Meeting (spm). Its purpose is create an
improvement plan by discussion of how people and process and
tools and relationships interacted. The scrum master is a peer
participant with other scrum team members. Retrospectives seek
to agree actions during the next sprint that will improve the team,
its charter, the definition of done and the fun we all have.
End.
TITLE= Scrum artifacts 6/6 - Ss18 s142
Lesson 142 TITLE= Scrum artifacts 6/6 -

Ss18 s142.

In prince speak the agile Artefacts are the products of Agile. 2

are management products like princes Appendix A templates for
information sets.
The third is the increment which is everything and anything that
delivers the business its operational capability. The increment is the
aggregate of everything delivered from the backlog so far. It doesnt
have to be in use but it does have to be Done.
Transparency of artefacts is central to scrums effective use in
optimising value and controlling risk. The scrum master coaches
everyone to achieve the best levels of transparency. Better trans-
parency equals better decision making. Or the other way around
incomplete transparency threatens flawed decisions, diminished
value and increased risk.
The scrum master inspects artefacts, listens to what is and isnt
said and senses patterns and feelings to detect lack of transparency
then convinces, and or educates the team to take action. Quotably
transparency is a path that isnt travelled overnight.
Product Backlog.
The Product Backlog is a list of what might be delivered. It is

ordered by value and owned and managed by the product owner.
It is never finalised, and is permanently open to amendment based
on what gives competitive advantage as of today for as long as the
product exists.
Several revisions ago prince made a significant distinction between
the product lifespan and project lifecycle. Lifespan maps to agiles
consideration of TCO perhaps better expressed as TVO [[Blog]].
Everything goes full-circle.
It is expected that as a product gains use in the market the backlog
grows to be exhaustive. The backlog is affected by technology and
consumer trends. Items at the top of the list are usually more clearly
defined, more granular and estimated at higher degrees of precision

than those lower down the backlog.
Quotably the backlog lists features, functions, requirements, en-
hancements and fixes. Each backlog item comprises description,
order, development effort estimate and value estimate. It might also
have an attribute to group items when multiple teams draw from
the same backlog. The backlog is product oriented rather than team
oriented.
To be suitably detailed for selection or Ready the backlog items
need to be groomed or refined. Grooming or Backlog Refinement
is how backlog items get their detail, their estimates of effort to
develop and of Value and order. It is an ongoing process between
product owner and the rest of the development team. The develop-
ment team identifies when refinement should be done. Prescription
says It does not consume more than 10% of a sprints effort. The
product owner may update backlog items at any time directly
themselves or by commissioning others.
Refinement must decompose backlog items to the point where each
items estimate shows it can be delivered with-in a sprints duration.
It is here that learning to be agile often takes some time. Your team
has to see how to break the end result into deliverable increments
that fit into a sprint. It needs an eye to see the natural divisions in
the product.
Through-out a sprints execution the effort to go is tracked by the
product owner : normally within a burn up or burn down-chart or
with a cumulative flow diagram. Any of these predict the date of
delivery of the current vision or project goal. Well address these
predictive statusing tools in section 21.
> The Sprint Backlog.
The product backlog is the list of everything needed in a product and

the sprint backlog is those backlog items selected for the sprint plus
a plan for delivering the Increment and realising the Sprint Goal.
A product backlog is made with nouns a Sprint Backlog includes
verbs. It covers everything needed to achieve doneness and it is
totally and exclusively under the development teams control. It
includes remedial quality work too.
Quote It makes visible all the work to meet the Sprint Goal at
a level that allows the Daily Stand-up to understand progress and
amend the sprint backlog throughout the sprint. The contents of the
Sprint Backlog emerges throughout the sprint as the development
team learns about the goal and the work to achieve it. As work is
completed, redundant work identified and removed or new work
identified and added the sprint backlogs Work-to-go figure is
updated visibly in real time. The current total is considered by the
development team at least in every daily scrum to manage progress
.
Definition of Done.
An age old project conundrum is when can value be recognised.

Discipline wise it is a mix of Quality Planning, scope definition,
Quality Control, Configuration Management and often also per-
ception and judgement. In short everyone has an opinion and it
is important to align specific expressions of those opinions so we
known when an increment is complete.
The Definition o Done aids the team in decision making about sprint
capacity and must define an operationally acceptable Increment.
Recall the Increment is the sum total of all increments. Done
includes all considerations of integration and might be expected to
grow in stringency as the product and our experience matures.
Teams might expect the organisation to have pre-existing defini-
tions of done and if so they must follow them. The d o d should be
universal across all teams. it may need to be extended or enhanced.
Note it is a singular definition of done that sets the standard for all
work done on the product or system.
End.
TITLE= Exercise-8: Critique a Work-Package - Ss18 s143 Case WorkPackage
Lesson 143 TITLE= Case-8: Critique a

Work-Package - Ss18 s143.
A Case study for using skill Back@Work now.

Review the list of work packages from Chestertons Cheeses and
draft a work package.
Post to the online forum or eMail me.
End.
TITLE= Exercise-9: Lego Building - Ss18 s144 Exercise Lego Animals
Lesson 144 TITLE=

Back@Work-SkillBuilder-9: Building
Lego Animals - Ss18 s144.
Here is an exercise that needs you to rope in some other participants,

perhaps your kids around the Sunday morning breakfast table! You
also need a bucket of lego.
End.
19 Kanban Method
TITLE= Kanban Method : 0of8 - Ss19 s145
19 Lesson 145 TITLE= Kanban Method

Section Overview: 8 - Ss19 s145 0/8
Kanban is a bigger section than most 8 lessons and 5,600 words of

narration.
As well as time-boxing we can use flow based team capacity
management.
We can combine the two. The study of workflows is at least as old
as the Gilbreths consultancy that flourished in the 1900s. In the
19 Kanban Method 329
1940s at Toyota Taiichi Ohno defined a whole lot more than just
work-flow tools to form TPS.
TPS is often called lean manufacturing. At least Lean is the word
made popular by James Womacks 1990 book that described what
he found at Toyota. Lean seeks to eliminate waste from processes by
many techniques. More than that TPS is a philosophy of company
wide focus on process improvement through values and culture as
well as techniques.
Further Mike Rother in his 2009 book Toyota kata tells us real
success depends on understanding the invisible force behind TPS
which is the kata or perfect pattern for embedding improvement
thinking in the workforce and coaching thinking in the manage-
ment.
By sticking to P2A we will be mostly omitting the softer and
arguably more important side for the more immediately accessible
elements.
One of leans techniques is Just in Time working. The just in
time approach to processes reduces a business capital requirements
as represented by money sat idle in incomplete inventory . We
minimise unsalable work in progress.
Just in time production uses an approach where a tasks start is
signalled by a latter step being about to need its outputs as an input.
Imagine Im the washer-upper in a restaurant There is a pile of dirty
plates next to the sink and a card with an arrow stuck on the wall
that says Shout for someone to get more plates. It is 6 plates from
the bottom of the pile. Thats my Kanban signal card. It calibrates
how many plates I can wash with how long it takes waiting staff to
go and gather more dirty plates and return them to the kitchen so I
dont become idle waiting for input.
When steps are written out as a work flow in European languages
they run left to right and are traditionally scheduled in that order.
Pull systems are often described as right to left. This right to left
control of flow through process steps, described as pull is often

represented on a wall board divided into work-flow steps.
In 2010 David Anderson wrote a book about his attempts to use
Goldratts Theory of Constraints also called TOC and Drum Buffer
Rope flow techniques to improve software development in his agile
team at Motorola.
Andersons book is called Kanban : Successful Evolutionary Change
for your Technology Business It has influenced many including
P2As author. Given its full title and contents and the narrow
breadth of our use we are only taking a little inspiration from it. Also
Andersons thinking has moved on so while p2a tells us of the 4 types
of review that help maintain project momentum Anderson now
talks of 7 cadences or rhythms that drive enterprise momentum.
The P2A manual doesnt mention ToC or Drum Buffer Rope (Also
know by its initials DBR) and just touches on Andersons or perhaps
I should say Taiichi Ohnos Continuous Improvement Culture.
They are off our path to the axelos P2A practitioner qualification
so I wont add them here and now. They are useful further research
avenues for you post exam via Andersons book, wikipedia or our
non-exam courses.
Returning to the path.
Kanban Method is a work flow method that adapts lean manufac-

turing where process steps are repetitive and of predictable and
fixed cycle times to project contexts where each work step has
unique characteristics and varying durations.
In Kanban Method when there is capacity in the last step of a pro-
cess flow this triggers the last but one step to pass-on work and so
triggers the last but 2 to pass on work and successively triggers the
first step to start a new piece of work. This is as lean manufacturing.
Kanban method adds a number of non-production line ideas such
as classes of service, for example to expedite something arising with

urgent need. Classes allow different pull speeds depending on the
cost of delay and risk from the work. Classes refine WIP limits.
Kanban methods approach to flow still uses the concept that the
work we start depends on down-stream capacity to handle it not
front end capacity to start it.
A simple way to implement this form of control is illustrated on the
slide. First list the process steps, their maximum capacity and all the
outstanding work by current process step on the teams Information
Radiator-IR.
P2A tells us that in Japanese a big visible sign board or a signal card
is a Kanban and in Chinese Kanban means looking at the board.
Between them is explanation of the name.
Big messages here may need you to finish this chapter to cut
through the jargon in which case be atuned to what concepts matter.
Kanban is most applicable from after {{Starting up a Project}} and
the Initiation Stage have got things going through development and
afterwards during product support.
Limiting wip improves the rate of throughput.
Kanban method has 6 core practices; 1) Visualise, 2) Limit WIP, 3)
Manage flow, 4) Make policies explicit, 5) Use feedback, and 6th )
Experiment and Improve.
The last three big messages are:.
Analyse and forecast with a CFD Cumulative Flow Diagram.
Break work down to small chunks that deliver value .
Where work really is of a different nature then it should perhaps be
managed via a different class.
End.
TITLE= Kanban and the Kanban Method 1/8 - Ss19 s146 1/8
Lesson 146 TITLE= Kanban and the

Kanban Method 1/8 - Ss19 s146.

Andersons Kanban Method is an alternative to scrum as a way to
control the work carried out by the development team.
In fact it is compatible with scrum as evidenced by what is called
scrumban.
1 Visual>
Most obviously the kanban board is a visual system of control .

Somewhere where we need to spend a little time to try-out the
mechanics. Our next slide in just a moment.
Kanban as in Ohnos TPS rests on several principles.
2 agility>
The First) is Start with what you do now. Day by day we evolve bet-
ter practices by CPI or Kaizen. Some quotable results are decisions
are made later when more information is available and so we hope
they are better decisions, lead times decrease, feedback increases,
transparency or everyones awareness increases.
3 Hi-inMp>
The flow method is most suited when there is a regular pattern of

work to be done, for example when we have a backlog defined.
End.
TITLE= The 6 general practices of the Kanban Method 2/8 - Ss19 s147
Lesson 147 TITLE= The 6 general

practices of the Kanban Method 2/8 -
Ss19 s147.
Andersons Kanban Method stands on 6 core practices.
Number one is visualise. Here is a Kanban board.
Card>
the columns are process steps and the coloured items are moveable
cards that makes the work and its position in the flow from Ready
to Deployed clear.
BigCard>
Each card explains a backlog item, its priority, effort & skill needs,&
Its acceptance authority. A cards position on the board shows its
current status. In prince terms the card is the Configuration Item
Record-A5. prince requires we update the CIR as we go. The whole
board of cards is a permanent and dynamic display of A5s status
updates that are reported in an Product Status Account-A18. Now
an a18 is a simple glance at the board.
The board is updated in real-time as team members start and finish
activities, discover impediments etc.
Lanes>
Kanban method uses Class of Service. 4 are common, between 3 and

6 generally suggested;.
1st is) Standard service. when you can deliver promises via standard
service the pressure from the organisation to label everything ur-
gent will decrease. Then truly urgent things can really be expedited.
Standard items are normally scheduled through the system as first

in first out or fifo : a pipeline architecture. They may or maynot be
estimated for duration instead the lead time reported from the cfd
may be our duration estimated more in a couple lessons time.
2nd class) are Fixed date deliveries. these are pulled into the work-
flow based on conservative estimates of duration. Mean estimated
duration plus three standards deviations is at least one suggestion,
3rd ) The Expedite class is for urgent items that arise unexpectedly.
Often expedite is limited to a single item at any one time across
the whole flow and may exceed other wip limits or interrupt
previous work items. An estimate of duration may be created to
give visibility of expected delivery.
4th) is the Intangible class. Intangible refers to its value. It is
necessary work that represents effort whose value to the customer
is indirect. It includes work such as correcting errors, housekeeping
tidy-ups and redesigns.
Across the board all the items are usefully decomposed to give
detail, for example for estimating with higher precision. There may
be more classes that the classes above in your specific context.
Decide on the classes required based on value and risk .
When bringing a backlog item to the definition of ready ensure
ready includes assignment of the required service level.
End.

Ss19 s148.

Core practice 2 is to avoid Muri or overburden by limiting wip to
the capacity of the step.
1 wip>
Goldratts critical chain in the ToC is so named because he identified

that the throughput of a process was limited by any bottleneck
steps. Leans principle of Muri or avoiding overloads is achieved
by feeding into the process at a rate dictated by down-stream work
exiting the process.
2 pull>
The pull approach where we start step 1 because step 2 has capac-
ityor more thatwhen the last has capacity the one before can start
and so on back to the beginning. It means we dont schedule tasks in
advance but operate reactively. Another of Goldratts observations
was that placing milestones and dates in a project destroys the
benefits of early achievement in prior steps. Later steps either
start when scheduled or late but rarely early. A pull system starts
work as soon as capacity is available. Lead times decrease often
dramatically.
3 Switch>
Goldratt particularly noted the impact of multi tasking and task

switching. Imagine you have just assigned me three four day tasks
and I focus entirely on one then moving to the next and so on. The
customer gets my first result after 4 days, then next after 8 days
and the last after 12 days : a nice smooth flow. If I focus equally by
switch every day between tasks then task one finishes on day 10,
task 2 on day 11 and task 3 on day 12. Not only has the customer
waited longer but then everything arrives in a flurry of activity that
may be hard to absorb.
WIP Limits.
The kanban board notes step capacity in its column heading. It

shows how many work items can be in the column at once.
End.

Ss19 s149.
Flow>
Core principles 3 and 6 are Manage the flow and improve collab-
oratively. Recall Ohnos 1st principle is start with what you have
and improve from there.
As well as seeking to avoid bottlenecks or overburden or Muri we
also seek to make the flow even. Even flow is achieved by the team
understanding the process and spotting adaptations that evolve a
better process. Uneven flow is Mura. Mura causes stops and starts
that add overhead or waste or to use the japanese word Muda.
Oh opps : Ive been adding to the materials. You dont need to

remember the words Muda, Muri and Mura or Toc and Goldratt for
the exam. Just recall that 1) is visualise, 2) is limit work in progress
3) is manage a smooth flow.
Managing the flow must surely also mean analysing it for speed
of throughput, predicting end times and much more. In-fact ideas
such as queuing theory have muc to say here.
Like why is it better to have one queue feeding all 10 checkouts in
the supermarket than 10 separate queues?.
More on that when we have looked at the 6 general practices.
2 4>
4) is that Chartering and Manage By Exception that we discussed

long ago. When we all know the rules of the game to quote the
definitive guide to scrum then decision making is aided, scrutiny
has a reference point against which to judge and conclude. Rules
or constraints make clear freedoms, empowerment and the space
within which the team can self-direct its sharing of roles and tasks.
The team builds its own norms or adopted policies over time.
End.

Ss19 s150.

Andersons points 5 and 6 are feedback and improving collab-
oratively as mentioned with point 3 manage flow by constant
improvement.
P2A tells use the best feedback comes from the person paying the
bill, but that is product feedback on the projects result .
1 FdBk>
The real customer has the most insight about the value of the
outcome. We also need good feedback from the process side. Also,
better feedback is quicker feedback and it is objective feedback and
quantitatively assessed feedback but it is only useful when it causes

action.
2 Quant >
Great feedback ensures that the most valuable backlog items exit
the development work flow earlier rather than later.
We should talk of improvement rather than feedback. Continuous
improvement is called kaizen in Japanese. Sometimes we have a
specific problem to solve and now we might enlist a specialist to run
a kaizen event. This may be a team during a compressed time period
during which we focuss on improving some issue. A challenge here
is the facilitator is well versed in analysis and change but often the
affected workforce is not. The activity of improvement is strange
and artificial to them not subconscious, practiced and natural. They
dont have a practiced kata.
In Japanese the word kata refers to an ideal pattern of doing
something, often martial arts attacks and blocks but also making tea
and everything in between. Toyota kata is the title of mike Rothers
book about toyotas culture for teaching the whole organisation
two kata; 1) is improvement kata and the second is coaching kata.
Coaching of improvers is not in a problems solution but in problem
resolutions. It is the equivalent in process improvement to give a
man a fish you feed him today, teach him how to catch fish and you
feed him for life. The workforce are the improvers being taught to
fish while the managers need to be better at teaching so must pursue
the coaching kata.
Feedback results from discussion or review. P2as reflection of
Andersons take on Kanban defines four review types. 1) The
daily stand-up meeting and 2) the perhaps weekly Service Delivery
Review, The Stand-ups benefit is it makes improvement thinking
natural and daily for the teams local kaizen. Helping to socialise
and embed the first kata, improvement kata. The DSM and Service
delivery reviews are used to check time-box status versus intention
and thus adjust policies or team norms. The Service Delivery

Review considers the results from daily stand-ups and also links to
strategy review at perhaps a quarterly time frame and risk review
at perhaps the monthly level.
3rd) is the Operations Review which runs the improvement kata
inter team as opposed to intra team. Not within but between the
projects agile teams. The OpsRvw may be above project level eg
at the program level and 4th) the Risk Review is an anytime but
perhaps never less than periodic consideration of the pattern of risks
that we are experiencing.
The coaching kata is the perfect pattern for showing improvers how
to make improvements to process. There is a 3rd kata; where the
coachs coach challenges the coach to coach better.
Experiments.
Improvement requires understanding of current and future target

state and of cause and effect so of experiments or spikes.
When knowledge of cause and effect are missing then spiking or
experimenting are needed to discover the links. When cause and
effect are well know (when we have transparency) then deciding the
actions to be taken is easier. Taking them then needs collaboration.
4 Everyone>
Combined with explicit policies and a spirit of quality is everyones

duty every day the steps within the products lifecycle become
easy to refine. Quotably we create the natural conditions for col-
laborative improvements. Kaizen or everyone takes responsibility
for everything they can do to improve quality all the time is a
significant culture shift.
Identifying where change may be beneficial is aided by observation
of the system in action, capture of metrics and hypothesis of cause
and effect. These thoughts match Six Sigmas Define, Measure,

Analyse, Improve steps. Kanban Methods author Anderson devel-
oped the method while at Motorola the originators of Six Sigma.
5 Failsafe>
Within the Improve steps we must consider the implications of

experimentation. Experiments should be designed quote in a safe-to
fail manner. For example dont test a new cars breaks by driving at
high speed along a limited length road. Much better to put the car
on a set of rollers where it doesnt actually move while the wheels
go around. Now poor breaking performance can never run out of
road. A failure is still safe.
The 6 s influence also says be scientific and data based. More to
come in our next few lessons.
End.
Resources.
http://www.methodsandtools.com/archive/toyotakata.php.
www.okalliance.com/wp-content/uploads/2013/10/Kata-Training-2013-
Manufacturing-Conference.pdf .
http://www.infoq.com/articles/David-Anderson-Kanban - scrum is
good enough, lean perfect & more.
http://theleanthinker.com/2015/04/27/toyota-kata-kaizen-events-and-
a3/
TITLE= Kanban : further guidance 6/8 - Ss19 s151
Lesson 151 TITLE= Kanban : further

guidance 6/8 - Ss19 s151..

If we take the best of both scrum and kanban we can have a
powerful approach.
Anderson points out in his writings outside the book inspiring p2a
that scrum and agile have different philosophies. Lean searches for
perfection, agile accepts get it wrong and correct later, lean says
wrong then correct is waste, the worst crime in the lean lexicon.
There are further tensions but they are off the exam path There are
also plenty of shared and plenty of complimentary elements.
While the danger is we get the worst of both the target is to
get the best of both. Both use empiricism or decisions based on
recent experience, both use daily stand-ups and other reviews to
identify process improvements, both empower the team and insist

on transparency.
Both set time as the fixed element and both compress time or
accelerate results.
Kanban can be inserted into scrum as the method to control the
work in a sprint. It can as happily and perhaps more powerfully
be used at business portfolio level to direct change based work at
portfiolio and program and project level Jarno vahaniitty twitter id
drAgileFant isnt a bad start point. At portfolio level kanban selects
the projects to be done based on operations ability to absorb change
and the organisations capacity. Capacity to RTO vs Capacity to
CTO.
Ive a free course here on that http://learn.logicalmodel.net/courses/context4free,
returning to p2a in both reduced breadth and depth of treatment
: p2a sign-posts these topics, it does not explore them so for an
exam target we dont need quiet the detail Ive been giving you. For
future B@W use you need to explore further, see our other course
offerings.
So Scrumban is the use of kanban to administer the work of scrums
sprints by using pull based workflow. A prince project can happily
use kanban to run a whole stage and remove the sprinting structure
or we retain the sprint structure and manage workflow via kanban
techniques of starting work because a later step signals it is about to
need the input. The later step requests or signals its predecessor to
provide an input. In manufacturing cycle times tend to be uniform
and predictable per widget. In projects and company start-ups every
work item is apt to be different. Manufacturing kanban needs extra
insight or technique.
2 Policy>
one way to cope is Kanban Methods defining of classes of service

as we just explored. A class may be represented by a colour code
eg standard is yellow sticky notes and urgent are pink notes. An

alternative representation is to place swim lanes across the board.
In all cases prediction and smooth flow is aided if the magnitude
of tasks is about equal in terms of size & risk. With practise teams
typically devise policies that divide work into smaller chunks while
still delivering value and at the same time identifying and reducing
risk.
3 control>
Andersons Motorola background may account for the suggested

approach to developing policy based on experiments. The quotable
advise is be scientific validate quantitatively on empirical, objec-
tive data. 6 steps are described 1) ask a question and 2) do research
so that 3) we formulate a hypothesis which we then 4) test with
an experiments from which we 5) analyse results and 6) establish
conclusions. this sound like dmaic as I explained earlier in this
section in new vocabulary to me.
Next Ill talk through the explanation of how to use kanban to
manage workflow The p2a manual gives us more what is kanban
than how do you use kanban.
End.
TITLE= Cumulative Flow Diagrams (CFDs) 7/8 - Ss19 152
Lesson 152 TITLE= Cumulative Flow

Diagrams (CFDs) 7/8 - Ss19 152.

An agile team often has a board on the wall that shows work status.
The board is actually irrelevant.
It doesnt mean we are lean or agile or imbued with kanban ways.
What matter is workflow is divided into a very few steps : as a
six-sigma sipoc would define for the P part if you know that tool.
Each workflow step has its work capacity limit set by examining
the teams skills, numbers, physical resources, tools, perhaps work-
stations and constraints.
Before the flow we have a reservoir of items that are ready. In a
configuration management and product breakdown sense these are
a5 whose status is work-not-started. In the illustration each day is
a row of the table and column of the graph : perhaps not the most
intuitive twist to the layouts.
Also we would not see the table and graph as illustrated here till
the work is all done.
On day 1 all the work is waiting in the backlog so everything but
the backlog is blank.
After the last day all the work is in the deployed state. Actually
given that the backlog includes MosCoWs coulds and the wont
and we cannot yet include the newly discovered this scenario as
Ive just explained it is a little idealised. Its a good start for a simple
description. To be closer to exhaustive we will need to expand it.
Between the start day and the end day the work flows through the
steps so the backlog is depleted but maybe never to zero and the
deployed accumulates to all that we intend to do being done.
We would expect to summarise the information into a graph. A
vertical slice through the diagram on any one day shows us what
work is where. Since each process step has a limited capacity that
ensures good even flow if we stick to the limits.
A horizontal view across the graph shows how long it takes for a
piece of work to flow through all the steps. The horizontal shows
the key metric item lead time. Shorter lead times are desirable for
quicker and cheaper delivery.
Since The graph shows us the table and the table shows us a finished
project lets use a time machine and go back a few days.
1 d12HiL>
Lets imagine it is day 12. Now things look like this. The data for day
13 doesnt yet exist!.
2 12 Status>
Reading the graph is slice by slice and backwards from results

achieved. A general rule of all project statusing is only and always
focus on what is achieved. For status look at results not activity, for
remedy and exploitation you can look at activity once you know
status minus plan which gives variance.
So the status at today is 8 deployed : dark blue, none ready to deploy
that would be red, 4 in test light purple, 3 in build : dark purple and
4 pink are ready to build when capacity allows.
3 d13>
When we get day 13s data the table has another row and the graph
another column. Deployed is still 8 but ready has increased to 1
because an item has moved on from test. Imagine here the testing
person visited the board and moved a sticky-note across a column
and in conversation with team mates identified that two items can
be pulled into test. We can see this because test was 4, is now 5 and
an item moved on from test so test must have gained 2 items from
Build. The test team member asked build collegues what can I pull,
so build may now visit the board to see what they can pull from the
waiting backlog.
You should pause here and internalise the words and picture.
Imagine the teams activity. They promoted an item pulled into
ready to deploy so they pulled two items into test from build.
Since builds total has only gone down by one not two ready to
build must have promoted one item to build which is why Ready
changed from 4 to three .
4 d14 > For day 14, again reading Right to left .
Deployed is still 8, ready to deploy has increased again so 2 items

finished test. Tests wip has only decreased by 1 so the value of
4 shows an item moved on from build to test. Since builds wip

stayed at 2 it must have taken an item from ready. Ready has
gone up 4 so 5 new items entered the Ready to build state on day
14. Perhaps a prior column Not Ready would be useful? Equally
imagine the po\ had conversation with those they represent out in
the business that led to addition of emergent newly desired features.
In some environments scope creep in agile environments servicing
the evolving needs of the business in a dynamic market place.
Ill scroll the table slowly and you should pause each time and
explain to your self what has changed by reading right to left
across the table and up the graph. You can draw the table 90-degree
rotated so that they both grow across, I guess you could instead also
draw the graph rotated. Whatever orientation imagine the teams
conversations that move sticky notes to reflect upstream results
achieved pulling downstream ready items onwards a step.
>this is day 15.
5 newly deployed items and wip in )test, )in build )and in ready
all stayed the same number. That should lead you to realise that
2 new items entered the test state, so 2 new items entered build,
so 2new items entered the ready state. If we had item ids listed
instead of counts youd see that the items in each stage are changing
even though the total of wip items per step doesnt make it obvious.
Notice that 2 items progressed into deployed from ready to deploy
from test all in one reporting period so you also cant see its
intra reporting period status. Perhaps to see them at rest in Ready
2Deploy we would have to snapshot at the hourly level.
> Now day 16.
Another new ready state item because one of the two items in build
is new because one build item was pulled into test.
> and 17
A newly deployed item means test pulled an item and so build

pulled two as is evident in the decrease in items in ready.
> And so on,.
day 18 the only movement is deployed pulled an item effectively

from test, day 19 deployed pulled an item, test pulled 2, build pulled
one, day 20 deployed pulled three, test pulled one, and build pulled
one, finally on day 21 deployed pulled 3, one effectively all the way
from build without intermediate stops being visible at the level at
which we are seeing status updated.
What we will examine next is using the CFD for throughput
assessment.
End.
TITLE= Cumulative Flow Diagrams (CFDs) 7/8 - Ss19 153

Lesson 153 TITLE= Cumulative Flow

Diagrams (CFDs) 7/8 - Ss19 153.
HiLight>
We cant tell from this analysis how long an individual item takes
or when any particular item entering build is actually delivered but
we can track the flow of work in aggregate through the system.
>
and the average time in the system.
Chart Lines>
The vertical slices of the graph show wip and the horizontal view
shows the average time between entering and leaving the kanban
steps. Work entering on day 8 has, on average exited by day 14, five
and a half days by the look of it.
2nd lines>
While work entering on day 15 is on average exiting by day 20,

through put has speeded up.
Even without the full table of data we can tell by the deployed count
rising from 0 on day 8 to 3 on day 9 that the initial delay in the
system was 9 days.
Lead time is used as a basis for predicting the duration of remaining
work and thus when work will be complete .
End.
TITLE= Kanban hints 8/8 - Ss19 s154
Lesson 154 TITLE= Kanban hints 8/8 -

Ss19 s154.

Flow based approaches can be added to time-boxes at any level.
One can flow a two week sprint or a three month stage. Quotable
the flow system is within the project but you can and you should
also run Portfolio management with kanban but this is a step off
the exam path . Lets return.
Kanban is a suitable technique for p2a stage workflow management
if the stage planning establishes the whole stage backlog.
1 HiL>
Otherwise we need the sprint planning meetings to select sprint

backlog items from the product backlog. In either case the work
content of a time box at sprint or stage level can be managed with
a kanban approach.
Kanban, as part of lean is focussed on avoiding waste : muda : TPS
identifies 7 forms of waste but that is beyond p2a. in p2a we know
that delay affects time to benefits.
HiL & Graph>
With reduced delay we get reduced time to benefits and more

efficient capital use. A double bonus. The quotable phrase is reduced
cost of delay.
A lot of P2A focuses on deliver early, avoid delay. In timeboxing
and scrums favour is the regular heartbeat of time to take stock
that Sprint Planning Meeting (spm) and Sprint Review (srw) and
Sprint Retrospective (srpv) provides. Against it prince already gives
us the Work Package-A26 and stage as reviewed episodes in the
project.
Little>
There are other useful analyse such as queue length, and in-process
time. In queuing theory; analysis of throughput includes Littles
Law.
LL says if you know arrival rates and cycle time you know the
number of items in the system, on average.
Buying a train ticket or queuing at the supermarket checkout are
classic examples. A single queue serving multiple tills reduces av-
erage wait time because a blockage at one till doesnt block anyone
in the queue attending other service points. Separate queues always
creates potential for the highest total wait time while a single queue
and multiple service points always has the best throughput.
Kanban says we can use empiricism to tell us the recent perfor-
mance and we know our backlog so we can determine our systems
capability and so forecast when we will have completed everything.
Evolve>
Interestingly the chief examiner also gives us here a reminder that

TPS says start with existing process and then we improve gradually
over time.
Exam question analysis next then B@W skill builder case study. Of
course you could do them in the opposite order : your choice.
End.


Ss19 s155.
Standard approach.
Pause? Read stem and candidate answers.
Welcome back?.
Ans>
Here is the chief examiners rationale,

Pause read and Ill comment.
Welcome back?.
The stem tells us there are prioritised requirements : MoSCoW must
be in our minds as a result, It also gives us a WIP-Limit so Kanban
must be there too and so we should be thinking {{Managing Product
Delivery}} and relevant roles will be tm, po, dev team etc.
A) Might be true, who knows? Its lowest priority but perhaps team
capacity is huge and work demands light.
B) No we are building capability not running the post delivery
operational enterprise.
C) Ahh two musts and 2 slots on the board, seems logical.
D) Three items and a WIP limit of 2 definitely means we wont start
all three.
I hope, the rational to B told you something about how to answer
other questions?
Benefits are being measured during the project not just after it as
plain p2 would suggest.
End.
TITLE= Case Exercise-15: Kanban - Ss19 156
Lesson 156 TITLE=Case Exercise-15:

Kanban - Ss19 156 .
Practical use requires fluency and confidence with the techniques.

Creating CFDs from raw data requires a little practice and I have
a great simulation for you here.
Reality requires a little dialogue and or some raw data in tables and
numbers that should be transcribed.
Ive provided everything you need in the course downloads for this
section. Have fun and as ever just shout in any of the available
forums to let me know when you need support.
XX ToDo: All to do here!.
End.
20 Plans theme &
estimating
TITLE= Plans theme & estimating - 3 - Ss20 157
Lesson 157 TITLE= Plans theme &

estimating Section Overview - 3 - Ss20
157
The agile community has had a lot to say about Planning and esti-
mating including Woody Zuills impassioned plea to not estimate.
20 Plans theme & estimating 359
Zuill and cos argument is easy to find online with the #NoEstimates
hash-tag. It has good points but the debate is not for inclusion until
after your exam answers are safely counted.
We have a whole course on Estimating. It really doesnt matter
what degree of agile you use, what your development process is,
all estimating is prediction and sits on some profound principles
like the difference between accuracy and precision : but that is off
the exam path : look at our estimating course for good insight, for
now we stick to the examiners opinions.
Key Messages of this section will be:.
1) Plan at multiple levels, plans at princes three different levels

are created from different needs and philosophies and different
techniques : Because the needs of the plans users are different.
2) Planning is about communications, prediction, control, evalua-
tion of viability and commitments.
3) P2A plans use empiricism heavily in at least the team plans
construction and maintenance, and should use it to some degree
in all plans, its called rolling wave planning or stages or sensible
management of uncertainty in other writings.
So at the Project Board and Corporate Management or Programme
Management level plans may be quiet traditional in construction
and presentation. Our holistic training in Outcome Delivery ex-
plores how to plan from a vision at board level so that strategy
aligned objectives are suitable to cascade to management and
development teams.
4) Planning should follow an approach based on planning Horizons.
5) Use Product Based Planning.
And last, 6) Estimate using Agile techniques.
Lets explore the details.
End.
TITLE= Plans : general view 1/3 - Ss20 s158
Lesson 158 TITLE= Plans : General view

1/3 - Ss20 s158
Fragile agile is famous as dive in unprepared.
On the other hand good agile also avoids wasting time creating
illusory plans whose basis is guesses and fantasy.
1>
Sense says we plan as much as we honestly can and when that is

very little we do just a small amount and observe the results before
either planning or doing more planning a little more.
2 EvsR>
This is empiricism in the footsteps of 17th century English philoso-

pher John Locke. Locke was the father of empiricism, a relevant
quote from him is no mans knowledge can go beyond his experi-
ence. A plan is of course encoded knowledge.
Build Measure Learn or probe-sense-respond are the techniques by
which we use the truth that the later we plan the more we will know
so the more useful planning will be.
3 LrMo>
The quotable phrase is Last or perhaps Latest responsible moment.
4 Features>
Agile project planning and particularly team planning focuses on

the results to be produced. So does princes Product Based Planning
approach. This is always a sound start when you can have a
dialogue with the customer. Agile approaches with the customer
embedded in the team ensure the practicality of this start point.
5 Team>
Planning is the process of creating a shared mental model, also

about uncovering options and selecting between then. It is an
inescapably social or team based activity.
The difference perhaps in an agile environment is the coach or
scrum master if we are in scrum knows its a team activity and
ensure it is carried out as one.
6 Points>
Results are often sized in arbitrary but relative units or points.

If microwaving a ready made soup is one point then making a
sandwich from sliced bread might be two and cooking a roast

Sunday lunch is too big to estimate but peeling the potatoes is a 1
while par-boiling and then roasting them is a 2. More in a moment.
End.
TITLE= Plans : Guidance 2/3 - Ss20 s159
Lesson 159 TITLE= Plans : guidance 2/3 -

Ss20 s159.

prince defines a project as something with an end and insists that
end is dated at the start.
1 EndD8>
It works perfectly for time boxing.

Indeed and ironically timeboxing is the only circumstance under
which it is sensible. princes key need to maintain a continued
business justification is met however plans are created if planning
gives us a baseline against which to judge viability. #### 2 any
style>.
Agile often proceeds without a pre-defined end date or ending
event. Whether we are at the end or not may be assesses on an
as you go basis.
3 Cone>
prince and agile both suggest that the further into the future the plan
projects its predictions the less precision is possible if reliability is
to be maintained. The quotable phrase is increased Margin of Error.
Margin of error is aka Cone of Uncertainty and is widest for the least
detailed plans : typically project plans as opposed to team plans.
3>
prince defines plans at project, stage and team or Work Package-

A26 level. Agile plans are at at least sprint and release level. P2A
tells us that Higher level plans such as project plans may be but
dont have to be conventional plans.
4 >
In any case all plans should be product based, should consider

dependencies and should reflect sensible groupings for example
skill set for team boundaries or related business areas for business
impact.
End.
XX ToDo: grammer.
End.
TITLE= Estimation 3/3 - Ss20 s160
Lesson 160 TITLE= Estimation 3/3 - Ss20

s160.

There are lots of estimating techniques and some specific to agile.
The most extreme is the dont do it community #tag #NoEstimates
but that is off the P2A radar. P2A only mentions two techniques;
story points and T-Shirt sizing so we will leave everything else to
our Agile Estimating Course : See the resources listed at course end
for further details.
Estimating is a tough capability to master and best done by teams

not individuals #### 1 Team>.
P2A recognises the wisdom of crowds which is implemented in
agile projects as team estimating. Its a derivation of the Delphi
Technique which you might know as a fairly mainstream technique.
2 Points>
. Team estimating often uses a set of cards inspired by the Fibonacci

series and called for fun estimating poker. It has nothing to do
with poker. The cards are numbered 1, 2, 3, 5, 8, 13, and then we
often depart from the series to go 20, 50, 100, Time for Tea and No
idea. T-Shirts sizes are similar but we have 5 buckets from Small
to XXL. Each is taken to be twice the size of the lower size i.e in
full 1,2,4, 8,16. Note well size is not duration. Size combines volume
and complexity as seen by this team. Over time the values normalise
as having meaning to the team. Team estimates are free of units so
they dont travel. One teams M might be anothers S or L, one teams
scale may be linear while anothers isnt
T-Shirts & Poker.
In either t-Shirts or Poker the game is played by each player

simultaneously showing a card or declaring a size that represents
their assessment. If we previously assessed roasting the spuds as a
2 then someone may say roasting the chicken is an 8 because
3 Because>
its the because that matters. In planning poker or T-Shirt sizing

its the rational of the size that drives debate and generates clarity.
The resolution of debate is often to decompose the feature step or
product another level. In this way smaller deliveries of value are
also often discovered.
The first principle here is the wisdom of crowds. If you looked-

up Snowdens KuhNevin talks on youTube you may have heard
his story about estimating the location of a missing submarine by
asking lots and lots of people and then averaging their assessments.
If you read Surowieckis book you find out about how accurate the
average of all the assessments of a bulls weight at a country fair
turn out to be.
Present Estimates Simultaneously.
4 Isolation>
Note that in group estimating it is important that all the estimates

are presented together or at least created without discussion. This
is important as it combats a problem called anchoring. Anchoring
is the effect on my estimating of knowing your estimate. To get
good estimates from everyone we need to combat anchoring. Thus
everyone estimates an item in isolation and then discusses.
Over time the teams norms establish a reliable size of a story
point but every teams reliable size is specific to the team. During
execution the team will discover how many points they can do per
week or sprint and this will be the teams velocity and will be
shown on a burn charts. Kent Beck and Martin Fowler observed in
Planning Extreme Programming that the liklihood is that todays
weather will be like yesterdays wit about a 75% correlation. Thus
if you want to know how long a task will take look at another task
that is as similar as possible and you have your answer with about
a 75% confidence level. Add some tolerance to express a range that
extends 75% to 90% and you have a very good estimate.
End.
TITLE= Exercise-10: Estimating
Lesson 161 TITLE= Exercise-10:

Estimating .
A Class exercise.
End.
TITLE= Eqn Paper_1 Qn_30 - Ss20 162

Ss20 162.
Standard process,
hit pause, analyse, answer, Ill share the chief examiners rationale,
pause and read then Ill talk through some thoughts that I hope build
your exam answering technique .
Welcome back?.
Here is the Chief examiners rationale.
Ans>
Was the stem familiar, if not are you proceeding in order? Ive pre-
sumed you would and do build the messages with that presumption.
Anyway a development team are using Kanban and have some
work to estimate.
A) uses rationalism so we dont need to read further to reject that

one.
B) suggests get your empiricism from other projects. That also aligns
tightly with the std prince2 process [ Capture previous lessons [
12.4.2 ] so sounds plausible. Better yet the specific form of estimate
is a lead-time so from a CFD so work done via Kanban .
C) Hmm so we could do some empiricsm based on this project so
now B) gives us similar work and C) gives us this project as a source
of input so that may have many relevant factors.
D) is noise because the question asks How and D) suggests
When and worse suggests we estimate before we might learn
more. Recall Last Responsible Moment.
So B similar work undertaken with same development approach or
C) this projects experience. However if we look at the Gantt chart
stage two work was entirely conducted by another team and we are
told that team estimates dont translate.
End.
21 Progress theme
TITLE= Progress theme : 4 - Ss21 s163
Lesson 163 TITLE= Progress theme

Section Overview: 4 - Ss21 s163.
An inherently empirical approach to control needs us to invest

sufficient focus in examining the projects progress through its
growing historical audit trail.
An empirical approach means asking How did that last bit go and
what does that imply for what is coming next?
In empiricism recent history is the basis to project where will we
end up.
21 Progress theme 371
Key messages in this section are:.
1) Convey status visually, eg with burn charts posted to information

radiators. Lo-tech and tactile is often best.
2) Assess progress at the direct, manage and deliver levels in a
variety of ways to maintain relevant visibility, for example of the
projects Continuing Business Justification at the direct level. It
all starts though with metrics that determine features delivered or
products delivered or value enabled.
Prince has many information sets aimed at communicating status.
3rd) then is P2As progress reports may mostly be replaced by
agreement with the project manager and Project Board to Read
what is posted to the display charts on the walls of the teams
workspace.
4th) The responses to status within the team will mostly be about
flexing the 6 aspects, well the 2 very flexible and 2 slightly flexible
aspects.
Can you instantly recall them? Pause maybe? Welcome back maybe?
Flex Scope and Quality maybe Flex Risk and Benefits, Fix Date of
delivery and the amount spent on delivery That is staffing levels
multiplied by duration and hourly rate is time and cost, at least in
any purely intellectual work.
5th) Assessing progress is usually very hard. The only 100% reliable
assessment is 100% complete. When we can demonstrate that we
have achieved the something matched to the Definition of Done.
6) When you know progress you take action : thats control. When
action must be taken by a higher level of authority that is escalation,
usually of an exception : its still control.
And last, 7); Tools of agile progress monitoring and forecasting are
burn charts, we will explore burn down and burn up and CFDs or
Cumulative Flow Diagrams before the end of section.
Lets explore the detail, do a back@work skill builder exercise and

analyse an exam questions make-up.
End.
TITLE= Progress : general view 1/4 - Ss21 s164
Lesson 164 TITLE= Progress : General

view 1/4 - Ss21 s164

Assessing progress is meaningless if you dont have a yardstick to
compare to. Ie some form of plan.
1 Plan>
Progress statements are meaningless without a comparison to some-

thing because you cant tell what status data means without a
reference point. Once we have a reference point the gap from
reality tells me what to do with or about the information. Should I
celebrate, cry or continue as we are?.
At project plan level the yardstick might be a p2 product checklist :
products and the dates the business wanted them by. This is exactly
a dated product backlog. Maybe reformatted as a Gantt timeline.
At delivery level the format is probably a Kanban CFD or a Burn
Chart. #### 2 Illust>.
A burn Down charts Ideal Line by definition the expected cumula-
tive delivery rate from tasks over the sprints duration. It maps 1:1
to a gantt charts view.
All useful status data is a comparison of what is achieved versus
what was intended. Achievement is always in terms of delivery.
Recall a user story always states its value so we can track value de-
livered. Interestingly no technique Ive heard of outside Dimension
Four and Assured Outcome Delivery includes explicit in-project
tracking of the value enabled but thats an aside, source for a blog
post [[Blog]]
3 EV>
At the risk of adding confusion there is a technique called earned

value. It is terribly badly named but fantastically useful as a project
tracking tool. Mis named because it tracks the suppliers budgeted
cost as baseline which is not the customer value. The key point
to recognise though is that Agile reporting and Earned value are
identical in intent, specification and conduct. Only the vocabulary is
different. The P2A manual explicitly advises using the 0-100% rule.
IE if it isnt finished then no value is earned. EV gives a number of
less draconian and quiet workable rules for reliable status tracking
but as ever these are not on the exam path so Ill leave them to
our earned value course. The referenced edition of The Measurable
News includes an elaborate mathematical proof of the equivalence
of burn charts and ev.
Trans>
However we track status it is only useful if it is shared and reacted

to; gains capitalised on and losses compensated for by flexing the
trade-space.
Status data is always best if it is simple and a direct result of work
done rather than an admin overhead to collect or in some way
derived. Good tracking is real time, matches gut feel but is objective
and auditable and Quotably it gives a sense of immediacy and is
published whatever it show : transparency. Ironically bad results
need the most exposure not hiding so we can ensure motivated,
widespread actions to correct.
End.
TITLE= Progress : guidance 2/4 - Ss21 s165
Lesson 165 TITLE= Progress : guidance

2/4 - Ss21 s165.
1 Delivery>
Leaving aside the mood of the team which is the most most
important project result the only project result of importance is
what is being delivered.
2 HiTime>
To track empirically requires understanding velocity. The glossary

defines velocity as A description of the rate of progress a team is
making. For example, if a team is completing 20 user stories points
per week then this is their velocity and it can be used to empirically
forecast their future rate of progress (assuming that the conditions

remain the same). You may know it as SPI. The two are mathe-
matically equivalent as the proof in the paper in the Measurement
Times referenced in the last lesson proves. Emotionally they may
feel different, their basis is different. A story point is a relative and
unit less measure that gets translated to duration by empirically
determining velocity.
3 >
A project is an investment so it needs control. By this we dont

mean taking empowerment away from the teams but we do mean
knowing where we are and perhaps guiding the product owner or
customer subject matter expert (C_SME). As an aside ive always
found asking how is it going? to be the wrong question. The right
start is first asking What do you need me to help with? and 2nd)
what is to go These are better questions and the best question is
always How are you? care for the people, servant leader ideas
again.
4 >
Burn down charts are equally applicable for the development team
and the Project Board to assess status. I cant say there are many
agile progress techniques but what there is does work at all levels.
The P2A manual explicitly recommends 1st setting stage boundaries
then position the releases and or sprints within stages. Burn charts
can now track at stage, project, release and sprint level. Other useful
reporting mechanisms exist but P2A doesnt itemise them.
[[I have a Progress tracking course on the agenda, drop me a note
if its of particular interest and I may accelerate its production]]
5 >
A P2A project may present progress to the Project Board by inviting

them to view the teams Information Radiator-IR rather than be sent
a Highlight Report-A11. Status pull rather than data push?.
Ditto the project manager who may collect Checkpoint Reports-A3
by reading team irs. Of course all parties need to be happy to work
this way. Both of these means of reporting would be recorded in the
Communications Management Strategy-A4 created in the Initiation
Stage and updated as part of {{Managing a Stage Boundary}}.
End.
TITLE= Burn charts 3/4 - Ss21 s166

Lesson 166 TITLE= Burn charts 3/4 - Ss21

s166.

Planning is important because it creates shared understanding.
Plans are important so that we can compare current status to
intention and use the shared understanding to agree what to do
next.
1 BurnsCharts>
Two burn charts with perhaps some artistic embellishment. Hope-

fully a settled team has a more regular trend That is less wobbly
lines.
A burn chart starts on the left with 100% to do and ends on the
right with 100% done. The horizontal access is time. A Burn-up can
reflect a situation where scope fluctuates by moving the 100% mark
upward or down. A burn-down chart cant reflect mid-sprint scope
variation. #### 2 DnUp>.
If you have experience in engineering fields you may very likely
have previously encountered burn downs as contingency account-
ing charts and burn-ups as earned value charts.
3burn>
A typical agile burndown shows the ideal rate of progress as the

team deliver 100% of the work in 100% of the time-boxs duration.
The straight line on the burndown chart representing the story
points delivered by the teams velocity.
When the team is progressing slowly the trace of actually completed
features or products will be above the ideal rate and when progress-
ing faster than expected the trace of actual is below the baseline
rate.
As shown the burn-up chart lacks an expected or projected rate. At

project even if not at sprint level it is typically S shaped.
In Earned value the projected is called variously the BCWS bud-
geted cost of work scheduled (bcws) or the planned cost or the
planned value [[blog pv as planned value]] and by convention
would be drawn in blue. Our EV practitioner course is scheduled
for release in 2016. While all this broader context is important for
post exam work that builds businesses let us for current purposes
come back onto the exam path.
4 focus>
The plot line marked actual shows what has been completed.
The graph is more reliable and meaningful when tasks are of
approximately equal size. The vertical axis is story points or percent
complete.
End.
TITLE= H Burn charts

Lesson 167 TITLE= H Burn charts .
Syllabus area.
Learning Outcome 5
Assessment Criteria 5.4 and 5.5
Speaker notes:.
This kind of graphic can apply to any duration e.g. a release, 3
month stage.
End.
TITLE= Information Radiators 4/4 - Ss21 s168

Lesson 168 TITLE= Information

Radiators 4/4 - Ss21 s168.
IRs or BVCs are the means to display the projects information.
#### 1 BVC>.
IRs are a mix of static items and, dynamics ones. eg registers such as
team risks and records such as current backlog, defect log, quality
register and Kanban columns, social news and events. They also
include anything else the team chooses to display. Particularly
useful might be project vision statement, team charter or working
agreements and sprint goal.
An IR should be visual rather than text were possible.
Quotably it is a push mechanism, pull is when information is hidden
and needs to be sought out (15.4.2.1) and quotably it expresses good
and bad information openly : agile is transparent.
Presenting slanted or massaged information is quote gaming. Un-
derstandable it is best if key information leaps off the board even at
a distance. Useful tools are sticky notes in a variety of colours and
self-adhesive marker dots, stars etc.
The quotable ffp test is can someone walking past absorb key
headlines.
In front of the display is a good location to hold a daily stand-up.
The stand-up will update the board from discussion but should
actually expect the board to already be mostly up to date.
Were a team is dispersed a board with a webcam that permanently
displays the board is preferred to a SharePoint, bascamp or similar.
Quotably attractive Information Radiators- are an inspiring influ-
ence whose significance should be appreciated. A trace of look
what we have achieved is a positive force for increasing team
velocity.
Personal Progress Check-Point!.
And your positive force is that we have now done 16 exam question
analyses and have less than 35 lessons containing input left to go.
Lets do our 17th eqn analysis.
End.
Big Visible Charts.
End.

Ss21 s169.
Pause read return?.

The stem tells us we have a burn downs so fixed scope sprint,

progress is slow causing low priority work is being set aside.
Ans>
Pause read welcome back.

Here are the chief examiners rationales. I dont see any answer
explaining why we are progressing poorly but the stem does state
we are behind expectation.
The stem actually tells us progress is stagnant : relatively flat. Thats
normally a big worry that the question here does not seem to
acknowledge.
Answer A) says velocity is below that needed to delivery every-
thing. That is true so A) explains the stems progress line above
ideal line by MoSCoWs drop shoulds and coulds
B) The burn chart is displayed so progress is visible to everyone
so also true but so what? It isnt explaining the assertion that we
should drop work as given in the stem.
C) Also true and another so what.
D) Also true.
Of A-D the only one that reflects any element of WHY is A, the
others are just facts without sensitivity to progress while A is related
to the consequences of progress or lack of it. The stem asked for the
best explaination of why the response is justified by the manuals
recommended way of running projects.
End.
End.
22 Quality theme
TITLE= Quality theme : 0of3 - Ss 22 s171
Lesson 171 TITLE= Quality theme

Section Overview: 0of3 - Ss 22 s171.
Quality is a major topic for every project and every bau environ-
ment too.
1 Manual>
Key messages here are:.

22 Quality theme 386
1) understand that in p2a scope is the volume of products and

features and quality is their refinement, fitness for purpose and
conformance to specification.
2) P2A says a quality failing is when something is delivered that
doesnt match its spec but it isnt a failing when we modify the spec
to be less demanding. Equally it is not a quality failing to de-scope.
Instead its the main technique for protecting delivery date.
3) Agile flexes scope and targets variable quality attribute levels
specifically to meet deadlines.
4) Customer Quality Expectations must be distilled to Acceptance
Criteria and the Acceptance Criteria met for all the items of scope
that are actually delivered. It is ok to leave stuff out, it isnt ok to
do stuff badly.
And last 5) The Definition of Done is an holistic expression of accep-
tance that covers topics such as the product is useable, operations
staff are trained, maintenance is enabled to keep it running, perhaps
also the customer is educated.
Some caveats;
The P2A manual uses Quality Control and Quality Assurance

without regard to and in contradiction to widely known definitions
published and used elsewhere.
The P2A manual attributes a method of check for failure after all the
work is complete to waterfall approaches. It is therefore what you
need to say to pass the exam but it is an horrendous misconception.
[[BLOG!]] quite breath-taking. Im actually affronted but that
doesnt help you achieve an exam pass so Ill stow it away.
End.
TITLE= Quality : General view of Agile Quality 1/3 - Ss22 s172
Lesson 172 TITLE= Quality : General view

of Agile Quality 1/3 - Ss22 s172.

General agiles IT heritage often makes the treatment of quality
something software specific. Perhaps not all the ideas travel to other
industries.
For example Refactoring is the idea of adding design to code
after the first few revisions start to show what are the important
parts of the software architecture. Refactoring says reengineer the
code internally any time it helps provided the external function
and interfaces remain unchanged. It relies on having available
automated tests that confirm function and fit are un-altered. The
concept can in some circumstances translate to physical products
but has more limitations. It always works in other intellectual
design based disciplines.
1 bp1>
The idea of defining tests that demonstrate meeting the acceptance

criteria before creating the products should always translate. It is
called test driven development. Start by knowing what the final
tests will be. Planning Extreme programming by beck and folwer
is good guidance whether your in software or not : dont be put off
by te title if you are in non software fields.
They point out that the smart way to do any projects requirements
is to start with the required terminal tests. Test Driven Development
matches the three end sections of the Product Description-A17 :
quality tests & methods & personell There should be a Product
Description-A17 behind every item in the Product Breakdown
Structure or to switch to agile vocabulary the dods content should
be relevant to every backlog item.
A broader, better philosophy is Dan Norths Behaviour Driven
Development : You should check out his website : more focus on
bdd in a few lectures time.
tastGo>
Changing tack; Im horrified but you need to know for exam

purposes that P2A says waterfall tests products after they are built :
Quote :unquote Thats absolutely opposite to my whole experience,
plainly it would be completely stupid but Anyway that is what the
p2a manual asserts so a possible exam answer
P2a says Agile specifically takes a test as you go approach including
quote test first. Test first really means prepare your tests in advance
and apply each as soon as possible.
DoD .
What we test against is the definition of done. The Dod is generally

accepted in agile to evolve both in completeness as the teams
understanding grows and in maturity as capability builds through

successive sprints.
The DoD is the answer to What is everything needed from the
development team to fully close their commitment?. It is broader
than just product built so includes for example that maintenance,
training and operational needs are all met too. I have summarised it
through out my career as That which when done means the client
happily settles the bill or if we end in court there is no argument
that we did what we should have.
4 ManPage>
The evolution of where are we going and thus what must we

produce means that the focus of Quality in agile tends to be low
down in princes Quality road map; the top presumes target clearly
defined in advance.
prince specifies the Quality Management Strategy-A22 during the
Initiation Stage. Agile teams are more likely to evolve any expres-
sion of QMS than try to write one at the start when little is known.
Stepping on to the real world path for a moment; mature organi-
sations should have a mostly applicable standard Quality strategy
for projects and other departments as should reputable suppliers.
Projects should not be reinventing the wheel each time. Equally
they must recognise kuhnevins guidance about when existing
practices in novel circumstances are a short tumble from an illusion
of control into chaos.
princes early consideration of quality is so that resource needs and
hence impact on costs and dates can be included into the Business
Case and resource demands. If scope is fixed then deadline and or
resource is the variable and depends on knowing quality targets and
approach. If date is fixed then scope and quality necessarily become
variable.
We are back to cost as the independent variable which is a counter
intuitive way of saying cost is fixed. Cost is fixed in software if team

is stable and date is cast in concrete because there are no other costs.
Not so true in any project with physical products made from raw
materials in addition to staff time. Here there is also the cost of
scrap.
End.
XX ToDo: ??
TITLE= Quality : Guidance 2/3 - Ss22 s173
Lesson 173 TITLE= Quality : Guidance 2/3

- Ss22 s173
Learning outcome 5, Assessment criteria 5.4 and 5.5

P2A allows for very informal use of Product Descriptions-A17. That

does not stop formality when wanted.
Product Description-A17 will most likely appear first as epics and
user stories that evolve their detailed requirements and acceptance
or quality criteria, tolerances and quality checking method during
development.
2 a21>
At project level the Project Product Description-A21 is the expres-

sion of the projects outcome or vision.
its major decomposition is the projects epics that together de-
liver a Behaviourally Driven Developments business outcome. Our
Outcome delivery courses are all about the tools, techniques and
behaviours of delivering behaviours : yep behaviours that deliver
behaviours.
The vision or outcome needs Customer Quality Expectation, Ac-
ceptance Criteria and project quality tolerances defined.
2 qp>
In the software world knowing the tools that are to be used for
testing, for build and for Configuration Management means there
is an emphasis on Quality Planning in the how do we do it? sense.
How to control quality needs to be accompanied by what quality
criteria to achieve. Princes Product Description-A17 describes
these factors in its headings Quality criteria, tolerances and testing
method and suitable personel.
Agile needs here are met by the acceptance test for example on the
obverse of an extreme programming card that takes the user story
as a
3 HiL>
The customer subject matter expert (C_SME) in p2a words or

product owner in scrum vocabulary must also make clear to those
they represent that the business has the inescapable duty to drive
acceptance demonstrations and make acceptance decisions.
End.
TITLE= Quality How to test 3/3 - Ss22 s174
Lesson 174 TITLE= Quality How to test

3/3 - Ss22 s174.

Agiles roots are in software. Terms like Technical debt are ex-
tremely geeky #### 1 Circle>.
Technical debt is the work created by building something poorly to

start with pending later refinement. As Ward Cunningham pointed
out when he coined the phrase; Its the consequence of trading-off
between quick and dirty and right but slow. It increases Total Cost
of Ownership.
When we are early on we often lack the basis for good decisions.
An example in this course is those videos where the sound quality
is below what I aspire to produce. In September 2015 there was a
technical debt of content to be rerecorded because I didnt have
the workflow to create excellence straight off. As my retrospectives
identified improved process so the backlog or refactoring grew. My
technical debt grew.
2 upRF>
In Refinement or refactoring Martin Fowlers point is we often dont

know the best architecture till we have done enough tweaks and
amendments to see the knotty problems emerge.
These are the consequences of earlier choices whose alternatives
had nothing to recommend them one way or another at the time
or whose subtleties where invisible to our untuned eye. These poor
choices are unavoidable but incur cost of remedy and interest costs.
This week I moved a misplaced lecture. The interest cost of that
debt work was 20 times the work if I had not misplaced it originally
because all my control records, cross references and many produced
artefacts all had to be updated. Waterfall developments suffer
hugh technical debt interest charges when they encounter required
change.
As another example; Imagine a car journey on a Saturday morning
with a choice of route into your local city. Only after you pick a
route do you discover that today one road has become a new street
market, some traffic lights are out causing jams at a cross roads.
If you had known in advance youd have taken the other route.
Technical debt includes interest costs which are the cost of retracing
your steps back to a point where you can switch route and then the
new cost of taking the other route. Refactoring is the work to take
the alternate route and re-test that you are headed towards your
required destination.
3 upDoR>
I think we have covered almost all the other points;.

lets refresh our memories and fill gaps. The D of R is a User story
that meets the INVEST tests or at least a subset: Do you recall those?
perhaps hit Pause before I tell you. They are I for Independent, also
Negotiable, Valuable, Estimatable, Small and Testable The glossary
says the criteria that determine if a piece of work is eligible to be
selected for inclusion in an upocoming timeboxs backlog .
4 Up DoD>
The glossary gives the DoD as criteria used to determine that work
is complete.
Something is either done or not done. Earned value calls this the 0-
100% rule and we discussed that 100% done is an holistic view that
includes every relevant stakeholders needs.
5 up >
TDD is the software approach of define tests then build code that
satisfies the test.
It is one of many techniques or practices from Beck and Fowlers
Extreme Programming approach. : As an aside B&Fs planning
Extreme programming is a book in my top ten. Whether you are a
software professional or not is 99% irrelevant to the value of reading
it.
6 down>
That brings us to BDD which is the most interesting entry on the

page for reality and for agile concepts in a non software world.
It is but a minor footnote to the exam.
BDD is outcome driven testing inspired by TDD but at the business
level. The B for Behaviour is a synonym for test that is expressing
a business goal or need or outcome. Bdd changes user stories from
As a Role I want to Action because Value. Now our U_S is Given
context when Event then outcome.
An example for a chef might be Given the dishes on the menu and
the ingredients in the fridge When the Customer orders a dish from
the menu Then I cook the meal and we revise the shopping list for
restocking supplies and later receive the customers payment.
Two other terms not on the axelos supplied slide here but in the P2A
manual are:.
Verification and Validation. Verification is the checking that some-
thing conforms to its specification and Validation is the checking
that something does what is needed.
The two are often distinguished as verification is Thing done right
and validation is Right thing done. I think thats hard to internalise
so try it like this; verification is proving the work was done correctly
and Validation is demonstration that the final result received is
what is wanted. Another perspective that might help is manage-
ment is following the rules and leadership is setting the right rules;
management is to verification as leadership is to validation.
Or is that verification is to management as validation is to leader-
ship? Writing the foregoing points down helps internalise.
Next is a Back@Work skill builder for reality and after that an exam
analysis for personal CV and Resume building.
How does this work? As a
End.
The true cost of a quick and dirty solution Ward Cunningham
:todays quick fix = higher future TCO until you refactor.
End.
TITLE= Quality in relation to Scope 4/4
Lesson 175 TITLE= Quality in relation to

Scope 4/4

Acceptance criteria are set from debate about CQE in SU-4 Prepare
the Outline BC(A2) and IP3 Prepare the QMS(A22) AC are verified
in Mprince Execute a Work Package (Sprint Review).
End.
TITLE= Exercise-11: Advert QC - Ss22 s176
Lesson 176 TITLE= Exercise-11: Advert

QC - Ss22 s176.
Here is a Back@Work skill builder. Step one is to imagine the user

story As <Chestertons marketing manager> I want to commission
Step 2 is translate the U-S to AC and share with me and the discuss
forum.
Step 3 is take a someone elses shared set of AC for the US
and imagine executing work to meet the AC in good faith. How
complete, unambiguous, and INVEST are they? Where are the loop
holes, omissions, ambiguities etc.
How would you improve US or AC?.
Can you generalise the improvements to be guidelines to creating

US and AC that you will ask your real teams to follow.
Lastly post/ share your guidelines.
End.
TITLE= EqA Paper_1 Qn_18 - Ss22 s177

Ss22 s177.
Standard practice.
pause and read and answer then return and Ill share an analysis
and the chief examiners rationale.
Paused and returned?.
This question is one where we need to have read enough of the

scenario to know Brand-U-Like are developing the Logo.
The stem tells us we need a BEST answer so we should prepare for
4 plausible and correct answers. We also need to note we are told
the intro to the Quality Management Strategy-A22 reinforces this
specific objective.
Ans>
Here is the CEs rational. Welcome back?.

A) Plausible. It specifically says the team must focus on the level
of quality so matches the stem.
B) Plausible but weak because Brand-U-L will be concerned about
reputation in their own qms. The projects qms should focus on
receiving the results as needed. Recall plain p2 says a project qms
is an aggregate of all stakeholders qms with the customers taking
the dominant role where necessary.
C) Like so many answers offered for questions wanting a Best
response this is a True fact in isolation but food hygiene standards
are not relevant at all to the projects quality guidance for its
branding team .
D) Also plausible but we have already observed the often agile
evolves the quality strategy rather than attempt to nail it all down
in advance. Nor is this statement guidance to the team producing
the specifics of a logo.
End.
23 CS {{Controlling a
Stage}}
TITLE= CS : 5 - Ss23 s178 0/5 CS Hdr
Lesson 178 TITLE= CS Section Overview :

5 - Ss23 s178.
By P2A standards the manuals chapter on CS is longer than many.

It looks like this.
23 CS {{Controlling a Stage}} 401
1 ManPg>
It is one consolidating & repeating much we have already covered.

Treat this as partly revision and summary and some embellishment
of new detail. What we will add to the p2a and axelos lessons is the
cs/mp interface.
PRINCE and agile fit together nicely because prince has always
been about the interface to technical work and about pre-agreed
time limits : those stage boundaries.
A stage is a time box for authority and resource allocation.
Ss23 tells us that Chapter 19s big messages are:.
First) Stages and the project managers constrained authority to ex-

ecute while within tolerance are the core of Manage By Exception.
MbE is the foundation stone of freedoms, empowerment and the
culture that allows agile development teams to organise themselves.
Its not possible to over emphasise the importance P2A attaches to
the self-determination idea.
2nd) The project manager is responsible for a stages delivery.
3rd) A stage may oversee multiple teams. So we may choose to
use a scrum of scrums for technical information flows within an
increment. S of Ss help coordination for delivery to deadlines. If
there are multiple teams then it is likely a product manager or Senior
User(s) oversees the product owners or CSMEs within each team.
Scrum of scrums coexists for product team interface purposes with
the project controls provided by prince through the activities in
{{Controlling a Stage}}.
P2A tells us the project manager may exercise control in part
through facilitating the s of scrums, or entirely separately .
Also Stages are a business and management boundary that can
be entirely unconnected to technical boundaries like releases. Of
course it makes a lot of sense to tie investment decision making to

points in the products journey to maturity but the two are separate
cycles and concepts.
4th and last The stage structure, particularly the use of {{Managing a
Stage Boundary}} encapsulates the sequence of Sprint Retrospective
(srpv) when we can ask the what made you Glad, Sad, Mad at the
end of a period of activity and then follow it with the Planning
Meetings (spm) at the stage, release and sprint levels that prepare
for the next period of activity.
End.
TITLE= Controlling a Stage 1/5 - Ss23 s179
Lesson 179 TITLE= Controlling a Stage

1/5 - Ss23 s179.
Learning outcome 5, Acceptance criteria 5.5/5.7
The P2A manual says quote the nearest equivalent to a stage in

agile is a high level time box.
The quotable distinction is that agile time boxes target delivery of
a result; product or feature. prince stages encompass a period of
authorisation.
The high level agile time box contains lower level time boxes that
may be called release, iteration or increment and may themselevs
contain sprints. Timeboxes will run in parallel if we have more than
one team.
When more than one team is involved there is likely to be a need
to coordinate between teams. This may be done with a scrum
of scrums meeting. Paragraph 19.2 tells us that scrum masters
meet in a scrum of scrums to air project level concerns and move
information between teams. The definitive guide in apdx H omits
mention altogether and nor does the rest of the p2a manual describe
scrum of scrums further.
sos>
P2A says that s of s is a good communications and coordination

tool but is not a control mechanism. That still needs project man-
agement.
A stage IS a timebox .
Set by management based on business & market place needs.
Duration agreed in SB/[ Authorize a Stage or Exception Plan [ 13.4.3
] discussions & perhaps also [ Authorize initiation [ 13.4.1 ]
Likely to be made up of one or more releases containing one or more
sprints.
A sprint is a timebox .
Perhaps sprint durations are documented in the Project Brief-A19

so decided in [ Select the project approach and assemble the Project
Brief [ 12.4.5 ]. Even if they are they could be subject to flex later.
Releases (& sprints) are often engineered to fit business needs for
stages based assessments. Somewhere that I cant now track down
the paragraph number the official manual says define the stages
then the releases.
End.
P2A says SofS ?Comms but ?Control.
End.
TITLE= {{Controlling a Stage}} Guidance - Ss23 s180

Lesson 180 TITLE= {{Controlling a Stage}}

Guidance - Ss23 s180.

We know the quote that the interface between CS and MP is the
glue that binds P2A together.
The reality is a lot happens via the daily stand-up which in prince
terms is the checkpoint meeting rather than the Checkpoint Report-
A3. Recall p2 says the team holds a meeting, the checkpoint, and
from that a report goes to the pm, the Checkpoint Report-A3.
ManPg>
In every process the manual provides a bridge between prince and

agile terminology. Course wise Check-out the revision aids. We see
that products are now called artefacts. Artefacts or management
products are the backlogs, burncharts, shippable product, imped-
iments and information radiators. They map to stage and team
plans, work packages, status reports, and records such as daily log,
risk register, issue register and issue report and configuration item
records.
We can also see that events are planning meetings and reviews and
product demonstrations at sprint and release level. Ill show you all
the standard p2 ones in a few lessons time.
fade>
Work assignments or the [ Authorize a Work Package [ 15.4.1 ]

to [ Accept a Work Package [ 16.4.1 ] interface runs planning,
scheduling and estimating as collaborative perhaps workshop based
team activities.
So that we foster the richest possible communications, help identify
sensible tolerances or constraints to signal exceptions, and encour-

age the team to own its work .
A Work Package-A26 may contain several timeboxes each deliver-
ing a feature or product as identifiable in the Product Breakdown
Structure. Each creates something capable of deployment even if
not deployed.
Within each timebox the team members take the next waiting
piece of work from the backlog according to the customer subject
matter expert (C_SME)s prioritisation rather than as the result of
upfront pre-assignment. The mechanism may be via the kanban
board indicating upstream capacity is coming free : remember my
washer-up example.
Team members use the daily stand up to coordinate their activity
and raise issues but the stand-up is not a reporting mechanism.
Reporting during the sprint or release is via the teams Information
Radiator-IR and at end is via the Review, or the optional product
demonstrations and the Retrospectives. Monitoring and forecasting
are empirically based, burn charts are more likely than gantt charts.
The focus is flexing scope and targeting quality attributes that are
realistic within other constraints. What is to be delivered may be
held in a backlog at project, stage, release, or sprint level,.
AoM>
The daily stand-up should escalate issues (sometime also called

impediments or smells or blockers) swiftly and identify and respond
to risks. Reviews and retrospectives also consider risks and issues,
their responses and status.
Stand-ups and reviews might focus more on product risk and
retrospectives on risk related to the organizations ability to adapt
to agile working, the agilometers focus. The degree of risk should
inform how agile is applied, as suggested by the analysis used
whenever the agilometer is updated and reconsidered.
End.
TITLE= Retrospectives 3/5 - Ss23 s181.
Lesson 181 TITLE= Retrospectives 3/5 -

Ss23 s181.

The definitive guide in apdx h defines a three hour time box for the
retrospective of a one month sprint while the P2A manual suggests
a whole day for the retrospective of a 6mth project. The major
thought here is that the purpose of the retrospective is to feed into
the next planning meeting!.
Retrospectives are particularly hard to hold. The psychology and
sociology is complex and they only work where the culture is
healthy. Were no blame has real meaning. Even here it takes effort
to ensure the third, fourth or fifth retrospective is covering good
territory. The P2A manual warns that it is necessary to change
the format and or focus to keep them worthwhile and use all
the techniques of workshops : We will cover all the workshop
techniques like independent facilitators under the heading of Rich
Communications. Recall long ago : Lesson 16 in Section 2 we noted
retrospective should have wide participation.
When running teams for real there are plenty of blog posts and
other internet resources that focus on how to make retrospectives
constructive, personality free events and keep them productive : the
twin challenges.
feel>
A Retrospective looks for improvement to working practices from

the people and process, facts and feelings viewpoint.
We are at the 80% point! Perhaps you

too should take a retrospective.
Perhaps you have questions? Dont forget the exam preparation

is instructor supported. p2a@logicalmodel.net Mail me with your
questions and a note of your exam registration code and if you have
now set the date. A date helps you focus.
If you have not yet set a date recall that some proctored timeslots
get booked-up quicker than others so if you want to take the exam at
4hrs notice while it is within the published service level your most
likely to have a slot at an unattractive time. That might suit you!.
To book a time and proctor visit www.logicalmodel.net/prince2exams
for details and follow the link to the shop to buy a voucher.
The voucher allows you to reserve you exam session on our ex-
amining institutes exam system. From there they will send exam
sitting instructions.
Note the stipulations for the exam set-up. Quiet work-space with no
cheat materials. A moveable webcam so you can show 360 degrees.
Im told some even want to see under your table and up to the
ceiling! You also need a microphone and speakers but not a headset
: axelos rules apparently. An attached printer is also sensible if you
want to print the scenario before your exam question answering
time starts. The proctor will explain how.
Preparing for the exam involves downloading the session monitor
that ensures your pc/laptop is dedicated to the exam while your
running the exam. It might need you to stop things like virus
software.
There is provision in the timings and the eis instructions covering
all this : just make sure you read them! Odd as it sounds for an
expensive mistake there have been those who get all the way to the
exam session and have overlooked some of the instructions. Since
exams maybe stressful a late discovery of something material is
upsetting.
Note the proctor will expect to see some photo ID like a passport,
drivers license etc They will also want to check that printed manuals
and locally printed exam scenarios are free of unapproved addi-
tions.
End.
TITLE= {{Controlling a Stage}} - Ss23 s182 4/4
Lesson 182 TITLE= {{Controlling a Stage}}

- Ss23 s182 4/4.

Lets see if this is the shortest lecture of all. I think we can safely say
we have covered every heading here several times.
>
I must make the point that it is not just development team working
that is visual, empirical etc but also the project managers work and
the Project Boards involvement too.
End.
TITLE= A26-Work Packages & Interface from PM to Teams - Ss23 s183
Lesson 183 TITLE= A26-Work Packages &

Interface from PM to Teams - Ss23 s183.
Here in condensed and pictorial form is what p2 says about the
CS/MP interface.
Ill preface it with an observation; When taken individually Nothing
in project management is complex but there is a lot of it and the bits
all interoperate. The result is complex in total.
>
This diagram is The interface between CS & MP it is taken from our

p2 F&P course so uses p2 vocabulary. In the revision aids Ive given
p2as mapping for a terms.
Assuming you are already p2 qualified I leave you to study the detail
as a refresher of your prince practitioner skills. If yor not, and so
want greater support let me know.
>
In my diagrams the colour key is .

Grey for business and benefits thinking or concern for outcomes,
Blue is products and outputs and management activity to provide
control,
red is technical work to develop products and yellow is the heart of
quality required in both contexts.
The light green are the information sets required to conduct the de-
velopment and management procedures. Artefacts or information
sets and events or activity sub-tasks all have vanilla p2 names and
p2a names.
The information sets and the activity sub-tasks are exhaustive and
a reliable representation of the standard p2 manual.
The whole of p2 is represented like this in our p2 F&P exam course
and our p2 job-aid and revision aid.
Perhaps you are not p2 familiar, if so and this model is too terse
without narration then let me know and Ill provide more details.
The animated version from our PRINCE2 Foundation and practi-
tioner exam preparation course revision aid referred to above is on
our website.
Visit www.logicalmodel.net/prince2exams and follow the link to
Revision and Job Aid. Within the job-Aid to go straight to the right
place for this slide use the searchbox on the right below the outline
tab and search CS to MP without the quotes.
End.

Ss23 s184.
Standard process .
Pause?.
Welcome back from reading this more wordy question?
The stem tells us we have planned a retrospective, and maybe done
it well (independent facilitator, 2hrs etc). The core of good workshop
practice is explained in section 29 on Rich Comms .
Ans>
Pause and Read the chief examiners opinions.

Is this welcome back again?.
A) says this is good because we have a facilitator. Having a

facilitator is good so that is true, but is it best? Best is what we
are asked for.
B) tells us WHY we hold the retrospective so may satisfy the stems
how well better than A).
C) is wrong, retrospectives invite a wide audience.
D) is wrong, reviews consider products, retrospective consider
process.
The choice is is B better than A?
the chief examiner thinks so. I think it is welcome that 2 answers are
clearly inappropriate. I sympathise if you think the question would
have been better after section 29 but it is focussed on retrospectives
which is the topic just covered and gives us a clue to the A vs B issue.
If the question had been about communications A may be better but
the question is about controlling a stage and its use of retrospectives
so the answer we focus on understanding behaviours trumps we
prepare and use a facilitator. Id like the distinction to be clearer
but thats why this exam is tough.
Our next topic is Stage boundaries. It is a long time since I last
challenged you to consider if you are consolidating what we cover
or rushing headlong towards the end.
IE do your own stage boundaries activities. A first pass rush and
a second pass where exam questions show weakness is a great
approach. A slow single pass with frequent look backs over recent
territory is another good approach.
End.
24 SB {{Managing a Stage
Boundary}}
TITLE= SB : 3 - Ss24 s185 Hdr {{Managing a Stage Boundary}} 0/3
Lesson 185 TITLE= SB Section Overview:

3 - Ss24 s185
Man Pg>
Stage boundaries are a major control point for prince and we use
them to assess current status and formalise authority to continue or
to stop and redeploy resources to where they would be better used.
24 SB {{Managing a Stage Boundary}} 416
Big messages from chapter 21 are:.
One) In P2A stage boundaries need little ceremony. The assessment

should not interrupt the natural flow of the development teams.
Unobtrusive assessment is made possible by the transparency of
Information Radiator-Irs, frequent releases, feedback loops and
focus on testing as we go throughout the stage. So the decision
whether to authorise continuation should be easy and obvious.
2) Stage boundaries may dove-tail with release planning but since
stages are administrative and releases are product or technical they
dont have to. In my experience with multi-team developments
the admin cycle matches the dominant technical teams journey
through major product maturity steps. Obviously results from
trialling an MVP affect release planning and viability discussions
.
And 3rd and last) A stage boundary provides the opportunity to
share learnings across the rest of the organisation .
End.
TITLE= Managing a Stage Boundary 1/3 - Ss24 s186
Lesson 186 TITLE= SB What you may Find

1 /3 - Ss24 s186

The P2A manual notes an agile project may stop by recognising
the remaining value of the backlog isnt worth the cost of further
development.
1 Viab>
This aligns it with the approach common in program management

for deciding that further development tranches are not worth the
admin cost of the controls that are in addition to operational
management.
The agile place to recognise weve done enough is at the end and
start of a release or sprint.
The {{Managing a Stage Boundary}} process is the prince place to

consolidate the information that recognises this situation. With
board approval {{Managing a Stage Boundary}} then becomes {{Clos-
ing a Project}}
2 bp1+3>
The sb process quotably establishes a firebreak that looks to the

wider picture than the development teams regular cadence of
sprint, sprint, sprint. We dont need quiet the stage boundary drama
at development team level if they are progressing through sprints to
a release and through releases that over time translate the product
backlog into delivered products and features.
3 Prg+>
The team may be progressing well but at the higher level there may
be external factors like market place change that affect benefits and
vision and mean that progress is no longer so valuable. {{Managing a
Stage Boundary}} is still where we ask the questions about progress,
a look back and about outlook, the look forward.
End.
TITLE= SB What To Do 2/3 - Ss24 s187
Lesson 187 TITLE= SB What To Do 2/3 -

Ss24 s187.

A prince project starts with the pre project work to get ready then
cycle, cycle cycle.
1 Animtn>
Each cycles loop can, infact is at some level a stage boundary. In

P2A the stage cycle is superimposed on the agile cycles. The graphic
might not do full justice to all the variations in alignment that are
possible.
Each prince cycle summarises its results in an End Stage Report-A9.
2 bp1+3>
by Reports we are not saying that a document is required. We are

saying there should be a focus on the value that has been enabled
and benefits delivered.
Also relevant will be the retrospective aspects. The P2A manual
gives a checklist of: 1) how much has been delivered, 2) what has
been released into use and 3) how are the benefits shaping up?
Im sure youll find an exam question on stage boundaries and
delivered, past tense, benefits.
3 bp4>
4) Also how is agile working for us : should we adjust the Agil-O-

Meter sliders and then what should we do about the score?
4 bp5 >
Can we exploit, do we have to improve? 5) Do we need to extend or

refine the Project Plan-A16 and Release plans and relation to sprints
within releases and .
5 bp 2>
5) Are quality and Configuration Management working well. For

example is Configuration Management coping with iterative de-
velopment so versioning and incremental development so new
features are being integrated to existing higher level aggregate
Configuration Items. Releases can only occur when quality control
through testing confirms the feature or product meets its acceptance
criteria and satisfies the definition of done.
End.
TITLE= SB How it might look 3/3 - Ss24 s188
Lesson 188 TITLE= SB How it might look

3/3 - Ss24 s188.

For my money {{Managing a Stage Boundary}} is 50% {{Initiating a
Project}} and 50% {{Closing a Project}} just in miniature. That fits
with Ken Schwabers statement that each scrum sprint is a mini
project.
{{Managing a Stage Boundary}}s conduct has many of the qualities
that {{Controlling a Stage}} and {{Managing Product Delivery}}
needs in an agile environment; the frequently quoted Inspect, then
based on what you find if it is useful then change what you do.
This is the proceed based on recent empirical evidence approach.
Also note that the most immediately compelling evidence is always
visual.
Prof. John Kotters See Feel Change as explained in The Heart

of Change is a good branch off the path for when you want to do
further research for Back@Work results.
1 Tab 21.1>
Each prince activity throughout the manuals process chapters

is mapped to the scrum artefacts and events. Unsurprisingly the
{{Managing a Stage Boundary}} set are backlogs, planning, review
and retrospective meetings. The mapping between prince and agile
is given in table 21.1 and the like all these mappings it is also in the
revision aids.
>
Lastly quotably stage boundaries merit little ceremony when the

development teams are cycling around sprints and releases because
the reviews are checking product, the retrospectives are checking
process and project outputs are being delivered.
This is what normal prince Project Assurance is expected to do
anyway and the planning meetings are looking forward to what
to proceed with and how to create it, again standard good practice.
Lets do a back@work exercise.
End.
TITLE= Back@Work Exercise-13: Retrospectives - Ss24 s189
Lesson 189 TITLE= Back@Work

Exercise-13: Retrospectives - Ss24 s189.
Hold your own retrospective.

Consider retrospectively what has worked well for you in the
exercises and in the course etc so far. Also what could be better. For
each Is good say why and for each could be better how would
we recognise better and if possible what actions would deliver it?.
Post to the forum or eMail me.
End.
25 CP {{Closing a Project}}
CP : 0of3 - Ss25 s190
Lesson 190 TITLE= CP Section Overview:

3 - Ss25 s190.
Our penultimate prince process, just {{Directing A Project}} after
this.
>
{{Closing a Project}} maps the agile vocabulary to p2 vocabulary. See

the revision aids for the cross reference otherwise we have little to
discuss.
25 CP {{Closing a Project}} 425
The 2 Key messages in tailoring {{Closing a

Project}} for P2A are:.
1) {{Closing a Project}} marks the formal end to the project and

confirmation that the projects purpose has been met but it should
be no big deal in an agile world as weve been closing out in small
ways since the first delivery.
All those small Frequent releases mean there are no or only a very
few products and features left to enter operations at project end.
Benefits are probably already flowing, maintenance capabilities
have been in operation for a long time. there is still a need in an
agile context to recognise the final project act but almost all the
traditional content has been dealt with long before now.
The project manager and Project Board can close-down the project
and move on.
2nd and last) We also need to touch on abnormal closure in this
section.
End.
TITLE= Closing a Project: What you may find cp 1/3 - Ss25 s191
Lesson 191 TITLE= Closing a Project:

What you may find - Ss25 s191.

Closing is a PRINCE2 rather than agile idea.
The P2A manual uses the phrase basic agile for a backlog and
sprint approach. In these cases the product owner may simply
concluded quote added value has become marginal. If there is
nothing more of value to do the project stops or just fades into
routine maintenance.
The P2A manuals mature agile environments will already have
formal processes in place to mark the transition from project to bau.
Recall long ago P2A told us mature agile environments might have
little to gain from P2A because they will have addressed the needs
that prince meets.
Regular handovers into operations mean the handover process is

practiced, easy and lacks drama , or is that trauma?.
The reviews, operational updates and sign-offs/acceptances happen
safely, easily, quickly.
We still need to organise the close of project celebrations that mark
psychological closure.
End.
TITLE= Closing a Project 2/3 - Ss25 s192
Lesson 192 TITLE= Closing a Project 2/3 -

Ss25 s192

Closure is probably a workshop whose agenda runs something like

these 10 points.
1) is there anything left to release if so lets also demonstrate and
review that. This is incremental and quotably not a big event, not
a big reveal nor containing any surprises
2) if acceptances to date have been very informal is there a need to
just check Customer Quality Expectation and Acceptance Criteria
are all finalised.
3) Is there anything operational and maintenance, training and
technical documentation wise outstanding? Obviously if the DoD
was well used throughout there wont be.
4) Where have we ended up against the original baseline of vision
and or Project Product Description-A21 etc that justified the project
at [ Authorize the project [ 13.4.2 ] and what can we tell the rest of
the organisation for their future Learning from Experience?
5) What is the benefits position? Perhaps by reference to the Benefits
Review Plan-A1 but definitely the Business Case-A2
6) What Follow-On-Action-Recommendations are there. Perhaps
these are backlog items so the remaining backlog is moving into
operational bau support. Some FOAR may be formally assigned .
7) What is the summary of all the retrospectives and linked is
8) What still needs to be shared as a last Lessons Report-A15
although there should have been many of these throughout the
project as inspect and adapt found things to comment upon.
9) A review of the use of Agile; quotably how well were retrospec-
tive used to address issues and risk by the project management team
and the development teams. Perhaps more widely how well did
the Agil-O-Meter provide timely and usable insight? How can it
be improved?.
10) Closure and quotably the exec stumps up for a team celebration
before the Tuckman team development stage of mourning arrives.
Consideration should be given to how to reduce the impact of team

stand-down of team members .
End project review attendees should be all relevant stakeholders
from top to bottom and pre-project to through-life plus an inde-
pendent and skilled facilitator.
Inputs will be the development teams Information Radiator-Irs and
product or features needing final demonstration.
1 ManPg>
the mapping between cp activities and agile events are all Project
review & retrospective possibly subsuming a final Release review
& retrospectives.
The artefacts are Vision, items completed and still on the backlog,
Remaining impediments and Risks and Current status as reflected
in Information Radiator-IRs .
End.
TITLE= Closing a Project 3/3 - Ss25 s193
Lesson 193 TITLE= Closing a Project 3/3 -

Ss25 s193

The above points are all now covered but the topic of premature
closure is not.
Premature closure in a fail fast and learn from a Lean Start-up
perspective is a success. We spotted an opportunity, pursued it with
experiment and drew valid conclusion to stop. The excellent use of
Manage By Exception.
Other sources of premature closure can also be healthy response to
agiles transparency bringing the right decision making information
into the open.
Premature closure in a traditional sense of stopping with nothing
to show for it is exactly what an iterative and incremental working
practice reduces or even resolves. Techniques that help are Em-

pirical forecasting, Transparency, Time boxing, the whole sprint/
release/ acceptance demonstration idea, Sprint Reviews (srw) and
Sprint Retrospectives (srpv), quick feedback, customer interaction,
spiking and early benefits all help reduce the likelihood of prema-
ture ends and the impact.
In a waterfall environment when we stop early everything is half
done, nothing is usable.
In an agile environment when we stop early half of what we want
is fully done; we have something to show for our efforts. Premature
closure is thus rather different in agile contexts.
Just Three more in-course question analyses to go then maybe you
should knuckle-down and do all of paper one and all paper two to
gauge where to focus revision.
End.
TITLE=Eqn Paper_1 Qn_34 - Ss25 s194


Ss25 s194
Standard process, read the stem decide the merit of each answer.
Welcome back?.
The stem tells us.
Its end of project and everything due is done.
Ans>
Here are the chief examiners views.

Welcome back?.
A) Its true that CP seeks to confirm acceptances have been received.
If we where agile they were secured as we went so nether a full
review nor obtaining acceptances is required.
B) In reporting project end we should look back and ask did we do
what matters? Actioning retrospectives matters, recall omitting any
event weakens the chance of success. This is something we should
do.
C) We might want a formal ceremony, for ceremonial purposes
of feeling self-satisfied but its handover will have been happening
incrementally. Probably from week 7 given the schedule we have
seen.
D) We might want procedures and design detail to meet the needs
of ops and that will be in the DoD. Unlikely the project manager
creates the technical documentation or that wed wait this long
and even if we have and the project manager does create the
document it is still a {{Managing Product Delivery}} activity rather
than {{Closing a Project}} activity .
End.
26 DP {{Directing A
Project}}
TITLE= DP : 3 - Ss26 s194 0/3
Lesson 195 TITLE= DP Section Overview:

3 - Ss26 s194.
The shortest chapter in the manual! Because agile is more about

product delivery than it is about strategic direction.
26 DP {{Directing A Project}} 434
1 manPg>
Big messages here, apart from the unspoken that agile addresses
concerns of developers without attaching itself to strategy and
cultural needs beyond what a product owner may be competent
to inject are:.
1) The biggest benefits of P2A occur when the Project Board is
actively agile. They have to be passively agile friendly at the very
least .
{{Directing A Project}} enables Manage By Exception which enables
empowerment. Empowerment is vital to enable self-organisation
which is vital for creative solution search and execution.
2) Information flows to the Project Board will be rich and regular.
Decision making may happen by attending reviews and product
demonstrations.
3) DP decision making by the Project Board may be based on
information quote pulled by them from the teams Information
Radiator-Irs .
4) Benefits will be enabled and possibly, hopefully delivered during
the project. Obviously this affects the Senior User(s) in operations.
5) Corporate Management and any Programme Management who
are project stakeholders must have some understanding of agile
[[Quick course for CoPM]]
Let me know if you would like a short course for your senior
management to create awareness.
End.
TITLE= Directing a Project 1/3 - Ss26 s195
Lesson 196 TITLE= Directing a Project 1/3

- Ss26 s195.

What you may find is interesting in the {{Directing A Project}}
context because if an agile environment has anything similar then
it is already mature and wont gain much from p2a.
In general agile sees the product owner as the sole point-of-contact
for the development teams link to the business. The product owner
may report to or liaise with a product manager or sponsor if for
example there are several development teams.
Stronger guidance might say more about the Senior User(s) on the
Project Board but the p2a manual doesnt offer more here.
End.

- Ss26 s196.
The slide, and the addition says it all .

The End, let us move on ?
prince is fundamentally Trust & empower (MbE).
The Command & Control perception is WRONG.
End.

- Ss26 s197 3/3.

This slide also looks like it says it all but
The big but is agile can be a big culture adjustment for any
senior management team. It calls for )trust, )empowerment over
interference, )transparency which includes by senior management
not just of reporting to them, also )appropriate decision making and
more. prince on its own often causes the senior management team
of blame based organisations to feel uncomfortable.
Agile moves further in the direction.
As a rule of thumb agile is going to amplify your organisations
culture. If that culture is unpleasant agile will make life tougher, if
the culture has weak or nasty elements they are goind to become
apaarent and the senior team wil have to recognise their own part
in that and duty to fix it.
Somewhat off our agenda but Ill mention the millennials work
ethos is transparency, connected, no bullshit, meritocracy not time
served.
Agile is of the millennial mindset much more than the baby
boomers
The required adjustments can be hard to create and hard to accom-
modate even by those willing to adjust.
Lets look at another exam question. Not yet our last analysis.
End.

Lesson 199 TITLE= eqn Paper_1 Qn_14 -

Ss26 s198.
Standard drill,
pause read consider etc.
The stem tells us the Project Board are embracing agile.
Ready for the chief examiners view.
ans>
Pause, read consider.

Welcome back?.
A) supports the manual with a direct quote from page 156 and I
quoted it 4 lessons ago so before we read the other answers that
looks like a good pick. Also it does not say that other forms of
information gathering are ruled out.
B) Hmm the exec should not go around the project manager to the
teams and the exec should probably only be directing the project
manager when the board doesnt speak with one voice.
C) if the Project Board is embracing agile that is good not poor.
Beside not all decision making is for exceptions.
D) No the Project Board should be up to speed at all times.
Did you also spot that magic word may. Magic flag words are
often a signal that an answer needs extra scrutiny. Other flag words
are must, all, never, not, and, sometimes, always etc. Always also
pay attention to the role referred to, the process, techniques, theme,
principle, decision, information sets. When ever they are mentioned
they modify the interpretation needed to get the right final answer.
Maybe you can devise a mnemonic that reminds you to scrutinise
questions for role-holders, principle, process, activity, product, be-

haviour, framework, technique, artefact and event.
End.
TITLE= H Agenda for Day 3
Lesson 200 TITLE= H Agenda for Day 3
The exam is later today it may be worth carrying out some admin
functions such as checking peoples ID.
27 Agile Contracts (focus
area)
TITLE= Agile Contracts (focus area) : 1 - Ss27 s201
Lesson 201 TITLE= Agile Contracts (focus

area) Section Overview : 1 - Ss27 s201.
Recall this course is targeted at the Axelos P2A exam.

I try to neither add nor subtract from what the manual says, just
comment where relevant to link to what you may already know and
what contrasts with what is commonly held outside the manuals
opinion.
27 Agile Contracts (focus area) 442
This chapters sentiments are mostly ok but its solutions lack

reflection of some well know practices. The P2A manuals author
says the chapter is here to help debate not make recommendation.
Somewhere there is a good podcast by Ken Schwaber on agile in
fixed price contract situations but my online search threw-up 7,000
hits and I couldnt track it down. I didnt review all the hits of
course.
The dept of defences 5000 series smart acquisition regulations
dont read like anything agile but they embody the needs of agile
contracts and the PMBoK has some better insight than given here :
p2a manual Table 28.1 being a particular low-point.
If you want to fry your brain you could search online for topics like
point of total assumption :it isnt exactly table 28.1 but its linked and
anything covering this topic should cover a variety of gain-share-
pain-share contract types suited to a variety of situations.
1 ManPg>
The P2A manual tells us agile and contracts dont sit happily
together. We are told that contracts are adversarial and agile is
collaborative.
P2A says a traditional contract commits a supplier to deliver a spe-
cific solution usually to a deadline and price but because projects are
uncertain, for example requirements change so someone will have
to pay when that happens. Therefore some form of contingency like
a 20% price uplift is required and that all this is counter productive in
a change friendly agile world where we need customer and supplier
to work together.
Quotablyfocussing on a contract is unlikely to help.
The chapters guidance is mostly a long-list of bullets as sum-
marised on the next slide.
The big messges are.
)Contract for outcome (this is central to dod5000),

)encourage collaboration and behaviours (also dod 5k),
)Structure for change and delivery of the highest value in a defined
timescale.
The best quote of the whole manual closes the chapter and indeed
closes the whole manual short of the appendices. It is Ultimately
the contract is a safety net not a weapon.
End.
TITLE= Agile contracts 1/1 - Ss27 s202

Lesson 202 TITLE= Agile contracts 1/1 -

Ss27 s202.

Quotably in agile Contract management what we want are con-
tracts that are conducive to agile working.
They should emphasise trust and collaboration through commit-
ment and incentives and risk sharing across known unknowns and
unknown unknowns and the means to settle who pays when things
surface in the project.
Points the P2A manual notes as typical issues are )suppliers adding
quote a contingency premium to cover uncertainty and )customers
trying to over-specify when they know little about the end result
required. This is quotably an illusion of certainty.
The official manual says Master agreements may remain relevant
but detailed SOWs need amendment to suit agile ways.
Arw>
The slides bullets relate to fix and flex. They summarise to 1)

focus on outcomes and benefits and value not outputs or work. The
right focus helps make adjustment. When agreeing definitions is
hard a middle ground is to agree such things as service levels and
throughputs.
Arw>
2) Define the required level of customer involvement including

named individuals and their roles and seek to establish the rela-
tionship needed .
Arw>
3) Use sprints and releases as the basis for defining time-based

deliveries and monitor against baselines using measures such as
delivered story points, delivered value, or achieved velocity. Now
the customer is buying time (this is exactly, for example how several
military air forces now buy flying hours instead of aircraft).
An initial deliverable might be requirements or prototype {Eh did
the manual just slip into a predictive waterfall world!}
Arw>
4) set-up break clauses to stop contracts.
Arw>
5) Link incentives to delivery on a sliding scale so if delivery falls

short the customer gets some form of credit {isnt that standard
practice in a million different very well known forms?!}. The manual
says incentives are not needed when trust is very high but are useful
if trust is only moderate. Also beware of incentives causeing people
to game the system .
Arw>
6) Define requirements at high or intermediate level so the correct

products can emerge without needing change control.
Arw>
7) Prioritise requirements by value and describe an MVP but be

careful that contract speak makes clear this is best endeavours and
not the minimum acceptable.
Arw>
8) Build requirements trading into contract concepts (DoD 5000 SA

again).
Arw>
9) add clauses to an initial skeleton contract as the required contents

is identified : quotably perhaps a minimum viable contract.
No template prescribed/ Forward thinking(!)/ StandAlone/.
End.
28 Appendix A and B
TITLE= Appendix A and B - Section Overview : 2 - Ss28 s203
Lesson 203 TITLE= Appendix A and B : 2 -

Ss28 s 203.
The big message here is the stuff on shaded backgrounds is not

examined. These two appendices are in turn; all shaded and mostly
shaded.
But there are plenty of management product and role definition
references in the manuals main body that do need attention.
For appendix A it is Ch23 which explains the tailoring of manage-
ment products as we will see in this section and for appendix B it
28 Appendix A and B 448
is that long Chapter on organization : manual Chapter 10 and our

course materials section 15
End.
TITLE= PRINCE2 Management Products and Roles 1/2 - Ss28 s204
Lesson 204 TITLE= PRINCE2 Management

Products and Roles 1/2 - Ss28 s204.
1 Apdx b>
Apdx B is the prince 9 roles all on a shaded background and

paraphrased but not tailored here plus the P2A roles that we saw
long ago (It is Slide 6/9 in the Organisation section 15 )
The roles are subject to examination.
1 A>
Appendix A mirrors the prince manual.

The templates have been paraphrased but not tailored from stan-
dard prince. Everything in Apdx A is on a shaded background. You
might refresh yourself from your p2-practitioner study. Chapter
23 advises the tailoring needs of each baseline. Almost all of it is
summary but it isnt shaded so is subject to examination.
Guidance on tailoring from Ch23 is .
Starting with baselines.

Benefits Review Plan-A1) matches frequent releases and benefits
starting during the project.
Business Case-A2) expresses the MVP and its delivery date for
exception purposes. The Business Case is written to support fix n
flex. It needs people with capability to write it.
If we are agile then Checkpoint Report-A3) are pulled from the
Information Radiator-IR but the comms strategy will set out what
is wanted.
Communications Management Strategy-A4) ensures everyone is
onboard with informal communications, daily stand-ups, models
prototypes and visualisations and the hierarchy of quote Data/
Information/ Knowledge/ Wisdom from Information Radiator-IR
at all levels from Sprint Review (srw) and Checkpoint Report-A3
or Highlight Report-A11 for the Project Board in {{Directing A
Project}}
Configuration Management Strategy-A6) must explain tools used
and match iterative and incremental working across versions. How
to handle Major Change and dynamic change must be explained.
That is baseline change versus in-team change.
Plan-A16) at all three levels of project, stage and team can be

product based and will be feature oriented, collaborative efforts
displayed less formally via lo-tech means (EG on the wall, hand-
written and movable stickies) specially at lower management levels.
Stage plans may be complimented by release plans.
Product Description-A17) are interchangeable with user story. Per-
haps starting as epics. They may be written on index cards or be
documents. User stories and Product Description-A17 are backlog
items stating Who/ What/ Why. Product Description-A17 can con-
tain more information than user story and the two can be used
together : the product is the higher level and the user story the lower
level of understanding (! Sic!! That seems contradictory to earlier
material covered).
Project Brief-A19) also can be informal. It will focus on project
definition in outcome terms that allow prioritization of scope &
quality. It will record the current Agil-O-Meter assessment and say
what agile elements will be used and why by what project roles
from delivery team up to and including Project Board roles.
Project Initiation Documentation-A20) is an evolved brief. It might
be posted to an Information Radiator-IR.
Project Product Description-A21) Probably created in a visioning
workshop and clearly displayed to all its composition section will
describe product groupings and high level Product Description-A17
or epics that quotably together make the outcome clear and precise
(Sic!) so the agile activity has a clear track to a clear end : yes after al
that disrupted environment and kuhnevin and agile means explore
the quotable is start with a clear end. Im gobsmacked, really I am.
Quality Management Strategy-A22) must be fully agile and also say
how to assure agile activity. Quality may reflect an early adopters
target market that is more tolerant of short-comings. Early adopters
is quiet a topic to drop in at this point! The quick summary is
in product development early adopters tends to value function so
much they overlook price and stability or other flaws where as
later adopters are the mass market and both very price and quality
sensitive.
Risk Management Strategy-A24) expresses that risk management is
everyones duty at all times and that agiles structure is itself a risk
response. The P2A manual sees risk management as the risk from
using agile such as poor behaviours from senior role holders rather
than say technical challenges.
Work Package-A26) is the formal interface to agile development
teams. Creation should be by collaborative negotiation perhaps
from the Sprint Planning Meeting (spm). The Work Package-A26
quotably defines a safe boundary of control or space for the team
to self-organise. Note this too; a Work Package-A26 may include
one user story or multiple releases or anything in between.
Now looking at the records Ch23 tells us.
Configuration Item Record-A5) will need to cope with iterative and

incremental working and the needs of operational stakeholders.
Daily Log-A7) is still the project managers note book.
Issue Register-A12) is probably a list on the Information Radiator-
IR.
Lessons Log-A14) reflects the continuous process improvement
ethos inherited from TPS plus Learning from Experience events like
Sprint and release Retrospectives It might be very prominent on the
Information Radiator-IR .
Quality Register-A23) and Risk Register-A25) may just be written
on the Information Radiator-IR by hand.
Note the written or stuck on the wall concept is per team. In multi
team environments there is a need to aggregate. In multi location
environments there is a need to share. A webcam is a example of
suitable sharing mechanism as is SharePoint provided its constantly
visible.
Lastly as a group Reports a3, 8, 9, 10, 11, 13, 15

and 18
Checkpoint Report-A3) will be via Information Radiator-IR and

burn-charts and the daily stand-up provided and quotably with
strong emphasis the team agrees and the dsm is not seen as a
reporting to mechanism.
End Project Report-A8) will include use of agile and the Agil-O-
Meter.
End Stage Report-A9) may be part of the release review and may
be built incrementally through the stage.
Exception Report-A10) Exceptions probably trigger an immediate
meeting to discuss options before being raised with the Project
Board. The exception is likely to be detected from something like
a burn chart showing status outside tolerances.
Highlight Report-A11) are important, may be benefit inclusive or
even focussed and may be verbal.
Issue Report-A13) and Lessons Report-A15) may be lo-tech, the
Issue Report-A13 might be produced in sprint and release reviews.
Product Status Account-A18) should be capable of supporting it-
erative developments high rate of Configuration Item Record-A5
updates.
End.
TITLE= Tailoring of the PRINCE2 Products 2/2 - Ss28 s205
Lesson 205 TITLE= Tailoring of the

PRINCE2 Products 2/2 - Ss28 s205.

I hope we are content that P2A and indeed vanilla prince does not
insist that appendix A documents are actually documents.
The information sets exist in any medium and format between dis-
cussion around an Information Radiator-IR for example to convey a
Checkpoint Report-A3 or a Highlight Report-A11 to some columns
and rows written on the Information Radiator-IR for Risk Register-
A25 and Quality Register-A23.
Mostly Configuration Item Record-A5 will want to be controlled
in a tool of some sophistication although at the level of delivered
product and features the cards of a kanban board may well be
adequate for PMs control needs when talking to the team and to
the customer.
1 Key>
The significant products are those that make the interface between
CS and MP.
Feature focus/ Agile speak.
29 Rich Comms
TITLE= Rich Comms : 3 - Ss29 s206
Lesson 206 TITLE= Rich Comms Section

Overview: 3 - Ss29 s206..
The official manual tells us that the Rich Communications chapter
26 is here to avoid the poor communications that occur all too often.
Big messages from this focus area of the official

manual are:.
We avoid poor comms by refocusing comms on peoples face-to-

face interaction with visualization over the written word. Appreci-
29 Rich Comms 456
ating where each mode of communications has strengths.

2) While the best communications are visual and face-to-face be-
tween co-located team members, where that isnt possible harness
technologies like video rather than over relying on eMail .
3) Workshops are powerful but expensive to hold and hard to get
right. They are hugely valuable when well done. Documentation
has a place for example as long term memory.
When done well workshops produce good feelings and emotions,
also high quality results quickly, create clarity, motivation, consen-
sus and ownership.
4) There is a suite of tools and techniques that are really helpful to
all forms of communication. Particularly there are skills and tools
to be explained that help run successful workshops. Really helpful
is having a competent facilitator.
Lastly 5) teams being agile will always seek to shift their commu-
nications into the channels that best suit clear and rapid communi-
cation .
End.
29 Rich Comms 457
TITLE= Rich communication : focus area 1/3 - Ss29 s207
Lesson 207 TITLE= Rich communication :

focus area 1/3 - Ss29 s207.

No method of communications is good at everything and all of them
are bad at some needs.
Communications covers transfer of the DIKW hierarchy or Data
Information Knowledge Wisdom.
Appropriate techniques are needed. Transfer may be by means
of and in roughly decreasing order of preference verbal face-to-
face and body language, visualizations such as models, figures
and pictures, video conference, phone, instant message, email and
document. Better is a mixture of them. Best communications are
face-2-face with visualisations and rich sources of information such
as team Information Radiator-IRs .
29 Rich Comms 458
Communication can be between 2 people or groups and is two way.

Effective communications needs the most appropriate time and
method. Quotable it is the projects oxygen and is always difficult to
some degree. It gets harder when there are multiple teams or many
people.
Type of communication, frequency and formality should be agreed
by the project management team including informal channels,
when records are needed or not.
The totality is the Communications Management Strategy-A4 which
also needs communicating in its own right perhaps by posting on
the Information Radiator-IR.
End.
TITLE= Rich communication 2/3 - Ss29 s208

29 Rich Comms 459
Lesson 208 TITLE= Rich communication

2/3 - Ss29 s208.

In general P2A says face-to-face is the best channel for knowledge
and information to pass between stakeholders.
Bad communications is everywhere. Good communications takes
proactive management and the will and effort of all participants to
achieve. Agile teams will try to shift communications to the best
channels often quotably meaning away from email which is sterile
versus the emotion, bonding and buy-in of a conversation.
Technology.
P2A notes a small team located in a single room working on one

product can be highly effective because communication is fast and
clear. P2A encourages moving communication traffic to the best
channels. Technology such as webcams and collaboration tools
should be used where they aid communications.
Written Word.
Documents have a place for example when teams are not collocated,
when facts need to be recorded for permanence, for allowing time
to compose careful thoughts ButPeople are not good at handling
large volume of the written word (!) large documents have many
disadvantages and anything with emotional content needs face to
face and body language or phone and tone of voice etc. Too much
written word is counter-productive.
Forget the p2a context for a second as this point transcends it all: To
lead and to manage requires not only to communicate but to ensure
others are communicating.
29 Rich Comms 460
It is easy to identify a vibrant team; it communicates quickly

through visualisations. It is harder to spot one over-reliant on eMail.
You cannot manage by eMail and attempts to do so damage even
destroy the teams heart and soul and energy.
Good communications takes organisation and planning, blended
use of media and channels. Use documentation only where nec-
essary.
And lastly for this lesson; the need for speed in agile environments
promotes the use of workshops, models.
End.
TITLE= Workshops 3/3 - Ss29 s209

29 Rich Comms 461
Lesson 209 TITLE= Workshops 3/3 - Ss29

s209.

As we come almost to the edn of all our detailed content here is one
of the most important topics. Workshops are a key technique in all
collaborative environments.
They take a lot of effort to organise and have a high cost to conduct.
You might pause and ask when have I been to startingly good and
crashingly awful workshops and what made each better or worse?.
When done well workshops can be used at any time for any purpose
Eg to estimate, to kick-off, for risk analysis, searching for designs,
problem solving etc but always consider if the result warrants the
cost.
P2A defines workshops as an activity where several people come
together to achieve an objective by harnessing interaction and
creativity. The principles of good workshop practice apply whether
the timescale is 15m, three hours or a whole day.
A workshop has; 1st) an owner or authorizing person, 2nd) at-
tendees with relevant contribution to make and 3rd) a neutral
facilitator is preferred who runs the process rather than has concern
for content or conclusion. Without a facilitator a groups efforts to
police themselves are only likely to be successful when the group
has been together for a long time. Policing requires generating a
health group dynamic, evening out contributes and ensuring the
right conduct and tone to contributions.
Workshops consolidate many peoples views discussed and shared
together with everyone visibly involved and contributing freely.
Done well workshops create synergy, involvement, understanding,
debate and buy-in.
Preparation is essential. The steps are 1) define objective to describe
29 Rich Comms 462
why the workshop will happen, 2) Identify attendees who can

achieve the goal, 3) set out the workshop steps or agenda, 4) cover
the logistics like place, time, biscuits, layout, equipment 5) pre-agree
attendees expected preparation such as background reading.
Conducting the workshop may call upon the use of techniques such
as:.
)listing Strength and weaknesses and then linking them to Opportu-
nities and threats arising or enabled, )An age old favourite is often
the 2x2 matricies such as hi-lo effort versus High-Low impact, )Rich
Pictures.
BB>
here is one from a recent engagement, )Voting such as stick the

red/green dot on the items of interest, )Gap analysis that describes
a to beand as is state and the steps from one to the other,
)Brainstorming or idea generation by free association and either
call-out or by writing sticky notes. Quotably Sticky notes may
encourage people to be concise, they can be anonymous tactile,
visual and moveable.
The p2a manual also tells us that appropriate techniques include .
)Visioning where objectives are expressed in a limited number
of words, as well as techniques such as )Edward DeBonos 6
thinking hats and )repeatedly asking Why, Why, Why. While these
9 techniques are listed they are not explained in even as much detail
as Ive given you here.
Its dead easy to search online for them though.
Lets try an exercise of a slightly different type to those we have
done so far.
End.
29 Rich Comms 463
TITLE= Exercise-14: Preparing a Workshop - Ss29 s210
Lesson 210 TITLE= Exercise-14: Preparing

a Workshop - Ss29 s210
Imagine you are preparing to run a workshop at Chestertons to

kick-off the Golden Clog project.
What preparation steps will you undertake?.
Be as complete as you can, roles, desired conclusions, steps, tech-
niques matched to steps and results etc etc.
When done check-off with the checklist in the revision aid (or
manual page 239)
Did you get the steps covered?.
Post to any of the courses sharing mechanisms as well.
And lets look at our last exam question within the sequential
exploration of the materials.
29 Rich Comms 464
End.
Lesson 211 TITLE= Paper_1 Qn_43 - Ss29

s211.
Standard stuff,
Pause, read, decide.
Welcome back.
The stem tells us a factor is affecting work to be done and wonders
how we would communicate that.
29 Rich Comms 465
Ans>
and here is the chief examiners view, pause and read then Ill
expand.
Welcome back?.
A) suggests this is an issue but we have no tolerance data to detect
a threat, the stem implies its part of planning and an agile approach
would be to be flexible.
B) Visual sounds good, decision trees are risk assessment tools but
have never been mentioned in the P2A manual so beside being
irrelevant they cant fairly be examined in a syllabus based on the
book.
C) Plausible but again why would we need the Project Board when
we have an empowered customer subject matter expert (C_SME)
and workshops are expensive do we need that expense?.
So d) seems a hot choice before we read it since all the others are
dubious D) says use our customer subject matter experts (C_SME)
well well in discussion in a meeting (cheaper option).
End.
29 Rich Comms 466

30 Apdx C: Health Check
TITLE= Apdx C: Health Check : 1 - Ss30 s213
Lesson 213 TITLE= Apdx C: Health Check

Section Overview: 1 - Ss30 s213
Im hard pushed to believe Appendix Cs advice on project health-

checks would ever underpin an exam question and it has no syllabus
reference but it is in the manual and the pages are not shaded.
The health-check chapter has some of the best quick-reference
material of the manual in it. Lets explore .
End.
30 Apdx C: Health Check 468
TITLE= Health Check (Appendix C) 1/1 - Ss30 s214
Lesson 214 TITLE= Health Check

(Appendix C) 1/1 - Ss30 s214.
The health check appendix asks questions about what the projects
behaviours, environment etc.
The questions on behaviours can be summarised as.
Collaboration, trust, no-blame, self-organisation, management sup-
port, inspect & adapt, continual improvement, transparency, focus
on value and on keep it simple, stakeholder are updated, the Project
Board are interacting, planning is collaborative, team social events
are being organised.
30 Apdx C: Health Check 469
Environment summarises as.
People are happy, enjoying, stable team, cooperating, responding to

change, engaged customer, balance, outcomes are understood, feed-
back is welcomed, learnings are shared and used, communications
is fast and wide, control is light, musts really are, every one groks
agile (search online for grok stranger first if you dont know this
work grok), releases are frequent, fix and flex understood and used,
agile events are routine, roles are clear, prince feels agile.
Process is.
Manage By Exception, Work Package-A26 interfaces working smoothly,

user stories are explored, iterative and incremental is in use, Dof-
Done and DofR are clear and applied, work is feature based and
timeboxed, the MVP is clear and useful, quality is independently
verified as we go, planning levels match our knowledge horizons,
requirements allow for flexing, Project Assurance adds value.
And lastly Techniques.
Timeboxes are fixed length, they dont stretch, information is

visible, prioritisation uses scope and quality attributes, Acceptance
Criteria are well expressed, estimating is a social event, [[Doc\ is
Lean!]], products are demod, risks are spiked, Burn charts widely
used and clear and up to date, user story start a conversation,
Kanban is more tha just a board, Workshops are used a s re-
quired, Stand-ups happen daily, Vocabulary is understood, Product
Description-A17s are flexible .
31 Apdx F & G: Transition &
Project manager guidance
TITLE= Apdx F & G: Transition & Project manager guidance : 0of2 - Ss31 s215
Lesson 215 TITLE= Apdx F & G: Transition

& Project manager guidance Section
Overview : 2 - Ss31 s215 Apdx F
Tranisation & G; Guidance to newly
Agile PMs 0/2
Again no syllabus reference.

31 Apdx F & G: Transition & Project manager guidance 471
Appendix F is only a page while G is just a few tables.

Its All good stuff. The signposts here for what is coming in this
section are.
Apdx F is guidance on transitioning to agile while G is advice to
project managers using agile under 4 or perhaps that is 9 headings.
They are 1st) Collaboration & Self-Organisation, 2nd) Transperency,
communication and exploration, 3rd) just environment and 4th)
plan monitor and control.
Lets explore.
End.
TITLE= Transitioning to Agile 1/2 - Ss31 s216

Lesson 216 TITLE= Transitioning to Agile

1/2 - Ss31 s216.
Being agile is not the goal its the enabler.

The goal is achieving organisational objectives more quickly and
with more certainty. A worthy goal. Agile may help but note that
agiles tools and techniques are aimed at product development and
maintenance so while the mindset encompasses value there is no
guidance for how to define vision or translate that to products and
behaviours.
1 BL>
Know the problem you want to solve before starting the journey.
For many people that is resolving projects that are late, and or
over cost, and or have incomplete scope and or wrong scope. This
is a project managers perspective about being better at whatever
projects the business might want : do things right territory rather
than do right things territory.
Simple project practice is start by knowing the to be state, the as
is and the journey between them Agile and kuhnevins complex
state are friendlier to the idea that we may start by knowing we
want change even if we cannot yet fully describe it. Ie the baseline
start and end points described within a Benefits Review Plan-A1
and Business Case-A2 and Plan-A16 at a level between complete
for simple projects and almost completely absent for disrupted
environments.
2 Success>
Know the definitions of success for your stakeholders : Terry Cooke-

Davis has probably written the most widely quoted academic paper
on this topic for projects and many others have noted the difference
between well run project and project delivering stakeholder value.

A project is successful when it delivers an ROI to its investor. Ben-
efits first and foremost. Its also successful when the development
team meet targets without burn-out. In a P2A environment we also
consider how well being more agile contributed.
3 Measure>
If you dont measure you dont actually know much (as I think Lord
Kelvin said).
The Agil-O-Meter provides a yardstick but will need tailoring to
local circumstances.
For each Agil-O-Meter scale we should question how did this area
help or hinder and how well did we assess it and what does that tell
us for the future?
There are perhaps three assessments : the benefits of PRINCE2 the
benefits of agile and the synergies of the two.
End.
[[BLOG there are three products of a project; physical products,
behaviours & management products of control]]
[[BLOG extending p2 upwards.]]
TITLE= Advice for a Project Manager using agile 2/2 - Ss31 s217
Lesson 217 TITLE= Advice for a Project

Manager using agile 2/2 - Ss31 s217.
This may be some of the best stuff in the manual.

Its whimsy created by the p2a development team in that they asked
themselves, now we are out of the formal book writing what advise
would we offer project managers.
It is some self referential fun. 39 user stories in the As a Project
manager responsible for using agile I would
All good value you can read as well as I so hit pause between each
table entry.
1>
hit pause while you absorb, also evaluate what your being advised
in the context of the whole journey so far.
x[[ToDo - Refer to Revision Aid]]

So what do you think? Great advice or motherhood and apple pie?.
Note in the sentiment expressed in various places but maybe not
reflected in the tables every entry that agile is not scrum, also
recognising David J Andersons observations about agile versus
lean mindsets.
Maybe many of these are not so lean as agile, eg Trust the people
to deliver, the Project Board wont overrule the development team
may be agile but lean is have roles, a tidy work-space, know the
optimal steps by analysing pre-defined procedures, avoid waste and
more that I leave you to research because its beyond the exam needs.
A good research source are our non exam Assured Outcome Deliv-
ery offerings.
End.
32 Whole Course Summary
TITLE= Course Summary - 1 - Ss32 218
Lesson 218 TITLE= Course Summary -

0of1 - Ss32 218
WOW Well done.

You have covered a massive amount of detail!.
Lets precis it. So that you can evaluate how you feel about each
topic. Recommend you make notes on a 4 tier scale running from
Got that nailed, thats ok, Not 100% and definitely needs a revisit
There has been detailed analysis of the reason the right answer was
32 Whole Course Summary 477
right in 22 exam questions and we also done 15 B@W skillbuilder

case-study segments.
0) Said hello,.
1) said we target b@w skill demonstratable with an exam pass, 2
& 3) we said we get synergy from both p2 which we use 100% and
agile which is mindset and manifesto, is iteration rather than total
progression, is behaviours, concepts and techniques and p2a defines
5 focus areas and 8 guidance points, isnt only scrum nor just IT, but
may have a basic sprint pattern of last times retrospective then spm,
daily-stand-ups, sprint review and retrospective. Mature agile adds
roadmap and strategy.
In 3) specifically we explored prince brings project control as is
needed when we tackle bigger changes that bau agile can handle
alone. Agile brings strength in managing product delivery proce-
dures via incremental iterations, We explored the p2 elements in
colletions of 7 and we saw how all 40 activities fit together. It may
pay dividends now you know all the p2a messages to revisit that
holistic procedural overview)
4) said not iron triangle, instead a fix n flex hexagon of fixed
time and cost, protected benefits and quality achievement and risk
exposure and flexible scope and quality attributes. 4 explored the
5 targets, on-time to deadlines, protect quality, embrace change,
stable teams, some requirements can be sacrificed to maintain
balance.
5) plus agile mechanics into {{Managing Product Delivery}} to
give stage timeboxes administred as kanban flow, scrum sprints or
scrumban but the key is that the agile mindsets integrates into every
aspect of running projects.
6) itemised princes principles and many agile frameworks prin-
ciples as described in appendix E, explored the p2a behaviours as
a distinct and slightly different list from the earlier list of agile
behaviours. 6) also explored p2 themes.
And then we descended into detail from 7

onwards.
7) explored getting going; su and ip and dp1, discovery or sprint

0, assessments such as cynefin which 8) explains. When situations
are disrupted best practice is no longer relevant but best practices
as practiced by experts are. To make judgement we need to ask the
right classifying questions 9) the Agil-O-Meter suggests 6 scales
One for flexibility of result to be delieverd, 2) collaborations 3)
communication 4) ability to iterate and deliver incrementally 5) The
environment and 6) everyones ability to grok agile.
10) contrasted value and benefits to explor ete business case in
agile. 11) said agile addresses risk almost as a by-product of
so many of its other behaviours so risk management becomes
more engrained and less visible 12) Addressed feedback loops and
especially Lead Startup and so Build Measure Learn, 13) explored
Product Description-A17 but as user stories from epic boulder to
ready gravel and prioritised by Moscow and ordered for delivery
sequence.
14) explore the two levels of change, dynamic and expectation or
pivot, 15) talked the huge topic or roles and org structure and
placed it all into the servant leadership context. The p2a angle is
managers are needed, multi-team means multi-product owner and
we rename them CSMEs and we always need working agreements
too.
16) takes {{Managing Product Delivery}} 17) explores what the
implications of frequent releases are. 18) revisits scrum mechanics
to explore in detail the workshop or events and the artefacts 19)
then explores David Andersons view of kanban method as an work
management regime that is an alternative to scrum. We explored
CFDs and stepped through andersons 6 general practices and ideas
such as classess of service. The 6 are )visualise, )limit wip, )manage
flow, )explicit policy, )feedback and )improve collaboratively.
20 saw planning & estimating. In estimating we touched on

planning poker and t-shirt sizing. The P2a exam doesnt require
deep treatment but our additional estimating course provides it. 21
is the progress theme; contents discusses IRs and BVCs with burn-
up and burn-downs and again deeper treatment is in our course
How To Measure And Express Project Progress Reliably. This is
a capability that relies upon 22s insights. 22 discusses how p2a
satisfies princes quality theme including a look at technical debt,
tdd and bdd, the definition of done and of ready.
23 covers {{Controlling a Stage}} and the mapping from prince
activities and management products to agile events and artefacts.
We explored in detail the cs mp interface in prince whether agile
or not. Strangle retrospectives are here rather than the more logical
placement in the 24s treatment of {{Managing a Stage Boundary}}
process or even 25s coverage of the {{Closing a Project}} process.
Winding down now in 26 we covered {{Directing A Project}}s
activities 27 gave us a little treatment of contracts in an agile
context 28 covered each of the management templates of appendix
a and touches on the roles of appendix b which we covered in
15s treatment of the organisation theme. 29 takes us through
workshops and other techniques suited to the curial nature of rich
communications 31 cover the apdx C which is questions for a
project health check 31 is Tranisitioning to agile and guidance to
agile pms and here we are at 32. Just 33 contact details and the
34 is thoughts on the exam and 35 is goodbye. Wow. So nearly
finished.
How exam ready do you feel? How real_use_ready do you feel?.
Practice paper 1 & study the Revision Aids.
For confirming exam readiness a good test is to do Practice Exam

#2.
My original recommendation was to save paper 2 till after youd

done all of paper one so now is the time to use it.
The best use is to find a quiet 150 minutes and do it as a real exam.
Keep a time record.
In the exam prep materials is a template answer sheet you can print
for the 50 questions.
For the real exam if we are meeting to do it on paper Ill take you
through all the details in class.
If you have not done all of exam paper 1 then sit down and go
through the whole paper before paper 2.
Chase down unsatisfactory results : those are wrong answers and
right answers you get by luck.
If you havent been all the way through the revision aids then do
those too.
Recall the revision aids are designed for you to read through more
than once.
1st pass tells you detail better consumed by access to reference
materials than narrations. Subsequent passes through revision aids
test if you recall the facts. At this time you must ask yourself if you
understand where items fit, where links exist etc.
Use your results to guide you on where to revisit topics and dip
into the materials a second or maybe even third time because of
doubts and errors, or where there was discovery through the exam
preparation aids or where you have some confusion.
The app based materials have a search function that helps track
down specifics.
Drop me an email p2a@logicalmodel.net if you need help. Please
include your exam voucher id to help my admin.
End.
TITLE= In summary - Ss32 s219
Lesson 219 TITLE= In summary - Ss32

s219.
I have already covered all this.

Lets precis; prince is already agile so when blended with agile
techniques and ideas the blend gives us a best of the best solution.
Pause to read the bullets and reflect.
End.
33 Contact Details
TITLE= Contact Details & Navigational Help - Ss33 s220
33 Lesson 220 TITLE= Contact Details -

Ss33 s220.
In this section, as the title says are the: Contact details for axelos
and also mine plus the course navigation notes:
See the text materials for platform specific navigation details.
End
33 Contact Details 483
TITLE= Contact - Ss33 s221
Lesson 221 TITLE= Contact - Ss33 s221.
Agile uses continuous feedback : here are your routes to feedback

to AXELOS.
Mine are there too for reference.
End.
TITLE= Who Are Logical Model Ltd? - Ss33 s222 LML
Lesson 222 TITLE= Who Are Logical

Model Ltd (LML)? - Ss33 s222.
HIDDEN SLIDE.
We would love to share the insights that leverage pmbok, prince,
agile through program and portfolio to be a holistic business gov-
ernance structure that cares for operations and copes with change
when ever change is sought or irresistibly thust upon us.
We call it new generation thinking and courses, white papers
and blog post are on our website at www.logicalmodel.net and
http://learn.logicalmodel.net .
The next slide also gives a rich set of links to courses that will take
your p2a and p2 exam knowledge up a gear to become useful in
delivering projects.
End.
TITLE= Links To Evaluation & Free for Personal Use Course Materials - Ss33
s223
Lesson 223 TITLE= Links To Evaluation &

Free for Personal Use Course Materials -
Ss33 s223.
[[New graphic]]
If you buy PM training as a corporate purchase it is likely much
of your costs are sunk without great ROI from real use of the
knowledge dispensed.
It can be because gaining skill needs more than exposure to knowl-
edge.
Exposure to knowledge works well for individuals wanting to re-
sume build by collecting certifications. Individuals with a support-
ive environment and a motivation to use the knowledge generate
great value, BUT you need all three; input knowledge, supportive
culture, individual motivation to use.
If you target value from change then you need broader coverage
that pmbok, p2 and p2a deliver. You need coverage from generating
Ideas that gain traction through to benefits harvesting.
AND.
You need the integration of tools and techniques from board-room

vision to boiler-room across development and operations.
You need appreciation of market-place cycles, annualised bud-
geting, teams and culture, product development life-cycles, total
cost of ownership and technical product realisation frameworks :
P2A is great for integrating the bottom, that is the boiler-room
level. [[PRINCE2 always was a management framework with two
interfaces, one down to development and one up to direction and
the boardroom]].
Neither p2a nor p2 looks up to the board room, to strategy, to
portfolios and care of capital in all its forms from culture and people
to intellectual property, brand and reputation, buildings, processes,
relationships and lets not leave out sources of funding.
Also note that P2A has told us a pretty one-sided version of how
to do the integration at the bottom. It has omitted all the great
guidance that didnt suit its messages, for example from rival
examining institutes. That is entirely fair from their perspective of
selling a product but there is more. Most significantly none of the
common frameworks tie it all together; neither prince nor P2A nor
PMBoK nor any other project management framework does the link
to the boardroom and benefits.
You need the psychology and sociology and the systems engineer-
ing to be integrated to the Management of Projects and of portfolios,
strategy, balanced scorecard and more. Also guidance on how to
create and socialise vision and a few more jigsaw puzzle pieces to
make the whole picture.
Outcome Delivery identifies and offers guidance on all the pieces.
We look forward to opportunity to explain the bigger picture to you
sometime.
We sell our courses like this one via

online platforms. Often B-2-C.
We also sell B-2-B as licensed courseware or as instructor led onsite

training or virtual or online blended session.
Commercial use requires a license - Available at reasonable negoti-
ated fee levels or unnegotiated fees of gbp1,000 per day or per use
which ever is the greater.
This is offer and use constitutes acceptance, Ill start action to
recover fee when Im aware of use.
On a personal note - If you can advise me of use that I am unaware
of Ill protect your anonymity & split what I recover with you 50
50.
End.
TITLE= Help! - Ss33 s224
Lesson 224 TITLE= Help! - Ss33 s224.
The value of this slide depends on your delivery platform. If it

supports links (so not the video delivery platforms but the html5
and flash based apps) then the three buttons on every slide will
move you around as noted here.
Youll also likely have a hierarchical structure of sections denoted
by thumbnails, a search function that will search within all the text
of all the lessons and all the notes.
Youll have a resources tab that links to revision aids and other
downloadable or online job aids and study aids.
And youll be able to whizz the timeline progress marker back and
forth to review, skip or otherwise jump about in the timeline.
Quiet a lot of keys also have functions : they behave differently
between windows, ios, android, mac etc so the best idea is to
experiment.
End.

34 The Exam
TITLE= The Exam - Ss34 s226
Lesson 226 TITLE= The Exam - Ss34 s226.
For online proctored exams the best source of guidance on test

taking instructions is to read the examining institutes guidance
fully and carefully. It will be sent to you as a result of booking an
exam.
Download the exam administration software in advance and expect
it will want other applications stopped and normally needs privilege
over virus software.
34 The Exam 491
Doing the exam softwares compatibility test in advance reduces

stress when you dont want distractions. A locally connected printer
is also a good idea.
If you havent already booked an exam
there is one further piece of advice Ill offer.

Without daily use then the speed at which you studied will be about
equal to the rate at which you forget.
If you consumed this content avariciously in a few days it will be
quiet short lived so do the exam soon and keep up the revision aids
in the interim.
If you have yet to complete all 100 mock exam questions then now
is a great time to work methodically through paper 1 and paper 2.
For paper 1 many questions will be familiar so you should recal the
rationale by which to identify the best answer. Paper 2 allows you
to test that comprehension and identifies for you where to focus a
targeted review on weak spots.
If you have taken a measured journey with lots of stops for re-
flection and re-drawing & re-writing or rerecording notes then the
likihood is more will stick for longer. Maybe you have done paper
1 & 2 already. Doing them again and the revision aid questions is
still helpful as exam prep.
In the end the two best ways to make it all stick

are to use it and to teach it.
End.
35 End of slide deck
End of slide deck - Ss 35 227
Lesson 227 TITLE= End of slide deck

Section Overview - Ss 35 227.
Thank you for investing time and effort with us.

I sure if you stuck it to here youve found the training useful for the
exam and beyond.
Throughout I have been aware of the ways to extend, refine and
enhance the P2A view.
35 End of slide deck 493
As we covered right at the start that is not compatible with an exam

focus.
Perhaps more important is that if you want to master one of these,
Jet (CC by details on photo)
you first have to master one of these.
Trainer plane (CC by details on photo)
axelos lessons
These slide from axelos are provided by them for atos to deliver
exam candidates.
Post exam you have credential but also concepts, vocabulary and
process model to join much more enabling training.
Maybe take a breather but your next capability development steps
probably include rolling-out to embed what we have covered in
your team and organisation.
After a breather consider our non-exam training that enhances
your proposal to your boss for a pay-rise or supports your bids to
By Rob Shenk from Great Falls, VA, USA (F-22 RaptorUploaded by Diaa abdelmoneim)
[],
By RuthAS (Own work) [],
customers to win contracts.

Those realworld courses build on these foundations, they also
corrects some p2a short-sightedness & add many great insights
beyond p2as contents .
I hope we have proved through this course our ability to help
with both the immediate roll-out challenges and the longer term
transition to master practitioner.
If you would like help with rolling-out to embed within your
organisation then please let us know.
When you feel ready to turn examined basics into nuanced reality
come back to http://learn.logicalmodel.net to look at what else we
offer that is off the exam track. We have an expanding collection of
our in-class training moving to mobile & eLearning.
The old adage applies; tell your friends what you liked and tell us
what you didnt so that we can fix it.
Please give us an excellent review or if you think that unjustified
please tell us why so we can address the shortcoming for you and
remedy it for future students.
Please note our hope of excellence is not claim of perfection
although perfection is always our target.
Some platforms where our materials are available run affiliate
schemes through which your introductions earn you a commission
: contact us for details. Likewise if you would like to translate
materials to your native language :
I wish you success, health and happiness in all your future endeav-
ours.
Best regards Simon.
End.
Who Are Logical Model Ltd (LML)? - Ss 228
Lesson 228 TITLE= Who Are Logical

Model Ltd (LML)? - Ss 228.
Logical Model Ltd are a thought leader in deliver of business change

methods.
Every projects true target is an altered future_state_Businesss_-
As_Usual also know as Outcome Delivery and based in behaviours
.
The aims of outcome delivery are to create benefits. Project man-
agement is a necessary subset but it is an incomplete toolkit. Scrum
and kanban are excellent product development regimes but they
start too late in the investment cycle for strategy and preservation
of capital. They finish too early and dont rise high enough in the
organisations overall melding of strategy and execution to deliver
rather than just help enable benefits.
This P2A course has equipped you to begin a discussion about how
to capitalise on P2A for business benefits.
How many times did we say that P2A focuses on bau and benefits
but when did following axelos guidance offer any advice, proce-
dure, tools or techniques to contrast strategic options, to define
goals and benefits, track benefits or enhance benefits?.
Where have you ever seen guidance in business terms rather than
project terms?.
That is what we LML add through focussing on outcome delivery.
We are members of the Outcome Delivery Network
Outcome Delivery Network
We dont like to call our chosen topic project management because

It isnt just PM it is Investment Management or Benefits Realisa-
tion or Management of Portfolios or Value Management or truly
Care of Capital in all forms from money to human and cultural
capital.
Culture trumps strategy.
FINAL, Final, final End.
phewwwwwwww.

Prince2agile Preview

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Prince2agile Preview

Transféré par

Droits d'auteur :

Formats disponibles

Passing the Prince2agile

Practitioner Exam at Your First

0 Hello and a very warm welcome. . . . . . . . . . . . . . 1

1 Introduction & Context . . . . . . . . . . . . . . . . . . 15

2 Overview the basics. . . . . . . . . . . . . . . . . . . . . 39

Lesson 16 TITLE= The Agile Manifesto : 4/10 - Ss2 s16 . 52

3 Tailoring prince for agile. . . . . . . . . . . . . . . . . . 73

5 Where agile plugs into PRINCE2. . . . . . . . . . . . 132

Congratulate your self!. . . . . . . . . . . . . . . . . . . 143

6 Principles & P2A Behaviours & PRINCE2 Themes. . . . 144

7 SU & IP {{Starting up a Project}} and the Initiation

8 Cynefin : (Pronounced Kuhnevin). . . . . . . . . . . . . 177

Lesson 73 TITLE= Case Study: Classify Chestertons

9 The Agilometer . . . . . . . . . . . . . . . . . . . . . . . 188

10 Business Case Theme . . . . . . . . . . . . . . . . . . . 197

11 The Risk Theme . . . . . . . . . . . . . . . . . . . . . . 212

12 Feedback & Lean Start-Up . . . . . . . . . . . . . . . . 219

Lesson 92 TITLE= Back@WorkSkill Builder CaseS-

13 Requirements (focus area) user stories & prioritisation 228

14 The Change theme . . . . . . . . . . . . . . . . . . . . 247

15 Organization theme & servant leadership . . . . . . . 257

Lesson 110 TITLE= Organisation : general view of agile

16 MP {{Managing Product Delivery}} . . . . . . . . . . . 286

17 Frequent Releases (focus area) . . . . . . . . . . . . . 298

Lesson 130 TITLE= Frequent Releases : focus area 1/2 -

18 Scrum theory & practice & artefacts and events . . . 308

19 Kanban Method . . . . . . . . . . . . . . . . . . . . . . 328

Lesson 150 TITLE= The 6 general practices of the Kan-

20 Plans theme & estimating . . . . . . . . . . . . . . . . 358

21 Progress theme . . . . . . . . . . . . . . . . . . . . . . 370

22 Quality theme . . . . . . . . . . . . . . . . . . . . . . . 385

Lesson 171 TITLE= Quality theme Section Overview:

23 CS {{Controlling a Stage}} . . . . . . . . . . . . . . . . 400

24 SB {{Managing a Stage Boundary}} . . . . . . . . . . . 415

25 CP {{Closing a Project}} . . . . . . . . . . . . . . . . . 424

Lesson 191 TITLE= Closing a Project: What you may

26 DP {{Directing A Project}} . . . . . . . . . . . . . . . . 433

27 Agile Contracts (focus area) . . . . . . . . . . . . . . . 441

28 Appendix A and B . . . . . . . . . . . . . . . . . . . . 447

29 Rich Comms . . . . . . . . . . . . . . . . . . . . . . . . 455

Lesson 212 TITLE= Online content only. . . . . . . . . . 466

30 Apdx C: Health Check . . . . . . . . . . . . . . . . . . 467

31 Apdx F & G: Transition & Project manager guidance . 470

32 Whole Course Summary . . . . . . . . . . . . . . . . . 476

33 Contact Details . . . . . . . . . . . . . . . . . . . . . . 482

34 The Exam . . . . . . . . . . . . . . . . . . . . . . . . . 490

If you havent already booked an exam . . . . . . . . 491

35 End of slide deck . . . . . . . . . . . . . . . . . . . . . 492

Lesson 1 Your Journey with Presenter:

TITLE= Our Topic: PRINCE2 Agile

Lesson 2 TITLE= Our Topic: PRINCE2

prince is a project control structure. It proudly declares that it

In text PRINCE2 and prince2agile peppered across a page is

P2A follows princes 7 principals and tailors the application of the 7

The Official PRINCE2Agile Manual.

The exam is wholly based on axelos official manual whose contents

Passing the exam is often a differentiator for selection in job

Dont forget I fully support your journey to exam success. Visit

For most people an online exam, perhaps taken at home and

Our uk local rate number is +44 (0)84 52 57 57 07. Also contact us if

Course Media Choices and Their Navigation.

TITLE= Media, Navigation & SubSections - Ss0 s3

Lesson 3 TITLE= Navigation &

course self-contained. Free previews can access less than students of