8

I work on a Scrum in Practice team that has many elements of the very popular question over on the software engineering stack exchange.. I found it on Hacker News.

The ones my team has:

  • The sprint coming first. We always deliver the sprint no matter what has happened (including the week we fled our offices and had to set up VPNs for the company) with the idea of just using the bug tracker to compensate.

  • Picking easy tasks so the Scrum Master doesnt interrogate us for "not producing" when we report to them during standup each day.

  • The part about tickets becoming architecture. A lot of this is just that developers are straightjacketed by the tickets because they want to get them done each day so they just build and then bolt on to what exists so nobody wants to spend time figuring out a how before doing.

  • The talk about focusing on velocity above everything is very relatable. We are pressured to keep our "commitment" to "ever higher velocity."

  • My team conspires to boost the velocity number by not qaing all that creatively which ensures that people can meet the daily deadline. It is a controlled infinite defects method thing.

  • Same with the endlessly being a junior developer as you never work on anything larger than a day long task.

I dont wanna get into the debate over whether it is Scrum or dark Scrum or Scrum in Practice or Applied Scrum or something related to concentration camp management. Some of these are not in the Scrum guide but others are but it is a distraction for the purposes of any answers.

My question is how one can effectively operate in this kind of environment while developing skills and not having to constantly defend the status of progress every day, at least until I can get an agile free job (any job boards for this?). I can use the incomplete specs as an excuse to do less work and just have work passed into the bug column, but it is exhausting marching through tickets day after day and needing to cling to a crappy spec to defend myself.

How does one deal with a bad Scrum workplace?

  • 2
    Did you find any advice in the answers to the linked question? – Solar Mike May 25 at 4:56
  • How big is this company? Is your scrum master also your manager? – Erik May 25 at 5:49
  • @joeqwerty work gets done just to a very low (at least in my view) standard. The pieces individually work but the entire product doesnt or at least is going to cost a lot of money from incorrect calculations and integration errors. We just build pieces and not hought is given to integration. – helpme May 25 at 7:52
  • 1
    @SolarMike kind of but the discussion was mostly about Scrum, it being terrible and what was real Scrum or not. The bits of advice were Matthew's toss out pieces to Nvoigt telling people to do it correctly which both require power. – helpme May 25 at 7:54
  • 2
    @Erik 30 developers out of 500 people. Our Scrum Master is our non-technical manager. Our technical manager just hides and codes. – helpme May 25 at 7:55
10

TL;DR:

The repeating symptom here is that your team has no autonomy to make decisions and talk freely, which is crucial to actually being a team. I have seen that in two scenarios: one is that you are actually not given autonomy by management. You have tried but were punished. And the other one is that you are so afraid of showing "weakness" that you don't try to be a team out of fear. The combination, where little mistakes by management (they are new to this, too) are blown out of proportion by fear mongering, is probably the worst.

The only way to find out is to take the risk and be open and transparent yourself, even if that might feel weak and vulnerable if you are not used to it. You will either get pushed back or you will enjoy a team. Even the push back might not be management, it might be other colleagues being held up in their old every-man-for-themselves, if-you-cannot-make-it-fake-it patterns that served them well under dictatorial management.

If you try to form a good team and fail due to management or colleagues, then there is no other way than to fire them and find a job where you can form a team.

Or hunker down and endure. But I urge you to find a team. It's really hard to describe how good a good team is, kinda like how you cannot really describe how a good pizza tastes to people who only ever had that frozen stuff. But I promise you it's worth it, even if I fail to properly describe it. Don't give up on pizza just because your current company only serves the crappy cheap one's. It's not the concept of pizza that's bad.


Long explanation

(Sorry, got carried away)

Well, Scrum operates on the idea that there is a time and place to inspect and adapt. Talk about what went well and what did not and improve it for the next sprint. This is called the Retrospective. So the obvious by the book answer would be "bring it up in the retrospective". The fact that you did not mention the retrospective makes me think you are not even doing "Dark Scrum" (as I understand it, keep to all the rules on the surface but pervert them) but you are just doing "Dark". Because the retrospective is in the book and not having it means it should officially not be called Scrum, "Dark" or otherwise.

I'll go through your list, compare with what should happen and in the end show what you could do.

The sprint coming first. We always deliver the sprint no matter what has happened (including the week we fled our offices and had to set up VPNs for the company) with the idea of just using the bug tracker to compensate.

The Scrum way would be to have a definition of done. A quality standard by the team and for the team so you cannot just sacrifice quality into oblivion. This is so basic that I don't know how or why you can start a single story without having it. If you don't define "done", how can you ever say you are done? In the whole process of Scrum the one thing that could be seen as "bad" in measuring a team as a whole is the number of bugs. If the ticket status is more important than the actual result, then that is a problem outside of Scrum. Tickets and status have existed long before this 30 year old agile hipster idea of teamwork. If nobody in your company brings up the number of bugs you produce as a problem or at least a measurement that has to go down, then that is the root problem, not your process. Yes, your process right now produces bugs, but Scrum is about inspect and adapt. Look at the system, see it produces too many bugs and then change the system. This is not your job and likely you are in no position to change your companies management. In this specific case, the only option you have is to fire the management (aka change the company).

Picking easy tasks so the Scrum Master doesnt interrogate us for "not producing" when we report to them during standup each day.

Well, this one is a sign of a core problem. What you need to find out is whether that problem lies with you individually (as well as your supposed team mates) or if it actually is a problem with your company culture. I had the privilege of seeing multiple teams switch to Scrum simultaneously under the same manager and workplace culture and I have seen teams thrive and enjoy and I have seen other teams falter and fail. So it's not always external, every individual has to be willing to take part in Scrum. The core idea of Scrum are the agile values. Teamwork is essential and there is no teamwork if you cannot be open with each other. The daily standup is to coordinate the team. To coordinate the team, everybody needs to know where the team stands and that can only be found out if each member tells the others where they are on their tasks. This can go two way: in a good team, there is no problem at all. You just tell the truth. Yes, maybe you made mistakes. Maybe you need help. Maybe not? Maybe you just hit a wall with your approach to the problem and will try another today. You can openly say so. Nobody will criticize you. What is important is to know where you are and maybe offer help. In a good team the Scrum master can be a silent observer, because the team will tell. And then there is "teams". Where people aren't a team. Where people are afraid to tell the truth. Where people are afraid to say they need help. Where people think they will be punished if they admit a "weakness". Where the Scrum master needs to "interrogate" people because they do not yield the required information freely out of fear of the consequences. And here is the kicker: I have seen groups where those fears were founded in reality. Because there was a manager present and they would use this team internal feedback against you. There, again, you need to fire management. You have no power to change this. But I have also seen teams where those fears where either completely unfounded or influenced by shadows from the far past. Where people where afraid of "consequences" that only happened in their mind. They never tried to be open, thinking that showing a weakness would somehow diminish their "Senior" status. First, it does not. Asking for help is something I expect from a Senior. It's a sign that you know what you are doing, you know your work and your personal limits. Only stupid or naive people think they can do everything on their own. And secondly, they never tried. Some where too afraid because a manager 10 years ago had treated them badly, some where not confident enough to admit they are not perfect. So you need to find out: as your standups are a red flag of not being an actual team: is that the environment, or is it you. Did you actually try to be a team and were you actually treated unfairly, or did you not even try? Because if being open and asking for help is punished in your company, again, sorry, you need to fire management. But maybe it's not. Maybe it's you. Maybe you need to risk it and find out. Because what you wrote is perfectly explainable with a good workplace culture but people that are afraid because of low self-confidence or bad prior experiences. You need hard evidence, not hearsay and fantasies. So try. Be open. Show a weakness. Worst case is you find out you need to fire management. But as that is already the current status, it seems it's relatively low risk after all.

The part about tickets becoming architecture. A lot of this is just that developers are straightjacketed by the tickets because they want to get them done each day so they just build and then bolt on to what exists so nobody wants to spend time figuring out a how before doing.

This is a straight up developer problem. Scrum is all about building an empowered team. And if the team says we need an architecture meeting that produces guidelines for our software, then that is the case. Who would say "no"? Who defines what the software looks like internally? No Scrum Master or Product Owner is ever going to tell you whether this is a service based architecture, whether is uses proper dependency injection, whether it has unit tests or not. The developers decide what the software looks like. And if they don't, because they are afraid of the next daily, they are doing it wrong. But what is the fix? Well, fix the whole team as above. You should never be afraid to go to the daily and say "yesterday I made a diagram on how our service will communicate after our current story, I have some questions about the database for Alice, maybe we can talk after the meeting, and if it's as expected, I will finalize it today and hopefully start implementing it tomorrow. I'll update our wiki later and send you all a link to the updated pages.". Refer to my part about the daily if the developers think this is not possible in their team.

The talk about focusing on velocity above everything is very relatable. We are pressured to keep our "commitment" to "ever higher velocity."

First, who made this commitment? It's stupid. It's not Scrum. You don't commit to increasing velocity and even he word "commit" in referring to work items in a sprint has been replaced 7 years ago. Find out who is actually doing this and ask them why. Is there a fix? Well, as a quick fix, ignore them? Don't play their games.

My team conspires to boost the velocity number by not qaing all that creatively which ensures that people can meet the daily deadline. It is a controlled infinite defects method thing.

Wow. Your team sure is not lazy enough. All it needs to increase velocity is estimating higher. You got a 3 point story. Great. I estimate another, roughly equal story at 20 points next time. Boom. Instant velocity boost. Improved my work performance by almost six times. Do I get a raise? This alone should show that velocity is not a measurement of anything but how the next sprint will go, because it is not an absolute number one could measure. It's made up points. If you need to produce more, make them up. Problem solved. This alone, the fact that you can make up your own velocity, should show people that it's not a good measurement.

Same with the endlessly being a junior developer as you never work on anything larger than a day long task.

I do not understand this one. Apart from the fact that breaking stories into day-long tasks is not Scrum, but a practice that people use with Scrum and other Frameworks (and for example my team adapted, inspected, found it pointless and adapted again to drop it), I don't see how it involves the seniority of the task. If the task is to implement federated security for your micro services, surely that task gets not less tricky if you do it in 15 daily tasks. You could argue that you do it in 15 daily tasks anyway because that is how work life works, you work a day, you go home, you come back, work a day, go home... the point of seniority is not to grab the task and vanish into a dark basement, hacking away planlessly at your keyboard until a solution mystically appears. You do the very same thing. You think about what steps to take. Then you take the steps one after another, day by day. For our team, we found it pointless to note those steps down, but having a plan of how to tackle a problem instead of blindly stumbling into it is a definition of being senior. I don't see how you arrive at the idea that having a good plan on how to tackle a problem makes you a junior. Also, who creates those daylong tasks? That's a developer, right? So even in the worst case scenario, some developer did get to play senior, the planned tasks did not just come from high heaven.

| improve this answer | |
  • 1
    Wall of text. Interesting writing, but I stopped in the middle because of no structure, subsections etc. Once edited, I think this is a valuable answer (at least up to the point I read, can confirm that). – Captain Emacs May 25 at 11:56
2

Do what is rewarded, as practically you are powerless.

In most companies, the majority of people have a top priority other than delivering a successful project. This isn't malicious, it is just that keeping their job or getting a good performance review is (reasonably) more important to them.

You would think these things are connected, but they aren't well connected because of something called a perverse incentive, which is when something which is not actually valuable is rewarded on the belief that the thing is a proxy for value.

Your company values velocity. They check for it in the standup. They insist upon it in sprint planning. They clearly don't care about the bug count (or at least lack the curiosity to check, which is a good proxy for not really caring). Have they ever mentioned valuing architecture? Probably not. The product owner seemingly isn't complaining about the bugs, so they are ok enough with them too.

The why of valuing velocity does not matter much. Maybe the manager is under pressure from above and needs to report steady progress. He can do that even if the pile of work just keeps growing. The project could have a hard deadline and as long as it has all the features, a buggy mess with everything might fulfill the contract while a half-finished quality product might not. Your complaints assume that quality is of great importance. For all purposes relating to you, that may not be the case because your manager has a greater concern than whether the product is good.

You don't have any meaningful control over your environment, so adapt to extract the best possible result for yourself. I would focus on becoming excellent at having a high velocity. If you can get every daily task done in 4 hours instead of 6, that gives you two extra hours a day to build your lifeboat out of there by building your skills.

You could also use those extra hours to get ahead on the next few days of tickets so that even if there are glitches, you can report that you did yesterday what you actually did two days ago and still be on pace.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .