Share goals and make the difference

chuzzeteAgile Coaching, Coaching teams from forming to performing, Participating-Supporting, Selling-CoachingLeave a Comment


During the Agile Team Development Canvas 2nd. iteration experiment, I worked with a small Scrum team composed by two (2) developers and its Product Owner. This team does support(operational stuff) and develop new  features at the same time, and it’s considered a service team, which means that its mission is to help other teams within the division, to reach their goals.

This team seems to be in the middle of a transition between the storming and the norming stage of Tuckman’s group development model, as I could verify after completing the questionnaire that I’ll share in my twitter account once this post get published.

Here is what we’d experienced:


The Sprint

1) At the beginning of the sprint, the team committed to deliver all features missing to push live new a website.

2) The Product Owner went in vacations during at least 50% of the sprint.

3) The team was interrupted several times with support stuff during the sprint.

Sprint outcome

  • The team delivered 50% of what they committed to deliver at the beginning of the sprint.
  • A “new tool”, non related with the website that was promised to be completed by tje end of the sprint, was delivered and push to production, so the stakeholders where highly satisfied and impressed with the features and the value that it will be bringing to the company since now on. 😀

Sprint Review

  • Although the sprint wasn’t completely done, the stakeholders evaluated the team positively, given the value that the team delivered by releasing the “new tool”.

Sprint Retrospective

  •  The Product Owner told the team that he wasn’t satisfied with the sprint results, and he mentioned that trust was broken between him and the team.
  • The development team wasn’t happy because they were convinced that they were doing it well, although they couldn’t complete the sprint as promised.

Behaviors observed

a) Communication was lost, both sides were talking about what happened during the sprint. The development team was trying to explain about interruptions and how support stuff make them lose focus when developing the web site and how that impacted their rhythm during the sprint. At the other side, the Product Owner was extremely deceived about the team not completing the sprint commitment, although he acknowledged the impact that support stuff caused on losing team focus when they were developing new features. At some point, it was hard to make them see that everybody was talking about the same thing.

b) Frustration started to raise, so the mood in the room was heavy, someone raised its voice and it seems that the sprint retrospective was about to be finised in a total disaster.

c) Emotion instead of reasoning, when discussing about the sprint, I felt that at some point we stopped discussing about facts and started taking things personal.

d) Almost Zero listening, EVERYBODY was unable to listen each other.

Scrum Master Challenge

How to transform that non constructive conversation into something productive?


once that happen, I recommend you to do follow thiese tips:

Put on your coaching hat.

  • Listen carefully what IS been said.
  • Let them talk, and when they stop ask them permission to repeat what they have said; that would help them mirror onyou what they are saying and doing.
  • Avoid judgement in the room as much as possible.
  • Be compassionate and mindful, which means be there, present for them, ready to take what they say and be compassionate about how they feel in that moment.
  • Feel the rhythm of the conversation, be attentive to the voice tone and look for those words/phrases that will make the team go back to normal.

Put your facilitator hat on.

  • Create the bridge between them, I use to writing in a white board, those key words that everybody is saying, so then we all can see what has been said and where are the points in common.


If you are able to help the team go back to the constructive zone, now is the right time to ask them about the team goals.

In order to do that, I used this kind of open question to start the conversation, addressing the Product Owner in the first place:

Powerful questioning

Example: What are the team(our) yearly/quarterly/monthly goals in terms of support and development?, What are the metrics(percentages) that we have committed to reach? How do we know that we re on track, based on what was discussed at the beginning of the fiscal year versus what is expectedfrom us on this?

Offer them the Gift of the Accountability

At this point of the sprint retrospective, you will  probably have reached the time box , but I think that at least you would been able to unstuck the team, by allowing them to focus on the real issue, which in my opinion, within this context was the lack of shared goals.

Probably if you have enough time, you could engage during the same meeting and continue discussing about goals, but I strongly recommend you to help the team with creating action items to follow up with this important discussion after. So then everybody will be able to see clearly and discuss openly about the team goals. I recommend to ask for a champion and a expiration date, in order to keep the team accountable about this important matter.

Offer your help to the Product Owner

Once the sprint retrospective is done, approach the Product Owner to offer him your help. Then ask him/her permission to share a piece of advice with him/her about the benefits of keeping the product vision and product goals fresh on the team’s mind more often in the future, as a way to get alignment and avoid this kind of non productive conflicts.

During this 2nd. Iteration of the Agile Team Development Canvas experience, I’ve used these models to support everything that was shared above:

1) The Arc of the Coaching Conversation-> Powerful questioning, Exploring

2) Hersey and Blanchard Situational Leadership -> Selling-Coaching, Participate and support, Team Maturity

3) Tuckman Group Development Model -> Storming to Norming

Does something resonates to you? I’ll appreciate your comments, thoughts or feedback.

What’s next?

In my next post, I’ll be talking about Technical Debt payment, who should decide when to pay it, and how assist the team to get there

All the best,


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.