handouts
DESCRIPTION
TRANSCRIPT
We are very happy to have you with us at AgileIsrael 2013, our sixth Agile conference. AgileIsrael is the major Agile event of the year in Israel, and we are happy to host it. This year we are focusing on "hands-on”, which means that every session is practical and immediately usable after the conference. We filled the conference with many interesting sessions and case studies, and have brought 5 international speakers to give you a unique experience. In the spirit of hands-on, some of our speakers have joined us in producing this booklet which includes handouts containing tips on various topics of Agile from meeting facilitation to discovering pains. We hope this booklet is useful to you and helps you leverage the ideas you got today in the near future. Please feel free to share it with your fellow workers. We will be happy to hear your feedback and assist your Agile journey, please write us at: [email protected]. Thank you for being part of this conference and see you all at AgileIsrael2014! Inbar Oren, conference Chair AgileSparks
Feature Teams – 10 guidelines and tips to make it happen right For those who have already been convinced about the need for their organization to migrate to feature teams. Here are some practical considerations and tips to help make the transition effective and successful. 1. Define the domain – Define the orientation of the team: specific line of business, specific product, specific strategic goals to achieve, or a squad team that can achieve anything. 2. Maximize autonomy - Align the team structure, processes, tools and environments with the teams’ goals so as to enable them achieve maximum results autonomously. 3. With empowerment comes ownership – Team should be responsible for end to end success or failure and have continuous improvement cycles to make the team perform better. 4. Invest in the technical landscape – Assign tech owners to each component, subsystem or knowledge domain. 5%-20% of their time will be allocated to the well being of the component (scale, stability, architecture, coding standards etc), enabling efficient and scalable development (test and deployment automation, etc) and knowledge transfer.
5. Remember the matrix – Although we push for autonomy of the team, we need a matrix of collaboration that crosses teams’ boundaries: PMs, Team leaders, Experts, QA etc. Establish forums and platforms for knowledge sharing AND relevant decision making. 6. Think architecture – Architects should be involved in major development efforts. Make sure they have free communication channels to PMs. Architects should enable, educate, review and promote system well being. 7. Delivery automation included – Each team needs to deliver. Delivery automation should be part of the team skills, supported if needed by external specific team (e.g. QA automation, deployment automation) 8. System support and stability - Based on the system maturity and size choose one of the two models for handling system support cases: All support cases to be handled in one specific team, or through rotation between teams. The more mature and larger the system – rotate it. 9. Dev-Ops collaboration culture – Feature teams boost the power of each team to make decisions. These might affect system stability. Be aware of this. Establish open communication and improvements cycles between dev and ops. Educate for collaboration.
10. Transition to feature teams - Execute as a step function. Make all the right preparations, execute, and be prepared for a few months stabilization period with lower efficiency. Mind: Treat transitioning to feature teams on one hand with great determination but keep reflecting and adapting to your own needs.
Pla
nnin
g m
eeti
ng -
9 st
eps
for
havi
ng a
n ef
fici
ent p
lann
ing
mee
ting
1. C
apac
ity
(1 m
inut
e) -
Sett
ing
the
time
(Day
s/ho
urs)
for e
ach
team
mem
ber.
Each
team
mem
ber p
roje
cts t
he a
mou
nt o
f tim
e s/
he
is g
oing
to in
vest
in th
e sp
rint
. It i
s im
port
ant t
hat t
he te
am m
embe
r will
giv
e th
e ca
paci
ty. F
rom
the
100%
cap
acity
the
team
mem
ber
shou
ld o
mit
pers
onal
tim
e (e
.g. v
acat
ion,
cou
rses
, tak
ing
part
in a
noth
er te
am),
com
pany
’s tim
e (e
.g. A
ll ha
nds m
eetin
gs, f
un d
ay) a
nd
Scru
m ti
me
(e.g
. end
of s
prin
ts m
eetin
gs).
2. R
elea
se v
isio
n (5
min
utes
) - T
he p
rodu
ct o
wne
r bri
efly
des
crib
es to
the
team
wha
t is h
appe
ning
with
the
rele
ase,
new
tren
ds, n
ew
cont
ent a
nd w
hat i
s the
focu
s of t
he re
leas
e.
3. S
prin
t vis
ion
(5 m
inut
es) -
The
Pro
duct
ow
ner b
rief
ly d
escr
ibes
to th
e te
am w
hat i
s the
vis
ion
of th
e sp
rint
, e.g
. wha
t is t
he
“sto
ry” o
f the
spri
nt.
4. S
oft e
stim
atio
n (5
min
utes
) - B
ased
on
the
abov
e an
d th
e "s
niffi
ng e
ra",
the
team
with
the
prod
uct o
wne
r, br
iefly
, dis
cuss
wha
t us
er st
orie
s see
m re
ason
able
for t
he te
am to
do
with
in th
e up
com
ing
spri
nt.
5. T
eam
Est
imat
ion
gam
e (6
0 m
inut
es) -
The
team
star
ts to
“dig
est”
eac
h an
d ev
ery
user
stor
y ac
cord
ing
to th
eir p
rior
ity a
nd se
t an
est
imat
e fo
r it.
The
estim
atio
n is
bei
ng d
one
for t
he e
ntir
e us
er st
ory.
The
team
als
o de
cide
s who
will
do
wha
t. Th
e en
tire
team
pa
rtic
ipat
es w
ith e
ach
estim
atio
n. Y
es, E
VER
YBO
DY!
It e
nds w
hen
the
capa
city
is e
xhau
sted
as f
ar a
s the
abi
lity
to fi
nish
a w
hole
use
r st
ory
(a c
omm
on m
ista
ke is
to s
tart
a u
ser s
tory
onl
y be
caus
e yo
u ha
ve a
cod
ing
capa
city
with
no
QA
capa
city
. Thi
s will
lead
to
inve
ntor
y w
aste
) 6.
Har
d E
stim
atio
n (1
0 m
inut
es) -
The
team
com
mun
icat
es to
the
prod
uct o
wne
r wha
t are
the
user
stor
ies t
hat t
he te
am c
an
com
mit
for t
he in
com
ing
spri
nt a
nd w
hat a
re th
e us
er st
orie
s tha
t the
team
MAY
del
iver
in c
ase
the
com
mitt
ed u
ser s
tori
es w
ill b
e co
mpl
eted
a h
ead
of ti
me.
Thi
s lis
t will
be
nam
ed “s
prin
t bac
klog
” 7.
Men
u (1
0 m
inut
es) -
Sim
ilar t
o a
rest
aura
nt m
enu,
the
team
cre
ates
a m
enu
of it
ems t
hat t
he te
am is
goi
ng to
pre
sent
at t
he e
nd o
f th
e sp
rint
. As o
ppos
ed to
a te
chni
cal l
angu
age
of a
use
r sto
ry, t
his m
enu
in w
ritt
en in
PO
lang
uage
. Thi
s men
u sh
ould
be
visi
ble
to a
ll th
roug
h th
e en
tire
spri
nt a
nd is
the
agen
da fo
r the
revi
ew m
eetin
g.
8. V
isib
ilit
y (1
0 m
inut
es) -
Cre
ate
the
visi
bilit
y ch
art f
or th
e sp
rint
that
incl
udes
all
of th
e ab
ove
and
will
be
upda
ted
only
by
the
team
bu
t vis
ible
to th
e en
tire
wor
ld. B
est p
ract
ice
is to
pla
ce th
e vi
sibi
lity
char
t in
a m
ajor
"hig
hway
" of t
he c
ompa
ny fo
r inc
reas
ed v
isib
ility
. 9.
Dai
ly -
Sett
ing
the
time
and
loca
tion
of th
e da
ily m
eetin
g (w
hich
is a
ctua
lly th
e da
ily p
lann
ing
of th
e te
am).
It is
impo
rtan
t tha
t the
te
am w
ill se
t it a
nd n
o on
e el
se (e
.g. t
he m
anag
er)
For
thos
e w
ho w
ant
to k
now
wha
t ar
e th
e st
eps
to a
2 h
ours
pla
nnin
g m
eeti
ng, h
ere
they
are
. N
ote
that
it w
ill t
ake
arou
nd 5
spr
ints
in o
rder
to
get
into
thi
s ti
mef
ram
e th
us it
is p
erfe
ctly
no
rmal
to
have
a 6
hou
rs p
lann
ing
mee
ting
in t
he fi
rst
tim
e.
tips for ATDD implementation –QA Transition to Agile testing
Tips for QA team transition to ATDD: Promote the new tester role.
o From bug hunter to “Represent the PO within the team” o QA and developers understand Agile approach for testing (whole team
approach, ATDD, automation pyramid) Train early the entire team (also development) on ATDD and how to write good BDD
o Understanding the framework (Text<->code) is a must! It is not so difficult to learn to write code automation
o One week Java training is enough to start o But, Automation champion to support the QA team and ensure
test infrastructure is a must ! o Need more focus on software engineering and refactoring (for the automation
code) o Ensure Scrum team support shared ownership concept accepted by the team
Read the Cucumber book ! be part of the community !
Tips for choosing ATDD tool Expressing expectations in a language and format that allow collaboration among the
whole team (PO/Dev/QA) Required minimum of test code (allow re-use, auto-completion) Test code written in the team “native” language (so developers can also develop and
support the QA) Play nicely with source control systems and continuous integration Pluggable to support a variety of interfaces (e.g. UI automation) Can become a product spec. (documentation tool) Active community
Tips for BDD development process Describe ALL expected business behavior with BDD , decide later what will be tested in
which level (UI, Manual, AT) Write Acceptance test (feature file) for MMF, Write user stories DoD as scenarios within
the MMF feature file Ensure BDD is readable, written in business language (not implementation) , as possible
use tables for the data description Integrate ATDD into the release process
o PO writes User Story description in the backlog management tool (it is rare to find PO that willing to describe it in BDD format )
o QA translate it to BDD (after team sniffing, before iteration planning) o PO review the BDD with QA (and if possible with development representative
from the team) o BDD is a condition for “Ready Story”, might be a step in the release Kanban flow
Team commit to the BDD!!! Not to the user story description. When team start working on the story:
o Developer and QA review together the BDD and agree: What to test, by whom and how to automate it (unit/acceptance)
o Developer develop first the “API contract” (so automation can run and fail), QA develops the automation (code review with developer)
5 Tips on how to implement electronic project management tool
Begin with physical task board Encourage: team work, commitment and trust through transparency,
visualization and activeness Make the board the team’s tool in the daily routine – use it to facilitate
discussions and meetings such as dailies, planning and retrospectives Only when the team shows active use….
Start using the electronic tool in the team Use big screens for visualizing the task board Facilitate the daily meetings Team member ownership on items on the board – they create\update the
items
Continue using sticky notes to facilitate discussions\decision making In order to be fully present in the meeting and focus on having an effective
meeting input the results of the meeting after the meeting to the tool (not the manager)
Visualize project progress Use Agile reports to visualize project progress, preferably Burn-up chart
and cumulative flow diagram Management feels thing are under control and allows the team to work Connects the team to the big picture and creates common language with
management
Visualize Improvement Choose 2 key KPI’s and use them on the board Fuel motivation by visualizing and acknowledging improvement in the
selected KPI’s
Update\Change the KPI’s according to needs periodically
Fr
om P
ains
to P
ract
ices
Inst
ruct
ions
:
1.
Star
t with
why
you
wan
t to
chan
ge (i
.e. w
hy a
re y
ou p
ursu
ing
Agile
?)
2.
Id
entif
y to
p 1-
2 pa
ins.
W
hich
Agi
le p
rinci
ples
wor
k on
im
prov
ing
thes
e pa
ins?
3.
For e
ach
of th
e Ag
ile p
rinci
ples
id
entif
ied
abov
e, w
hich
Agi
le
best
pra
ctic
es fo
cus o
n th
ese
prin
cipl
es?
4.
Se
lect
thos
e pr
actic
es y
ou’d
like
to
pur
sue.
5.
Rins
e an
d re
peat
.
* M
anag
e th
e ch
ange
as a
n Ag
ile
proj
ect.
** A
lway
s rem
embe
r why
you
are
pu
rsui
ng th
e ch
ange
s.
Individuals and Interactions: 10 Lessons from Putting People Before Process
In the last 15 years, many Agile teams and organizations have been valuing individuals and interactions
over processes and tools. Here are their top 10 lessons.
1. People are not “resources.” Respecting them as individuals opens the door to the amazingpotential of intrinsic motivation, self-organization, collaboration, and positive team synergy.
2. Focus keeps you going. By limiting individual multi-tasking and the team’s overall work inprogress, and by having all necessary participants collaborate, teams can finish and deliver workearlier, which motivates and energizes them.
3. Nurture the joy of delivering value. Changing one’s role from “building software” to“delighting customers with outstanding value” creates a virtuous cycle of engagement andsuccess.
4. Take small, safe, feedback-rich steps. Approaching every activity this way reduces the fearand mental weight of large or unfounded moves, so teams can focus on doing the right thing.
5. A standardized environment is for standard people. Proximity among colleagues increasescommunication and collaboration, as well as the sense of belonging and recognition that peoplecrave.
6. Collaboration requires a suitable social environment. In collaborative teams, emotionalintelligence and social skills must outweigh technical skill so people want to be members andhave each other’s back.
7. High-performance teams need investment. Most teams need support to reach highperformance and stay there: facilitation, leadership, championing, protection, coaching.
8. Manage less, lead more when the situation allows self-organization, empowerment(autonomy), and collaboration to flourish.
9. Lead collaboratively. Collaboration doesn’t just improve results through reduced mistakes andsimpler solutions. Collaboration mitigates the risk of employing human beings to do work.
10. Human conduct trumps “best practices.” Practices must be tailored to context: “Will peopleuse them?” and “Will they do them well?” Let the team choose, to increase buy-in.
Visit us at: www.TheHumanSideOfAgile.com and www.3PVantage.com
© 2013 Gil Broza Email: [email protected]
How Technically Agile Is Your Team? (Self-Assessment Tool)
Visit us at: www.TheHumanSideOfAgile.com and www.3PVantage.com
© 2013 Gil Broza Email: [email protected]
W W W . A G I L E S P A R K S . C O M
The 10 commandments for the facilitator
1. Do you have strong opinions on the meeting subject / agenda / conflict / interest?
Maybe you should ask someone else to help you by participating in the meeting to representing this opinion so that you can remain neutral…
2. Prepare… who is attending? Who really needs to be? Who shouldn’t be?
3. Is the team willing to accept a new way of work? Are they prepared to take it from you? Today?
4. Are the meeting participants, boundaries, constraints clear? Make sure time limits, space, time-of-day, etc…
5. Oh – are all the participants coming? Are they ready? Did they prepare last meeting's action items?
6. Meeting goals and agenda, are they clear to everybody? Including you? State them to agree and start the meeting. Is anybody taking notes?
7. Is there enough time? Do less, but close issues…
8. Is everybody with you during the discussion? Are you helping people understand each other? Are all the voices heard? Is anyone too dominant?
9. Accumulate action items. State them clearly when they show up, and make sure they are visible. Action item – what, who, by when…
10. Decisions? Is the team committing, or is just the manager making decisions? Who will really carry out the action items?
For consulting about the transition to efficient meetings, visit www.agilesparks.com