An Exercise to Help Your Team Feel More Comfortable with Conflict

Have you noticed your organization becoming so focused on building a happy, engaged workforce that your leaders are becoming profoundly conflict-avoidant? I see examples of this all the time. One clue that your team is avoiding conflict is if the least bit of discomfort in a meeting causes someone to suggest that you “take it offline.” This, of course, triggers the meeting-after-the-meeting phenomenon — another hallmark of a conflict-avoidant culture.

You can normalize productive conflict on your team by using an exercise to map out the unique value of each role and the tensions that should exist among them. Here’s how. Draw a circle and divide that circle into enough wedges to represent each role on your team. For each role, ask:

1) What is the unique value of this role on this team? What should this person be paying attention to that no one else is? What would we miss if this role wasn’t here?

2) On which stakeholders is this role focused? Whom does it serve? Who defines success?

3) What is the most common tension this role puts on team discussions? What one thing does the person in this role have to say that frequently makes others bristle?

Read the complete article and other intersting articles related to handling conflict here:

Playful learning with Improv Prototyping

The purpose of Improv Prototyping is to re-enact a challenging scenario faced by a group or an individual and work together to devise different behavioural strategies and interventions by acting it out. The twist that this structure brings is that the person who introduced the scenario becomes the ‘director’, while the others become the ‘actors’. This allows the director to playfully experiment with strategies, behaviours and interventions.

Read the complete article here:

Wat is een Agile Release Train? [in 10 stappen aan boord]

Hoe ziet een Agile Release Train (ART) er eigenlijk uit, en wat is een ART als je het hebt over SAFe? De stappen die de Agile Scrum Group beschrijven vertellen je wat een Agile Release Train is en wat er nodig is om een ART op stoom te brengen.

  • Hoe start je met een Agile Release Train?
    • SAFe opleiden:
    • Train je Agile leiders
    • Value Stream Maps en de eerste ART
    • Set-up van de ART en de teams
    • De belangrijkste rollen binnen de ART
    • Opzetten van de Backlog
    • Opleiden van de teams
    • PI planning
    • Uitvoeren van de eerste PI
    • Op basis van een Inspect en Adapt workshop wordt het deelproduct uit de PI geëvalueerd

Leees de complete blog-post hier:

Trying out MindMeld – a Liberating Structure in development

MindMeld is a microstructure still in development, which means it’s not yet part of the 33 in the LS menu, but it is a promising one in the works. MindMeld is a combination of forming Mindmaps by using the structure What, So What, Now What? (W3). Saskia Vermeer-Ooms has used W3 several times and she thinks it is a powerful structure to use when you need your audience to come up with concrete actions of a certain challenge. You do this by first taking two other steps in which you take the time to observe the data available before drawing conclusions and moving into action mode.

Read about her experience with MindMeld in this post:

Getting DevOps Wrong: Top 5 Mistakes Organizations Make

DevOps is all of the following:

  • A cultural shift in how processes, code, and technology are delivered.
  • A philosophy around continuous development and integration with users, business, and even market dynamics.
  • A practice that continuously evolves.
  • A tool to help deliver services and applications and market-ready speeds.
  • A process to help companies innovate at a much faster pace than what traditional (or legacy) software tools and infrastructure could offer.

Bill Kleyman made a list of the top 5 mistakes organizations make while deploying DevOps:

  1. You’re still using checklists, runbooks, or other manual processes to manage code.
  2. Your release cycle happens every few months (or even years) and deployments keep you awake at night.
  3. Your developers feel that their role ends at deployment.
  4. You focus on tools over culture.
  5. Your people are still in silos.

Read the complete blogpost here: