This Blog is part of series where I share my experience with Agile scaling frameworks. These include Scrum @Scale, SAFe. Less and Nexus. This blog concentrates on “What works” and “What Doesn’t Work” in Scaling with Scrum @Scale.
Scaling Agile team is one of the most complex change managements in an organization. It touches/effects every part of the organization, organization design, culture, people, process, budget, and the organization eco-system (Key stakeholders, suppliers, customers, users etc.).
I have more a decade experience in IT industries. My last half a decade has been spent in Agile transformation in various roles as Agile coach, Product Owner, Agile Transformation coach and Senior Scrum Master. The most interesting part of the transformation is my one year plus, in one of the top software companies as an Agile Transformation Coach.
I worked with 5 other Agile transformation coach experts, enabling the biggest unit of the organization with over 2,500 developers in their scaling journey. One lesson I learnt on the journey is that no one size fits all when it comes to agile scaling frameworks. The major key point before scaling is trying to ask key questions and understand, why scaling? What are the pain points? How mature are the teams in terms of technical agility (Scrum and/or Kanban, team dynamic, self-managing)? Does the organizational culture/design support the scaling? What is the size of the organization? What is the maturity of our product/services? These are key important questions and multiple dimensions that need to be addressed. These determine which framework / process / practice could fit for the business agility goal and ways to adapt it to fit the needs of the organization.
What works: SoS (team of teams) is practice used in Scrum @Scale to organize Scrum teams (4-6 more ideal) in solving a complex problem and achieving business agility with minimum bureaucracy. While scrum deals with a team, SoS is a scaled Scrum teams which still perform the rituals that are done in one Scrum Team. SoS is smart approach of organizing multiple scrum teams into a value stream/complex solution that cannot be fulfilled with one team. I can confidently say that the approach works well with valuable outcomes, if implemented well. That does not bulletproof it from challenges that come with scaling transformation because humans are involved.
The teams must be mature and have all the necessary skills for an end-to-end process delivery. This is a misconception which I have experienced a lot in the software industry, where they expect every developer to be a full-stack. While this is highly appreciated, the major focus should be on team dynamics and having each of the necessary skills distributed between the team members. This is not to discourage developers from becoming “T” shaped or “E” shaped. The extraneous cognitive load should be taken care of which causes more harm than good.
The Team should live and breathe in Agile manifestos values and principles. These core values and principles must be integrated into the culture and communication structure between the team and top management. E.g., decentralized decision making: Let knowledge workers (developers) make decisions that will affect them and don’t assume as Management team that you understand. Another E.g., could be, bringing solutions to knowledge workers instead of problem to solve.
The team should be Scrum Mature: combining multiple teams that are proficient in scrum and those that are beginners will hurt the productivity and value delivery of the product. Coach and train every team/individual and ensure they understand the fundamentals of all events and artifacts in Scrum.
Ensure that the teams are cross-functional where necessary and regular integration of the features/functionality to the main product/solution.
Ensure that the Executive action team (EAT) takes the responsibilities of cross-team coordination, continuous improvement, impediment removal, and delivery cadence while maintaining shared responsibility on the business metrics and OKRs and customer feedback.
Ensure that key Stakeholders are included in Executive MetaScrum (EMS). Without the senior agile leaderships who pioneers and do the walk, the transformation journey would always be lagging. True agile leadership and lean budgeting are crucial in S@S as an operating system and management 4.0.
These are key important questions and multiple dimensions that need to be addressed. These determine which framework / process / practice could fit for the business agility goal and ways to adapt it to fit the needs of the organization.
What does not work: There is no place where applying any framework by book would work as expected. The most important task of any Agile coach/transformation coach/change agent is to observe/study the organization, find out what could work and what might not work. Build a formidable guiding coalition of volunteers (EAT) that will support the transformation and adapt frameworks/practices to suit the needs and the organization design.
No Agile framework is one size fits all, neither a silver bullet promises for all organizational structure, size, and challenges. The key fundamental is to understand what scaling means to the organization and find the best possible ways of solving the problem by adapting already existing framework to the needs of the organization.
What could also be a challenge is when all the teams are not using Scrum. I have seen it as a big challenge, trying to get teams that work in Kanban way to follow the rituals in scrum. The resistance is huge especially in organizations that adopted Scrum instead of adapting it.
To continue with this series, click here for Factors to consider and best approaches for effective team alignment is scaling structures.
About the Author
Ejikeme is an servant leader with decades of experience in Software industry. He has worked with SMB and Large companies in Africa, North America, and Europe. Ejikeme holds BSc. in computer science and MSc. in Software project management. He is passionate on growing self manage team and organisational Business agility. 'We/Us' sounds better than 'Me/I.'