We just started a new project and introduced Scrum to our division of the company. What questions should I be asking?

Question

I am a software lead who is just kicking off my first project (into the 4th sprint) at my new company (I have been here three months). One of the reasons the company chose an outsider was to help transition to a more Agile model. They also invested in training a Scrum master for the project.

Here is the problem. While things started off fine, things have slowed to a crawl. Developers aren't engaged and spend a lot of time goofing off. Planning poker estimates are soaring. Resignations have arrived. More bugs are making it to production.

I am going to try and have some conversations, but I like to walk into conversations prepared. What is it that makes certain devs averse to Scrum? Why might they be disengaged? Does it only work with certain devs? What questions should I be asking them during these conversations?

It did wonders at my old company, but is seemingly sinking the team at this one.

Answer 1

I have been in a similar situation myself, although not in a Scrum environment. The way I understand it, it is not about Scrum, it is about people.

As a manager, you must understand that you ALWAYS manage people, and the people do the job. Unfortunately for me, I understood that too late.

So the best thing you can do is to organize unofficial / semi-official F2F meetings with the people, and ask them what makes them reluctant / opposing. Ask about their own reasons. Ask about the reasons of other people - according to the understanding of the other person. Collect as much data as possible. In the end, you will have a chance to analyze it and act on it.

Since you are new in the company, you do not know the dynamics of the relationships. Even more, the balance of those dynamics changes, and NOT in your favor, when you joined the team. I am sure that at least one person wanted to take the role that you have now. And other people expected to move up in the remaining positions.

If you go the official way, you have much bigger chances to fail. Build good relations with your colleagues, and then thing will smooth by themselves.

---

It did wonders at my old company, but is seemingly sinking the team at this one.

No two people are the same. No two companies are the same. You have the wrong expectations. You are one, they are many. It is much easier for you to adapt to them, then it is for them to adapt to you.

Answer 2

What is it that makes certain devs averse to Scrum? Why might they be disengaged?

People naturally dislike changes and agile/scum can be a big change. It doesn't mean that they won't stick to the rules or even come to like it, but in the beginning, there is a natural fear to the change of policy.

Does it only work with certain devs?

Yes. Some people don't see the point of scrum (with or without good reasons). Best case they don't like it but stay professional and deal with it. Worst case they hinder the rest of the team with their attitude.

It did wonders at my old company, but is seemingly sinking the team at this one.

Unfortunately, it's like comparing apple and oranges. Two companies are inherently different (different culture, different people, different size...). What work for one may not work for the other.

A piece of advice: you're talking about devs but you have to take into consideration that scrum involve management too. If only the devs are working with scrum and it's imposed on them by management, but management doesn’t play it's part it can really sink the level of engagement of devs but that's more an issue for the scrum master.

Answer 3

How each organization implements Scrum can be as varied as each organization itself. Many challenges are a matter of how it is implemented and presented. Resistance to change will naturally lead us to look for reasons to not like the new way.

Some specific areas that may cause resistance include:

• Invalidating experience. Change comes with implication that the way you know and feel you’ve been effective is wrong and useless.

• Buzzword compliance. Time and time again, many have seen the next new revolution promising radically improved greatness, only to watch it fizzle or be of marginal value. You can’t expect them to love it because they’re TOLD it’s great since everyone’s doing it.

• Role dilution. While it’s often touted how Scrum teams pitch in and cross traditional boundaries, many are really drawn to function X. And it’s rare that everyone is really good at everything. This spreading around to other areas dilutes their focus into things they specifically never chose to do and may not be as good at.

• Loss of detail. Some Scrum implementations can focus so much on sprint boundaries and terming everything in user terms that artificial divisions in a system are wedged in. This can lead to details getting set aside in order to get only a particular story’s functionality in. That parked detail can be missed entirely or forgotten, then cause later setbacks when it impacts the final product need.

• Time waste. Sprints on their own can turn into mini-waterfalls where devs spend much of their time rushing to get it into QA’s hands in time only to not have development to do for the last half. Conversely, QA can’t do much of their work until that handoff.

Agile is rarely presented as a rigid set of rules. Be willing to work within your team dynamics and other factors and alter the pieces that don’t work for your situation. And keep perception in mind. You may have the best of intentions, but if you’re perceived as telling people what they’ll like vs. presenting an option and asking for help in giving that opportunity a real chance, you’ve started in a hole.

Answer 4

I work with a dev who loves it to the point of keeping a Scrum book on his desk.

My feelings are far more mixed.

We had a question asker a few weeks ago who hated it.

Here are some of my problems with it to give you some potential ideas:

1. No defined areas of responsibility. I would much rather have a large chunk which I am responsible for than be handed random bits of work every two weeks. I am a relative junior, so for now it is fine, but resumes need to show tangible coherent achievements. A friend quit a Scrum team as he feared that he would never be able to leave as no large parts would be assigned to him.

2. It assumes intrinsically motivated people. Not an issue on my current team, but the Scrum idea of team accountability means that those who don't care drag down those who do. How does an individual developer insulate themself from blame in a Scrum project which is failing? I don't know. That scenario seems like university group projects all over again. It also allows a disengaged developer to do little and let the mess just get generally blamed on the team. It also doesn't provide anything to the incentive sensitive developers, who would view regularly helping teammates as bailing them out. Their productivity in Scrum would crater.

3. No clear evaluation system. I haven't a clue whether I am doing well or poorly in the eyes of my company or my project. This is just a preference, but I like regular scoring and evaluation.

You also should just consider that change usually causes some people to leave. It happens.

Consider what project management/incentive tools were previously used? Were bonuses paid for on-time achievement? Did the company stack rank? Are devs used to competing with each other? Companies tend to attract types and you might just have a group of competitors.