This is my presentation in Scrum Gathering London 2018.

1. 1 Agile Training and Coaching - © 2018 Petri Heiramo, Agilecraft Ltd, Finland
Behavioral Hypothesis of
Team Formation
Scrum Gathering London, 2018
Petri Heiramo, CST, Agilecraft Ltd

2. Classic Explanation of Behavior
Images from Wikipedia

3. Classic Explanation of Behavior
vs

4. Kurt Lewin
Principles of Topological
Psychology, 1936
B = ƒ(P, E)
Image from Wikipedia
B = Behavior, P = Personality, E = Environment

5. Let’s
Test
This

6. Please stand up, if…
1. You regularly eat candy and chocolate
before lunch
2. You believe it’s healthy and a good idea
to eat candy and chocolate before lunch
3. You have taken candies or chocolate
from the tables and chairs

7. I assume you know
the following already…

8. Workgroup Team
“Sum of its parts” ”We need synergies”
Individual goals Shared goals
Individual responsibility Shared responsibility
Centralized and assigned
leadership
Emergent leadership (although
formal leader exists)
Individual behaviors Shared behaviors
I can “win” even if you “lose”
Everyone “wins” or “loses”
together

9. 9 Agile Training and Coaching - © 2018 Petri Heiramo, Agilecraft Ltd, Finland
Communication Looks Like This
Workgroup Team

10. Teams
>Σ"
Workgroups
=Σ"
Valuecreationability
Time
Low risk
Cognitively easy
Low emotional investment
High risk
Cognitively challenging
High emotional investment

11. Tuckman Model
Forming – come together and accept
the goal, avoidance of conflict
Storming – disagreements voiced
and argued, no agreement
Norming – behavioral alignment and
continuous improvement
Performing – very effective
operation and exceptional value
delivery
Forming
Storm
ing
Norming
Perform
ing

12. Ok, then…

13. If( TeamFormation == Behavior,
LewinsLaw == True ) {
if (X, Y, Z,…) {
Team.Form.Begin
}
}

14. Google: Project Aristotle
Psychological safety Can we take risks on this team without feeling
insecure or embarrassed?
Dependability Can we count on each other to do high quality
work on time?
Structure & clarity Are goals, roles, and execution plans on our
team clear?
Meaning of work Are we working on something that is
personally important for each of us?
Impact of work Do we fundamentally believe that the work
we’re doing matters?

15. You First
Discuss with your neighbor,
what conditions do you perceive as
critical for team formation to begin?

16. There are 3 critical qualities
that initiate or prevent team
formation.
I deeply
suspect that…

17. Shared Voluntary Goal
Everyone knows the Vision
• What, why, who, when, how, …
Can be external or internal goal
Accepted personally
by everyone
• Worth striving for

18. Goal Not Achievable Alone
If achievable alone, why spend
the effort to team up?
Goal must integrate the work of all team members
Focus on end result,
not on components or activities

19. Appropriate Challenge
Too easy à no need for teamwork
Too hard à people give up Frustration
Boredom
Challenge Skill
Flow
Teams also enter “flow”,
though it looks a little
different

20. Flow
What Often Happens: A Better Approach:
Flow
Frustration
Boredom
Challenge
Skill
Frustration
Boredom
Challenge
Skill
Apathy

21. 1) SharedVoluntaryGoal
2)GoalNotAchievableAlone
3) SufficientChallenge

22. Speed, Ease
Co-location
Development framework Variety
Personalities
Culture
Coaching
Knowledge
Tools

23. Take a moment, and…
• Think of the project or product team you are part of now (or
working with)
• Write down (2 min)
• What is your team’s goal? Is it voluntarily embraced by everyone?
• Do team members need each other to reach that goal?
• Is the goal appropriately challenging?
• If you feel that some condition is not present, note that down, too
• Discuss your notes with your neighbour (4 min)
• See if you can help each other improve/clarify the conditions

24. As a coach…
1. Ensure that the three conditions are true
2. Use catalysts to speed up and ease the natural
process
3. Profit

25. We can take this
hypothesis further.

26. An example of a possible state map for a character in a strategy game.
http://flylib.com/books/en/4.70.1.87/1/

27. Forming Storming Norming Performinga, b, c, … h, i, j, … o, p, r, …
l, m, n, … u, v, w, …
å, ä, ö, … x, y, z, …
s, t, u, …
e, f, g, …

28. Conditions for AdvancementForming
storming
• Safety
• Courage
And the 3
Conditions,
of course

29. Conditions for Advancementstorming
norming
• Mechanism to decide
together
• Commitment to decisions
• Clear boundaries
• Trust and respect

30. Conditions for Advancementnorming
performing
• Ambition / Relentless
Improvement
• Discipline
• Personal competence
• Embracing variety
• Stable team

31. Conditions for MaintenanceperForming
• Continued big challenges
• Often driven by team itself
• Appropriate change
• Scrum, Inc.: 20% change
• Keep wolves at bay

32. In the behavioral hypothesis, we have:
3 Critical Conditions
Catalysts
Conditions of Advancement

33. One Last Thing…

34. Intrinsic motivation is driven by:
Autonomy
Mastery
Purpose
(assuming that respect is taken care of)

35. Let’s Compare
Motivation
Autonomy
Mastery
Purpose
Team Formation
Shared Voluntary Goal
No-one Can Win Alone
Sufficient Challenge

36. Summary
If the hypothesis is correct,
trying to make teams jell is useless.
Create right conditions, and
people will start to self-form.

37. AVOID
… trying to convince people
… using trickery or sleight-of-
mind (e.g. bonuses,
dishonesty, flattery, made-up
deadlines)
… applying pressure
EMBRACE
… a meaningful shared goal
… techniques that
bring people together
… open-ended challenges
… coaching through the stages

38. I invite you to test the hypothesis,
and send your feedback to
Petri Heiramo
Agile Trainer & Coach, CST
Agilecraft Oy
petri.heiramo@agilecraft.fi
Kiitos!

39. Practices to help foster an
environment with the
3 Critical Criteria
Additional
Content!

40. Shared Vision Workshop
The PO and Development Team
collaboratively clarify that both
have the same Vision in their
minds.
Remember to involve all Team
members!
Make Team do it – PO consults.
Focus on next release only
Key things to remember:
• Only allow 3-4 critical features /
elements
• Fun is better than not fun
• Visual trumps text
• Iterate a few times

41. Internal Goal
Sometimes the external goal is
not sufficient for team formation
Ø E.g. not challenging enough, or not
open-ended enough
The team can self-select a twist
that adds challenge
Ø E.g. faster delivery, using new or
better techniques, higher quality,
as a team, one hand behind
back,…
Key things to remember:
• Safe to fail! Don’t tell others J
• Ok, maybe the PO should know

42. Increase Challenge over Time
Don’t give the Team the full
challenge at first
Start with a simpler, smaller part,
then expand
Ways to increase challenge
Ø Add new features over time
Ø Make challenges more open-ended
Ø Experiment with new tech, etc.
Ø Learn new techniques
Ø Increase quality
Key things to remember:
• Keep the big picture in mind
• Use proper Agile development
techniques
• Requires PO’s understanding and
engagement

43. Increase Challenge over Time
Don’t give the Team the full
challenge at first
Start with a simpler, smaller part,
then expand
Ways to increase challenge
Ø Add new features over time
Ø Make challenges more open-ended
Ø Experiment with new tech, etc.
Ø Learn new techniques
Ø Increase quality
Key things to remember:
• Keep the big picture in mind
• Use proper Agile development
techniques
• Requires PO’s understanding and
engagement

44. Collaborative User Story Writing
User stories are reminders of
conversations had and to be had
PO and Team write the stories
together
Focus on bigger picture over too
much detail
Ø Cover all users and features with at
least one story each
Recommendations:
• Don’t split up the group to
subgroups
• Use physical tools, like index cards
• Print out any materials that contain
references or prior work
• Reserve about 60-90 minutes
• Aim to 30-40 stories

45. Team Writes Acceptance Criteria
Request that the Team writes the
acceptance criteria for the
stories
Forces Team to study the
features together
Confirms their understanding to
PO
Recommendations:
• Keep PO close by
• Use iteratively in refinement
meetings
• PO needs to approve the criteria
and should clarify any criteria the
Team “did not get right”

46. Story-Level Design
For each user story going into a
Sprint, create a ”one-page”
shared design
Ø User flow and design
Ø Technical design
Ø Database changes
Ø Testing
Describes what the system will
look like after the story is done
Recommendations:
• Should only take 15 minutes for
most stories
• Use flipcharts or whiteboards
• Whole team participates (or at least
all disciplines)
• Can be done either in refinement or
Sprint Planning
• Extract tasks from this design

47. No Individual Goals
Avoid anything that would create
individual goals over shared goals
For example:
Ø No names on stories
Ø Don’t assign tasks in Sprint
Planning
Ø Only allow names in Daily Scrum
Use real user stories for Product
Backlog items
Recommendations:
• If you have to put an assignment on
a story, use “Team”
• Face magnets can help (also
enforces WIP limits)
• Tasks should be an average ½ days,
so that people can’t disappear into
a “cave” for long

48. Different Daily Questions
1) Of the things I did yesterday, what do others
need to know?
2) Of the things I plan to do today, where do I
need help or coordination with others?
3) What is blocking or slowing us down?

49. Fourth Daily Questions
“Are we still able to deliver to our commitment?”
The Team answers this together at the end of the Daily
Scrum
Use for example thumb voting

50. Collaborative ATDD
All team members collaborate to
define and implement automated
acceptance tests
Define what to test together
Pair programmers and testers to
automate them
Recommendations:
• Add these tasks to task board
• Teach programmers to create
scripts, teach testers to modify &
copy/paste automations
• Automate the tests before coding

51. Pair Work
Pair all production code
(programmers)
Pair all acceptance tests
(programmers and testers)
Pair exploratory testing (testers
with anyone else)
Pair design (designers with anyone
else)
Pair learning (everybody)
Recommendations:
• Driver only “types”
• Navigator thinks
• Rotate often
• If one person is much more senior,
they should mostly navigate
• Plan for pairing in Daily Scrum

52. Mobbing
More than two people doing
something together
Mob programming, mob testing,
etc.
Recommendations:
• Driver only “types”
• Multiple navigator think together
• Rotate very often
• If you mob as a full team, you no
longer need Daily Scrum and many
other things
Check the Mob Programming video from
https://www.youtube.com/watch?v=dVqUcNKVbYg