Teams resilient to Scrum, demotivation and ... many questions inside (my real case)

I feel like running circles

If I cannot insist on doing something but just can try to convince them, they do not listen. They just tell 'No' to all my arguments, and do whatever they want.

The previous 2 Scrum Masters couldn't handle that situation (it was the same every time and it is repeated now), and left the company.

This is a kind of anarchy, where the team is empowered to make decisions, but that sounds like the authority to decide was given to the kids in kindergarten. Of course, they decide to eat candies and to play instead of eating healthy food and having daily routine schedule (eat-play-sleep-learn-repeat). The same is with my teams here.

2 previous Scrum Masters faced the same situation and after endless amount of attempts quit the company. I'm the third one.

Every change I make, they oppose. They act OK only if I do not intervene in what they are doing and they do what they want. And they say, of course, that they do not need a Scrum Master at all

I'm so sorry for you. I can only imagine how frustrating this must be.

To me this sounds more like an issue in company culture, where it's all about deadlines, command & control. The only way I can think of to fix this is starting from scratch. Put work aside, give the teams including POs+management proper scrum training and do a sprint as it should be done the right way without force or pressure. And then do it again. And again. In the beginning this will result in less done work and postponed deadlines. But in the end it will result in a better product and happier people. Period.

I don't know what will be discussed or decided by that delegation board. But the lines above resemble what I'd tell suggest them to do. If the company wants to improve and go the agile way, it will invest the effort. If it doesn't, this company might just neither be ready scrum nor worth huge amount of blood, sweat and tears you're investing there.

I wish you all the best!

Bearing in mind that this is the second attempt to implement Scrum in this office, who in the organization is the sponsor for that change, and wants it to happen? 

Thank you, Steven. This issue happens only with these teams and only with these POs. Actually, all other teams in the branch office are quite OK with Agile and their PO adopt the practices. These teams are the only ones that have such problem. And of course, I understand that the team members would have been more agile-friendly if POs behaved in a different way. For me that also a problem with culture, even rather not with company culture in general but with these teams specifically. And I am still not eager to quit the game but just trying to understand how should I act.

I've worked in other companies and with other teams, so this is not my first experience.

Delegation board - an activity, during which it will be decided who is responsible for what (the 7 levels of delegation, - tell, sell, consult, agree, advise, inspire, delegate). In my opinion, if it will be clear for the teams, who, for example, establishes Scrum ceremonies (thought, for me it was quite obvious, before I came here), so the rules will be more clear. And so on, and so forth. We are going to discuss that, and what questions we will need to clarify by that delegation board. Like what are responsibilities of PO, Scrum Master, team, etc.

Btw, in your company, who can schedule Scrum ceremonies? Can Scrum Master schedule them if he thinks it will be more convenient and effective? Does he still needs to get all team members + all POs to agree to that schedule? And if one team member or one PO disagree, that means that Scrum Master is obliged to accept their schedule?

For me, in my previous projects, I've always did that and had no problems, until I came here.

Ian, thank you for your question.

Our head office and our top management is the initiator. They implemented Scrum in their office and it works well. Also, no significant problems with that in our branch office, just with my specific teams.

I've been warned that I will have a hard piece of work when I came here, but I couldn't imagine it will be like that. I'm OK for challenges (in professional way), but when it comes to dealing with offensive, rude and uncivilised behavior on a daily basis, I feel frustrated.

Executive sponsorship for change must be in place from the top downwards, including at the local level where change is implemented across delivery teams. Very often it is absent in the "frozen middle" layer of management, sometimes referred to as the organizational permafrost, which is where agile transformation typically founders.

However, going by what you say, that quality of sponsorship does in fact seem to be in place across management layers. If so, then you have a significant and rare advantage. I suspect though that sponsorship is not quite so complete, in so far as Product Owners may be continuing with ingrained management behaviors and old cultural norms. If there is permafrost then that is where it might be found.

Do you have a line of communication to the sponsors higher up, whether they be in the branch office or head office? If so, you need to put transparency in place over the lack of progress, and ask those with executive authority what they intend to do about it. How will executives apply their sponsorship to bring about the change program they themselves own? Is there a change backlog for example, with agile patterns and practices they are willing to sponsor, and with you - not as owner or sponsor - but as the Scrum Master and coach? An organization's officers can't delegate their responsibility for organizational change to anyone else including you.

I think Ian has summed up the issue of executive sponsorship quite well.

I'd like to address some of your more specific questions:

Btw, in your company, who can schedule Scrum ceremonies?

I'm not sure what you mean by "scheduling" Scrum ceremonies. I think scheduling takes place fairly automatically. The sprint is a fixed timebox. At the beginning of that timebox you have a Sprint Planning and at towards the end of the timebox you have a Sprint Review and a Sprint Retrospective. It pretty much schedules itself, more or less.

As such, there is no one who has the specific authority to "schedule" these ceremonies. They just take place. Of course, for most teams it may be convenient to keep a calendar where these meetings are shown. But since its pretty much clear which meeting goes where on the calendar, really anyone can add them to the calendar. In my team, that's mostly me, but if I miss it, anybody else may do it.

I gather the scheduling issue you're facing isn't about that, though, is it? It's more about how long each of the ceremonies should be. The Scrum Guide gives timeboxes for Sprint Planning, Review and Retrospective in a one-month sprint and states that for shorter sprints, the events are "usually shorter". I've found it's a good rule of thumb to set the timebox proportionally (i.e. for a two-week sprint half of what the Guide stipulates for a month-long sprint). That's a good starting point. If there's a problem with that timebox, it can be adjusted, but that should be a team decision. In my current team, we ran into problems where the Sprint Planning didn't fit into the timebox. I suggested a larger timebox, but the Development Team disagreed and eventually we found a way to be more efficient about the Planning and stay within the timebox. When we ran into a similar problem with the Retrospective, the whole Scrum Team discussed this and we ended up with a slightly larger timebox because we felt the Retro was worth it.

If my teams get empowered, they prefer no retrospectives at all. And I personally feel that it is a very bad idea.

That is not their choice to make. The Scrum Team and the Development Team are self-organising within the constraints of the Scrum Framework. As such, the decision to abandon Retrospectives means you're no longer doing Scrum. As Scrum Master it is your responsibility to ensure the Scrum Framework is adhered to. And that means you're well within your rights to tell you team mates that they must not abandon the Retro. But for that to stick, you will need to show them why the Retro is important. Maybe they feel it's useless because of the way it's currently run? Perhaps some changes to the Retro are in order. I once had a Developer tell me that he agreed with the principle of Sprint Retro and understood its importance, but that he felt the activities I had chosen for that particular retro were a waste of time. I ran quite a different retro after that and he happily participated.

I understand you're frustrated - I would be frustrated, too. But if you're not willing to quit the team, you'll have to treat them as peers. From what I read between the lines of your posts, you're not doing that right now. And that's a harmful constellation.

Julian,

as for scheduling, I just wanted to understand the situation with my current teams.

Before, with other teams and other company I simply were telling something like this (during the meetings) that the schedule will be as follows, let us say, Monday 10am - sprint planning, Thursday 2pm - Story time, Friday 5 pm - Sprint Review and 6pm - retrospective. Noone objected, as everybody understood the importance of ceremonies and for them specific hours didn't matter. Even if someone was asking to shift some ceremony, we discussed and either agreed or were finding some compromise together with the team.

Now, the situation in these teams are as follows. Just to be more clear, I think, I will bring you the complete picture.

I have PO1 with Team 1 and Team 2

PO2 with Team 3

When I came to the company, the sprint schedule was as follows:

Monday:

Sprint planning

Team 1: 10:00- 11:00

Team 2: 11:00 - 12:00

Team 3: 10:30-11:30

As you can see, the planning was overlapped and I physically was unable to participate in all three plannings.

The situation with Daily Scrums was the same, they were all overlapping each other.

Story time - the same overlapping

Friday: Sprint review is one for all three teams, so all 3 teams are participating.

It is 4pm-5:30pm

And then goes retrospective, 5:30pm-6:00pm (the same time for 3 teams)

Then at 6pm everybody goes home and that's it.

I have talked numerous times to POs and the teams to change sprint schedule so that I can participate in all ceremonies for my all 3 teams and to adjust Friday Sprint review so that all 3 teams have Retrospective.

POs either refused or simply ignored my words. The teams are so afraid of POs that they just didn't tell nothing. and some of them was telling that it would be nice if they have a Retro, but PO says they need to do coding.

I'm fighting for a few months here to get that chance to participate in all ceremonies, but in vain. The only thing POs said OK is to shift daily scrums so that I can participate in all three teams. That's it.

Is such situation ok?

Maybe that will help you

That is not their choice to make. The Scrum Team and the Development Team are self-organising within the constraints of the Scrum Framework. As such, the decision to abandon Retrospectives means you're no longer doing Scrum. As Scrum Master it is your responsibility to ensure the Scrum Framework is adhered to. And that means you're well within your rights to tell you team mates that they must not abandon the Retro.

These are golden words and they completely fall into my ideal picture of world, Julian. The problem with the POs that they do not listen except you are asking for something they originally wanted from you.

As for timeboxes, the teams are quite OK with the timeboxes for Planning, Story time and Daily Scrum. The only thing concerns Retro, as POs insist that this is a waste of time, which can be spent on coding.

At the moment there was only 30 minute slot for retrospective for all 3 teams. Meaning that I do Retro 1 per 3 weeks per each team. And we have 1week sprint. In such a way, each team has a retro only 1 time per 3 sprints.

And the POs are quite OK with that, so the teams. When I asked to change that, they told that the only change they accept (POs) is to cancel retrospectives at all, so that I need to choose - 1 retro per 3 sprints per team or nothing at all.

Then I was speaking to the management and they admitted that Scrum Master has the right to schedule Sprint ceremonies, so I shifted Sprint review one hour earlier and the time remained (1.5hour slot) was dedicated to 3 retrospectives, 30 minutes per team. Then.. you have read what happened

Do you have a line of communication to the sponsors higher up, whether they be in the branch office or head office?

The problem is that our top sponsor who is the father of the Scrum idea is very busy person and visits our office maybe few times per year. Maybe, twice.

Anyway I will be talking to the management next week when they come to our branch office and will try to highlight my concerns once more...

What I personally think is that:

Scrum Master must be present for sure at: Sprint planning, Sprint review, Retrospective.

They say that if meetings overlap I can attend (?) the ones I consider more important..

Is such situation ok?

No, I don't think it is. The whole Scrum Team participates in Sprint Planning and that most definitely includes the Scrum Master.  But that points me to another problem I previously didn't see in your posts.

The company is trying to establish Scrum in that branch office and has assigned one Scrum Master to three teams? It's not that assigning a Scrum Master to multiple teams is against the Scrum Guide. But in a situation where three teams are struggling with their adoption of agile, it is ill-advised. Ideally, each of those teams should have its own Scrum Master. Wishful thinking, I know ... ;-)

But in this particular scenario it does pose a very serious problem. I can fully understand why the PO and Development Team of Team 3 don't want to wait until Teams 1 and 2 have finished their Sprint Planning before launching a Planning of their own. That's half a day wasted waiting for ... well, you. Not that it's your fault, but you are the bottleneck. You're the shared resource that can only be in one place at a time, yet is expected to be in three places at once. That is a problem and it needs to be addressed.

The same applies to the Sprint Retro. Of course team 3 doesn't want to do an hour of idleing around waiting for Teams 1+2 to finish their retros. But since you are part of all three teams, you are inherently expected to attend all three retros.

The Scrum Framework mandates a retrospective after every sprint. Having one every three sprints is a violation of the rules of Scrum. It also robs your team of two-thirds of its opportunities to improve its process.

When I asked to change that, they told that the only change they accept (POs) is to cancel retrospectives at all, so that I need to choose - 1 retro per 3 sprints per team or nothing at all.

Why do the POs think they are in a position to make such a demand? The Product Owner has absolutely no authority to blackmail you into cancelling the Sprint Retro. Someone or something has left them under the impression that they can decide how the team's time is spent and that they have some sort of power over you. I suggest you try to find out where that comes from. Has somebody told them they have that power? If so, why? Is it a misunderstanding of the framework? Have the POs received Product Owner training? What was their position before Scrum was introduced - are they having troubles adjusting to the new framework?

Heh, Julian

Yes, you are right. One Scrum Master for 3 teams and this is the way it was planned here initially. Also, one Product Owner per 2 teams. (and the second one is assigned to 1 team)

As for Sprint Planning, I'm able to be present with 2 teams, as these are never overlapping. The problem is only with the third team, but I do not attend planning at the moment, just sending them a reminder, e.g., do not commit more than you can do, for the POs - do not overload sprint, etc, etc (I can share it, if you need :) and them simply check the sprint backlog, and contact the team, asking whether it was good, and whether they had any problems.

The same is valid for Story Time.

I  understand that it is not the best solution, but still, I can live with it somehow. Maybe there's a way for improvement, but I just do not see it at the moment. One Scrum Master per 1 team doesn't fit the budget. So it will stay like that.

The Retrospectives, though, are in my top concern list.

I thought about making a single Sprint Change day:

Monday - Sprint Start Day



10- 11:30 Sprint Review (3 teams together)

11:30-13 Retrospective (Each team separate, 30 min each)

13- 14 Lunch Break

14- 16 Backlog Refinement (2 teams together, team 3 separately)

16 - 17 Technical Refinement (as useful/required)

17-18 Sprint Planning (decomposing technical tasks, estimating)

Each team separate, typically done without PO, PO may assist on demand, when required

but again, POs said that they will never agree on that.

In my opinion, that might solve the problem. 

 

Why do the POs think they are in a position to make such a demand? The Product Owner has absolutely no authority to blackmail you into cancelling the Sprint Retro. Someone or something has left them under the impression that they can decide how the team's time is spent and that they have some sort of power over you. I suggest you try to find out where that comes from. Has somebody told them they have that power? If so, why? Is it a misunderstanding of the framework? Have the POs received Product Owner training? What was their position before Scrum was introduced - are they having troubles adjusting to the new framework?

Both POs were developers, and further technical leads. Then they became Product Owners. Maybe, that's one of the reasons they continue behaving like line managers.

Our management tries to explain that all roles are quite equal, just do different tasks, but our dev team members watch Powerpoint slides that are shown to them during the meetings with the management, and then tell me that I should understand that in theory it is, but it's political, and in practice our POs are their bosses.

I will talk to the management about some training for the POs, but you know what's frustrating me? The fact that I'm not the first telling the management about what's going on here, but if it remains as is, .... it is quite self-explaining. I was talking about this situation during their last visit, and by the next visit they decided to do a delegation board so that all people here understand what specific rights and responsibilities has each role, so maybe that will help. At least, in theory :) (sad smile)

I will talk to the management about some training for the POs, but you know what's frustrating me? The fact that I'm not the first telling the management about what's going on here, but if it remains as is, .... it is quite self-explaining

Yes, I found that curious myself.

Our management tries to explain that all roles are quite equal, just do different tasks, but our dev team members watch Powerpoint slides that are shown to them during the meetings with the management, and then tell me that I should understand that in theory it is, but it's political, and in practice our POs are their bosses.

If it's "political", that means the POs do indeed have some form of power over the developers. Either perceived or real. You may want to find out what that power is.

Just out of curiosity. Is there a formal hierarchy among the Product Owners, Development Team members and You (Scrum Master) in this company?

As you're aware, Scrum relies on the values of Courage, Openness and Respect, which all seem to be lacking in the described scenario. With a formal hierarchical structure within the Scrum Team, it becomes extremely hard to exercise those values.

The situation seems to be quite unsustainable, and I'd personally be reluctant to coach on a environment where there's no Respect at all (cursing, shouting, etc). However, if you still have a good relationship with the management / executive sponsorship, I'd say your best shot is to show them how these values are being impacted by the PO/Development Team behavior and how this is hurting the company outcomes (poor quality, low levels of transparency, low value delivery, etc). 

I'd also try to have honest one-on-one face-to-face conversations with some of the POs and Team Members and try to understand where this resistance comes from and what can be changed to overcome this barrier, whilst still adhering to the Scrum rules & values.

However, I still believe this is a culture issue, which requires executive support and probably external help.

Cheers,

Is there a reason for 1 week sprints? With two weeks, you would be able to stagger Sprint begin and end among the teams. With this you automatically win flexibility in the scheduling of sprint events, as they hang directly on the Sprint itself.

Plus, with a two week cycle, you may be able to deescalate the POs' mind-set of 'coders need to be coding, instead of sitting around in meetings'. You automatically have a whole week for coding, without the large events.

I have two teams, each with two week sprints. And each week one team ends and begins, while the other team is in the middle of the sprint. Keeps me pretty busy, but there are no scheduling conflicts. We are also able to start and end in the middle of the week, which frees up Friday. With one week sprints, you're pretty unflexible.

Cheers

Hi,

Try to make comments short and hopefully helpful.

Issue 1 Head office vs Branch office

It's not surprising that changes advocated by head office are pushed back by branch offices or some people in branch offices.

It would be good if you figure out who is the key stakeholder in the branch office and her or his attitude. You need to have it managed. Unfortunately, scrum does not cover this. Bear in mind making change in an organization never has an easy path, though it seems you just kicked hardest rocks.

Issue 2 People in power not letting it go

Scrum has powers distributed to the 3 roles. Collaboration is the key, which only stand when each roles is mature, self managing and respect the other 2.

In your case, the POs are senior and authoritative, like line managers. The development team simply do what they're told.

Try to find a few strong developers who buy in Scrum and have them in the dev team if you cannot change the POs. Well, I would say this is a bit political, however the issues you are facing are not Scrum issues. They are people and culture issues, well which are political issues.

Hope this helps a bit and you implement Scrum successfully at the end of the day.

Sounds like another tale of "Superficial Scrum".  The values are being completely ignored, and they not doing Scrum.  Here is a powerful question that you can ask the Product Owners & Stakeholders:  Are we getting what we need as a business?  (rhetorical question...no of course)  Ask them if they would be willing to try some changes to get the results that they desire.  When they say yes....take them "back to the basics" including setting the foundation of the values & how the empirical process works.  When the deviate from those values call that behavior out (privately...1 on 1 at first) and remind them about their commitment to change.  I think one of the hurdles we face is helping people understand that Scrum works...but Superficial Scrum rarely works.