3

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?

  • 3
    The lack of a product owner / committed domain expert is a much more serious impediment than the one with the team, IMO. The team will eventually get up to speed with Scrum (or you will find another methodology that suits them better). – guillaume31 Jul 19 '16 at 7:02
  • 3
    I don't understand why you're trying to shoe-horn a methodology into a situation that won't welcome it. I can't stand people flying the 'agile' and 'scrum' flag when it simply doesn't suit every situation/team. They respond well under a waterfall methodology - please explain why you'd choose to ignore the things that help your team perform best. – JᴀʏMᴇᴇ Jul 19 '16 at 7:47
  • 2
    The team isn't supposed to come up with ideas. That's the product owner's job. If you don't have a product owner then you are stuck. – gnasher729 Jul 19 '16 at 7:56
  • This is a management issue. I you want to activate them they need to understand why they are doing it. See examples like: ted.com/talks/… which explains the difference. If you only talk about what should be done they will not initiate things by themselves. Just starving without leading won't go anywhere, they still have no clue on where to go. – Luc Franken Jul 19 '16 at 8:07
  • The team is absolutely supposed to come up with ideas. The product owner is supposed to filter those ideas. Sorry but customers don't know what they want. They know what they like. Formal or not, whoever is providing money for the team is the customer. – candied_orange Jul 19 '16 at 12:02
6

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.

5

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).

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

  2. 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?

  • 1
    Maybe Agile or Scrum isn't right in your situation+1 – JᴀʏMᴇᴇ Jul 19 '16 at 7:47
2

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.

  • 1
    This sounds like a recipe for disaster. – Robert Harvey Jul 19 '16 at 3:40
  • 1
    +1 If you want them to be self organizing, stop organizing them. – Bryan Oakley Jul 19 '16 at 11:52
  • This would be good advice for a scrum master, but not necessarily for an organization. Scrum masters are supposed to encourage self-organization and some times that requires actually stepping away as a scrum master. However, the product owner and potentially managers/supervisors, if they exist, should definitely not step away. They should put on additional pressure, which combined with no scrum master presence, should force the dev team into a self-organize or die situation. It is a dramatic move, though, and should only be done in the most dire of situations, where nothing else has worked. – Chris Pratt Jun 6 '17 at 18:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.