KEGON AG 2014 1
Self-designing Feature Teams
Agile Lean Europe (ALE)
Krokow, 21.08.2014
KEGON AG 2014 2
Agile Management Consultant
Solution Focused Coach
25 years of experience in software development
7 years of experience with Large Scale Scrum
3 Enterprise Agile Transitions (bwin, ADAG, Telekom P&I)
Scaled Agile Framework (SAFe) Program Consultant and Trainer
07.2012-03.2014 Senior Agile Coach @BMW (via Valtech GmbH)
Josef Scherer
KEGON AG 2014 3
Training and Consulting for Agile@Enterprise
Leading SAFe consulting company in Germany (5 SPCs, 5 SAs)
Scaled Agile Inc. Partner
Customers using SAFe
KEGON AG
What are self-designing teams?
Principles of organizational design in Large Scale Scrum
Stories of self-designing teams @ BAML and BMW
Why do it?
How to do it?
Role of management?
Role of facillitators?
How does it feel like for a team member?
Learnings from these stories
Two Stories about Forming Teams in Large Scale Scrum
Large Scale Scrum as Organizational Design Framework
KEGON AG 2014 5
Organizational Principles behind the Agile Manifesto
Customer collaboration over contract negotiation
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 best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.
http://agilemanifesto.org/iso/de/principles.html
Motivated Individuals Autonomy, Mastery, Purpose
7
4 Levels of Team Autonomy Self-designing Teams
KEGON AG 2014 8
Scaling Scrum starts with understanding and being able to adopt standard real one-team Scrum with
Direct collaboration between business & development
Customer focused Feature Teams
Self-managing cross-functional Teams
Start a large-scale agile Scrum adoption by ensuring leadership understands the organizational implications.
Real agile development with Scrum implies a deep change to become an agile organization; it is not a practice, it is an organizational design framework.
Large Scale Scrum as Organizational Design Framework
http://www.crosstalkonline.org/storage/issue-archives/2013/201305/201305-larman.pdf
Direct collaboration between PM and R&D
„Contract Game“ PM & R&D Product Manager as PO
Product
Management
R&Dstart end
(release)content freeze
(release contract agreed)
The Milestone point
is arbitrary
more,
more,
more!
less,
less,
less!
1 2
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. V odde
All rights reserved.
Customer focused Feature Teams
Component Design Fokus
Item 1
Item 2
Item 3
Item 4
...
…
system
comp
C
Team
comp
A
Work from multiple teams is required to finish a customer-centric feature. These dependencies cause waste such as additional planning and coordination work, hand-offs between teams, and delivery oflow-value items. Work scope is narrow.
Product
Owner
comp
B
Team
comp
A
Team
comp
B
comp
C
Item 1
Item 2
Item 3
Item 4
...
…Team
Wu
Product
Owner
Team
Shu
Team
Wei
system
comp
A
comp
B
comp
C
Every team completes customer-centric items. The dependencies between teams are related to shared code. This simplifies planning but causes a need for frequent integration, modern engineering practices, and additional learning.Work scope is broad.
Component teams Feature teams
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
Customer Feature Fokus
Item 1
Item 2
Item 3
Item 4
...
…
system
comp
C
Team
comp
A
Work from multiple teams is required to finish a customer-centric feature. These dependencies cause waste such as additional planning and coordination work, hand-offs between teams, and delivery oflow-value items. Work scope is narrow.
Product
Owner
comp
B
Team
comp
A
Team
comp
B
comp
C
Item 1
Item 2
Item 3
Item 4
...
…Team
Wu
Product
Owner
Team
Shu
Team
Wei
system
comp
A
comp
B
comp
C
Every team completes customer-centric items. The dependencies between teams are related to shared code. This simplifies planning but causes a need for frequent integration, modern engineering practices, and additional learning.Work scope is broad.
Component teams Feature teams
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
Self-managing, cross-functional Teams
R&D Departments Cross-functional Teams
Lead Designer
Designer
Designer
Lead Arch.
Architekt
Architekt
Lead Dev
Developer
Developer
Developer
Developer
Developer
Developer
Test Lead
Tester
Tester
Tester
Craig Larman, Ahmad Fahmy Self-designing Teams @ BAML
KEGON AG 2014 13
http://www.scrumalliance.org/community/articles/2013/2013-april/how-to-form-teams-in-large-scale-scrum-a-story-of
Traditional program @BAML Bank of America‘s Merrill Lynch
42 people, 35 „team“ members
Business-analysis group
3 component groups, „private“ code ownership
Test group
7 week integration testing and release phase
Background
increase customer value,
reduce waste and lead time
by forming „real“ Scrum Feature Teams
co-located, self-designing Teams
cross-functional, cross-component teams to reduce handoffs and dependencies
team size ~7 team members (excluding PO & SM)
able to deliver any item from the backlog and
deliver completely „done“ end-to-end functionality
Goal
Management: introduction and background: 20 minutes
Ideal team definition: 20 mins.
Management leaves
Cycle 1: 25 mins., Review: 10 mins.
Cycle 2: 25 mins., Break: 20 mins., Review: 10 mins.
Cycle 3: 25 mins., Review: 10 mins.
Choose ScrumMasters & Team names: 15 mins.
Retrospective: "Plus-delta" feedback: 5 mins.
Conclusion and thanks: 5 mins.
Workshop Schedule
Plus-Delta
Plus
process, facilitation, and timekeeping (11)
creation of well-balanced team (8)
sense of empowerment (7)
sense of team spirit (3)
Delta
Inadequate room choice (6)
More facilitation required to break deadlocks (5)
Pressure to join a team you're not happy with (3)
More information ahead of the meeting (3)
Reluctance of team members to move out of the initial teams (3)
Mark Bregenzer Self-designing Teams @ BMW
KEGON AG 2014 18
http://www.agileworld.de/content/self-designing-teams-bmw
5 component teams incl.
1 IT PO,
2 Business Analysts (POS) and
6-7 Developers, one as SM
4 “cross cutting” teams
2 PMs as
Chief PO and
Chief Architect
1 Agile Management Coach, 4 Agile Team Coaches
Background
© valtech gmbh
Backlog items cannot be pulled by all teams due to know how constraints -> Redesign teams s.t. any team can pull any item
Routine work led to decreased motivation -> drive up motivation through increased autonomy and purpose
Social conflicts between team members -> let teams reform themselves
„Selfish“ teams instead of „one team“ spirit
Reduce number of „cross cutting“ teams and include members in feature teams.
Challenges, Goals
About 80 participants including management
Management explained project vision and workhop target and left.
Management came back at the end for the team presentations and closing.
Workshop Schedule
Skill Cards
© valtech gmbh
Team Org Chart
1st Iteration 4 new teams formed except one team x which remained almost unchanged
2nd Iteration Some members left team x but other teams tried to keep their members. Team x was incomplete and the process stagnated.
3rd Iteration After the break someone voluntered to join team x.
Iterations
Choose Team Names, Rooms, SMs …
Self-Designing Teams @BMW KEGON AG 2014 25
The opening practices helped to warm up and get used to move around the room.
Stagnation at iteration 2 seems normal. Have a break and trust the people to get the job done.
One facilitator for each team helps to speed up inspection & adaption of team composition.
A lot of positive energy from the workshop.
Increased trust of management in teams ability to self-organize.
Know how bottlenecks don‘t disappear, if you don‘t invest in mentoring, coaching, pairing etc.
Social conflicts might recur and must be addressed.
Key Learnings
KEGON AG 2014 27
Train all participants in Large Scale Scrum (LeSS) and let them figure out, how to form feature teams in 2 hours.
Vote Scrum Masters and let them facilitate the team forming event (EduScrum)
Let Product Owners pitch their product vision and ask them, what skills they need to develop the product (Lean Startup)
Have people with different work preferences and sufficient linking skills in the same team (Team Management System)
What would work for your organization and environment?
Some Alternative Approaches
Recommended
