The Team Manifesto: the foundation every team needs

Ideally, teams get the chance to select their own members, organize a kickoff and define a strategy to reach the given goal. Most of the time teams are created top-down and there’s no time available for a decent kickoff. Teams just start with the realisation of the project and everything seems to be going smoothly. But when the first serious impediments arise the foundation of the team will be tested. Teams with a solid foundation will also struggle in the beginning but survive and become stronger than before. Teams without this foundation might also survive after a harsh period, but chances are they fall apart and the project is killed and the team dissolved.

The first step in becoming a solid team is establishing a solid foundation. This foundation consists of a shared vision about teamwork and the required quality standards.

For this purpose, creating a team manifesto is the ideal instrument. It is an agreed way of working among the team members that ensures mutual understanding. Years ago I got inspired by this blog post, since then I’ve changed it slightly to fit new insights. With every team I start, creating the team manifest is the first thing I do, success guaranteed!

The steps are:

  1. Set a time box of one hour. Pick a flip over, some sticky notes and markers
  2. Ask the team the question ‘What does team mean to you?’
  3. Let them answer this question in silence and write it down on a sticky note. One answer per sticky note.
  4. Gather all notes and ask the team members to present it to each other
  5. Cluster the ideas and identify and prioritise the themes by voting
  6. Write down ‘Team Manifesto’ on a A3 poster and the 5 most important themes on the left side
  7. Give the team some time to brainstorm about the other extreme of the earlier defined themes. For example: the extreme of ‘fun’ might be ‘boring’.
  8. Write down all the extremes on the right side of the poster with in the center the word ‘above’.
  9. The last important step is to invite everyone to affirm their commitment to the team manifesto by writing down their signature below the poster.
  10. Make sure the team manifesto is well visible in the team area.

The same exercise can be done by posing the team the question ‘what does quality mean to you?’ This creates awareness about the required quality and stimulates craftsmanship.

What are the advantages of creating a team manifesto? Read the full article here: https://medium.com/the-liberators/the-team-manifesto-the-foundation-every-team-needs-c1d72ccfe689

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: https://hbr.org/2017/04/how-self-managed-teams-can-resolve-conflict

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: https://medium.com/the-liberators/playful-learning-with-improv-prototyping-18dc4ab4a304

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: https://agilescrumgroup.nl/agile-release-train/

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: https://www.linkedin.com/pulse/trying-out-mindmeld-liberating-structure-saskia-vermeer-ooms/

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: https://www.informationweek.com/devops/getting-devops-wrong-top-5-mistakes-organizations-make/a/d-id/1333173

Scrum And DevOps

DevOps is not about tools and automation in the delivery pipeline. In fact, as we have learned tools and automation is only one-third of DevOps. In overall, DevOps is about Collaboration & Collective Ownership, Focus on the flow of value delivery and Learning and experimentation culture. But sadly, many tooling vendors position DevOps as tools and process for the delivery pipeline. This will get the management excited because many managers think that after buying and installing the “DevOps” tools without changing their organisation will make their company instantly agile. This is like putting the cart in front of the horse.

In this article you can read that Scrum and DevOps actually share more in common than most realise. Just like how Scrum is not about tools and process, the DevOps Three Ways is also about values and principles: https://www.scrum.org/resources/blog/scrum-and-devops