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:
- Learn to say NO
- Don’t blame but do your best, have a positive attitude, be an example, other persons will follow
- Be smart and have a flexible mind
- 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
- Learn to mediate and strengthen collaboration, if problems comes from outside collaborate with people around it’s a way
- 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.