10 ms·

At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta;

At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, so nobody says much of importance, and just parrots what is already on the Jira board. * Scrum master driving process above scrum. The scrum master's role is to make sure scrum rules are adhered to. But at this company, any deviation from scrum itself poses a threat to this person's job security, so it doesn't happen. More high-level processes are not optimized because the scrum master defines everything. * Technical debt. I see this time and time again. User Stories are supposed to be forecasts, not commitments. But the business doesn't like stories carried over, so they become commitments. At the end of each sprint, everyone rushes to get their stuff done, and hacks are implemented to meet an arbitrary deadline. Many times I want to begin my work by refactoring something to what it needs to be first, then do the actual user story. But its risky because the refactoring might take more than the allocated story points, and you get dinged. So I do the story first, and if there is time do the refactoring but it almost never happens. * Poor product owners. During maintenance phase, we could work on cleaning up technical debt, but this value is not appreciated by business so they keep us busy with bikeshedding. One gripe I have about scrum, is there is nobody representing engineering, as the product owner represents the business. These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I need to up my game with how to play it - but I wish I could use something else, perhaps kanban.

icelancer 7y ago
> Daily standup I have never worked at a company where this actually goes right and could not be replaced by [insert ticketing system here]. We use Basecamp to do daily check-ins on a very high priority issue, if we have one, which we usually don't.
- thrower123 7y ago
  Managers are the only people that like daily standups, so far as I can tell. I've never figured out why you couldn't just do it over slack or equivalent. It's massively inefficient to get everyone to meet up in the morning.
  - detaro 7y ago
    Many places do it over Slack.
  - rdtsc 7y ago
    Managers need to justify their jobs. Reading off a slack report every day seems too simple and not worthy the salary they're paid. Compare that to a large meeting and live status updates, everyone stands, etc. Now that is some "serious work" happening. Think of it from the point of view that managers have mangers they report to. When shit goes wrong they have to cover their asses. "So it's late. But did you check on their progress? Wait just over slack, no actual meetings? Ok, that obviously needs improvement".
    - tomjakubowski 7y ago
      It's not like it's a requirement that "managers" be at a standup meeting. Some of the best teams I've worked on have done daily standups without managers, and I dare to say most of us enjoyed them and found them productive!
      - asark 7y ago
        Managers are often looking for ways to fill their calendar. Meetings, calls that could be a two-minute Slack exchange, et c. Some will hop into meetings like that if they can. They love the recurring ones, especially, bonus if they can apologize any time they have to skip it for something that actually, maybe, matters ("uh, yeah, we don't care if you come, OK, thanks for apologizing I guess?")
      - mcv 7y ago
        I have never been in a team where managers were present at the standup meeting. In fact, sometimes I have no idea who my "manager" even is. We've got a team, we've got stakeholders, we do the work. If a manager wants to join, that's fine, but he's not in charge of that meeting. All this talk of standup meetings being primarily for managers is really weird. It's not for managers, and they have no reason to be present. It's for the team, to improve cooperation within the team. If the team has a better way to accomplish that, then they should use that.
crummy 7y ago
Standups can have their use but I can't imagine a 20 person standup being useful. Why do you bring so many teams together for it?
anon1m0us 7y ago
The way I decided to play the game was like this, "I won't be attending the Daily Standups anymore as I don't think they add value and do subtract value." The project mgmt response was, "Attendance at standups is mandatory." Regardless, I didn't go to anymore standups and when I got flack for that, I stopped going to the office all together. When I got flack for that, I stopped working all together. Then I got fired. That solved all my scrum problems.
- boltzmann_brain 7y ago
  Underrated post
- analog31 7y ago
  I got criticized for zoning out at scrum meetings. So I watched what the managers do. They show up for the first few minutes, look alert, then leave as if in a hurry. I started doing the same thing, and never had a problem again.
  - Aeolun 7y ago
    If you do this often enough. People will assume you are busy if you don’t show up at all.
    - madmulita 7y ago
      Don't forget to always roll up your sleeves and carry around some papers.
      - alchemism 7y ago
        If you are in a paperless office, tapping a tablet with a stylus as you walk confers the same office space prestige.
  - maxxxxx 7y ago
    That seems to be secret for managers anyway. Always appear eager and motivated and then run away.
scarejunba 7y ago
Are you in a position to effect change? If not, leave if you can. If not and you can't leave, suck it up. Otherwise, here's a couple of notes freely given with no claim to excellence except that I've worked with successful scrum teams and unsuccessful ones: * The 'business' is everything. All code is liability. Code that can't do things the business wants to do and hinders those things is a particular cost to the business. Product Owners who don't understand that "refactoring code to make it extensible before extending it" is the cost of doing business just have to learn that lesson. If they won't, let them go. Bad ones are a dime a dozen so you can always hire another clueless one if you want. It's like having a loan that you're paying lots of interest on. Saying "We can't spend time refinancing that. We have to go earn money." doesn't make sense as some absolute truth. * Engineering is not in contrast to the business side. There is no need to represent engineering because the product owner is supposed to be able to understand all inputs into the program. If engineering is slowed down by the lack of dealing with some technical debt that's not some engineering problem divorced from the business. It's the business. This requires reaching across from the engineering side, being clear when things aren't going well, not starting on ridiculously long "refactoring" projects that are just lateral changes, and being clear what the expected outcome of any tech debt relief is. Avoid "feels cleaner", "is more elegant", "is more extensible". Talk in terms of outcomes: faster response to outages, the ability to add things like X (requires you to understand the product some, which is something an engineer should do), less time spent debugging issues. If trivially measurable, measure and demonstrate improvement. Builds trust. * I'm not too convinced "Scrum Master" needs to be a solo job for anyone. The incentives are skewed. If you have a team of ideal people and they all pick up on the principles and you correct the bad patterns they have, they won't need you. The job inherently obsoletes itself which means the median person taking the role will entrench themselves in process to keep themselves relevant. * 20 people at daily standup makes no sense. It's 10 minutes or 15 or whatever so you have 30 s to describe something. It isn't so much the time, though, but the fact that there are too many people here together in the room. It makes no sense. Find smaller units of organization. Conway's law presents but the alternative is much worse.
jboy55 7y ago
First of all, most issues with process issues are more a reflection of the organization and what drives them than the process. I would say you should start talking about, 'Our process' instead of 'Scrum'. >These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I need to up my game with how to play it - but I wish I could use something else, perhaps kanban. Spoiler, your Scrum books aren't going to help you figure things out, unless your org actually wants to change. You have your own unique process, but that you have a unique process isn't an issue. The issue is that your management seems to not respect the input of engineering. No process will work the way you want as long as that is true. Some thoughts, * Most critical, your team is way to big. Should be half as big * Scrum master should be a team member and rotated along the team. The process should be a result of constant tuning via the Retrospective. The scrum master here, should lose his job. * Engnineering owns the implementation of the stories, product owners should not be a part of the conversation on how to do something, they only can say 'what'. * If you can't decide your own points, then again, you have your own process. If you can, and you need to refactor, you need to add points for that. If you can't do anything to change, then again reading scrum books isn't going to help. You can say, 'this isn't the way your supposed to do this' as much as you want. processes always reflect the organization. Unless the engineering team is an equal to the product team, it won't matter what process you have.
- addicted 7y ago
  However, many companies face similar issues. For a moment I thought the OP worked for my company because we face the same issues (that's not possible however because in person stand ups are banned at our company due to the distributed nature). 1) While I agree that 20 people seems like too large a team in general, I have a fundamental problem with the idea that scrum can determine what size team is right. What seems to be happening, it appears to me, is that we have a fair idea of how large a meeting can be before it becomes unwieldy, and scrum has a daily meeting as it's fundamental component, so basically decides that for it's fundamental component to be effective there shouldn't be more than 8 people so therefore teams shouldn't be larger than 8 people. That seems backwards to me. 2) Almost every scrum training usually has a separate scrum master. I do think the idea of a team member being the scrum master makes a lot of sense and would probably alleviate a lot of the concerns. 3) Scrum story points are supposed to reflect end user benefits. A refacorin's benefit will only show up after several sprints. In the meanwhile you hurt your velocity significantly because your refactoring is likely to be 0 points. Now, this actually makes sense to me, but the issue is that in most places management is carefully monitoring velocity and is gonna hold the drop against the team. To be fair though, I think this is another issue where the real problem is management converting a measurement metric into a target, which basically negates any use it may have as a metric. My biggest issues with scrum are: 1) A daily standup is ridiculous. It's highly disruptive and gives me the feeling of someone constantly peeking over my shoulder. A better strategy is a simple email when someone has an update, or a blocker to the rest of the team. Very few of my projects are done in a single day, and it's psychologically stressful to join every meeting saying I worked on story A, will continue working on story A for 3-4 days in a row, while the managerial types rattle off a list of meetings they attended, emails they sent, trainings they completed, etc. 2) Sprints are far too inflexible. Each story should basically define a new Sprint for the people involved in that story, which may or may not be longer than originally expected. I don't see the point of having a fixed 2 week period that applies to everyone. Why not just have a weekly or biweekly meeting where you go over everyone's stuff and see where you stand. It's basically a more flexible version of what sprints try to achieve, without the psychological issues created by having to fit things into a Sprint or alternatively having to carry it over into a whole new Sprint. That same meeting can track how many points were earned since the last meeting and you have your velocity being tracked as well. Retrospectives are great. But they should be included in the same 2 week catch up meeting. I find scrum tries to create a lot of artificial deadlines, possibly to encourage people to break things into smaller pieces and make regular progress, but I find that's not how people usually work. In my experience people tend to work more in spurts, delivering a ton of features and bug fixes over a couple of days, and then going relatively quiet for the next few days. Not because they aren't working, but because thats just how things usually pan out since software development is a decidedly non linear process.
y96V89C668e7Q74 7y ago
I feel like you work at my last company. But so many companies f* this up that it could be any company. I got fired from any last job after being one of the only engineers willing to say something to management about this. I figured I had a popular opinion - many other engineers often DM'ed me on slack encouraging me to continue speak out, including my own manager, so I somehow figured I should be safe speaking out, politely, as a respected majority representative. In fact I was dead wrong. By saying that scrum was a problem, I ended up making product managers / CTO who loved scrum and used it as an hour long opportunity to lecture the team every day feel threatened. Getting fired was one of the best things that ever happened to my career, because in retrospect it was a dead end company that was run by fear. Management was afraid of ideas or challenge to power to the point where innovative ideas and feedback were never well received and a culture of fear and not stepping out of line arose, even though it was sugar coated with fake company values of "openness" that nobody really believed in but that managers loved as a way to elevate themselves. I suspect many companies are a my least a little bit like this. Unfortunately it is human nature and there are so many stories in history, usually of narcissistic dictators, that mirror this. This was a very extreme example but I'm sure many other companies struggle with this when it comes to challenging scrum. Managers tend to love scrum because it's a chance, daily, to "manage" and to get status updates so that they feel comforted. It makes it so that trust is no longer necessary, and bad managers are often bad at trust. I guess another way to view scrum is to realize that it is often a reflection on management's subtle fears and insecurities being projected onto the processes of the company. It is an instance where employees unfortunately must manage up.
dragonwriter 7y ago
> Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room It is central to the idea of the daily standup is that it is one team. > Its limited to 15 minutes, so nobody says much of importance, and just parrots what is already on the Jira board. If you have another mechanism for sharing what each person has done and is doing, then the standup should just be for sharing information about and resolving barriers. > Stories are supposed to be forecasts, not commitments. But the business doesn't like stories carried over, so they become commitments. If you organizationally can't get away from commitments, then you need to cut back the amount you plan to do so that there is some slack. As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly.
- doomslice 7y ago
  > As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly. The powers that be at my work decided that “sprint predictability” is the most important metric here. This means that if we pull in stuff near the end of the sprint but don’t finish, predictability goes down. Thus, we are encouraged to not take on extra work if we don’t expect to finish. What this means in reality is that we start working on it without pulling it into the sprint and then get a head start for next sprint. What’s your take on that?
  - asark 7y ago
    My (related) experience has led me to believe reporting to management should be strictly separate from any tools or processes used to track actual work, specifically to avoid dumb shit like this. Team task-tracking should be a team communication tool. If you want to report task-related stuff upstream it should be totally separate, with updates/sync done by a human (project manager would make sense). I also think speculative future make-believe planning junk should be kept out of the real getting-shit-done tool. Put it in there when it actually matters. There should be no "on ice" or "phase 3" (when in "phase 1") crap in the tool the devs use. It may or may not make sense to have them involved in planning stuff that early, but keep the output of that planning away from the real-work trackers until it's closer to time to do it. I think that's part of why Jira (and similar, heavy, report-focused tools) is so god-awful. It not only tries to have features for teams to get stuff done and for five other roles to dig around in tasks and reports for whatever reason, it enables and encourages that, and I'm fairly sure, at this point, that it's fundamentally a bad idea.
maxxxxx 7y ago
I passionately hate being asked for "commitments". If it's stuff of any reasonable complexity or novelty I will have no idea how long it will take and therefore can't make any commitments. The only thing I can commit to is to make sure that people don't waste time and work towards the goal. The problem is that management has no problem wasting a lot of time with useless meetings or not committing to the final feature set but instead changing requirements all the time.
- Aeolun 7y ago
  Changing requirements is fine, as long as they recognize that stuff like that impacts the schedule. Generally they don’t though.
- sopooneo 7y ago
  If you can say more than a minute, but less than a decade, you've already got SOME idea of the timeframe for a task. Granted that sort of estimate would get you called to HR for insubordination. But can you pull the bounds in from either direction at all? I say this as someone just moving into project planning and management. From that perspective you start to see that some level of estimation s critical. My preference is to ask devs for just the tightest bounds to timeframe they're actually comfortable with, then estimate based on that and pass up the chain. I consider it to be on my shoulders if things take longer than I communicated upwards.
  - maxxxxx 7y ago
    I understand that estimates are important and I give estimates. But recently in my company it’s fashionable to talk about “commitments” and I won’t give those. In my view this is just a way to get overtime and weekend work out of people once things fall behind so they meet their commitments. I commit to do my work as best as i can but I can’t commit to work overtime because of issues that are often out of my control.
    - sopooneo 7y ago
      That makes perfect sense. And I applaud your push against a practice that does seem to be pushing devs for unpaid overtime. You're right.
munchbunny 7y ago
I think this gets at a very common problem with managers in the hierarchy. They forget that iteration of processes is crucial to good agile process. Your goal isn't to adhere to "true scrum." Your goal is to tailor scrum to what your team needs. If your daily stand-ups are just repeating the JIRA board, then just give people back their time. If your features are coming out badly designed, then stick a designer in the engineering pods, or call out the design phase in project lifecycle. If your projects are consistently late, then... slow down the estimates! Of course teams that do it right tend to know this, but the bad implementations of scrum I've seen consistently lack attentive iteration on the process itself.
bartimus 7y ago
> User Stories are supposed to be forecasts, not commitments. Indeed the commitment is supposed to be with the sprint goals. I've seen this vital aspect of scrum getting overlooked too often.
VonGallifrey 7y ago
> One gripe I have about scrum, is there is nobody representing engineering, as the product owner represents the business. That is definitively not be the feeling you should have. In "proper" scrum the Team is supposed to represent engineering. If you, for some reason, don't feel like you can represent these concerns then that is a huge issue. The PO shouldn't be your boss either. At least it isn't so in the company I work for. It sounds like the PO is the boss of that team, if he "keeps you busy". I am super grateful that our Scrum Master knew what he was doing and suggested creating a separate line on the Org chart for the POs so that they are explicitly not in charge of development. The team is in charge and POs are more advisory. Sounds to me like there are some deeper problems in the company then just the scrum. There are so many red flags in your comment. I don't know if those books are going to help you "play" scrum better, because what you guys are doing does not sound like scrum at all. Kanbans probably also not a solution. I really like Kanban, but it isn't going to remove the bad elements that seem to control that company.
- mcv 7y ago
  Yeah, that's an odd complaint. You are engineering, are you not? The meeting is already about engineering. If you have more engineering as an outside stakeholder that the PO isn't able to represent, by all means bring someone in to represent them.
- verinus 7y ago
  this. In scrum the dev teams maintains a technical backlog and fills the sprintbacklog as THEY see fit- from the product backlog AND the technical backlog. the PO has no say in this! he can complain that he thinks not enough features from his product backlog are planned, but should trust that the team knows what they are doing.
megaremote 7y ago
> Daily standup Change them so that people talk about what is blocked then. > Scrum master Tricky, like anyone who doesn't want to adapt. > Technical debt Create tickets for debt, put them on the backlog. > Poor product owners Tricky.
- alkonaut 7y ago
  > Create tickets for debt, put them on the backlog. That will risk making a huge technical debt section in the backlog that will find it hard to get priority. It's better to condition new features/bugfixes on the cleanup that caused them. "I can add this feature in 1 day but will need 4 days to clean it up. So my estimate is a week." I constantly nag developers to do this when they find that they are pressed for time and want to make a hack. -"I'm nearly done but I can't find a nice way of doing this because of an existing code smell so I'm considering adding another smell" -"Did you ever find that this was NOT the case?" -"No..." -"So do you always double or triple your estimates so you know you can comfortably refactor" -"No..." I think this is a disease of Scrum. Too short estimates exist because developers pat themselves on the back for finishing things quickly.
  - postfacto 7y ago
    That will just lead to stories to change something simple the color of a button taking 3 days because you hit a tech debt minefield refactoring. You don’t want someone looking at JIRA and seeing it took you 3 days to change a simple button color. Keep technical debt in separate tasks to make the tech debt visible and to keep management accountable for not making efforts to get rid of it.
tannhaeuser 7y ago
> nobody says much of importance, and just parrots what is already on the Jira board Worse, the moment anything of interest gets being discussed, SM stops it, saying "let's take this offline" (in German-speaking projects at least, where there's a tendency to use English words to really say nothing at all). Which brings us to > any deviation from scrum itself poses a threat to this person's job security, so it doesn't happen MBAs have identified and captured the role of a Scum master (sic!) to comfortably represent a project towards management, without the responsibilties of a project manager (I'm just moderating the project), yet with an instrument to turn time-based freelancing and employed work into a fixed-price deal through commitments/forecasts.
mcv 7y ago
Standups with multiple teams, or simply very large teams, are a terrible idea. I'm currently in a team that has very quick, fun and productive daily standups (despite not even having a good standup space for it), but we have only 3 devs and a handful or other people involved. But I've also been in projects where standups drag on and on and on, and they're hard to get under control. Usually, those projects had much larger teams. I suggest smaller teams, and if you have this kind of multi-team standup, discuss with your team to have your own independent standup instead and send one representative to the big one.
jpswade 7y ago
It sounds like you're missing probably the most important part of agile which is "at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly". In Scrum, it's retrospectives. Continuous improvement is a theme that runs across agile, scrum, lean. Without giving feedback, how are you going to improve?
mmcnl 7y ago
This is terrible but has nothing to do with scrum. Poor management won't magically disappear after adopting scrum.

icelancer 7y ago

> Daily standup I have never worked at a company where this actually goes right and could not be replaced by [insert ticketing system here]. We use Basecamp to do daily check-ins on a very high priority issue, if we have one, which we usually don't.

thrower123 7y ago
Managers are the only people that like daily standups, so far as I can tell. I've never figured out why you couldn't just do it over slack or equivalent. It's massively inefficient to get everyone to meet up in the morning.
- detaro 7y ago
  Many places do it over Slack.
- rdtsc 7y ago
  Managers need to justify their jobs. Reading off a slack report every day seems too simple and not worthy the salary they're paid. Compare that to a large meeting and live status updates, everyone stands, etc. Now that is some "serious work" happening. Think of it from the point of view that managers have mangers they report to. When shit goes wrong they have to cover their asses. "So it's late. But did you check on their progress? Wait just over slack, no actual meetings? Ok, that obviously needs improvement".
  - tomjakubowski 7y ago
    It's not like it's a requirement that "managers" be at a standup meeting. Some of the best teams I've worked on have done daily standups without managers, and I dare to say most of us enjoyed them and found them productive!
    - asark 7y ago
      Managers are often looking for ways to fill their calendar. Meetings, calls that could be a two-minute Slack exchange, et c. Some will hop into meetings like that if they can. They love the recurring ones, especially, bonus if they can apologize any time they have to skip it for something that actually, maybe, matters ("uh, yeah, we don't care if you come, OK, thanks for apologizing I guess?")
    - mcv 7y ago
      I have never been in a team where managers were present at the standup meeting. In fact, sometimes I have no idea who my "manager" even is. We've got a team, we've got stakeholders, we do the work. If a manager wants to join, that's fine, but he's not in charge of that meeting. All this talk of standup meetings being primarily for managers is really weird. It's not for managers, and they have no reason to be present. It's for the team, to improve cooperation within the team. If the team has a better way to accomplish that, then they should use that.

crummy 7y ago

Standups can have their use but I can't imagine a 20 person standup being useful. Why do you bring so many teams together for it?

anon1m0us 7y ago

The way I decided to play the game was like this, "I won't be attending the Daily Standups anymore as I don't think they add value and do subtract value." The project mgmt response was, "Attendance at standups is mandatory." Regardless, I didn't go to anymore standups and when I got flack for that, I stopped going to the office all together. When I got flack for that, I stopped working all together. Then I got fired. That solved all my scrum problems.

boltzmann_brain 7y ago
Underrated post
analog31 7y ago
I got criticized for zoning out at scrum meetings. So I watched what the managers do. They show up for the first few minutes, look alert, then leave as if in a hurry. I started doing the same thing, and never had a problem again.
- Aeolun 7y ago
  If you do this often enough. People will assume you are busy if you don’t show up at all.
  - madmulita 7y ago
    Don't forget to always roll up your sleeves and carry around some papers.
    - alchemism 7y ago
      If you are in a paperless office, tapping a tablet with a stylus as you walk confers the same office space prestige.
- maxxxxx 7y ago
  That seems to be secret for managers anyway. Always appear eager and motivated and then run away.

scarejunba 7y ago

Are you in a position to effect change? If not, leave if you can. If not and you can't leave, suck it up. Otherwise, here's a couple of notes freely given with no claim to excellence except that I've worked with successful scrum teams and unsuccessful ones: * The 'business' is everything. All code is liability. Code that can't do things the business wants to do and hinders those things is a particular cost to the business. Product Owners who don't understand that "refactoring code to make it extensible before extending it" is the cost of doing business just have to learn that lesson. If they won't, let them go. Bad ones are a dime a dozen so you can always hire another clueless one if you want. It's like having a loan that you're paying lots of interest on. Saying "We can't spend time refinancing that. We have to go earn money." doesn't make sense as some absolute truth. * Engineering is not in contrast to the business side. There is no need to represent engineering because the product owner is supposed to be able to understand all inputs into the program. If engineering is slowed down by the lack of dealing with some technical debt that's not some engineering problem divorced from the business. It's the business. This requires reaching across from the engineering side, being clear when things aren't going well, not starting on ridiculously long "refactoring" projects that are just lateral changes, and being clear what the expected outcome of any tech debt relief is. Avoid "feels cleaner", "is more elegant", "is more extensible". Talk in terms of outcomes: faster response to outages, the ability to add things like X (requires you to understand the product some, which is something an engineer should do), less time spent debugging issues. If trivially measurable, measure and demonstrate improvement. Builds trust. * I'm not too convinced "Scrum Master" needs to be a solo job for anyone. The incentives are skewed. If you have a team of ideal people and they all pick up on the principles and you correct the bad patterns they have, they won't need you. The job inherently obsoletes itself which means the median person taking the role will entrench themselves in process to keep themselves relevant. * 20 people at daily standup makes no sense. It's 10 minutes or 15 or whatever so you have 30 s to describe something. It isn't so much the time, though, but the fact that there are too many people here together in the room. It makes no sense. Find smaller units of organization. Conway's law presents but the alternative is much worse.

jboy55 7y ago

First of all, most issues with process issues are more a reflection of the organization and what drives them than the process. I would say you should start talking about, 'Our process' instead of 'Scrum'. >These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I need to up my game with how to play it - but I wish I could use something else, perhaps kanban. Spoiler, your Scrum books aren't going to help you figure things out, unless your org actually wants to change. You have your own unique process, but that you have a unique process isn't an issue. The issue is that your management seems to not respect the input of engineering. No process will work the way you want as long as that is true. Some thoughts, * Most critical, your team is way to big. Should be half as big * Scrum master should be a team member and rotated along the team. The process should be a result of constant tuning via the Retrospective. The scrum master here, should lose his job. * Engnineering owns the implementation of the stories, product owners should not be a part of the conversation on how to do something, they only can say 'what'. * If you can't decide your own points, then again, you have your own process. If you can, and you need to refactor, you need to add points for that. If you can't do anything to change, then again reading scrum books isn't going to help. You can say, 'this isn't the way your supposed to do this' as much as you want. processes always reflect the organization. Unless the engineering team is an equal to the product team, it won't matter what process you have.

addicted 7y ago
However, many companies face similar issues. For a moment I thought the OP worked for my company because we face the same issues (that's not possible however because in person stand ups are banned at our company due to the distributed nature). 1) While I agree that 20 people seems like too large a team in general, I have a fundamental problem with the idea that scrum can determine what size team is right. What seems to be happening, it appears to me, is that we have a fair idea of how large a meeting can be before it becomes unwieldy, and scrum has a daily meeting as it's fundamental component, so basically decides that for it's fundamental component to be effective there shouldn't be more than 8 people so therefore teams shouldn't be larger than 8 people. That seems backwards to me. 2) Almost every scrum training usually has a separate scrum master. I do think the idea of a team member being the scrum master makes a lot of sense and would probably alleviate a lot of the concerns. 3) Scrum story points are supposed to reflect end user benefits. A refacorin's benefit will only show up after several sprints. In the meanwhile you hurt your velocity significantly because your refactoring is likely to be 0 points. Now, this actually makes sense to me, but the issue is that in most places management is carefully monitoring velocity and is gonna hold the drop against the team. To be fair though, I think this is another issue where the real problem is management converting a measurement metric into a target, which basically negates any use it may have as a metric. My biggest issues with scrum are: 1) A daily standup is ridiculous. It's highly disruptive and gives me the feeling of someone constantly peeking over my shoulder. A better strategy is a simple email when someone has an update, or a blocker to the rest of the team. Very few of my projects are done in a single day, and it's psychologically stressful to join every meeting saying I worked on story A, will continue working on story A for 3-4 days in a row, while the managerial types rattle off a list of meetings they attended, emails they sent, trainings they completed, etc. 2) Sprints are far too inflexible. Each story should basically define a new Sprint for the people involved in that story, which may or may not be longer than originally expected. I don't see the point of having a fixed 2 week period that applies to everyone. Why not just have a weekly or biweekly meeting where you go over everyone's stuff and see where you stand. It's basically a more flexible version of what sprints try to achieve, without the psychological issues created by having to fit things into a Sprint or alternatively having to carry it over into a whole new Sprint. That same meeting can track how many points were earned since the last meeting and you have your velocity being tracked as well. Retrospectives are great. But they should be included in the same 2 week catch up meeting. I find scrum tries to create a lot of artificial deadlines, possibly to encourage people to break things into smaller pieces and make regular progress, but I find that's not how people usually work. In my experience people tend to work more in spurts, delivering a ton of features and bug fixes over a couple of days, and then going relatively quiet for the next few days. Not because they aren't working, but because thats just how things usually pan out since software development is a decidedly non linear process.

y96V89C668e7Q74 7y ago

I feel like you work at my last company. But so many companies f* this up that it could be any company. I got fired from any last job after being one of the only engineers willing to say something to management about this. I figured I had a popular opinion - many other engineers often DM'ed me on slack encouraging me to continue speak out, including my own manager, so I somehow figured I should be safe speaking out, politely, as a respected majority representative. In fact I was dead wrong. By saying that scrum was a problem, I ended up making product managers / CTO who loved scrum and used it as an hour long opportunity to lecture the team every day feel threatened. Getting fired was one of the best things that ever happened to my career, because in retrospect it was a dead end company that was run by fear. Management was afraid of ideas or challenge to power to the point where innovative ideas and feedback were never well received and a culture of fear and not stepping out of line arose, even though it was sugar coated with fake company values of "openness" that nobody really believed in but that managers loved as a way to elevate themselves. I suspect many companies are a my least a little bit like this. Unfortunately it is human nature and there are so many stories in history, usually of narcissistic dictators, that mirror this. This was a very extreme example but I'm sure many other companies struggle with this when it comes to challenging scrum. Managers tend to love scrum because it's a chance, daily, to "manage" and to get status updates so that they feel comforted. It makes it so that trust is no longer necessary, and bad managers are often bad at trust. I guess another way to view scrum is to realize that it is often a reflection on management's subtle fears and insecurities being projected onto the processes of the company. It is an instance where employees unfortunately must manage up.

dragonwriter 7y ago

> Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room It is central to the idea of the daily standup is that it is one team. > Its limited to 15 minutes, so nobody says much of importance, and just parrots what is already on the Jira board. If you have another mechanism for sharing what each person has done and is doing, then the standup should just be for sharing information about and resolving barriers. > Stories are supposed to be forecasts, not commitments. But the business doesn't like stories carried over, so they become commitments. If you organizationally can't get away from commitments, then you need to cut back the amount you plan to do so that there is some slack. As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly.

doomslice 7y ago
> As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly. The powers that be at my work decided that “sprint predictability” is the most important metric here. This means that if we pull in stuff near the end of the sprint but don’t finish, predictability goes down. Thus, we are encouraged to not take on extra work if we don’t expect to finish. What this means in reality is that we start working on it without pulling it into the sprint and then get a head start for next sprint. What’s your take on that?
- asark 7y ago
  My (related) experience has led me to believe reporting to management should be strictly separate from any tools or processes used to track actual work, specifically to avoid dumb shit like this. Team task-tracking should be a team communication tool. If you want to report task-related stuff upstream it should be totally separate, with updates/sync done by a human (project manager would make sense). I also think speculative future make-believe planning junk should be kept out of the real getting-shit-done tool. Put it in there when it actually matters. There should be no "on ice" or "phase 3" (when in "phase 1") crap in the tool the devs use. It may or may not make sense to have them involved in planning stuff that early, but keep the output of that planning away from the real-work trackers until it's closer to time to do it. I think that's part of why Jira (and similar, heavy, report-focused tools) is so god-awful. It not only tries to have features for teams to get stuff done and for five other roles to dig around in tasks and reports for whatever reason, it enables and encourages that, and I'm fairly sure, at this point, that it's fundamentally a bad idea.

maxxxxx 7y ago

I passionately hate being asked for "commitments". If it's stuff of any reasonable complexity or novelty I will have no idea how long it will take and therefore can't make any commitments. The only thing I can commit to is to make sure that people don't waste time and work towards the goal. The problem is that management has no problem wasting a lot of time with useless meetings or not committing to the final feature set but instead changing requirements all the time.

Aeolun 7y ago
Changing requirements is fine, as long as they recognize that stuff like that impacts the schedule. Generally they don’t though.
sopooneo 7y ago
If you can say more than a minute, but less than a decade, you've already got SOME idea of the timeframe for a task. Granted that sort of estimate would get you called to HR for insubordination. But can you pull the bounds in from either direction at all? I say this as someone just moving into project planning and management. From that perspective you start to see that some level of estimation s critical. My preference is to ask devs for just the tightest bounds to timeframe they're actually comfortable with, then estimate based on that and pass up the chain. I consider it to be on my shoulders if things take longer than I communicated upwards.
- maxxxxx 7y ago
  I understand that estimates are important and I give estimates. But recently in my company it’s fashionable to talk about “commitments” and I won’t give those. In my view this is just a way to get overtime and weekend work out of people once things fall behind so they meet their commitments. I commit to do my work as best as i can but I can’t commit to work overtime because of issues that are often out of my control.
  - sopooneo 7y ago
    That makes perfect sense. And I applaud your push against a practice that does seem to be pushing devs for unpaid overtime. You're right.

munchbunny 7y ago

I think this gets at a very common problem with managers in the hierarchy. They forget that iteration of processes is crucial to good agile process. Your goal isn't to adhere to "true scrum." Your goal is to tailor scrum to what your team needs. If your daily stand-ups are just repeating the JIRA board, then just give people back their time. If your features are coming out badly designed, then stick a designer in the engineering pods, or call out the design phase in project lifecycle. If your projects are consistently late, then... slow down the estimates! Of course teams that do it right tend to know this, but the bad implementations of scrum I've seen consistently lack attentive iteration on the process itself.

bartimus 7y ago

> User Stories are supposed to be forecasts, not commitments. Indeed the commitment is supposed to be with the sprint goals. I've seen this vital aspect of scrum getting overlooked too often.

VonGallifrey 7y ago

> One gripe I have about scrum, is there is nobody representing engineering, as the product owner represents the business. That is definitively not be the feeling you should have. In "proper" scrum the Team is supposed to represent engineering. If you, for some reason, don't feel like you can represent these concerns then that is a huge issue. The PO shouldn't be your boss either. At least it isn't so in the company I work for. It sounds like the PO is the boss of that team, if he "keeps you busy". I am super grateful that our Scrum Master knew what he was doing and suggested creating a separate line on the Org chart for the POs so that they are explicitly not in charge of development. The team is in charge and POs are more advisory. Sounds to me like there are some deeper problems in the company then just the scrum. There are so many red flags in your comment. I don't know if those books are going to help you "play" scrum better, because what you guys are doing does not sound like scrum at all. Kanbans probably also not a solution. I really like Kanban, but it isn't going to remove the bad elements that seem to control that company.

mcv 7y ago
Yeah, that's an odd complaint. You are engineering, are you not? The meeting is already about engineering. If you have more engineering as an outside stakeholder that the PO isn't able to represent, by all means bring someone in to represent them.
verinus 7y ago
this. In scrum the dev teams maintains a technical backlog and fills the sprintbacklog as THEY see fit- from the product backlog AND the technical backlog. the PO has no say in this! he can complain that he thinks not enough features from his product backlog are planned, but should trust that the team knows what they are doing.

megaremote 7y ago

> Daily standup Change them so that people talk about what is blocked then. > Scrum master Tricky, like anyone who doesn't want to adapt. > Technical debt Create tickets for debt, put them on the backlog. > Poor product owners Tricky.

alkonaut 7y ago
> Create tickets for debt, put them on the backlog. That will risk making a huge technical debt section in the backlog that will find it hard to get priority. It's better to condition new features/bugfixes on the cleanup that caused them. "I can add this feature in 1 day but will need 4 days to clean it up. So my estimate is a week." I constantly nag developers to do this when they find that they are pressed for time and want to make a hack. -"I'm nearly done but I can't find a nice way of doing this because of an existing code smell so I'm considering adding another smell" -"Did you ever find that this was NOT the case?" -"No..." -"So do you always double or triple your estimates so you know you can comfortably refactor" -"No..." I think this is a disease of Scrum. Too short estimates exist because developers pat themselves on the back for finishing things quickly.
- postfacto 7y ago
  That will just lead to stories to change something simple the color of a button taking 3 days because you hit a tech debt minefield refactoring. You don’t want someone looking at JIRA and seeing it took you 3 days to change a simple button color. Keep technical debt in separate tasks to make the tech debt visible and to keep management accountable for not making efforts to get rid of it.

tannhaeuser 7y ago

> nobody says much of importance, and just parrots what is already on the Jira board Worse, the moment anything of interest gets being discussed, SM stops it, saying "let's take this offline" (in German-speaking projects at least, where there's a tendency to use English words to really say nothing at all). Which brings us to > any deviation from scrum itself poses a threat to this person's job security, so it doesn't happen MBAs have identified and captured the role of a Scum master (sic!) to comfortably represent a project towards management, without the responsibilties of a project manager (I'm just moderating the project), yet with an instrument to turn time-based freelancing and employed work into a fixed-price deal through commitments/forecasts.

mcv 7y ago

Standups with multiple teams, or simply very large teams, are a terrible idea. I'm currently in a team that has very quick, fun and productive daily standups (despite not even having a good standup space for it), but we have only 3 devs and a handful or other people involved. But I've also been in projects where standups drag on and on and on, and they're hard to get under control. Usually, those projects had much larger teams. I suggest smaller teams, and if you have this kind of multi-team standup, discuss with your team to have your own independent standup instead and send one representative to the big one.

jpswade 7y ago

It sounds like you're missing probably the most important part of agile which is "at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly". In Scrum, it's retrospectives. Continuous improvement is a theme that runs across agile, scrum, lean. Without giving feedback, how are you going to improve?

mmcnl 7y ago

This is terrible but has nothing to do with scrum. Poor management won't magically disappear after adopting scrum.