I’ve had this thought for a while now of demonstrating how can people and organizations deal with everyday situations and present an analysis of them based on my personal views, while some might find this judgmental, others may find this an interesting reflection of their behavior and explore alternatives.

For the sake of the following scenarios I will assume that we are discussing a Large Scale Scrum product, 6 feature teams, one product owner (That is you!)

Situation 1:

You have just realized that the product is behind schedule.

The Good: You meet with representatives from all teams and try to see if there is a way to re-prioritize the backlog in a way that will allow meeting customer needs within the deadline, in case this option does not work well, you try and collaborate with the customer to reach a solution that works for both sides.

The Bad: You add more developers (you may mistakenly call them resources) in order to finish on time. You won’t. You have obviously haven’t read “The mythical man month”.

The Ugly: You instruct the teams “to do whatever it takes in order to meet the deadline”, the team in return will probably cut quality, have lower motivation and trust, and will over-estimate the features next time.

Situation 2:

It is sprint review, a team was not able to get any of their items to Done and hence did not present anything.

The good: You ask the team if there is anything you can do to help. You appreciate them for the honesty and for the fact they were not willing to sacrifice quality or paint a false picture. This conveys the right message to the teams and will encourage transparency. By offering help and avoiding blame you also help build and maintain trust with the teams. Following the meeting you talk to the team to find out more details.

The bad: You ignore it (e.g. you say “Never mind”) and hope that everything will be better the next sprint. Your intentions are probably good, but by ignoring this situation you may be sending the message that it is ok for a team to show nothing at the end of the sprint. It is not.

The ugly: With the presence of all other teams (it is sprint review…) you show how frustrated you are with the team, you ask blaming questions (mostly starting with ‘why’), making disrespectful statements and comparisons such as “You should really learn from team X”. This will backfire.

Situation 3:

It is sprint review, a team demonstrates feature and you find it was not developed to meet customer needs (maybe there’s a bug, maybe it is misimplemented) 

The Good: You explain that this is not what you the customer needs, You either ask the team to make the required modifications and show it again in the next sprint review meeting, or keep it as is and ignore this PBI when calculating velocity.

The bad: You explain that this is not exactly what customer needs, you review the gaps, in order to give the team credit for the effort, you either add another PBI or split the one in question into two, you add the “correct” part of the PBI into the velocity calculation.

The Ugly: You see the problem and ignore it. You don’t want to hurt the team’s feelings, you make sure it is somehow fixed in an “under the counter” manner, possibly by another team or one of the team members.

Situation 4:

It is the middle of the sprint, you are observing the daily meeting of one of the teams, it seems that the team is behind the planned schedule and will not be able to complete everything they planned for, you also notice that there are currently 4 PBIs that are in progress.

The Good: You wait patiently until the daily meeting is over, if the team did not discuss this issue themselves you share your observations with the team and Scrum Master, you may also offer help and avoid telling the team what to do. You make sure to remember this and raise this in the retrospective.

The Bad: You interrupt the daily, you ask specific team members about the status of their tasks, you make suggestions and offer advice without being asked to do so. Possibly you split some of the unfinished PBIs (Product backlog items) so that the part that is not yet done will be a new PBI.

The Ugly: You stop the daily and take control over it. You start micromanaging the team in a way that you believe will get them to complete the items they planned for.

Situation 5:

During one of the retrospectives, the team claims that the PBIs are not detailed enough which makes it hard for them to develop them properly, they request that you start writing the PBI in a more detailed manner, possible even write a functional spec for each PBI.

The Good: You dig deeper, you and the team perform an analysis of the problem, you try and understand the reasons for the team not able to “fill the gaps” and clarify the details of the requirement on their own. Once the problem is clear, you help the team create experiments for improving the situation.

The Bad: You want to help the team so you go back to writing detailed specification, missing the bigger goal which is to get to a state in which the team has  a good business understanding and the ability to communicate directly with the customer in order to clarify the requirements. You have just decided to deploy a “quick fix” for a serious problem which is exactly what you expect the team not to do.

The Ugly: You say that you also think that the requirement should be more detailed, but explain that according to the agile coach, this is the way things should work, this is agile and that’s a problem that the team needs to deal with.

I hope you find these situations and their description interesting. Would love to know what you think, whether you have encountered similar situations and how you reacted.

May the force be with you.