Agile teams: roles and responsibilities

AGILE TEAMS
ROLES AND RESPONSIBILITIES
Holger Schauer
2014-01-22

View Slide

Persons vs. roles
2014-02-10 2
H.Schauer “Agile teams: roles and responsibilities”

View Slide

Responsible etc.
2014-02-10 3

View Slide

Why roles and
responsibilities?
I want to be
an expert!
Look, I’m worth
something!
Let me focus on
my work!
I know what
others want
from me!
2014-02-10 4

View Slide

Why roles and
responsibilities?
We know who to
talk to!
We know who is
to blame!
Everyone is the
specialist for
something!
Maybe someone
would like this job!
2014-02-10 5

View Slide

Culture eats process for breakfast
team individual
contribution expertise
improvement analysis
2014-02-10 6

View Slide

Somebody needs to …
…have a vision of what is needed
…say what needs to be build and when
…clarify what needs to be build and why
…design how to use this thing
…have an idea on how to make it work and do it
…verify that it is working and fits the needs
…run it (sell it etc.)
2014-02-10 7

View Slide

Teams vs. groups
2014-02-10 8

View Slide

Tuckman’s model
Forming
Storming
Norming
Performing
2014-02-10 9

View Slide

Groups are not teams
 Roles and responsibilities don’t matter in
performing teams.
 Corollary: When you don’t know what is
expected of you, you are not working as a
team.
2014-02-10
H.Schauer “Agile teams: roles and responsibilities” 10

View Slide

Individuals&interactions over
processes & tools
 Business people and developers must
work together daily throughout the project.
 Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
 The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
 The best architectures, requirements, and designs
emerge from self-organizing teams.
from agilemanifesto.org
2014-02-10 11

View Slide

Agile teams
 Contain all the roles required
 5-7 people is the sweet spot
 Deliver value every iteration
 Scrum Teams are self-organizing
and cross-functional.
 Agile teams are cross-functional
teams […] The team is responsible for self-
management. (Scaled Agile Framework)
 … similar in other agile and lean methods …
2014-02-10 12

View Slide

Members of cross-functional teams
 Cross-functional teams have all competencies
needed to accomplish the work without depending
on others not part of the team.
 A generalizing specialist is someone who:
 Has one or more technical specialties
(e.g. Project Management, UX/design, Java) […]
 Actively seeks to gain new skills
in both their existing specialties as well as in other areas, including both
technical and domain areas.
Cf. Scott Ambler, “Generalizing specialists”
The Scrum Guide, scrum.org
2014-02-10 13

View Slide

Self-organization
 … is a process where some form of global
order or coordination arises out of the local
interactions between the components of an
initially disordered system.
 This process is spontaneous: it is not directed
or controlled by any agent or subsystem
inside or outside of the system;
 however, the laws followed by the process
and its initial conditions may have been
chosen or caused by an agent.
https://en.wikipedia.org/wiki/Self-organization
2014-02-10 14

View Slide

Three levels of self-organization
 Self-organized
 E.g. software development team
 Self-selected (= self-designed)
 Self-organized and system selects its own members
 E.g. founders of a start-up business
 Self-directed (= self-governed)
 Self-selected and no direction outside the system
 E.g. criminal organization
cf. Jurgen Appelo’s “Dolt’s guide to self-organization”
2014-02-10 15

View Slide

Self-organize to what?
cf. Jurgen Appelo’s “Dolt’s guide to self-organization”
2014-02-10 16

View Slide

Boundaries and guidance
2014-02-10 17

View Slide

… by managers and leaders
2014-02-10
H.Schauer “Agile teams: roles and responsibilities” 18

View Slide

3 pillars of team work
Team member
• engagement,
motivation
• ability to make
contacts
• ability to take
criticism
• ability to learn
• reliability
• tolerance
Inner structure
• internal goals
• rules
• transparent
communication
• clear leadership
• cooperative
decision making
• feeling of “we”
context
• goals
• communication
• infos
• support
• degree of
freedom
• supporting tools
• praise
• clear boundaries
Cf. Dieter Rösner
2014-02-10 19

View Slide

Collaboration
 Everyone works together to move one task
forward to done
cf. Johanna Rothman “Agile teams and collaboration”
2014-02-10 20

View Slide

Enable collaboration
 Shared understanding of …
 … how we do things here
 … what our values are
 Visibility
 Which tasks need to move forward?
 Which tasks are moving forward?
 Who is working on it?
 Who needs help?
2014-02-10 21

View Slide

Lather, rinse, repeat
Figure out
what to do
next
Start
working
on it
together
Help each
other out
as needed
Finish it
2014-02-10 22

View Slide

Facilitation
 We facilitate each other’s work with feedback
and coaching, meta-feedback and meta-
coaching
 Not evaluation or praise, feedback:
 Create an opening
 Describe behavior
or results
 State the impact
 Make a request
Observable
behavior
Feedback
cf. Johanna Rothman “Agile teams and collaboration”
2014-02-10 23

View Slide

But …
 “I don’t know how to do this”
 Could you get help from the team?
 “I don’t know what needs to be done”
 How can you find out?
 “I don’t have time to do this”
 Does this have priority or not?
 “I don’t know if I should do this”
 Can the team help you?
 “Somebody else told me I should do this”
 Is the team self-organized?
 “Somebody else told me I have no time to do this”
 Does this have priority or not?
 “this”: some task / activity to be done
2014-02-10 24

View Slide

Transition to self-organization
 Roles don’t matter as long as the team members
know what they need to do
 Roles can help during transition to self-
organization
 Avoid the obstacles of sticking to roles and
responsibility definitions
 e.g. blame-free post mortems: move from “what / who
caused this” to “how can we avoid this next time”?
 e.g. help each other out in case of lack of knowledge /
time
2014-02-10 25

View Slide

Roles and tasks in agile teams
 Many tasks are the same as in non-agile teams
 e.g. designing, testing, developing, …
 Some are: planning, requirements management, …
 Role names might differ
 e.g. Scrum: Product owner, Scrum master, …
 e.g. XP: Customer on-site, developer, tracker, …
 e.g. DAD: Primary roles such as Stakeholder, Team
member, Team lead, Product owner, Architecture owner
and Secondary roles such as Specialist, Domain expert,
Technical expert, Independent tester, Integrator
2014-02-10 26

View Slide

Team organization complexities
 Co-located vs. distributed teams
 Component vs. feature teams
 Scaling the product owner
 Decision making
2014-02-10 27

View Slide

Co-location makes it easier
 Co-location allows for easy and quick exchanges
in a team
 Just ask or talk with the guy needed
 You know when the guy is available
 Simple tools can be used (boards, etc.)
 Working together comes naturally
 Benefits of face-to-face communication
2014-02-10 28

View Slide

What is distribution anyway?
 Distribution can come in various forms
 Geographical distribution
 Organizational distribution
 A simple definition:
 Distributed teams are teams that have something
preventing them from collaborating in person and
face to face. (by Tom Wise, leadingagile.com)
2014-02-10 29

View Slide

Distributed teams complexities
 Increased organizational effort
 determine time slots for communication
 determine who needs to be communicated with
 “natural” boundaries occur
 language barriers
 cultural differences
 “them” over there vs. “us” here
 groups vs. teams (of teams)
 Too much indirect communication
 Fact: Projects done by small, co-located teams are
way more successful
2014-02-10 30

View Slide

Higher bandwidth is better
Email
Phone
Face-2-face
 Face to face (plus whiteboards etc.)
 High resolution video on large screen plus great sound
that is always on
 Bad video and bad sound that’s sparely used due to
extra costs
 Messengers, chats, electronic whiteboards
 E-Mail, ticketing systems
 Wikis, documents
2014-02-10 31

View Slide

Minimizing impact
 Bring everybody together physically in a single
location as early as possible
 Meet physically with everybody every so often
 Celebrate major achievements together
 Invest in good video conferencing and
first-class audio systems / phones
 Use electronic tools mainly to record / track
decisions, not as main communication tools
 Enable non-work communication
(chat, social media …)
2014-02-10 32

View Slide

Collaborate: delegate
2014-02-10 33

View Slide

Collaborate: network
cf. Johanna Rothman
2014-02-10 34

View Slide

Component vs. feature teams
 Components are typically technical systems
 Features often cut across components/systems
 Components are communication boundaries
 „not my concern“ / „not invented here“
 Same concept might be handled / implemented /
named differently in the various systems.
 A feature might have varying impact on the different
systems, i.e. more or less work.
 Integration needs require alignment of teams, progress
and solutions.
 Please note: this is Organizational distribution!
2014-02-10 35

View Slide

The agile product owner
adapted from Roman Pichler’s “Product owner on one page”
2014-02-10 36

View Slide

Scrum: Product Owner
 … is responsible for maximizing the value of the product.
 … is responsible for managing the Backlog.
 clearly expressing Product Backlog items
 ordering the items in the Product Backlog to best achieve goals and missions
 optimizing the value of the work the Development Team performs
 ensuring that the Product Backlog is visible, transparent, and clear to all, and shows
what the Scrum Team will work on next
 ensuring the Development Team understands items in the Product Backlog to the
level needed.
 The PO may do the above work, or have the development Team do it.
The PO remains accountable.
 The Product Owner is one person, not a committee.
 For the Product Owner to succeed, the entire organization must respect
his or her decisions.
2014-02-10 37

View Slide

Scaling the PO: problem space
 the “single wrenchable neck”
 It’s not only about working with multiple teams
 Too many requirements for one person
 Too many stakeholders need to be handled
 No single person can be a domain expert in all areas in a
large project
 Solution space is too large
 “if you haven’t come up with at least 3 options to solve a
problem, you don’t really understand it”
 Multiply by number of requirements
2014-02-10 38

View Slide

Scaling the PO
 Use the team
 Have the team work with the customer
 The team should build up domain expertise
( team stability over time)
 Hear the team’s opinion on planned features
 Delegate (some) decisions to the team ( solutions)
 Work with other teams / POs
 e.g. Scrum of Scrums
 build a community / tribe of Product Owners for
getting feedback / help
 easier with fewer dependencies
2014-02-10 39

View Slide

Scaling the PO: e.g. SAFe
 Product Owner per Team (“lower-case” p)
 Product Manager per product (“upper-case” P)
 works with Portfolio Management
 determines business objectives
 owns the program vision
 participates in release planning
 maintains the product roadmap […]
 Program Portfolio Management
 Epic owners for business and architectural Epics
 decides about investment themes […]
 Collaborate via “Delegate” (not entirely, ART)
2014-02-10 40

View Slide

Decision making: what is needed
 Requirement decisions
 What should we build?
 When should we build what?
 depend on business objectives
 require understanding of problem domain
 require understanding of value
 Solution decisions
 require understanding of outcome
 require understanding of risk
 require understanding of dependencies
 require understanding of effort
 depend on budget
2014-02-10 41

View Slide

Requirement decisions: problems
 Lack of knowledge (“I don’t understand”)
 Ask or bring in the domain experts / customer
 Ask the team
 Gather data, light-weight analysis
 Lack of empowerment (“Too many powerful
stakeholders have too many opinions”)
 Defend your clear-cut opinion, provide evaluation
 Organize a decision among stakeholders
 Use a non-agile approach
 FUD: Fear, uncertainty and doubt
2014-02-10 42

View Slide

Breaking the vicious circle
 Get feedback as early as possible
 Ask people to give feedback (stakeholders,
customers, team …)
 Get data (from existing statistics, use A/B tests …)
 Decide in the presence of uncertainty
 Learn along the way (see above)
 Remember that we intend to …
 Correct mistakes as early as possible
 Don’t miss the “Last responsible moment“
2014-02-10 43

View Slide

2014-02-10 44
 Contact me:
 Email: Holger Schauer
 www.find-method.de
 plus.google.com/+HolgerSchauer

View Slide

Picture references
 Miners, https://commons.wikimedia.org/wiki/File:Bundesarchiv_Bild_183-13287-0001,_Bergarbeiter,_Arbeitsbesprechung.jpg, CC-BY-SA 3.0,
Bundesarchiv, Bild 183-13287-0001 / CC-BY-SA
 Trial, https://commons.wikimedia.org/wiki/File:Bundesarchiv_Bild_183-31316-
003,_Berlin,_Proze%C3%9F_gegen_Agenten_vor_dem_Obersten_Gericht.jpg, CC-BY-SA 3.0, German Federal Archives
 Sasha Lobo, https://commons.wikimedia.org/wiki/File:Sascha_Lobo_in_Berlin.jpg, CC-BY-SA 3.0, Ronniegrob
 Bored, http://www.hackcollege.com/blog/2010/07/14/three-tips-to-making-the-best-of-your-boring-internship.html, CC-BY-SA 2.0, sunshinecity on
flickr.com
 Team, http://www.flickr.com/photos/[email protected]/3385718581/, CC-BY-SA 2.0, paddynapper on flickr.com
 Group, http://ukwebfocus.wordpress.com/2013/11/11/facilitating-a-wikipedia-editing-session-the-solo13-experience/, CC-BY-SA , Toni Sant
 Cells, https://commons.wikimedia.org/wiki/File:Bone_marrow_WBC.JPG , CC-BY-SA 3.0, Bob J. Galindo
 Heart, https://en.wikipedia.org/wiki/File:Wiki_Heart_Antomy_Ties_van_Brussel.jpg, CC-BY-SA 3.0, Tvanbr
 Maze, https://en.wikipedia.org/wiki/File:Longleat_maze.jpg, Public domain, Rurik
 Fence, https://en.wikipedia.org/wiki/File:Westtown.jpg, Public domain, MyWikiBiz
 Compass wind rose, https://en.wikipedia.org/wiki/File:Brosen_windrose.svg, CC-BY-SA 3.0, Brosen
 Gold bars, https://en.wikipedia.org/wiki/File:Gold_Bars.jpg, CCO 1.0, Agnico-Eagle
 Coach (O. Hitzfeld), https://commons.wikimedia.org/wiki/File:Otmar_hitzfeld_in_bulgaria.jpg, CC 3.0, Biso
 Swarm, https://commons.wikimedia.org/wiki/File:Fish_in_the_Ningaloo_reef_%28368690753%29.jpg, CC 2.0, Angelo DeSantis,
http://www.flickr.com/photos/angeloangelo/368690753/
 Kanban board, https://commons.wikimedia.org/wiki/File:Simple-kanban-board-.jpg, CC-BY-SA 3.0, Jeff.lasovski
 Money, https://en.wikipedia.org/wiki/File:Billets_de_5000.jpg, Public domain, Wazouille
 Market, https://en.wikipedia.org/wiki/File:Ul_merc%C3%B2_dal_lunedi.JPG, CC-BY-SA 3.0, Brianza2008
 Choking, https://commons.wikimedia.org/wiki/File:North%E2%80%93south_choke_blue.JPG, CC-BY-SA 3.0, Jdcollins13
 Thumb, https://commons.wikimedia.org/wiki/File:Thumb_up2.png, CC-BY-SA 2.5, AzaThoth
 Teams, https://commons.wikimedia.org/wiki/File:Patriots-Steelers_2005.jpg, CC-BY-SA 3.0, Bgag
2014-02-10 45

View Slide

Further reading
 Johanna Rothman, “Agile teams and collaboration: what’s new about agile”,
http://www.slideshare.net/johannarothman/agile-teams-and-collaboration-whats-new-about-agile
 Jurgen Appelo, “The dolt’s guide to self-organization”, http://de.slideshare.net/jurgenappelo/the-dolts-guide-
to-self-organization
 Tim Wise, “Enabling distributed agile teams”, http://www.leadingagile.com/2013/10/enabling-distributed-
agile-teams/
 Johanna Rothman, “Networks for managing agile programs”,
http://www.jrothman.com/blog/mpd/2013/03/organizing-an-agile-program-part-2-networks-for-managing-
agile-programs.html
 Scott Ambler, “Roles in disciplined agile delivery”,
http://disciplinedagiledelivery.wordpress.com/2012/12/18/roles-in-disciplined-agile-delivery/
 Scott Ambler, “Generalizing specialists”, http://www.agilemodeling.com/essays/generalizingSpecialists.htm
 Roman Pichler, “Scaling the Product Owner”, http://www.romanpichler.com/blog/roles/scaling-the-product-
owner/
 Roman Pichler, “The Product Owner on one page”, http://www.romanpichler.com/blog/roles/one-page-
product-owner
 Dean Leffingwell, “Scaled agile framework”, http://scaledagileframework.com/
 Ken Schwaber, Jeff Sutherland, “The Scrum guide”,
https://www.scrum.org/Scrum-Guide
2014-02-10 46

View Slide

Agile teams: roles and responsibilities

Agile teams: roles and responsibilities

schaueho

More Decks by schaueho

Other Decks in Programming

Featured

Transcript