LeSS (Large-Scale Scrum) is a framework for practicing scrum beyond single team. This is not a new framework in reality many organization opt for LeSS or LeSS like framework naturally. I will tell a story in a form of workshop to share my experience in implementing Large-Scale Scrum. Will cover about LeSS principles, rules and practices.
Will also cover organization change by adopting large-scale scrum. I strongly advocate to change organization design and structure for successful adoption of agility. LeSS is not prescriptive but provides principles and rules to bring change in organization. My story will cover both part of LeSS wherein I will be sharing principles that helped us in making organization change and how team self-manages to practice scrum beyond single team.
This is a 2 days session that will cover Large-Scale Scrum (LeSS Framework) implementation story in the form of workshop. Participants will have to go through many activities in order to understand the situations created by facilitator. Workshop will cover principles like system thinking, queueing theory, empirical process control and Lean thinking etc. Workshop will also cover how to deliver integrated product increment at the end of every sprint by excellent technical practices. This workshop will touch the areas which many people avoid discussing like undone work in sprint, how to manage those undone work and why not to go for proxy product owner etc.
Workshop will start with why and when LeSS or LeSS like framework needed. Where we will have questions and answers session to understand need of scaling and what scaling means. Will share the situation that I have encountered and also what could have been done to avoid those or the need of scaling framework. Will practice Causal Loop Diagram (CLD) to understand the need for Scrum, Large-Scale Scrum and why organizational change needed for agile adoption at enterprise.
Couple of activities on how to form team? Activities includes identification of product to understand the size of product and development team. Team get structured very well if product is real because real product bring whole product thinking. Choosing framework based on size of product also become easy if product has been identified clearly. Another activity is on feature team vs component team. What is the meaning of feature team and how to organize by customer value?
Workshop will help to understand some burning questions like how many product owner needed if there is more than one development team? How a single product owner can cater multiple development team? What will be role of Scrum Master? Do we need to have dedicated Scrum Master for every team or can one Scrum Master facilitate multiple development team? What will be the role of managers in large-scale scrum?
My story will cover majority of these questions with how we started organization changes and where leadership team get involved. How we conveyed some tuff messages to middle manager like “you are important to organization and organization values your work but unfortunately role is no longer relevant”. Best part of our implementation is nobody left job feeling unwanted and yes there was many resistance but all resistance are not bad as it helps in understanding organization complexity and people psychology.