Low maturity of the dev team and self-organization in scrum

Question

I got feedback from the Scrum Master on the project I'm on that I'm too controlling with the development team and my behavior contradicts the idea of scrum and is demotivating for the (outsourced) dev team. He's been on the project for much longer than I.

And I actually agree, although the second side to it is that by increasing the control I increased the performance very strongly.

I joined the project several months ago. I'm the tech lead responsible for the dev practices, app quality, app architecture and similar.

When I joined there was 0 documentation of anything (architecture, processes, etc.), 0 CI/CD and even contacting the dev team was difficult (no instant messaging possible, they were not checking their emails frequently). People regularly didn't show up to daily stand-ups without any explanation. Add to that the fact that sometimes it came up during the sprint review (!) that someone had doubts about the US they were supposed to work on and only during the review clarified them and was able to start working on them. Add to it that the status updates were dramatically unreliable (it was said that some task was done and when I checked it was discovered it wasn't, then I asked if they could correct, they said they did, I checked and noticed they didn't, etc. This could take weeks).

I started to introduce changes and did plenty of change management: trainings and similar, even individual trainings to get people up to speed. There was a lot of backlash from the dev team, who complained about the new rules. (Just to mention that in the meantime I joined some meetings on other projects, just to observe and came to the conclusion that they actually adopted even stronger rules towards their vendor dev teams).

According to the feedback I got, I control the team too much, remind them too much about things and leave them too little freedom.

I'm new in the company so I want to be liked. However, by introducing rules and expecting people are reliable I lose popularity points. What should I do to progress at the organization I'm at?

Answer 1

What should I do to progress at the organization I'm at?

Start with understanding what the organization wants and values and then figure out what your own goals are.

Look at it from the team's perspective: before you showed up, everyone was cruising comfortably. Nothing really got done (or done well), but apparently that was perfectly fine and no one complained or cared about it.

So user42891 comes in and mixes things up. Objectively, the team is working a lot better now, communication is clearer, throughput is up, deliverables should be better & faster. Subjectively, however, their life got worse: they have to put more time & effort in, there is more control and they have to do more thing they don't like doing. Of course, they will be miffed about that.

A few things to do

1. Find out why the pre-user42891 state was fine. Have a talk with the scrum master, product owner, or your own food chain. What were the expectations/goals for this team, and how were they stacking up against them?
2. Understand how your new org works and thinks. If the past behavior was fine, what's the benefit of changing it and how does it fit into the overall landscape.
3. Make sure that your goals are aligned with the organization. Critically examine your own values and that of your leadership around you. It's possible that these are not aligned: if you want to kick butt and the people around you are fine with just cruising, than you have a disconnect here.
4. If you want to implement change, you need to incentivize the team. If productivity is up (and productivity actually matters) than it should be easy to justify some rewards: extra time off, bonus, a nice outing, etc.
5. Failing that can try to motivate through "it's the right thing to do and it's great to feel productive, you can become a better dev this way" but that's hard battle for an outsourced team since they primarily are treated (and feel as) hired guns.

Answer 2

self-organization is a skill. Teams need to learn that. There are plenty of articles on how to get your team there, so I won't repeat all of that here. It can get lengthy, you should google that and read it up.

The articles usualy assume you have inhouse teams. With outsourced teams, you have questions of contracts and trust. They may not have the same motivation to make the product succeed as you do. There maybe even perverse incentives for them to waste time so their company gets paid more. Good outsource companies thrive by delivering quality, bad companies thrive by extracting maximum amount of money with minimum of work while making sure they won't be liable for that. So managing outsourced teams is harder. Of course they complain about you enforcing rules, because that means work.

Another common problem is outsourcing companies often hire the cheapest people around. Juniors (which they often are) balk at being comanded around. But even in scrumteams there is the expectations that juniors follow the lead of seniors. Of course, the senior shall here the ideas and opinions of the juniors, but in general senior have more experience and juniors should listen to them. This is a fine line and hard to do well, even with external teams only.

But even with self organized teams, you as a customer(!) can require certain levels of quality in your contract. This is then not a how it is done and in which order (the purview of self organization), but a what has to be done (e.g. documentation has to exist!). So then you can change the Definition of Done and say as a customer: nothing is done unless it is documented! And yeah, I have seen things like this written in contract: Ci/Cd pipelines expected so changes can be fast, system written with certain techonologies required, etc.. Especially if you let the oursourced team create the system and intent on maintaining it yourself!