Anatomy of a Self Organizing Team

What does it mean by a ‘Self-Organizing team’?  Or it’s just an euphemism for something else? Or even worse-it’s just a fancy term?

This particular entry is a result of my relentless pursuit in search of a ‘Self Organizing’ team. I have always doubted the existence of such mythical teams, however my perseverance made me search for them whatsoever. In this short presentation, I would like to present the experience of my journey and observations on the anatomy of such teams. However reluctant I was, I decided to add some data points to my personal journey to make it more sellable. Fortunately, few of the observations are not very different from the accepted reference points. Hence I would also refer to the group behaviors explained by various psychologists like Sigmund Freud, Eric Berne etc in this short talk.

 
2 favorite thumb_down thumb_up 6 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Problem Introduction
  • Theory behind group behaviors
  • My Script, Your Script and Our Script
  • Co-Created Relationships
  • Who is the alpha?
  • The Anatomy: Illusion of Control and Rewards
  • Principle Based Teams Vs Rule Based Teams
  • Discussion and Closure

 

The presentation will be based on examples and practical scenarios from projects.

Learning Outcome

  • Helps to understand group behavior in the software teams
  • Helps in team coaching

Target Audience

Scrum Masters and Agile Coaches

schedule Submitted 4 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Deepak Dhananjaya
    By Deepak Dhananjaya  ~  1 year ago
    reply Reply

    Hi Karthik,

     Considering the topic and sub-topics, would 20 mins be sufficient for the talk to be effective?

    You have also used key words like "alpha", "Script", are the referenced from some models or study? would be good to know the references.

    Deepak

  • Karthik Kamal Balasubramaniam
    By Karthik Kamal Balasubramaniam  ~  4 years ago
    reply Reply

    Hi Deepak

    The idea is to keep the session short and just give a perspective about the nature of the self organizing teams . However, I also intend to touch on the concepts like "Script" and "Alpha"  to give an idea about group behaviour and will not discuss those proven concepts in detail. Since, there are no activities planned during the session, I will be able to cover these topics in 20 minutes.

    Please do let me know if you still think it will take more time.

     

    Regards

    KK

  • Karthik Kamal Balasubramaniam
    By Karthik Kamal Balasubramaniam  ~  4 years ago
    reply Reply

    Thanks Joel :)

    I have not presented this topic in any of the forums, but have been discussing this with my teams for a while now. 

    And yeah, results would be the crux of the presentation. However the idea here is to demystify the concept of self organizing teams and to learn from them. Also, to extend the 1-0-1 interaction to the concepts of group behaviour and work around them to create successful teams.

     

    Regards

    KK

  • Joel Tosi
    By Joel Tosi  ~  4 years ago
    reply Reply

    Hi Karthik,

       A very nice submission.  Have you presented this anywhere before?  Would you be able to give the 'result' of your research or would that give away too much?

    Thanks,

    Tosi

  • Karthik Kamal Balasubramaniam
    By Karthik Kamal Balasubramaniam  ~  4 years ago
    reply Reply

    Hi Vijay

    Thanks for your feedback.

    Yes, you are right. This topic will be more appropriate in the 'Agile Lifecycle' category. I will do the needful. 

    Regards

    KK

  • Vijayanand Nagaraj
    By Vijayanand Nagaraj  ~  4 years ago
    reply Reply

    Hello Karthik,

    This seems to be a good abstract and it will be interesting to hear experiences of your journey. However, I feel its a misfit into the Scaling Agile Adoption Theme? The abstract is about how to build a self organizing team while following the "Agile lifecycle". So do u feel it is better suited for Agile Lifecycle theme?


  • Liked Karthik Kamal Balasubramaniam
    keyboard_arrow_down

    Karthik Kamal Balasubramaniam / Deepak Dhananjaya - I am OK, You are OK

    45 Mins
    Workshop
    Beginner

    There is a level of "assumptions" that each one of us work with, while we deal with any system. Here in this case the system could be a team member, the manager, the management, or the entire organization. While we work with assumptions, the conversations or the discussions or the work we do, can seem like getting nowhere because of the conflicts, and a sense of frustration piles on .This is a common situation and a very common feeling amongst Coaches/Scrum masters/Project Managers or anyone dealing with project management scenarios. That is where "contracting" helps us get our way through!

    Contracting is a concept of "Transactional Analysis" school of psychology. Eric Berne defines it as "an explicit bilateral commitment to a well-defined course of action". Sometimes contracts will be multi-handed - all parties to the contract will have their own expectations. In the unusual event that these are all congruent, then fine. However, if not, then discussing everyone's expectations will lead to greater understanding and therefore to a clear contract. The risk in not doing this is that problems in completing the contract will emerge at some stage.

    3 Categories of contracts are administrative, professional and psychological.

    Administrative contracts deals with the operational agreements- like fees, who has to do what, time, frequency, attendees etc.

    Professional contracts deals with the expectations from each role and clarifies the essential setup required to achieve the same

    Psychological contracts talks about how we work as people and help to understand how we express our comforts/ discomforts       

    Amongst the three contracts psychological contracts are very essential and often ignored in projects. This type of contract will help us co-create any assignment and it’s a powerful tool for Agile coaches while they work with their teams, managers, organization etc.

    Further to agree with any contract, both the parties should operate from a space where there is mutual trust and concern (I am Ok , You are Ok).

    This report will discuss in detail about these contracts with examples from Agile projects, in an activity based sessions. We will also discuss the life positions based on 'I am OK, You are OK' theory.

    Note: Please note that this presentation is not about the business/financial contracts that most of us are aware of. However, the framework of contracts could be applied in any situation including the business/financial contracts.

  • Liked Gopinath R
    keyboard_arrow_down

    Gopinath R - 3Cs for Agile Project Success - Critical Success Factors & Proven Practices

    20 Mins
    Experience Report
    Beginner

    Agile methodologies are gaining wider acceptance in Software Development and Testing due to its inherent values like Accelerate Time to Market, Eliminate Waste and flexible to adapt changes quickly. Agile practices emphasis on effective communication, collaboration and customer involvement for addressing the challenges in developing the product in dynamic business environment due to fast changing requirements. The co-location of project teams and high customer interaction throughout the project helps in achieving effective communication, team and customer collaboration.

     In an outsourced or offshore Software development, teams are geographically distributed to develop products in a collaborative and cost-effective manner by better utilization of global talents. Adopting agile methodologies helps in better ROI by developing quality products as per changing market needs in short span. Adopting Agile in global software development shall pose few challenges due to wider geographical distance, time zone differences, and cultural aspects and so on.

     

    This paper presents 3Cs – Communication, Collaboration and Customer Involvement as Critical Success Factors that need to be considered while implementing Agile for Global Software Development. It also details proven practices to address the challenges due to distributed agile software development. This paper is based on Author’s experience in executing Outsourced Product Development engagements using Distributed Agile Methodologies for co-creating Telecom products

  • Liked Naresh Jain
    keyboard_arrow_down

    Naresh Jain - SAMPLE PROPOSAL - Product Discovery Workshop

    Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 4 years ago
    Sold Out!
    90 Mins
    Tutorial
    Beginner

    Many product companies struggle with a big challenge: how to identify a Minimal Viable Product that will let them quickly validate their product hypothesis?

    Teams that share the product vision and agree on priorities for features are able to move faster and more effectively.

    During this workshop, we’ll take a hypothetical product and coach you on how to effectively come up with an evolutionary roadmap for your product.

    This 90 mins workshop teaches you how to collaborate on the vision of the product and create a Product Backlog, a User Story map and a pragmatic Release Plan.

    This is a sample proposal to demonstrate how your proposal can look on this submission system.

  • Liked Prathitha Gangadharan
    keyboard_arrow_down

    Prathitha Gangadharan - Cycles of Development Applied to Teams

    Prathitha Gangadharan
    Prathitha Gangadharan
    DIRECTOR QUALITY
    ARICENT
    schedule 4 years ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    In her theory of cycles of development, Pam Levin talks about 7 stages a human being goes through from birth to becoming an adult. Each of these stages have unique requrements for any individual. The way the environment responds to the individual in each of these stages will determine how the individual will make sense of themselves with respect to their environment.

    Interestingly an individual goes through these stages when they enter a new situation. This could be as simple as walking into a roomful of new people or when they join a new team, or an organisation. Each one has their own own pace. While this is very logical for an individual how is this related to Agile?

    I have seen that teams also go through stages in their development. This is not just the forming, norming, storming and performing stages which is the internal process of a team. This is about the team being identified as an entity and being supported in their journey of becoming a high performing team. In understanding the cycles of development, we get some clues of what needs a team may have at different points in their journey to becoming self-organised.

    I would like to discuss Dr.Pam Levin's model in the context of a team and propose do's and don'ts that can support the journey of a team

    The seven stages:

     

  • Liked Karthik Kamal Balasubramaniam
    keyboard_arrow_down

    Karthik Kamal Balasubramaniam - 7 Deadly Sins of 'Agile- But' Teams

    20 Mins
    Experience Report
    Beginner

    This report is based on the analysis of the epidemic called ‘Agile-But-Teams’ in services organization. The presentation would cover the following 7 anti-patterns in such teams,

     #1 Fix ‘everything’ in your contract (definitely no breathing space) 

    Sign contracts with fixed scope and penalties. Ensure you include at least 30 metrics with fixed targets without accounting for team’s capability.

      #2 Don’t groom your requirements, make them look beardy and scruffy 

     Ensure your product backlog grooming is either not taken seriously or not done until the first day of the sprint.

     #3 Be a salary thief and never change a thing 

    Freeze your process steps in the beginning of the project and create checklists that would ensure compliance on a monthly basis. If possible, include mechanisms for tailoring and deviation, but never change the process.

     #4 Be loyal to the law of averages 

    Set organizational baselines for Agile teams and measure them periodically. Also, get RCA’s and reasons for missing the organisation targets.

     #5 Trust the pyramid and mummies 

    Adhere to the team pyramid structure and give the product responsibility to the identified leads.

     #6 Never Tell, Only Ask 

    Never change your product development/testing practices empirically instead implement industry ‘best’ practices based on case studies from other projects.

     #7 Make Self-fulfilling prophecies 

    Constantly discuss about, how Agile is not the right model for your project. Ensure your prophecies are fulfilled and there is no redemption whatsoever

     The presentation would also cover the possible antidotes for the scenarios and explain in detail about the behavioral sciences behind such patterns.

  • Liked Tim Born
    keyboard_arrow_down

    Tim Born - Scaling Agile/Scrum At An International Bank

    Tim Born
    Tim Born
    Executive Director
    JPMorgan
    schedule 4 years ago
    Sold Out!
    45 Mins
    Case Study
    Intermediate

    Scaling agile practices across thousands of people around the globe is challenging on many dimensions, yet it can be done!

    Besides the usual problems with timezones, languages, colocation and cultural friction, what are the key issues that make or break agile at scale?

    The answers may surprise you, since they may not be obvious unless you have already been down this path before.  There is surprisingly little literature and precious little practical experience being shared from people who have successfully flipped large organizations to become more agile.