How to get started with Scrum when the team is bad at generating ideas?

Question

I have a bit of a problem regarding implementing Scrum into a project. The team I'm working with is generally just very bad at coming up with ideas. I'm not sure if it's a matter of them not feeling comfortable with the environment or what.

I've worked with them before, and they actually work best under a Waterfall development strategy where all the requirements and tasks are laid out for them, and the roles are assigned by some Project Lead, and they don't have to do much of the thinking or organizing themselves. They work fine under that methodology.

However, when it comes to generating Sprint Tasks, all I get in the Sprint Planning Meeting is blank stares. No one's willing to speak, and I am forced to drive the discussion. Maybe I'm not leading them on very well either, I'm really not sure what the root of the problem is unfortunately. We just don't get anywhere in the Sprint Planning Meeting unless I'm leading them on, and even then, they just nod when I say something, and then I write it down as a Sprint Task, and the cycle repeats. Not very Agile in my opinion.

I asked one of the team members I'm a good friend with why they might be having trouble, and he said it was because they lacked a thought out requirements specification for each PBI, so they couldn't really generate any Sprint Tasks when they didn't know what goal they were trying to achieve. I recognize that we can't just dive into a project without understanding the requirements even remotely.

In response I devised a one-to-two month "Product Backlog Planning" phase before each Sprint where we look at the PBIs, decide which ones we want to "flesh out" (which we call realizing), and then spend the next month or so and the next 3-4 meetings writing informal "Requirements Specifications" for the chosen PBIs.

It seems to work, and it doesn't feel like it clashes with the principles of Scrum or the Agile Manifesto, but I don't want to lie to myself. Also, spending one to two months between sprints is a terrible waste of time in my opinion, and from what I've read it sounds like the time between Sprints is usually between one to two weeks. I also don't want to risk turning into a "Scrum-but".

I've worked with Scrum before, but never on a team where it just worked. So I never got an opportunity to really observe and appreciate why the things in Scrum are the way they are, and so I never had any understanding of when it was necessary to change them (see "We Tried Baseball and it Didn't Work").

If it's of any importance (which I believe it might be), we currently do not have any established or official Customer, meaning we have to go out and actively look for the requirements, instead of the Customer bringing their requirements to us.

What should I do to help overcome this team impediment, whilst also not turning into a scrum-but? Am I on the right track, or an I flying way off the rails?

Answer 1

What I think you lack here is a product owner. Somebody who knows about the product you guys are working on and who can make sure that the user stories that end up in your backlog meet DoR (Definition of Ready). This, of course, does not mean that the team should take what is in the backlog at face value. They do need to challenge it and ask for clarifications wherever needed. However, putting in more details in the US could help them see the picture better, which could lead to them being able to add pieces that are missing. On a side note, what @CandiedOrange said makes sense. You need to coach the team, rather than manage them. They must feel the need to succeed, of course. That is up to them. But micromanaging them eventually makes them dependent of you, which is not what you want to achieve.

Answer 2

There's a couple of potential solutions:

1. Is it really the case that the team should be generating ideas? Engineering teams are generally responsible for implementing ideas that come from product management, not coming up with the product itself and then creating it. Perhaps you need a PM to design the product so that the team can stay focused on creating it.

Once the Product itself is defined, it's a fairly methodological process to create high-level stories representing features and then individual tasks underneath those; it sounds like you're saying the team lacks inspiration, which isn't really part of sprint planning (although lack of motivation could be a factor).

2. Maybe Agile or Scrum isn't right in your situation. There are cases where external requirements and processes make more sequential development sensible.

3. Should the purpose or existence of the team be questioned in this case? Without a customer, what are the business goals? If you're part of a larger organization, could this team be working on other thing(s) with more value?

Answer 3

Starve them.

Seems whacky but what's killing them is you keep spoon feeding them.

Scrum works best when you don't push. The more you manage them the worse this will get.

If you have a team of smart driven people all you have to do is lay out a goal and make it clear that they are expected to find work. Just make it obvious that you're watching who's accomplishing what.

Don't assign work. Set a goal. If you want them to be self organizing, stop organizing them.

Keep going to the meetings but be willing to wait them out until they start doing it.

If this leaves you with nothing to do you don't belong on the team. You teach them how to do this by doing it yourself. Pick something to do and start doing it. Just don't pick a big enough something that leaves nothing for others to do.