Scrum, Possibly done wrong

Question

I'm not against Scrum. I love it, it's right on my second preference right after RAD, however in my current team they made me hate it. We're possibly doing it in the worst possible way.

We have the usual Sprint planning which takes roughly 30 minutes while writing user stories ourselves and that's all. Right in that 30 minute we answer questions like the following:

• What should the user do?
• What is needed for this (Subtasks).
• How much time will it take?
• Okay we're done, see you tomorrow morning in the daily stand-up meeting.

This really frustrates me and they won't listen to me. There is no planning, like at all. At the point of (2) all 4 developers talking about different ways of solving a particular problem. It would be fine, but we also don't have any clarified vision and thus everyone has different understanding of where is the whole project headed. Thus our ideas completely differs. This usually ends up in chaos. For example the most recent story in our newest shiny project's first sprint:

Vision: We need an application to perform unit testing on X application.

User stories:

1. User logs in
   • Create DB table (No schema has been clarified)
   • Create Login View
   • Authenticate user to Y server.
2. User sees the available unit tests
   • Create a view to display unit tests
   • Read DB table
   • Implement CRUD operations
3. User executes unit tests.
   • Implement selection to the upper view
   • Add an execute operation
   • Display the result in a new page

What my worries were:

1. Vision doesn't say anything about where this whole project is headed thus we will end up re-implementing the majority of our functions when going to the next spring, or after that, or after that... (Checked - this happened right away; I can't help it I just hate to work on something that will be erased right at the start of the next spring. I don't think Scrum is about it, it would be really useless)

2. No actual planning. We haven't clarified anything what the DB should look like so how to create it? I can create a DB for such a system with 1 to N tables depending on what the project should achieve in the future but this is not so serious as a DB can easily be extended.

3. Based on (2) we started working on different parts. I created the DB while others created views and again others created operation implementations. All of us had different understanding and even in just a day we ended up with non-compatible models that just couldn't be integrated.

What have we done wrong:

• No planning. My team just hates planning, they're like act first and ask later. I'm like: I.DO.NOT.DO.SOMETHING.TWICE.BECASE.YOU.ARE.LAZY.TO.DO.PROPER.PLANNING.
• No communication between team members, but even I didn't expect that just under one day we will end up like that.

What is going wrong in here? Is it just me with the wrong understanding of scrum or my worries are true? This is giving me so much stress at work I barely can handle it anymore.

Answer 1

I'm intrigued as to who "they" are in this line : "This really frustrates me and they won't listen to me." ?

It reads as if you're referring to the rest of the scrum team. If so, I suggest you need to get to a "we" footing as soon as possible and work on communication.

With regard to some of the items in your post, a few things come to mind immediately:

1. If you don't have one, you need a product owner to own the product, it's vision and it's backlog. If you do have one, they may benefit from good training or coaching

2. You are absolutely right about needing a Product Vision. You seem to have one but, you infer that it describes some functionality rather than a complete product vision. If so, have you tried to discuss this within your team?

3. If you don't have one, you need a scrum master to help the product owner and development team to play by the rules of scrum and, in your case, encourage communication within the team. If you do have one, they may benefit from good training or coaching

Concerning your worries, I would add:

1. I think you mean 'sprint' where you write 'spring'

2. It is common in scrum that product backlog items are changed to reflect better understanding

3. You shouldn't need to describe the database in depth when you start a project. Scrum works best with emergent architecture based on implemented functionality

4. If multiple developers work in the same area without communicating, it's highly likely that you will step on each other's toes and get the outcomes you describe