Islam Ismail on collaboration Anti-Patterns

Great teams live and die by their ability to collaborate. Collaboration is a key skill for all in the team. But what can we do when that collaboration is not emerging? Islam shares a story of a team that exhibited several collaboration anti-patterns, and what we can do as Scrum Masters about it.

About Islam Ismail

Islam Ismail is a senior agile project manager and Scrum Master at Wirecard Technologies GmbH in Munich, Germany. In his current role in PMO and with teams he focuses on scaling agile and unifying processes across divisions.

He was an electronics engineer for five years and a technical manager for six years before making the switch to software in 2011.

Fueled by his passion for the agile field, Islam moved to Munich, Germany, in 2014 where he enriched his knowledge and experience.

Outside of work, he enjoys reading, traveling, playing soccer with friends and spending time with his wife and two lovely daughters.

You can link with Islam Ismail on LinkedIn and connect with Islam Ismail on Twitter.

Islam Ismail on the dangers of mixing Team Member with Product Owner role

The roles in Scrum were created for a reason, trying to “merge” those roles into one person comes with many dangers. In this episode we explore the case of the senior tech lead who was also the Product Owner for the team, and the problems that come from that.

Islam also shares tips on how to deal with that case, if you have to face it.

About Islam Ismail

Islam Ismail is a senior agile project manager and Scrum Master at Wirecard Technologies GmbH in Munich, Germany. In his current role in PMO and with teams he focuses on scaling agile and unifying processes across divisions.

He was an electronics engineer for five years and a technical manager for six years before making the switch to software in 2011.

Fueled by his passion for the agile field, Islam moved to Munich, Germany, in 2014 where he enriched his knowledge and experience.

Outside of work, he enjoys reading, traveling, playing soccer with friends and spending time with his wife and two lovely daughters.

You can link with Islam Ismail on LinkedIn and connect with Islam Ismail on Twitter.

BONUS: Melissa Lang on using Nonviolent Communication as a method to build stronger teams

Nonviolent communication is a method of a communication process developed by Marshall Rosenberg beginning in the 1960s. It focuses on three aspects of communication: self-empathy (defined as a deep and compassionate awareness of one’s own inner experience), empathy (defined as an understanding of the heart in which we see the beauty in the other person), and honest self-expression (defined as expressing oneself authentically in a way that is likely to inspire compassion in others).

Melissa was made aware of Non-violent communication via the work of Bob Marshall (check out his episode on Scrum Master Toolbox Podcast), and his blog where he published several articles about Nonviolent Communication. Thanks to this work, and some of the Marshall Rosenberg Nonviolent communication videos on YouTube, Melissa got started with NVC. A journey that changed her view of communication and what matters when it comes to building stronger teams.

But how can we, as Scrum Masters benefit from this method?

A simple context where NVC may be useful is when teams and team members want to get and give feedback. NVC can be very useful to phrase our feedback in a way that highlights what we are looking for (our needs being met) without expressing judgement over others (our opinions of them). But that’s only one of the contexts where NVC may be useful. There are many others.

I bet your team has a lot of written communication with stakeholders and within the team. Is that right? Well, then you know that written communication has a lot of potential for misunderstandings and to generate conflicts. How can we avoid that? By using better approaches to communicate. Melissa also explains how we can use NVC ideas to make written communication less conflictuous and more likely to have the impact we hope.

What we need to be able to communicate effectively

NVC is a good method to structure our communication, but before we can use that method we need to understand how we feel. NVC, being a needs/emotions driven communication method requires us to be aware of our own emotions and feelings. So we need to learn about emotions and needs. And especially we need to enlarge our vocabulary about needs and feelings so that we can communicate them in a way that is understandable by others. This is especially important if you are not a native speaker of the language you use at work.

Where should I get started if I want to know more about NVC?

When it comes to getting started with NVC, Melissa has a few recommendations for us. The first is the book by Marshall Rosenberg: Nonviolent communication, A Language of Life, but is also very important to practice every part of the method as well as read and learn about emotions, feelings(PDF) and needs.

In this episode Melissa also shares simple practices you can take into use immediately to help you practice NVC and help your team learn about, and maybe even get started with NVC.

About Melissa Lang

Melissa has worked in many diverse jobs over the last 20 years: ethnomusicologist, cook, IT project manager, agile coach. In all of those jobs, her main focus has been on strengthening team work and facilitating communication. As a dedicated agilist for 10+ years Melissa has worked at a range of companies, from start-up to multi-national corporation. Currently she is coaching teams from Barcelona and Hamburg at Xing AG where she has been employed since December 2011.

You can connect with Melissa Lang on Twitter and link with Melissa Lang on XING or LinkedIn.

If you want to follow Melissa’s writings, be sure to follow her blog over at Medium.

 

Constellations dynamic for retrospectives

Total time: 60-90 minutes

Purpose

The purpose of this dynamic is for everybody to participate and share their feelings, perceptions and opinions without even talking (at first).

Benefits

  • For the team: They can see themselves and understand their colleagues from a different perspective, they can really feel others because they are not talking or trying to gain their position within the room. They just observe, feel and act their feelings.
  • For the facilitator: There is something so powerful about standing in a circle. You know it if you do your daily meeting. We can immediately see the whole picture, the real feedback from the team without mixed perceptions or words, which generally cover the real significance. We can say: “bodies don’t lie”.

Objectives

  • Empathy building.
  • Address and specify the situation the coach is sensing and the team doesn’t feel like talking about this for of any reason (e. it’s too painful, they feel uncomfortable, and some team members are unaware).

What you need – Preparation

  • Find out the number of participants first: The room where the retrospective will be run must have enough space for everybody in the team to be able to stand up in a circle (and move from a tight to a larger circle).
  • Adhesive tape: to post the cards on the wall or board before the discussion.
  • An element or object: big enough to serve as a reference for the responses, noticeable and “good looking” (I wouldn’t recommend a trash bin), and not so distracting or not so high that participants can’t look at each other’s faces. (e., it could be a mini statue, an umbrella stand, or a little circle drawn in the middle of the room).
  • Write down statements or questions: to read out loud on cards so the team can express their response about these topics.
    • Statements examples:
      • I feel free to express in this retrospective.
      • I am satisfied with the results of this sprint.
      • I am happy with the quality of our code.
      • I consider our releases are easy and smoothly delivered.
      • I think my daily work is recognised.
    • Question examples:
      • Do you feel safe enough to be able to express in this retro?
      • Are you satisfied with the team collaboration?
      • Do you consider the technical debt has been reduced in this sprint?
      • Do you feel motivated in your daily work?
      • Do you think you are making an impact on people’s lives with our product?

How to run the retrospective

A. Introduction (1-5 minutes)

  1. Brief check in: Make sure the team is relaxed and ready to start. A brief check in exercise can help to set the environment.
  2. Explain the rules: Position the element in the centre of the room to act as a reference for the team members. No one is allowed to talk during this exercise. Only explain that standing closer to the object will mean “YES”, “I TOTALLY AGREE”, while being farther will represent of “I DON’T AGREE”, “NO”.

B. Running the exercise (10-15 minutes)

  1. Read the cards out loud one by one and leave time for the participants to respond with action.
  2. Observe the situation: They will individually respond by getting closer or farther from the object. You will notice people in between: “I AM NOT SURE” or “MAYBE”, just watch. Take mental notes, or have someone external to the team help you with the notes.
  3. Ask the participants about their feelings: Listen closely to what they went through during the exercise. You will notice the different reactions and realisations. That input is invaluable for you as a facilitator to go on with the discussion. Sometimes the participants are so amazed they need time to stay calm and reflect about what had just happened, especially when one of the topics was revealing for the team. Maybe a relaxation exercise is handy here, if necessary.

C. Sharing thoughts (10-15 minutes per topic)

  1. Post the cards on the wall and vote: Tell them to vote prioritising the situations according to what they consider critical to address now for the team.
  2. Select the topics: The most 2 or 3 voted topics will be discussed in pairs or mini teams of 3 or 4 people, according to the time left for the retrospective.
  3. Discuss: Start by the most voted one first. Set the time for discussion. Let the conversation begin!

D. Taking action: (15-20 minutes)

  1. Share results: After each topic discussion, share their opinions, proposals, options and work to find the next steps to follow.
  2. Make a commitment: The result may be an experiment to try: set the hypothesis, metrics, who will be accountable, and time to check again.

Powerful questions:

  • How does this topic make you feel?
  • Do the other team members feel the same? Why?
  • How can you contribute a solution to the situation you have just found?
  • What could we do to improve this particular subject?
  • Is there anything else creating this perception?
  • Where can we start? Who else can we involve in the solution?
  • Why is this important for the team?

Additional tips, comments and alternatives:

  • It is very important to find the right questions/statements for the team to elicit reflection, especially when you already know the situation, and they can’t see it yet.
  • Questions and statements are good for The participants tend to repeat them in their heads, so they get to their feelings and act accordingly.
  • Follow a defined format, questions or statements. Following all at the same time might be confusing.
  • Choose a maximum of 10 topics to avoid losing focus.
  • The topics can be technical, human, process or product related; there are no limits here. You could even use this dynamic for an agility assessment, where the statements or questions are related to the agile principles.
  • It has been very useful to me during facilitation in almost any case, with people; talkative or shy, who were new or had been working together for several years, who weren’t participating too much lately in the retros, and so on.

Special thanks

Thanks Vasco Duarte for bringing up the subject in your podcast: Scrum Master Toolbox

About Carolina Gorosito


Carolina is a natural connector and team enabler, great at finding people’s strengths and helping them combine their skills to become high performers in the organisations and obtain better results every day. She currently works as an Agile Coach and is a dedicated Creative Change Agent, specialised in problem solving and communication.

You can link with Carolina Gorosito on LinkedIn and connect with  Carolina Gorosito on Twitter.

Anssi Lehtelä on Systems Thinking for Scrum Masters

How do we understand the system conditions affecting our teams? Anssi shares with us how he does that, and why his approach is important for Scrum Masters to get a good grasp of what Systems Thinking is really about.

In this episode we refer to Gerald Weinberg’s Introduction to General Systems Thinking book, a good primer for those interested in learning more about Systems Thinkin.

About Anssi Lehtelä

Anssi is a new born optimist, team work enthusiast, and a big supporter of get more done by doing less things. Developer , tester, and the “process guy”. You can link with Anssi Lehtelä on LinkedIn and connect with Anssi Lehtelä on Twitter.

Anssi Lehtelä shares 4 areas for Scrum Master success

Anssi shares his 4-area model for Scrum Master success and also some of the indicators and metrics he uses to evaluate his own work.

About Anssi Lehtelä

Anssi is a new born optimist, team work enthusiast, and a big supporter of get more done by doing less things. Developer , tester, and the “process guy”. You can link with Anssi Lehtelä on LinkedIn and connect with Anssi Lehtelä on Twitter.

Anssi Lehtelä explains how to achieve big changes with small steps

Change brings uncertainty, fear and perhaps even chaos to teams and organizations. Change processes can be forced and cause more problems than what they are supposed to help with. How can we avoid this? How can we bring in the necessary changes, perhaps even big changes, without causing chaos? Listen to Anssi as he shares one such story with us. In this episode we talk about the Lean Change Management book by Jason Little.

About Anssi Lehtelä

Anssi is a new born optimist, team work enthusiast, and a big supporter of get more done by doing less things. Developer , tester, and the “process guy”. You can link with Anssi Lehtelä on LinkedIn and connect with Anssi Lehtelä on Twitter.

Anssi Lehtelä on how changes in team composition can destroy teams

Teams evolve, people move on and new team members join the team. Those moments are prime candidates for disaster. New team members bring new ideas and they change the internal team dynamics. This, in turn, can lead to chaos and problems. How can we avoid such problems? Listen to Anssi’s story and what he recommends you take into account if you are about the hire new team members.

About Anssi Lehtelä

Anssi is a new born optimist, team work enthusiast, and a big supporter of get more done by doing less things. Developer , tester, and the “process guy”. You can link with Anssi Lehtelä on LinkedIn and connect with Anssi Lehtelä on Twitter.

A “Positive” Retrospective

One of the Agile principles states that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” These “meetings” are more likely called Retrospectives and can be held in many different formats (here are some examples https://trello.com/b/40BwQg57/retrospective-techniques-for-coaches-scrum-masters-and-oth er-facilitators and http://retrospectivewiki.org/index.php?title=Retrospective_Plans)​. The most famous is the “Mad, Sad, Glad” format, and many others are just variations of this very basic format.

These formats are based on the aim to analyze the previous team’s activities in order to achieve better results. Sometimes, it may also help to analyze the successes of the team in order to understand what helped in achieving them and how to replicate such successes: that’s what I call a “Positive Retrospective”.

The period we may wish to analyze may vary; last iteration, last month, last year and so on. What do we need to organize this retrospective? The usual materials such as some stickers, pens and a whiteboard or a flipchart.

The first action to take is to create a collaborative and positive atmosphere, so ask the attendees to write down some few words of appreciation for a colleague (or more), thanking him/her for something he/she did during the given period, for the person or for the team. Give the team 5 minutes to write.

Then ask each attendee to read aloud what they wrote, speaking to the colleague they want to thank. This phase shouldn’t take more than 5-10 minutes.

The next phase is to list all the positive results achieved in the period.

Ask the attendees to write down on the stickers all the positive results achieved, using a short statement (one per sticker) – they will be given the opportunity to explain in the next phase. Give them 5 minutes to write.

Now ask the attendees to explain the individual positive issues, one by one. They should be concise in their description but still be able to let the other attendees understand the issue. Then the sticker is pinned to the whiteboard. If any other attendee has a similar issue, he/she has to discard it. Please be careful to avoid starting any discussion. This is the time to list the results and not to discuss them (moreover, the discussion will be shaped in a particular way, as we will see in the following stage).

Once everybody has explained their issues (this stage should last no more than 10 minutes), you’ll have all the stickers on the whiteboard. It’s time to vote.

Each attendee will have six votes to give to the issues stuck on the whiteboard: three votes to vote the issues by its intrinsic or technical value (for example, the team reduced the technical debts by 50%, or has stabilized the daily standup) and three votes to vote the issues by the positive impact it had on the product (for example, thanks to this new feature, the customer increased his sales by 20%). You can use any means to vote: in my example, we used little red self-adhesive dots for one and green for the other, but you can use different signs, different colored pens, and so on.

Why differentiate this way? The answer is easy: teams tend to identify their success with the product’s success; we delivered this feature, the customer were happy, we eliminate that bug and so on, forgetting that with success stories, many other aspects must ​ be considered. For example, adopt a more effective framework for the chosen programming language, start unit testing, practice a scrum ceremony in a more efficient way and so on. The team must learn these positive issues as well, as they allow the team to be more effective ​ (as per the above mentioned Agile principle).

Once the voting is finished, just rank the issues by the numbers of votes (any kind).Voting and ranking shouldn’t take more than 5 minutes.

Once the stickers are rearranged on the whiteboard (the most voted ones are on top) you can start to discuss. The format may be free (you can discuss any issue as long as you want), or fixed (an issue can be discussed for a maximum amount of time of 5 or 8 minutes, for example). Choose the format you like, what counts is the discussion itself.

Ok, let’s discuss, but about what? We usually discuss what’s going wrong, and how to fix it. Now, here instead, we’re discussing what went right! Well, we can first identify what made that positive issue possible. Usually, we can identify two main paths: one internal to the team, and one external. The internal one refers to all the actions the team takes to achieve a result, which may impact the team, the process or the product. For example, by autonomously adopting a new programming framework the team was able to deliver those given features and the customer was very happy. Note the ​ word “autonomously”: the team was not forced by any external entity to take that decision, but reached a result that had an external impact anyway.

The external path refers to all those actions taken or conditions set up by the system (your department, your local agency, your company, and so on) that made it possible to achieve that given result. For example, the team was able to learn how to deal with noSQL databases thanks to a dedicated budget for training on new and emerging

technologies/methodologies. In this case, an external reason made it possible to achieve an internal positive result. Nevertheless, we mean to say that an internal result will sooner or later reflect itself into an external positive result (or at least, this is what the system hopes…).

The discussion stage may last up to 50 minutes, to keep the whole retrospective no longer than 2 hours.

And now, just like any Retrospective worthy its name, let’s write down some action points.

Like any positive issue in any field, we aim to replicate it and also do something to improve that experience to feel even better. So we can define the underlying actions that will lead us to even better results. Some questions easily come to mind: can we replicate the positives we had during the period, applying them to current or new issues? For example, we may ask for a new course to learn a new language to create a new software asked by our customers. Or, can we improve the path that led us to have positive results to have better results or even the same results but in different areas? For example, improve the continuous integration process to have a faster/safer deployment of our deliverables.

Or just have more frequent retrospectives to improve our work!

Discussing and writing the Action Points may take up to 20 minutes.

Now the meeting may be closed. See you next Retrospective!

About Enrico Di Cesare

Always interested in improving the quality of the software produced for himself or for his customers, Enrico became an Agile enthusiast as soon as he discovered it. With extensive previous experience as a Project Manager and Coordinator, Enrico works as an Agile Coach, Scrum Master and Product Owner, introducing, mastering, facilitating and refining the adoption of Agile with new collaborative tools.

Anssi Lehtelä shares an alternative to formal retrospectives

Retrospectives can sometimes become just formalities and fail to deliver improvements, or worse: fail to motivate the team to improve the way they work. Anssi shares with us a story of such a situation and his own alternative to formal retrospectives that he still uses today. Do you have retrospectives that fail to deliver value? This episode is for you!

About Anssi Lehtelä

Anssi is a new born optimist, team work enthusiast, and a big supporter of get more done by doing less things. Developer , tester, and the “process guy”. You can link with Anssi Lehtelä on LinkedIn and connect with Anssi Lehtelä on Twitter.