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