How to deal with an Agile team that doesn't "self organize" or work as a team when you are junior?

Question

I'm a relatively new dev who is part of a team building a invoice management and payment system for our company. We don't have a project manager as we use this methodology called Scrum and in theory the team is supposed to "self organize." But the team doesn't organize at all. We are handed these vague features to work on, we work on them, and then we mash them together in a merge and go get handed more features.

In practice what happens a lot is that nobody knows what is going on with lots of things. I don't know what other developers are doing and they don't know what I am doing. I know no SQL besides select and now am building the entire database system thing for transaction history with bits of code copied off W3 schools but am developing it alone when it is a core part of the system. It is not as if this company is a low paid one which hires random people. I'm the only person here to never work at either Amazon or Uber which is intimidating in itself. The skill seemingly exists but they just go and do their work and nothing happens as a team.

There have been numerous features I don't understand and when that has happened it seems that I can build whatever and our testers will say "I think its ok. See if they complain." I can ask the other devs and they will just tell me that they often don't understand what or why they are doing so they just code to the very short spec and let testing figure it out and testing passes it off to the business analyst who often doesn't know who passes it to the product owner who passes it to some client who passes it to their expert in X.

You will often never hear back on clarifying questions but the sprint still needs to be finished so you do whatever and pass it into master. Plenty of features are 80% finished and never get done.

I feel like I am just building little widgets and tossing them into a pile behind me. Maybe this is how development works?.

The only thing we do with any sense of organization or regularity is the Scrum stuff.

How does one grow/achieve anything in this environment?

Answer 1

I would focus on technical skill development. As a junior, you can't change lousy corporate structures.

Teams of people stuck together (i.e. they did not choose each other, which is the case in most workplaces) tend not to self organize in a very useful way.

• They don't in school. One kid ends up doing all the work and then attaches the names.
• They don't in university. A couple kids end up doing the work and try to dump the other members off the team.
• They don't in the myriad of hackathons where they put you on a team instead of you forming your own.
• They didn't in the capstone projects of my life until it came to deliverable time and even then those were mostly to generate the paperwork required, not the project itself.

Why does this happen? Some kids view the risk as acceptable as 80% of the time, they got a good grade for next to nothing.

Even if they do, they tend to organize around the principle of extracting something of value for themselves, not really around the project. If the incentives and project needs align, that can be great, but most of the time there is a misalignment and that impacts the results. In school that works fine as your project is directly tied to your grade, but in the workplace, incentives are often hilariously detached from results.

We had an interesting question on this topic two days ago: Why nobody wants to tell the boss he's made a mistake?

This:

just code to the very short spec and let testing figure it out and testing passes it off to the business analyst who often doesn't know who passes it to the product owner who passes it to some client who passes it to their expert in X.

and this:

You will often never hear back on clarifying questions but the sprint still needs to be finished so you do whatever and pass it into master. Plenty of features are 80% finished and never get done.

explain your department. The cost of doing something in a useful way is the enormous frustration of getting the required information and being willing to hold back the sprint to wait for it. The cost of just letting someone else deal with it appears to be 0. If it is like most companies, pay is completely disconnected from project outcomes and developers don't get judged on the project as a whole.

Your team is self-organizing. They are self-organizing in a way that keeps their frustration low.

I suggest you build up your technical skills while you are there. Take the database project as an opportunity to spend a ton of paid time learning how databases are designed. Maybe your company will even pay for a course! Investigate that option.

Answer 2

Teams are supposed to self organize... but that doesn't happen via a magical process; it happens due to individuals taking on the responsibility to collaborate as needed with who they need to work with.

Let me give you an example. I was working on an app for rubber mixing, and while it didn't have an 'Agile' label on it... it was Agile. I was effectively lead developer and PM for it.

The team for that was definitely self organized. If I needed to coordinate with the user base, I'd get ahold of them and have some demos/meetings/whatever with them. If I needed to talk with the machining side... I contacted the machining side. If I needed corporate in terms of priorities, well, I contacted Corporate. Some members were regular because I often needed their input/approval, some I only talked to a few times. But it was something that I took the initiative for.

So how does this relate to you?

"We are handed these vague features to work on, we work on them, and then we mash them together in a merge and go get handed more features."

Yeah, see, there's a problem right there. You're given a feature to work on. It's expected that, if you don't know precisely what you're supposed to do, you organize the people needed to determine that so that you eliminate the confusion! If I were in your shoes, the first thing I would do is contact a supervisor from the area requesting the feature to do a quick 5-10 minute meeting to make sure you understand the request.

"There have been numerous features I dont understand and when that has happened it seems that I can build whatever and our testers will say "I think its ok. See if they complain.""

Once again, you failed to self-organize. You don't know what how you should be building something? Then figure out who you need to work with, and get them involved. If you're supposed to build a SQL database but don't have the necessary background? Tap into the SQL knowledge that others have.

In short? Self-Organizing Teams isn't some magic sauce. It's individual people, once they realize they have a need that they can't fulfill, getting help from other areas from within the company. It's realizing that you don't necessarily need a high-level manager to dictate team structure: you let the current needs of the project do it organically.