Many teams suffer from dysfunction where they lack trust and have huge communication overhead. Can we fix it? I do not have directly plug and play solution for this but I have done some experiments in this area which I would like to share during this talk. 

 To give some idea things like following will get presented with real life experience

  1. Right Information radiators
  2. Culture of Accountability
  3. Transparency
  4. Fixing the Process or work allocation and monitoring
  5. Promote Healthy Conflict
  6. Show vulnerable side of you
  7. And many more… I am still exploring.
 
2 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Opening : 5 Min with Questions related to Team Dysfunction

Sharing Dysfunction Smells : 10 Min

What worked for us :10 Min

What did not work for us : 5 Min

Conclusion : 5 Min

Q&As : 10 Min

Learning Outcome

Better Understanding of team dysfunction 

Target Audience

Scrum Masters , Agile Coach

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Sanjay Kumar
    keyboard_arrow_down

    Sanjay Kumar - Refactoring Strategy for Big Design Smells

    60 Mins
    Case Study
    Intermediate

    Agile design or emergent design relies heavily on timely refactoring efforts that aim to improve existing design. Yet often, when the code base grows or when someone else's code is handed over to us, there is a reluctance to refactor existing code - despite an obvious design smell. While the reasons to avoid refactoring may be well-grounded – lack of time, lack of understanding or fear of breaking it – in the long term, delaying code refactoring makes the code rot further. And, as a result, technical debt continues to pile up.

    This session begins by reviewing common design smells, discusses five key features of good code and then discusses a common yet often overlooked design smell in detail – big methods. Using an example of a big method, it proposes a refactoring strategy that will ensure that a refactoring effort does not cause any negative side effects. During the session, participants are walked through a real code refactoring example – step by step.

    Though the session focuses on one particular design smell (big methods), the proposed refactoring strategy should apply equally well to other design smells too.

  • Liked Sridharan Vembu
    keyboard_arrow_down

    Sridharan Vembu - Over-selling the "Enterprise Agile Frameworks and Certifications"

    Sridharan Vembu
    Sridharan Vembu
    Head Engineering
    CreditMantri
    schedule 2 years ago
    Sold Out!
    45 Mins
    Talk
    Intermediate
    Agile is only for smaller projects and/or startup organisations - Not Anymore. Taking my own and my organisation's experience, Agile is a proven methodology that is well suited for delivering complex, distributed, multi-year enterprise programs, for many years now.
     
    While this is really a great thing for agile enthusiasts and practitioners, it’s a bit of worrying sign for me the increased recognition and popularity the ‘Agile Certifications’ and ‘Agile Frameworks’ are receiving among individuals and organisations who would like to adopt Agile to stay relevant in current world.
     
    I would like to share my views on the adoption of these frameworks and certifications, why I feel they are not-so-agile and how am I and my organisation are solving similar problems without the need for any of these frameworks and certifications.
     
    I am planning to walk through the complete life cycle of the most recent program that I’m part of (from Inception to Initiation to on-going Execution to Post-Production Support) and bring out the relevant agile principles that we adopted, context based customizations we did and the best practices that we have come up with.
    • For instance, one should know the clear difference between hygienic practices vs context based practices - the first ones are not to be compromised at any cost, whereas the latter ones are to be applied based on the need, not because some framework prescribes it.
    The typical life cycle stages that we follow in any program / project delivery is normally: Discovery - Inception - Initiation - Execution - Transition, whereas the actual set of practices within any of these stages and how they are being implemented could be very different from project to project, team to team. 
    • For example, in the Execution Phase, doing pair programming and following TDD are hygienic practices for us. Having said that, it’s perfectly okay for a pair to split and work on a specific task on a case-to-case basis (we call this Pragmatic Programming) and the pair decides when and how long they would split and when to re-join.
    To give an idea on the complexity, enterprise and distributed nature of the program, some key data points:
    • Started almost 3 years ago, on-going
    • 10 quarterly planning workshops done so far
    • 10+ teams, 7 timezones
    • peak program size: 250+
    • peak team size from my org.: 50+
    • total no of systems: 10+
    • geographical spread: plan: 100 countries, 132 locales launched so far: 53 countries, 56 locales
    • 140 page-views / sec
    • Av. response time: 1.3s
    • Handling 100+K products in the catalog, 15+ K pages , 300+ K responsive images
    • Blue-Green production deployment (zero downtime over 1.5 years)
    • 3 weeks cycle of production releases