Self-designing Feature Teams

download Self-designing Feature Teams

of 27

Embed Size (px)

description

Two stories of self-designing feature teams and learnings from that experience. The autonomy of teams to form and re-form themselves to build teams, that manage themselves to deliver value to customers frequently can be a real boost of motivation and performance.

Transcript of Self-designing Feature Teams

  • KEGON AG 2014 1 Self-designing Feature Teams Agile Lean Europe (ALE) Krokow, 21.08.2014 Josef.Scherer@KEGON.de
  • 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. Vodde 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. 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 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. 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 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 Americas 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 @BMWKEGON 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 dont disappear, if you dont 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