Building Cross-Functional Scrum-Teams in a Hardware Project
6 likes2,058 views
The document discusses the establishment of cross-functional scrum teams in a medical technology company, emphasizing the transition from disciplinary to interdisciplinary collaboration. It outlines the challenges and steps taken towards cross-functionality, including team configurations, sprint processes, and the importance of effective communication and iterative delivery. Lessons learned highlight the necessity for clear roles, ongoing support for team members, and a shared vision for teamwork.
Building Cross-Functional Scrum-Teams in a Hardware Project
- 1. Building cross-functional Scrum-Teams or How Electricians, Mechanics, and (Embedded) Software Engineers Stephanie Gasche went T-shaped
- 2. Who am I? Stephanie Gasche ⟩ Management Consultant at Boris Gloger Consulting ⟩ studied English, History and International Business Management in the UK and France ⟩ assists Agile Organisations and Scrum-Team members during the change ⟩ founded her own start-up www.fleissigebiene.com in 2013 ⟩ blogs about Agility at http://borisgloger.com/author/stephanie-gasche/
- 3. Welcome to the Medical Technology Sector The Company ⟩ German SME ⟩ specialised in laboratory automation ⟩ recent take-over by large pharmaceutical company
- 4. Welcome to the Medical Technology Sector The Product ⟩ highly innovative ⟩ hardware product ⟩ started in 2011
- 5. Welcome to the Medical Technology Sector The People ⟩ ca. 35 people involved incl. several consulting and body-leasing companies ⟩ spread across 3 locations in Germany and Switzerland
- 6. Welcome to the Medical Technology Sector The Process ⟩ working with Scrum since early 2013 ⟩ 3-week sprints ⟩ embedded in traditional product development process ⟩ highly regulated environment
- 7. Why use Scrum to build Hardware? What the top management wants... ⟩ improved communication ⟩ shorter feedback cycles ⟩ transparency of product status ⟩ transparency of problems ⟩ clear roles and responsibilities ⟩ focus on delivery ⟩ know-how transfer through teamwork
- 8. Using Scrum to build Hardware How is it different? ⟩ longer feedback cycles ⟩ keep suppliers close ⟩ ...and procurement even closer ⟩ rapid prototyping ⟩ think in results, not product increments
- 9. Today‘s Fairy Tale How to turn disciplinary teams into interdisciplinary teams in 3 steps? ... And back again. Learning from my mistakes...
- 10. Cross-Functionality What is it? Why would you want it? ⟩ team of generalising specialists ⟩ fosters explicit know-how transfer ⟩ work on different layers at the same time to enable iterative delivery ⟩ easier integration ⟩ optimisation of whole product ⟩ less coordination, fewer queues at hand-overs
- 11. Once upon a time...
- 14. Feasibility ! ⟩ topped expected outcome ⟩ first major milestone reached ⟩ 24h Party with 150+ people
- 15. Hello Feasibility ⟩ different product backlogs full of ad-hoc stories ⟩ every team working on different parts ⟩ large dependencies between disciplines (visualisation in Scrum Arena) ⟩ high fluctuation, little know-how transfer ⟩ inefficient Scrum Day ⟩ one main location ⟩ Major speed decrease within 1 week ⟩ team members actively urging for cross-functionality!
- 16. „Let‘s do it properly“
- 17. Sprint #1 on the Journey to Cross-Functionality “The Creative Sprint“
- 19. Creative Sprint Why? What? ⟩ fun and something different ⟩ perhaps make new discoveries ⟩ official cut between development process steps ⟩ Product Owners find time to write backlog ⟩ first informal feeling for cross-functionality ⟩ constellations working together for the first time ⟩ How To: selection of ideas " Sprint Plannings " Daily Scrum " delivery
- 20. Sprint #2 on the Journey to Cross-Functionality “Chaos“
- 22. Chaos Why? What? ⟩ constraint: only two teams (10+ people each) ⟩ home location for team members ⟩ Product Owner Team: Daily Scrum, product backlog blockers (shared product backlog), CPO and CSM ⟩ ScrumMaster Team: Daily Scrum, CSM ⟩ How To: shared backlog " team division in Sprint Planning 1
- 23. Sprint #3 on the Journey to Cross-Functionality “Taking A Step Back“
- 25. Taking A Step Back Why? What? ⟩ three teams ⟩ 2x interdisciplinary ⟩ 1x software ⟩ two locations ⟩ Quarterly Milestones as short-term goals ⟩ changing of roles ⟩ SoS for Firmware & Software and Electronics ⟩ one Product Owner & ScrumMaster Team ⟩ active team building
- 27. Learning for the Future
- 28. Taking A Closer Look Small attempts in smaller settings ⟩ 100 % Product Owner and ScrumMaster a must ⟩ each discipline must have at least one sparring partner of same discipline ⟩ varied Backlog Groomings ⟩ create awareness of tractor factor ⟩ be firm about prioritisation of stories & tasks ⟩ feature-driven, cross-functional backlog ⟩ ask questions & be honest ⟩ play the Market of Skills game
- 29. And Now? Yes, but no. We still have a long way to go... ⟩ build a feature-driven product backlog ⟩ create a shared product vision ⟩ show benefits of t-shape ⟩ roles are work in progress ⟩ support & schooling for Product Owners ⟩ find ScrumMasters ⟩ establish a strategy for scaling the teams ⟩ use my team as ambassador for interdisciplinarity ⟩ go fully cross-functional
- 30. Lessons Learned Cross-Functionality in Hardware ⟩ communication & alignment (get everyone on board) ⟩ cross-functionality is a shared goal to work towards ⟩ take one step after another (don‘t try everything at once) ⟩ keep the team small ⟩ limit the locations ⟩ be actively aware of each step ⟩ cross-functionality follows feature-driven product backlog ⟩ work with a pilot team
- 31. Building cross-functional Scrum-Teams or How Electricians, Mechanics, and (Embedded) Software Engineers Stephanie Gasche went T-shaped