Using Socio-technical Systems theory for self-organized teams
One of the core aspects of Scrum is self-organizing teams that deliver software in small iterations called sprints. For those who try to move from traditional development models to Agile, one of the major challenges is forming self-organizing teams. The sprint teams are truly cross-functional teams that choose the best way to do their work without being directed by others from outside.
Are there any design principles or theoretical frameworks that can help us go about forming such teams ? What would be the desired design for team structure and control? If such teams are meant to be more "open" for customer collaboration and adaptive to environmental changes, what are the design criteria one should apply? How can the team regulate itself and make decisions concerning its own work arrangements?
Socio–technical systems theory offers to answer such questions as what is the fundamental unit of work design (individual or team), where should the locus of control be, what are the conditions for self-organizing teams to form (task differentiation, boundary control and task control), etc
Socio–technical systems(STS) theory is a body of theoretical and empirical work which seeks to improve productivity and human enrichment by focusing on the inter dependencies between people, technology, and environment. A definitive outcome of this theory is the development of self-organizing work groups.
STS theory defines work systems as having both technical and social subsystems. A technical subsystem concerns the tools and processes that are needed to create products and services. The social subsystem concerns the work structure that relates people to the technical subsystem and to each other.
This session is about throwing light on the theoritical basis of self-organizing groups, which is STS, and how using this knowledge of this theory, organizations can build self-organizing teams which are effective and successful.
Outline/structure of the Session
1. History and Background of Socio-Technical Systems (STS)
2. Core Design Concepts of STS
a. Unit of Job Design
b. Locus of Control
c. How does this apply to Agile self-organizing teams
3. Conditions for Self-organizing Teams
a. Task Differentiation
b. Boundary Control
c. Task COntrol
d. How does this apply to Agile self-organizing teams
4. Validating STS application using other theoritical frameworks
A systems theory perspective helps to link the various aspects of an organization or a system in general and understand how one part interacts and affects the other. Understanding the theory behind any system helps us to gain insights on why certain things work and why certain things don't work.
Socio-technical systems theory and it's application to the Agile team structure will help the audience to know how the job design and the team structure and it's expectations, skills, satisfaction, autonomy, etc are linked. Simply stated, this theory helps us to understand how the social system and the technical system interact with each other, how do we create conditions for enabling this interaction effectively, that will maximize the performance of a self-organized team.
scrum masters, organization leaders, organizations who are looking at transitioning to Agile
schedule Submitted 3 years ago
People who liked this proposal, also liked:
Krishnamurty VG Pammi - Lean Scrum - The need of the hourKrishnamurty VG PammiAgile CoachIVY Comptech
schedule 3 years agoSold Out!
The 2015 state of scrum report published by Scrum Alliance states that the outlook of scrum is highly favourable. Virtually all consider it likely that their organization will use scrum in future. While this is good, the survey also noted one of the key challenges observed by survey respondents as “Product owners and teams were just not willing and/or enthusiastic about Scrum best practices”. Thus, although scrum methodologies have greatly increased productivity, scrum is not without its problems. We need to quickly address this gap.
Keeping scrum values at the core, scrum methodology is mostly visible to teams on the ground in terms of three pillars (1) Scrum roles (2) Scrum artifacts and (3) Scrum events. While Scrum has kept scrum roles and scrum artifacts lean, it has empowered teams on the ground to learn the art of performing scrum. Scrum prescribed guidance on scrum events with clear purpose, frequency, maximum duration and recommended attendees. It recommends teams to learn the art of performing scrum events through their experience stating “scrum is easy to understand and difficult to implement”
While some scrum teams mastered this art, I find most of the scrum teams are still struggling in this process. I come across situations where teams are not finding scrum events interesting primarily because they find these events unproductive. The result is that we see less interactions and cooperation from the teams during scrum events. This is impacting basic agile manifesto “Individuals and interactions over processes and tools". In net, there is no surprise when product owners and teams were just not willing and/or enthusiastic about Scrum best practices.
Lean Scrum is the need of the hour. As part of lean scrum, we will adopt scrum methodology at the core and we implement lean framework to address the pain areas witnessed by teams
As part of this talk, I will share my experiential insights on
- Outlook of scrum is highly favourable. Although scrum methodologies have greatly increased productivity, scrum is not without its problems. We need to quickly address these gaps
- While scrum has kept scrum roles and scrum artifacts lean, it has empowered teams on the ground to learn the art of performing scrum events. Are we keeping these events lean and Valuable?
- Lean scrum – The need of the hour
- What is Lean Scrum
- Anti-Patterns/Most frequently faced challenges/ wastes experienced by scrum teams in each of the scrum events (case findings based on my experience)
- Where do the scrum teams stand on "expected scrum patterns" in each of the scrum events (case findings based on my experience)
- Leverage "Lean Framework" to craft scrum events towards value generation. How to draw "AS-IS" and "TO-BE" Value stream management maps for two scrum events.
- Leverage "Lean framework" to help scrum teams to learn the art of performing scrum events through realizing value and enhancing their reach on "expected scrum patterns".
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” The term value is increasingly becoming starting point of what we do. We need to keep questioning everything we do using customer value generation as the yard stick
Unless, we drive scrum events towards value generation by continuously eliminating waste/ anti patterns, there is no surprise that “Product owners and teams were just not willing and/or enthusiastic about Scrum best practices” as observed by "The 2015 state of scrum" report.
This is where Lean-scrum could prove to be powerful...