How can I motivate the team to take more responsibility for user stories?

Question

My team consists of 4 team members and me as the Product Owner, filling up the backlog and proposing the next stories to be done. We currently have no Scrum Master, and we use the Kanban method.

I am not very happy with the performance of the team. There is a lack of collaboration and communication. I always explain the stories without going into all the details, and then everyone grabs one story and works on it on their own.

When it is delivered for review, I often discover that the Definition of Ready was not respected. There are rarely any questions asked of me.

I try to encourage them to exchange information about their topics during the Daily Scrum. This does not really work. Then I give them tasks, asking them to take their time without me to split the stories into subtasks to encourage collaboration. That does not really work either. My feeling is that they have no courage to push topics themselves. They like to get concrete tasks that are very detailed. This is not working well for agile development.

Shall I have them make a Definition of Done (DoD) maybe? To think more in detail about the story? Shall I try to encourage them more? How? Or shall I not insist and prepare the stories in another way? That would require much more time from me.

Answer 1

From what you are describing, it looks like:

1. You want your team to be (more) self-organizing and proactive in doing the work, and engaging in conversations with you (the PO) when they spot something missing. You want them to be more Agile.
2. Your developers are more accustomed to being told what to do and to receive detailed task for which they don't really care if there are still unknowns or incomplete things. They seem to be accustomed to a more traditional approach of management.

If you want them to become more Agile, you can't just tell them to go self-organize. That will not work. You need a few things first:

• a safe environment in which they can make mistakes. You want an Agile transformation which involves change. And change can be chaotic and confusing. One status quo needs to be replaced with another and the transition will be messy. They will make mistakes, there will be conflicts, there will be undesired results or effects. The team needs to deal with all of this mess, learn from their mistakes, try something else, make a mess, learn, try something else... repeat. Do they have an environment in which they can do this? Or will they be punished for mistakes? Will they be blamed for the mess? Will management intervene to take control of the entire situation and fix things? Will they be pressured to "figure it out already"? If they don't have a safe environment to change in, they will not change.
• even if they have a good environment to work in, they need guidance. They might figure things out eventually on their own, but it's always better to give them a helping hand. An experienced Agile coach or experienced Scrum Master, or a new team lead that already has an Agile mindset can pull them out of the existing status quo.
• competent people. They might have the support, they might be offered guidance, but if they lack the skills and the proper attitude then no matter how much you try to change the context, the behavior will probably remain unchanged.
• time. Even if you are lucky and get the previous things, it will still take some time. Don't expect things to change overnight or in one week. Some Agile teams can even take months to become well oiled machines, while many other teams never truly become Agile but just go through the motions.

Figure out were you stand with all of this, and then you can look for ways to push forward a change.

Answer 2

TL;DR

Your goal of encouraging self-managing collective ownership of the product development process is the right one for encouraging team agility. However, the team as whole appears to lack sufficient experience (and possibly the teaming skills) required to fully embrace agility.

The solution is essential to find the X in the implicit X/Y problem. That means identifying the roles and skills missing from the team, and addressing the gaps at a more fundamental level. It seems highly likely that the dysfunction is organizational, and probably can't be improved without active leadership from the top.

Analysis and Recommendations

First of all, it's worth noting that you aren't doing formal Scrum, as evidenced by the fact that you have no Scrum Master. Based on your description of the project structure, it seems more likely that you're doing some variation of Kanban or Scrumbut. The lack of a coaching role or process referee is at least part of the problem, so I'd strongly encourage you to add a Scrum Master, Kanban expert, or agile coach to the team.

Next, acknowledge that you don't actually have a team. Instead, you appear to have a group of individual members who are neither self-managing nor collectively invested in delivering a coherent product. This is part of what Scrum was designed to address through its core accountabilities. While other frameworks certainly allow for agile teams that are real teams, not just a collection of individual contributors, Scrum is the most widely accepted template for encouraging that. You might want to reconsider whether your Kanban or Scrumbut process is sufficient scaffolding for building the type of team you say you want.

Beyond that, you might need to work with line management or senior leadership to determine whether the organization is hiring the right sorts of T-shaped people who are capable of being self-managing, want to be collectively responsible for measurable outcomes, and have the skills to collaborate and swarm rather than act solely as individual contributors. Agile frameworks don't magically make mediocre collections of individuals a cohesive team; they simply provide scaffolding that enables self-actualizing people to come together and collaborate more effectively within the limits of their individual skills and abilities.

High power-distance cultures and organizations often struggle with agile implementations. Companies that hire for narrow technical capabilities and willingness to respect authority frequently run into problems when switching to agile development models that require a different skill set that focuses on:

• creativity,
• independent- and critical-thinking skills,
• a strong drive for collaboration, and
• honest and courageous interpersonal communications.

If the problem is systemic, the problems will need to be addressed top-down from the senior leadership level to gain any real traction. Be honest with yourself, the team, and senior management about the expectations of the team and the skills/experience gaps the team has. It's up to the organization to decide how to fix the expectations they have of the team, and to populate the team with the right people and skills required to make the project successful. Any other approach is simply stepping around the problem without addressing it head-on.

Answer 3

Software developers rarely care about the product they develop and rarely are interested in the domain. If you can find an experienced developer who's interested in the domain - he can start leading the team instead of you. He'll most likely have the same problems as you do, but he's closer to the dev world and will have more authority.

You can also try to get more interest from the team by giving them lectures on the domain. Knowledge may provoke interest. It rarely works, but give it a shot. This will cost you time for sure, but life's not easy :)

Otherwise you'll have to start describing tasks in more details. There's nothing wrong with this - someone has to.

They like to get concrete tasks, very detailed. Which in my opinion is not working well for agile development.

Detailed tasks work fine. In my practice I see that it's actually more performant to separate req & dev activities. It's pretty hard to do both analysis and development, even if you are able to do both.

It doesn't of course mean that developers should be fully oblivious about the features they work on. If there's a mistake in the requirements they need to be able to spot it.

Shall I make them make the DoD maybe

Well, DoD should be clearly understood by developers anyway. Whether to include requirements review in DoD - that's a good question. Since you want requirements part to be done first - you'll have to make them work on the task description first. But I can't think of a way to formalize this (we don't want devs to just say "yep, I reviewed the description" - this won't cause any changes).

Personally if I have doubts whether a developer can do things right - I ask them to first write in words how they'll implement the task, but this is rather low-level technical thing, that's probably not what you want..

All in all - you have issues with the team. We can spend hours coming up with the ways to encourage them, but usually these problem are solved only by changing the composition of the team. By adding/removing people or changing their roles (e.g. making one of devs responsible for requirements).

Answer 4

In my view, I would avoid thinking about this issue in the context of software, Agile, Scrum, Kanban or whatever else. I think you need to focus on teaming models and theories as these cross development methods, ideologies, and even industries and domains. There are several credible models out there that have stood the test of time and you would do well reading about them, learning, and trying to see how you can fit them into your context. The Tuckman model has been around a long time. There is the DISC model and the GRIP model. And there are others to research, too.

There are tactical things you can do for this team now and the other answers can shed a light on that; however, I think you need an understanding of the base upon which those tactical solutions live.