Posted in my 2 cents

Avoid the “blame external problems” retrospective

In every organization there are out-of-our-control problems. We don’t live in isolation, even if ideally we are in a room not distracted during our sprint, there are external influences.

And that’s normal.

What’s important to recognize is that it’s impossible to live in an ideal world. We don’t and we’ll never do.

Someone has to sell our services, deal with clients, sign contracts, give support. Someone is sick, in late, or have a disruptive behaviour.
Our team live in contact with other actors of the big development game: designers, sysops, managers, and the shareholders and stakeholders, nonetheless the PO sometimes could give us headaches.

Ideally all the actors should convey with the team about all details, the team should be formed around the project. Ideally we have meetings in time and timeboxed and the client is always joining our Reviews.

But what happens when it doesn’t work as expected?

Teams blame externals. And feels bad about the inability to change the situation.
Often because those causes could last for long time, if not forever (or for the project/team/company life).

For example if the management impose the team a project, without giving opportunities to discuss and deal on scope, budget and time, the team will be most likely in trouble sooner or later.

If the project depends on external producers not included in the team, for example graphic designers or UI/UX experts, the team has a possible issue.

If the Client willings to be part of the game is very low, because “he just wants what he has signed for”, the team is in serious probable troubles.

The agile culture in many companies in not complete at all levels and often teams depends on others.

And it’s simple not possible to do in different way (or change quickly). And teams start blaming outside-problems.
My suggestion is that even in those situation, which i admit are quite complex to solve, the team should focus on what can do, more than what can’t.

Simple because blaming outside doesn’t solve issues. Working on issues solve issues.

During retrospectives try to move the focus on what could be done, not on external problems. But as SM work harder on those issues, they can destroy a good team.

 

A wise man told me:

Scrum is the art of doing what’s possible and ignore what’s not possible.

or in other words:

Start by doing what’s necessary. Then do what’s possible. And suddenly you are doing the impossible.

I would advise some simple suggestions:

  1. Learn to say NO
  2. Don’t blame but do your best, have a positive attitude, be an example, other persons will follow
  3. Be smart and have a flexible mind
  4. Be patient, you cannot complete a big puzzle in one day, it needs time and patience but constance enlightens the path to put all pieces together
  5. Learn to mediate and strengthen collaboration, if problems comes from outside collaborate with people around it’s a way
  6. Coach and teach Agile values, but please just don’t say “you’re not following agile values” that’s just another blaming approach 😉

 


 

Here some wise words from “Agile Retrospective – Making Good Teams Great” by Esther Derby, Diana Larsen:

Teams who identify external groups as the source of their ills and want those people to change end up frustrated. Waiting for other people to change is an exercise in futility. The most powerful place to start change is within the team. Even when your team doesn’t have direct control, your team can take action to influence or change their own response.

 

Posted in books and articles, my 2 cents

Avoiding the Do-Nothing Retrospective

This is a lesson i’ve learned many times running my own company: “ending a meeting without a decision is disruptive”.

You are investing time discussing, analyzing, gathering data, process information and  multiply that for the people involved. And if the meeting give no action then it’s a waste.

A 2h meeting for 5 persons could be 10 wasted hours.

You can apply the same to Retrospectives, repeat this mantra with me:

Avoid the Do-Nothing Retrospective

This is not only true but extremely true.

Keep in mind why do we retrospect: Not because the Scrum guide says that but because we want to improve. And we believe we can do it through inspection and adaption.

So take at least an action as result of the meeting, if you think everything is perfect, but i assume is not, use a simple:

“Keep the things running smoothly and great like the past sprint”.
And trust me even trying to replicate a great sprint is not so easy.
If you know and understand why the past sprint was so great you can create your team list of good habits to perform well again.

In real cases we found many things not running well, which most likely a common path, in those situations the suggestion is to avoid too much changes, and work on one or two improvement(s) at time.

Sometimes when is not possible to find a solution in the retrospective meeting I encourage the team to schedule a dedicated meeting to discuss the topic and find a solution, people has time to prepare and maybe experiment some idea and be ready for a very focused problem solving meeting. Those meetings could be done by just few team members or maybe some team members and some external persons.

Not only avoiding the disruptive do-nothing retro is vital but also avoid the “Blaming external causes Retrospective“.

Last but not least keep in mind those wise words from the book “Agile Retrospective – Making Good Teams Great” by Esther Derby, Diana Larsen:

Change happens in the course of normal work. Teams who believe their retrospectives are a waste of time often keep their improvement plans completely separate from their daily work plans. When the plans are separate, no one finds time to do the “extra” work.

 

 

Posted in my 2 cents

Scrum Master Service to the Product Owner

From the Scrum guide:
The Scrum Master serves the Product Owner in several ways, including:

  • Finding techniques for effective Product Backlog management;
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;
  • Understanding product planning in an empirical environment;
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.

How much are you coaching the PO and the Dev Team? Are you just a secretary or a proactive SM? Are you stressing the PO to create right user stories or just accept everything he ask?

Posted in my 2 cents

Scrum Master Service to the Development Team

From the Scrum guide:

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Helping the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

How much of those point are you really working out on your daily basis?
In a scale from 1 to 5 try to vote yourself in all of those points.

Posted in my 2 cents

Scrum Master Service to the Organization

From the Scrum guide

The Scrum Master serves the organization in several ways, including:

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

How much of this rely truly on the SM shoulder? How much on the Agile Coach? What’s your experience? As SM are you practicing this part of your duties?

Posted in my 2 cents

Transparency vs Openness

Transparency

(the definition by book)
Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

Openness

(the definition by book)
As we work together, we express how we’re doing, what’s in our way, and our concerns so they can be addressed.

What’s the difference and my interpretation

Transparency refers more on having a common language, that everybody inside and outside the team understand. Which is achieved by having a transparent access on knowledge and information.
Openness refers not only on having transparency but also on having a collaborative and/or cooperative managment and decision-making.

For example sharing Goals, DoD, DoR, User Stories, Burn-down chart brings transparency up.

Openness is about to say what have need to be said. Without blaming but with open mind and courage. For example when we describe an impediment or we reject a unready User story or propose a new breaking idea.

It’s not about saying everything to everybody but the right things that could probably hurt a bit but are needed in order to reach goal and preserve values.

That’s my opinion, what’s yours?

Posted in my 2 cents

Effective communication in a distributed Scrum team

Since I’m working in a distributed team for nearly 3 years I can share some thoughts

Scrum is simple, but is not easy to apply

let me add

…and it’s even more evident in a distributed team.

Let’s first take a look at the situation:

  • different timezones
  • non-native language speakers
  • different environment/infrastructure
  • poor communication

Continue reading “Effective communication in a distributed Scrum team”

Posted in books and articles, good resources, inspiration

How to improve scrum values in the team

I was reading this 2016 article from Dave West, which is very interesting since he suggests some simple ideas to improve scrum value in the team:

  1. Put the values on a wall and have each team member write up how they are going to demonstrate the value in their working day.
  2. Add a ‘values moment’ to your retrospective. This gives everyone an opportunity to inspect and adapt on their values.

you can 3 find more on the Dave’s article.


source: https://www.scrum.org/resources/blog/updates-scrum-guide-5-scrum-values-take-center-stage

Posted in good resources, inspiration

Keeping Retrospective fresh

Today i was attending an interesting webinar about the topic “Keeping Retrospective fresh”, here my notes.

Why do we retrospect?

First of all it’s clear we make retrospectives not because the Scrum guide says we should, but because we want to understand and improve performance!

 


Warning signs of ineffective retrospectives & root causes

Because doing things is not the same as getting things done

Continue reading “Keeping Retrospective fresh”

Posted in inspiration

Inspire the change

One of the Agile value is “Responding to change” but how it’s possible if we suffer of inertia to change? Let’s be inspired by those wise words:

He who becomes the slave of habit,
who follows the same routes every day,
who never changes pace,
who does not risk and change the color of his clothes,
who does not speak and does not experience,
dies slowly.

[…]

Continue reading “Inspire the change”

Posted in my 2 cents

Be a role model, lead them by good examples

Let me be brutal: everyone wants the others do what he thinks is the best. Someone reach this goal with his authority, someone is authoritative. Someone over-rule others with power, others are well-informed and considered experts on their field.

A scrum master is an unpowered role by definition and while he should be well informed, hardly is an expert like a senior developer. How can we drive the team in the right direction? If you read the title you know yet: by good examples, be a good example for your team. Continue reading “Be a role model, lead them by good examples”