agile teams: self-organizing, collocated, and distributed agile teams: self-organizing, collocated,

Download Agile Teams: Self-Organizing, Collocated, and Distributed Agile Teams: Self-Organizing, Collocated,

Post on 27-May-2020

0 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • 1

    ©2004-2014 by IT-communication.com 1 1

    Jutta Eckstein

    je@it-communication.com

    http://it-communication.com

    Agile Teams:

    Self-Organizing, Collocated, and Distributed

    ©2004-2014 by IT-communication.com 2

    Agenda

     Building Teams

     Team Maturity Stages & Collaboration

     Multi-Projecting and Part-Time Members

     Large and/or Global Self-Organizing Teams

  • 2

    ©2004-2014 by IT-communication.com 3 3

    Building Teams

    ©2004-2014 by IT-communication.com 4

    Self-Organizing Team

     Cross-functional

     Organizes itself and its work

     Integration instead of separation

    – Competency, responsibility and task inseparable

    – Thinking and acting

    – Leads to more flexibility toward customer requests

  • 3

    ©2004-2014 by IT-communication.com 5

    Self-Responsible Feature Teams

     Comprehends all necessary roles

    – Domain expert, tester, ...

     Comprehends all required know-how

    – UI, database, …

    – Or gains the required know-how

     Ensures to complete stories (or features) in an iteration

    – According the definition of done

    ©2004-2014 by IT-communication.com 6

    Knowledge Transfer

     Agile principles and practices ensure knowledge transfer

    – Joint estimation and iteration planning

    – Collective ownership of delivery and process

    – Daily Scrum

    – Pair programming

     Higher competency inside a group

    – Team members learn from one another

    – Absences are easier to compensate

    – Continuous optimization

  • 4

    ©2004-2014 by IT-communication.com 7

    Ensuring the Business Value

     Customer / product owner

    – Decides on highest business value

    – Steers the iteration

    – Provides feedback on delivery

    – Obtains feedback from the teams

     Represents customer perspective

    ©2004-2014 by IT-communication.com 8

    Coach (aka Scrum Master)

     Responsible for:

    – Coaching team in self-organization and creation of valuable

    products

    – Cooperation with roles and functions interfacing the team

    – Removing barriers

     Ensures:

    – Process is understood

    – Organization of team meetings

    – The organization supports and understands the process

  • 5

    ©2004-2014 by IT-communication.com 9 9

    Team Maturity Stages & Collaboration

    ©2004-2014 by IT-communication.com 10

    Team Maturity Stages

     Tuckman‘s

    Team Development Model

    Forming Storming

    Norming Performing

    Adjourning or

    Transforming © Jana Friedrich, use with permission

  • 6

    ©2004-2014 by IT-communication.com 11

    Agile Chartering

     Initial understanding and agreement on:

    – What & How

     Alignment of whole team

    – Business people and developers

     Note from Diana Larsen & Ainsley Nies:

    – Chartering is more important than charter!

    ©2004-2014 by IT-communication.com 12

    Retrospectives

     Continuous learning

    – Recognize and extract best practices

    – Reflection on and optimization of the

    process

    – Prepare for next iteration/release/project

     As a team get more effective and efficient

    – Reinforce your joint history

    – Make your shared values explicit

    – Define your common rules

  • 7

    ©2004-2014 by IT-communication.com 13

    Personal Development

     Regard failures as learning possibilities

    – Not as malfunction

     Learning is required by everyone at any time

     Sustainable Improvement

    – Continuous reflection and improvement

    – Everyone has to act self-responsibly

    ©2004-2014 by IT-communication.com 14 14

    Multi-Projecting and Part-Time Members

  • 8

    ©2004-2014 by IT-communication.com 15

    Multi Projecting

    Project 1 Project 2 Project 3

    Earliest possible return-on-investment

    2 4 6 Months

    With Prioritization

    Without Prioritization

    (task switching not considered)

    ©2004-2014 by IT-communication.com 16

    Multi Projecting

     Multi projecting delays all projects

    – Later ROI for all projects

     Fully staff each project

    – Work on one project after the other

  • 9

    ©2004-2014 by IT-communication.com 17

    Part-Time Members

     Ensure every individual works for exactly one project

     Ensure team coherence

    – Team has joint goal

     Multi-tasking reduces productivity

    – It is a sign for lack of decision

     Everyone can keep the focus during the iteration

    ©2004-2014 by IT-communication.com 18 18

    Large and/or Global Self-Organizing Teams

  • 10

    ©2004-2014 by IT-communication.com 19

    Building Teams

     Avoid the typical structure

    – According activities and know-how

    • Analysis in Germany, UI in India, middleware in Ireland...

     Instead structure along features

    – For ensuring the business value and the customer‘s

    advantage

    – Features/Stories shouldn‘t be split across teams

    ©2004-2014 by IT-communication.com 20

    Collocated vs. Dispersed Feature Teams

     Distributed but collocated

    subteams

    – But: required know-how is often

    not collocated

    – Cross-team communication is

    harder

     Dispersed subteams

    – Cross-team communication is

    enabled by collocation

    • Eases conceptual integrity

    – Inner team communication is

    enforced by common goal

  • 11

    ©2004-2014 by IT-communication.com 21

    Supporting Whole Teams

     Every feature team needs the product owner‘s support

    – Educate product owner(s) by shadowing

     Team of product owners with one lead product owner

    – Major contact to the real customer

    – Ensures big picture

    – Final decision on priorities

    ©2004-2014 by IT-communication.com 22

    Feature Focus and Conceptual Integrity

     Feature focus might prevent conceptual integrity

     Yet:

    – „Simplicity comes from conceptual integrity“ (Parnas)

     And:

    – Required support depends on system’s complexity

  • 12

    ©2004-2014 by IT-communication.com 23

    Complexity of Systems

    Uncertainty

    Changes

    Low

    Many

    High

    Stable, Uncomplex

    Adapting

    Unstable, Complex

    Few

    ©2004-2014 by IT-communication.com 24

    Supporting Stable Architecture

     Chief architect is premise for conceptual

    integrity

    – Chief architect pulls the strings

    – Communicates the vision

    – Servant with courage and experience

     Community of Practice

    – Role of architect in each feature team

    – Architects meets for synchronization and

    decision making

  • 13

    ©2004-2014 by IT-communication.com 25

    Supporting Unstable Architecture

     Technical service team provide architecture as a service

    – A good architecture evolves

     Feature teams provide a product owner

    – Formulates and prioritizes the requirements

    – Steers the iterations of the technical service team

    ©2004-2014 by IT-communication.com 26

    Supporting Adaptive Architecture

     Technical Consulting Team

    – 1-x architects support several feature teams

    – Architects will work with feature teams on demand

  • 14

    ©2004-2014 by IT-communication.com 27

    Uncertainty

    Changes

    Low

    Many

    High

    Stable, Uncomplex

    Adapting

    Unstable, Complex

    Few

    CoP / Chief

    Architect

    Technical Consulting

    Team

    Technical Service Team

    Different Models for Architectural Support

    ©2004-2014 by IT-communication.com 28

    Uncertainty

    Changes

    Low

    Many

    High

    Stable, Uncomplex

    Adapting

    Unstable, Complex

    Few

    CoP / Chief Architect

    Technical Consulting Team

    Technical Service Team

    Time

    Complexity Decreases over Time

  • 15

    ©2004-2014 by IT-communication.com 29

    Summary

     Cross-functional teams

     Congruency of competency, responsibility & task

     Feature team(s) & product owner(s) ensure value delivery

     Distributed or dispersed feature teams

     Technical teams & roles are service providers

    ©2004-2014 by IT-communication.com 30

    Many Thanks!

    Jutta Eckstein

    je@it-communication.com

    www.it-communication.com

View more >