A slightly different, behavioural take on team formation - foundations, support, and practical tools, to support the growth of the team.

1. 1 Agile Training and Coaching - © 2017 Petri Heiramo, Agilecraft Ltd, Finland
Real Teams
Easier Said And Done
Petri Heiramo, CST, Agilecraft Ltd

2. 2 Agile Training and Coaching - © 2017 Petri Heiramo, Agilecraft Ltd, Finland
Foundation
Journey
Practices
Journey

4. 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

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

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

7. 3 Conditions

8. B = f(P, E)
B = Behavior, P = People, E = Environment
Lewin's equation, Kurt Lewin,1936:

9. Forming into a team is a
natural human response
to certain conditions in the
environment.

10. if (X, Y, Z)
then team.form()

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

12. Y) 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

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

14. Catalysts

15. Speed, Ease
Coaching

16. Conditionsof
Advancement

17. Imagine a state machine

18. Once certain conditions are
achieved, the machine
automatically moves
to a new state

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

20. 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, …

21. 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

22. Conditions for AdvancementForming
storming
• Safety
• Courage

23. Conditions for Advancementstorming
norming
• Ability to decide together
• Commitment to decisions
• Clear boundaries
• Trust and respect
• Acceptance of differences

24. Conditions for Advancementnorming
performing
• Relentless improvement
• Discipline
• Personal competence
• Embracing variety of opinions
• Sufficiently stable team

25. Conditions for MaintenanceperForming
• Continued big challenges
• Appropriate change
• Scrum, Inc.: 20% change
• Keep wolves at bay

26. Practices
Effective Team

27. Shared Release Vision
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

28. 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

29. 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

30. 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

31. 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”

32. 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

33. 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

34. 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?

35. 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

36. 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

37. 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

38. 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

39. https://www.youtube.com/watch?v=dVqUcNKVbYg

40. Conditionsof
Advancement
3 Conditions
Practices
Catalysts
Effective Team

41. Summary
Trying to make teams jell is useless.
Create right conditions, and they will start to self-form.

42. Summary
DON’T
… try to convince people
… try trickery or sleight-of-mind
(e.g. bonuses, dishonesty)
… apply pressure
DO
… help form a clear shared goal
… use techniques that
bring people together
… provide open-ended challenges
… coach through the stages

43. Thanks!
Petri Heiramo
Agile Trainer & Coach, CST
Agilecraft Oy
petri.heiramo@agilecraft.fi