13 ms·

I've learned to hate software process. If you have team sizes set sanely and empower devs to do what they need to do in order to accomplish the goal, they'll b

I've learned to hate software process. If you have team sizes set sanely and empower devs to do what they need to do in order to accomplish the goal, they'll be fine without the management overhead of arbitrarily imposed productivity flow. Agile et al, along with 99% of the features in ticketing systems, exist to make managers feel like they are justifying their paycheck. If you are a manager and this makes you angry, you're one of the bad ones.

loloquwowndueo 2y ago
Just keep in mind that a lot of people equate Agile with Scrum, which is incorrect. Agile is about exactly what you said: empowering devs to get shit done. None of the extra “keep managers happy” crap that Scrum introduces is in any way covered by the Agile manifesto.
- dangard 2y ago
  [flagged]
- LeFantome 2y ago
  What in Scrum is about keeping managers happy?
  - pan69 2y ago
    Story points, velocity, burn down charts, shit like that.
    - wild_egg 2y ago
      None of those things are part of scrum as described by the actual guide
      - RussianCow 2y ago
        But nobody follows the actual guide so it doesn't really matter.
  - wsc981 2y ago
    Some things that come to mind: - burn-down / velocity charts - retrospectives - poker sessions - daily stand-ups - user stories and related tickets (eg in JIRA) There’s probably more ... Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff. As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we don’t deal with any of the above shit. Which of course is sure to change as the company grows, as that seems to happen often. Our current way of working (remote company, 4 people): - 2 calls a week, which tend to last about an hour. - We discuss work for upcoming week or future stuff. - We try to deliver every week on whatever was agreed upon at start of week. Actually, previous company I worked at, was a bit bigger (35 people), but also very little rituals, at least for devs. There was a support department that did the JIRA related stuff. And we had like 2 day-long meetings every year to discuss personal goals/work for next half year. But afterwards just a short weekly meeting for team (sometimes lasting only 10 minutes), no stand-ups and such.
    - jghn 2y ago
      I've been a dev, and I've been an EM. The only thing on that list I've ever liked is the velocity charts. And the only reason I liked them is that it helped me give a slightly less made up date to my own bosses to explain when something might ship. Over the years I've found that devs have been the one who like retros. Or at least a certain subset of them. When I've been an EM I would try to get rid of them, only to have them requested by my teams. Who knew.
      - rpcope1 2y ago
        As a developer, I find retros most useful when EMs (and probably PMs, depends on how things are configured organizationally) aren't present, as it should give a chance to talk freely about challenges you or the team face, which often are organizational in nature and may involve one's management chain. My current role doesn't adhere to this, and it makes retro often really painful.
        jghn 2y ago
  - twunde 2y ago
    Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. Sprints themselves which promise that a certain amount of work will always get done, without any free time being wasted. A lot of the ceremonies in general are mostly helpful to the EM/PM. How many things that you're doing are actually improving how you get work done? Especially when you consider how much time is spent on these ceremonies (sprint planning 1 hr, sprint retro 1 hour, daily standup 15-30 minutes. Plus whatever prep is needed and the interruption time.) For many companies this is a 20% or more overhead that's mainly busywork because you still need the additional meetings to understand what you're working on.
    - gedy 2y ago
      This may sound like a no true Scotsman argument, when our company was trained by one of the scrum founders about 18 years ago, they were very clear that the daily standup was only for the team members, and the scrum master. (The scrum master could be a team member, and rotate btw). Managers were not allowed or invited to these. The only thing product managers and engineering managers would participate in and give feedback was in Sprint demos, and the beginning of planning meetings to answer any questions on upcoming stories. At the time it was incredibly freeing and fixed a pretty awful and behind waterfall project. I was (briefly) at a startup a couple years ago that said they "did Scrum" and what a clusterfuck that was - all the managers meeting daily with devs to see if they were behind and scold them if they were. See ya.
      - ta_1138 2y ago
        But Managers as the center of the scrum is how many, many tech companies the outside world wouldn't call crappy run things. They also use Jira, mostly because they want reports that let people two or three levels up think they have any control over anything. One of my least favorite standups was even worse than a ceremony for the manager: The manager and the Product representative were there in every single one, but they didn't actually pay any attention: Another 20+ minutes of "parking lot" would be added after the 5-10 minute process as they asked the team all the random questions they thought they needed, in which they also proved that they weren't actually paying attention to the actual updates, or the tickets, or anything. In practice, a sequence of 1:1 meetings where everyone was stuck watching, because after inquisition to one person, it'd come after another. In practice, I don't think I've seen scrum run without a manager in standup, ever.
  - everdrive 2y ago
    Without a lot of the project reports, the manager would honestly just have no idea what's going on. I recently moved into management, and one of the challenges I'm trying to balance is how to be aware of my team's progress without wasting their time or being a bottleneck for them. It's a legitimate problem which is often tackled poorly.
    - skydhash 2y ago
      You can just talk to them. No need to set a ritual around it. Most professionals know about expectations and the team’s need to deliver.
      - everdrive 2y ago
        That's what I'm doing currently. We're a small team, and I'm a technical manager.
    - laboratorymice 2y ago
      regardless of "process", work items should be tracked (in the problem solving record for our future selves sense, not time keeping sense), so you can follow those. If you're a non-technical manager, then either a) the implementation goes super smoothly and the estimate the dev team initially gave you is all the progress update you need, or b) it doesn't go super-smoothly and you should be involved in any discussions that arise. If you find yourself asking "when is it ready?" you've likely gone astray.
    - randomdata 2y ago
      At least in the case of software development, which seems to be what Scrum is targeted at, you get the project reports for free by way of the commit log. That said, the 12 Principles of the Agile Manifesto offers another solution: Get rid of management entirely. It states that developers are best to work with the rest of the business collaboratively. Which is the irony of Scrum claiming to be Agile: Only management wants to use it, defying Agile to its fundamental core.
  - dartos 2y ago
    Burn down charts, team velocity, and story points. They all exist to give software development the illusion of predictability, but saying that a project should take “x sprints” is just setting a deadline with extra steps.
    - PaulHoule 2y ago
      There is nothing wrong with burndown charts but story points and team velocity are poison. The way you get good at estimating is looking at your database of experience. “I did a task similar to this in 8 days”. Calendar time is real and punchclock time is real, either can be measured. Story points are not real and not measurable and they leave you lost at sea thinking that estimation is impossible, a scam, etc. See also https://en.wikipedia.org/wiki/Function_point https://en.wikipedia.org/wiki/Function_point Which is also a kind of development “funny money” but which have a somewhat rigorous method to arrive at estimates.
      - rerdavies 2y ago
        Agreed. Team velocity is a poison number. But entirely necessary in order to provide a data-driven approach to converting story points into time predictions (with appropriate disclaimer of risk) that people outside the team need. Data driven! How could that possibly be a bad thing? Maybe best to just treat it as a classified secret that nobody actually needs to know. People inside the team just need to know that their stories are arranged in correct order of priority. People outside the team actually do need time axes on their burndown chart. But they don't need to actually know the toxic voodoo that was performed to produce the conversion. :-P But actually seriously. Nobody needs to know that number.
    - rerdavies 2y ago
      Right. So you don't do that. No development process ever has provided bulletproof predictability. Your job as a project manager is not to provide bullet-proof predictions; it's to manage risk, and expectations, and make sure that development work is correctly prioritized. And of course to keep your development team protected from external insanity, because happy, stress free development teams are productive development teams. (But that's a separate issue). Here's the feature list; here is where on the list we'll definitely get to, here's where on the list we definitely won't get to, and everything else is some shade of inbetween. Now, would you like to adjust the priorities of any of those features, or would you like to change the deadline?
  - _heimdall 2y ago
    I don't know if this is properly part of scrum, but it is how I've seen it implemented on every team I've been on where scrum was implemented. Sprints end with some kind of demo, retrospective, and sprint planning designed almost entirely to keep PMs and managers in the loop and happy. Reports are generated, spreadsheets with a few quarters worth of tasks are updated, and PMs or managers get to run that further up the chain, presumably to make it clear that great progress is being made under their supervision and well run scrum methodology.
    - lo_fye 2y ago
      There are no PMs in actual Scrum. Scrum Teams are self-managing, so there's no need for a PM. There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum. Scrum is iterative, by design. It's supposed to evolve with the CLient's needs and desires. They want to be able to change the scope, the price, and the timeline on a whim. If you aren't billing per-Sprint, then you're going to have a constant "charge the Client for a change request" mentality, which makes them feel like they're being Nickel and Dime. It's much better to say "We welcome your changes at any time for any reason. It may not fit in the next Sprint, but we can always put them in the one after that." In Sprint-based projects the Client has to be free to terminate the agreement at any time, if they feel they're not getting enough value in exchange for their money. This is why constantly delivering value to the Client is key. When they charge a flat fee, they feel they need a PM to make sure they don't lose money. And how can you know if you're losing money? You force people to track their hours back. It all gets toxic. When the Client pays per Sprint, as long as each Sprint is profitable and delivering value, it can be a huge profit center that has no end date. Often times, Clients will just keep adding features forever instead of stopping at the flat fee end date.
      - _heimdall 2y ago
        I could have been more clear there, "PM" has many different meanings these days. I've never been on a team using scrum that didn't have a project manager or product manager as part of scrum (or both). Most often they have been my scrum leader. Scrum is supposed to be self-guided, but I have never seen it implemented on a team of any scale. I also wouldn't expect a team without PMs, whether that's project managers or product managers, to be very effective. Someone needs to be focused on keeping the project moving, and often the skills needed for a scrum leader/master overlap greatly with project managers. Someone also needs to be focused on the product and how the team's efforts fit into the longer term product goals. If that isn't anyone with a PM title it will be someone else playing that role with everything but the title.
  - pie420 2y ago
    they give managers visibility, deliverables, stuff to fill their calendars with, and automates their job into easy, if inefficient daily meetings.
- 2-3-7-43-1807 2y ago
  1) scrum is even more democratized than agile 2) no matter what "agile" was supposed to mean - managers anyway interpret it as devs having to be very agile for them all the time ...
  - jrs235 2y ago
    And by "devs having to be agile" you mean "devs having to be interruptible during managers hours and flexible in doing their work after all the bs office hours are over".
    - 2-3-7-43-1807 2y ago
      exactly ... i mean even without hindsight "agile" is a rather poor choice as the label. it just evokes the wrong ideas too easily.
      - slim 2y ago
        it's not poor, it's clever. that marketing is what made agile the dominant paradigm nowadays. remember agile was adopted in entreprise despite IBM pushing RUP
- whiteboardr 2y ago
  From experience i haven’t come across any “agile” organization that runs true to the manifesto. There’s been plenty of discussions why the “what could have been” got buried in certain people jumping in, creating weird layers and interpretations of some process for their own profit and ego. Chinese whispers then lost in translation.
  - _heimdall 2y ago
    I worked at a small startup that actually handled that distinction well for a while. We did 2 week sprints, but that really was more to keep a remote team regularly in touch and updated. Sprint work was very much up to each dev, and at the end of the sprint anything that changed or slipped was just chalked up to lessons for future work. That did change eventually, both as the team grew a bit more and funding started to run low. Eventually we had the worst of both worlds mentioned in the article, sprints with more rigid goals leading to a quarterly goal driven more by marketing goals than anything else. Throw in the fact that the still rather small company ended up with one person making product, marketing, and even technical decisions and we devolved into glorified code monkeys pretty quickly.
  - whstl 2y ago
    My team works in an agile fashion. I simply stay out of their way and every week they finish what they promised to finish. The team is high-quality and hasn't missed targets or estimates. Most of our "ceremonies" are purely for socialization, as decided by the team. But this is extremely fragile, because it takes a lot of energy to fight external people (often product people) who want to remove the self-management aspect. Unless this is in the DNA of the company, you can't have agile or real Scrum, because it threatens those kinds of power-grabs. For this to work, you literally need someone threatening to fire people who attempt to micromanage others.
- replwoacause 2y ago
  We use Agile at our company and let me tell you, it sucks. Maybe straight up scrum would be worse, but honestly agile is invasive and just feels like you’re being babysat and forcing people to give BS updates at standups because they’re afraid of sounding unproductive.
  - prepend 2y ago
    I find Agile is like democracy. It does suck, but it’s better than everything else. What would you prefer besides agile? I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Everyone should just work on things until they are done. He argued this earnestly and didn’t recognize that there are opportunity costs and conflicting priorities and the need to choose what to do. He earnestly argued that every single user story should be worked on in order of entry until it was completed. It would have been precious how clueless this suggestion was if he didn’t spent 20-40 minutes a week arguing this as an explanation for why his items weren’t done and why he was civil disobediencing to refuse to estimate or report time on tasks.
    - rightbyte 2y ago
      I'd have the straw man variant of waterfall every day in place of agile. Like, the constant micromanagement and process lawyers pushing you down makes me misarable. At least with classic project processes you'd have some oversight plan to follow.
    - pyrale 2y ago
      > I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Plenty of learned people have made defenses for having no estimates. If you want to make the opposite claim, you don't need to use a junior dev as a strawman.
      - prepend 2y ago
        I think estimates are wrong but useful and necessary. I don’t think it’s a strawman argument at all. For simple activities you can get by with no estimates but with dependencies estimates become more and more necessary.
- lo_fye 2y ago
  "Keep managers happy" isn't part of Scrum, either. If you read any of the Scrum books by the creators of Scrum, you'll find that the way 95% of companies implement Scrum is nothing like what Scrum was intended to be. They mess it up, essentially in the name of marketing, and not wanting to truly change their ways.
- JohnFen 2y ago
  > Agile is about exactly what you said: empowering devs to get shit done. Sure, that's the goal. In reality, though, that's very nearly never what it does in practice. That's why I have come to view "agile" shops with an extremely skeptical eye.
- philwelch 2y ago
  Most “Agile” process are agile in the same sense that the Democratic People’s Republic of Korea is democratic.
benfortuna 2y ago
But what does it mean to "empower devs". Do you give them requirements and say I'll check in on deadline day in 6 months? Presumably you would still use iterations to track progress, Epics/Features to break down requirements, some kind of estimation to track if you're ahead/behind schedule? I certainly wouldn't go back to Waterfall days, but I suspect many current devs never experienced that.
- shaunxcode 2y ago
  as things are ready to be shown you will see them : this is how you will know
- Retric 2y ago
  There’s a world of difference between checking back in 6 months and daily standup meetings + a host of weekly meetings. If you don’t trust your team to be productive for 2 weeks without communication something is deeply wrong. Individuals should be in constant communication, but few things need to be said to everyone. Scrum style management may be useful for highly dysfunctional teams, but it frequently adds a great deal of unnecessary overhead.
- gridspy 2y ago
  - One on Ones to discuss roadblocks and thoughts every week. - Issue tracking as a common place to describe what needs to be done and thoughts / details on how it is solved. Something lightweight like Trello is ideal - A Kanban board so people have an organised way to pick up new issues when low on work - A weekly showoff meeting where there are few 5 minute presentations and a 30 minute "I did something really cool or learned something really cool" - 6 month task split into 1 month ish deliverables, with a flexible deadline for each. Presentation of finished work each deliverable.
  - cvoss 2y ago
    This is basically how my team does it. I love it. My manager spends much of her time figuring out how to help remove our roadblocks and planning the 6 month to 1 year horizon (with our input). I lead the weekly meeting where we do the showing off, PSAs, or light brainstorming on issues with broad relevance. Two scheduled meetings per week = tons of dev time and freedom to explore / innovate! (Ok, three weekly meetings if you count the product-wide meeting, which is usually a waste of N-5 people's time, and I usually have it on the background while I continue working.) We are remote, so ideally there's also one in person gathering per year to do the big vision casting and major high level brainstorming. We still have room to improve, especially in the area of ad-hoc dev-dev communication. Always interested to hear how others do it!
justmarc 2y ago
Absolutely right. Well put.
bdangubic 2y ago
After 26 years in the industry this is the only process that actually works - hire the right people and get the F out of the way
- tcgv 2y ago
  > hire the right people That’s no easy feat and often oversimplifies the challenge of building competent teams. I think it’s achievable if you have a large budget to hire only senior/experienced devs and a mature hiring process/team. Plus, if your company has strong tech branding, it becomes easier to attract top talent too. But if you’re at a startup with limited funding and possibly no branding at all, you’ll likely face this situation: - Hire inexperienced but honest, motivated people with the potential to grow, and invest in mentoring them.
  - bdangubic 2y ago
    I do not disagree with anything you said at all! Though chances of success diminish here. If you have to introduce some "process" - whatever that "process" is - because you do not have competent people and you feel like "process" will fix it, your chance of succeeding are a lot smaller IMO...
bfrog 2y ago
Pizza sized teams that can directly interact with customers don't need management. Management is playing telephone with someone in the middle with their own interpretation of everything which is 99% wrong.
- patrickmay 2y ago
  It sounds like you've had bad management (like we all have). Good EMs will unblock you, deal with conflicting priorities from stakeholders, provide you with air cover to have focus time, and help manage your career growth (among other things). If your EM isn't doing that, find another one.
  - randomdata 2y ago
    > Good EMs will unblock you, deal with conflicting priorities from stakeholders, provide you with air cover to have focus time, and help manage your career growth (among other things). Those don't really seem like things you'd want to outsource, no matter how good the outsourcee is.
- ozim 2y ago
  Sounds like you mix up management with product people. Product people are not management at least not where I worked. I see how it might be a problem if your manager is talking to the customers. Product people are or should be equal to dev, engineering. They should indicate priorities but should not in any way evaluate engineers especially if they have no technical expertise.
mrits 2y ago
The reality is even good devs tend to work hard on the wrong thing. Accountability comes from your peers as much as your manager. If this makes you angry you are one of the bad ones.
- skydhash 2y ago
  Everyone tends to work hard on the wrong thing if it what they like to do most currently. Everyone. A conversation is all that is needed to remind them of the team priority, non need to create a creativity carcan with processes.
- randomdata 2y ago
  Give good devs a direct line to the customer and they're apt to always work on the right thing, but will spend a lot more time dealing with the customer and a lot less time in development in order to do so. Leave good devs to play telephone through a middle-man, what we call the manager, and they almost certainly will work on the wrong things, but will have a lot more time to do it. I wonder which is actually more productive? Agile (of the Manifesto kind) posits that the former is most productive, but Agile (of the fake kind) seems to always want to revolve around the latter. The general sentiment is that fake Agile is the one that gets it wrong, so presumably cutting out the manager is what is most productive, but more data is welcome.
  - SoftTalker 2y ago
    Disagree. The customer often has tunnel-vision on their needs, and doesn't know what's possible, and might have trouble even describing it except that their manager told them that their foo task was a problem. The devs have the opposite problem, they can imagine all sorts of new technology that would be fun to use (for them) in helping the customer solve their problems with doing foo, and even if they understand foo from the customer's business perspective they they may not have a great understanding of how big a problem it is in the grand scheme of things and what commitment of resources and expenses are justifed in solving it. Managers talking to managers can (in theory) draw some boxes around scope and priorities and get the right development problems solved at the right time. They may talk and realize that doing foo isn't even really a great idea and they should be doing bar intstead. Line-level employees working directly with developers will not be as likely to realize that. Developers can fall into the trap of thinking that because they are smart (mostly) at building software they are automatically smart about all the business processes and problems and goals of the company. They should certainly be informed about those things, but they are not experts in everything.
Lutger 2y ago
I've heard a lot of push back against all kinds of process on this forum, and it always surprises me. But reading the article made something click: it is not about the specific process, the (lack of) autonomy is what really matters. I guess I got lucky to work a lot in teams where we largely controlled our own process, so even if we used bits and pieces of scrum, kanban or other methodologies, it was always of our collective choosing and when it didn't work, we changed it. I did like to have rules, principles and process. A simple playbook for a daily meeting that made us not forget important things and sped up the meeting. Making things in small increments meant that I didn't have to review thousands of lines of code. Having a visual overview of work neatly spelled out means I don't have to re-think every time I pick up a new item to work on. This also prevents useless work because one of your teammates decides to work on the same thing as you without telling it. All these things make me happier and more productive working together on some big thing. The key is that the team should be in control of the process, not some manager who isn't part of the team and affected by the process. You need to have a stake in it. The only other factor that undermines this is 'process for the sake of process'. Every part of the process needs to earn the inevitable cost its implementation is bringing. Some people seem to be happy paying the pricing without getting the value.
mrmetanoia 2y ago
It seems we go astray when we start defining and evangelizing things that may have worked for some group of people to push them on others. Somewhere in all this process stuff, I see maybe what some teams were doing but I doubt it was as rigid and I doubt they indulged in it when it made no sense. Once these teams or people are asked what they're doing right - it eventually gets defined into rules and then evangelized to people made to feel they can't deviate or improvise when the framework makes no sense. "Trust the process." So people start wasting their time going through the process rather than using the process as a framework/tool for getting things done, they 'do' the process. Their job is standup, their job is scrum, tickets, and points, and as a result their job is only marginally to do the things that need doing. Company's might take more issue with this inefficiency if the workforce didn't double as something to manipulate pre and post head/tailwind to make the stock rise.
SoftTalker 2y ago
All of these methodologies (and most formal software architectures as well) have as a their main sales pitch the idea that you can hire average/entry-level developers and build good software with reduced defects and on a defined schedule if you only follow these magic guidelines. It refuses to learn from The Mythical Man-Month and recognize that building software has an essential complexity that cannot be avoided. You need smart people to implement and manage it, and you'll have to pay them what the market says they are worth. Building software that's more complicated than a standalone CRUD system is hard, it will always be hard, and unpredictable, and to some degree stressful. No methodology will ever make it anything else because the methodology used doesn't change the nature of the problem.
bunderbunder 2y ago
My first and second experiences with Scrum couldn't be more different. And they were successive. Actually, they happened on the same team, same people, same project. Before: the team had internally decided to use Scrum. Other teams were not using it, and inter-team coordination used traditional project management methods. It was fantastic; the team worked like a well-oiled machine and I really did feel more productive. We never had crunch time. I did not feel the "end-of-sprint mini crunch" that this post describes; instead the norm was that, by the last couple days of the sprint, people were starting to finish up whatever tickets they had taken and pivoting to helping teammates get the rest of the work done. Oftentimes we'd close out all the user stories a day or so before the end of the sprint, and have all that time for tidying up the codebase, fixing small technical debt items, experimenting with new tools, or planning ahead for the next sprint. So, if anything, it was the opposite of what the article describes: the last few days of every sprint were downright relaxing. After: The executives got wind of Scrum, and decided to standardize the whole company on it. We stopped work for a week so that we could have a famous Agile coach do an all-hands Scrum workshop. Which was fun, but the middle and senior managers were conspicuously absent. And then, after that, things kind of went to heck. The way our team did Scrum rapidly started to change as our team manager started getting explicit instructions on how to do things. We also started experiencing pressure to keep or maintain velocity. We started getting questions about why our velocity was so much different from other teams'. We could explain that the story point scale is team-specific and you can't compare story points across teams, but that didn't go anywhere. As I said, the middle and upper managers skipped the Scrum training. They weren't interested in being lectured about what I'm sure they perceived as pedantic little bullshit details. I left that company and went to another where leadership didn't mandate any Agile methodology. My team did a homegrown Kanban-like thing. A team I collaborated closely with used Scrum. It also seemed to work pretty great. Again, possibly because we chose it for ourselves. I don't think the other team would have done as well on Kanban. Scrum wouldn't have worked so well for our team. I didn't see a problem with that. We each had different business domains that warranted very different "rules of engagement" with our stakeholders and ways of organizing the work. Since then it's been a couple more companies where "Agile" was mandated from the top, and, apologies to Tolstoy, but they were both miserable in the same way that the first one was after the Scrum mandate got handed down from above.

loloquwowndueo 2y ago

Just keep in mind that a lot of people equate Agile with Scrum, which is incorrect. Agile is about exactly what you said: empowering devs to get shit done. None of the extra “keep managers happy” crap that Scrum introduces is in any way covered by the Agile manifesto.

dangard 2y ago
[flagged]
LeFantome 2y ago
What in Scrum is about keeping managers happy?
- pan69 2y ago
  Story points, velocity, burn down charts, shit like that.
  - wild_egg 2y ago
    None of those things are part of scrum as described by the actual guide
    - RussianCow 2y ago
      But nobody follows the actual guide so it doesn't really matter.
- wsc981 2y ago
  Some things that come to mind: - burn-down / velocity charts - retrospectives - poker sessions - daily stand-ups - user stories and related tickets (eg in JIRA) There’s probably more ... Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff. As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we don’t deal with any of the above shit. Which of course is sure to change as the company grows, as that seems to happen often. Our current way of working (remote company, 4 people): - 2 calls a week, which tend to last about an hour. - We discuss work for upcoming week or future stuff. - We try to deliver every week on whatever was agreed upon at start of week. Actually, previous company I worked at, was a bit bigger (35 people), but also very little rituals, at least for devs. There was a support department that did the JIRA related stuff. And we had like 2 day-long meetings every year to discuss personal goals/work for next half year. But afterwards just a short weekly meeting for team (sometimes lasting only 10 minutes), no stand-ups and such.
  - jghn 2y ago
    I've been a dev, and I've been an EM. The only thing on that list I've ever liked is the velocity charts. And the only reason I liked them is that it helped me give a slightly less made up date to my own bosses to explain when something might ship. Over the years I've found that devs have been the one who like retros. Or at least a certain subset of them. When I've been an EM I would try to get rid of them, only to have them requested by my teams. Who knew.
    - rpcope1 2y ago
      As a developer, I find retros most useful when EMs (and probably PMs, depends on how things are configured organizationally) aren't present, as it should give a chance to talk freely about challenges you or the team face, which often are organizational in nature and may involve one's management chain. My current role doesn't adhere to this, and it makes retro often really painful.
      - jghn 2y ago
- twunde 2y ago
  Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. Sprints themselves which promise that a certain amount of work will always get done, without any free time being wasted. A lot of the ceremonies in general are mostly helpful to the EM/PM. How many things that you're doing are actually improving how you get work done? Especially when you consider how much time is spent on these ceremonies (sprint planning 1 hr, sprint retro 1 hour, daily standup 15-30 minutes. Plus whatever prep is needed and the interruption time.) For many companies this is a 20% or more overhead that's mainly busywork because you still need the additional meetings to understand what you're working on.
  - gedy 2y ago
    This may sound like a no true Scotsman argument, when our company was trained by one of the scrum founders about 18 years ago, they were very clear that the daily standup was only for the team members, and the scrum master. (The scrum master could be a team member, and rotate btw). Managers were not allowed or invited to these. The only thing product managers and engineering managers would participate in and give feedback was in Sprint demos, and the beginning of planning meetings to answer any questions on upcoming stories. At the time it was incredibly freeing and fixed a pretty awful and behind waterfall project. I was (briefly) at a startup a couple years ago that said they "did Scrum" and what a clusterfuck that was - all the managers meeting daily with devs to see if they were behind and scold them if they were. See ya.
    - ta_1138 2y ago
      But Managers as the center of the scrum is how many, many tech companies the outside world wouldn't call crappy run things. They also use Jira, mostly because they want reports that let people two or three levels up think they have any control over anything. One of my least favorite standups was even worse than a ceremony for the manager: The manager and the Product representative were there in every single one, but they didn't actually pay any attention: Another 20+ minutes of "parking lot" would be added after the 5-10 minute process as they asked the team all the random questions they thought they needed, in which they also proved that they weren't actually paying attention to the actual updates, or the tickets, or anything. In practice, a sequence of 1:1 meetings where everyone was stuck watching, because after inquisition to one person, it'd come after another. In practice, I don't think I've seen scrum run without a manager in standup, ever.
- everdrive 2y ago
  Without a lot of the project reports, the manager would honestly just have no idea what's going on. I recently moved into management, and one of the challenges I'm trying to balance is how to be aware of my team's progress without wasting their time or being a bottleneck for them. It's a legitimate problem which is often tackled poorly.
  - skydhash 2y ago
    You can just talk to them. No need to set a ritual around it. Most professionals know about expectations and the team’s need to deliver.
    - everdrive 2y ago
      That's what I'm doing currently. We're a small team, and I'm a technical manager.
  - laboratorymice 2y ago
    regardless of "process", work items should be tracked (in the problem solving record for our future selves sense, not time keeping sense), so you can follow those. If you're a non-technical manager, then either a) the implementation goes super smoothly and the estimate the dev team initially gave you is all the progress update you need, or b) it doesn't go super-smoothly and you should be involved in any discussions that arise. If you find yourself asking "when is it ready?" you've likely gone astray.
  - randomdata 2y ago
    At least in the case of software development, which seems to be what Scrum is targeted at, you get the project reports for free by way of the commit log. That said, the 12 Principles of the Agile Manifesto offers another solution: Get rid of management entirely. It states that developers are best to work with the rest of the business collaboratively. Which is the irony of Scrum claiming to be Agile: Only management wants to use it, defying Agile to its fundamental core.
- dartos 2y ago
  Burn down charts, team velocity, and story points. They all exist to give software development the illusion of predictability, but saying that a project should take “x sprints” is just setting a deadline with extra steps.
  - PaulHoule 2y ago
    There is nothing wrong with burndown charts but story points and team velocity are poison. The way you get good at estimating is looking at your database of experience. “I did a task similar to this in 8 days”. Calendar time is real and punchclock time is real, either can be measured. Story points are not real and not measurable and they leave you lost at sea thinking that estimation is impossible, a scam, etc. See also https://en.wikipedia.org/wiki/Function_point https://en.wikipedia.org/wiki/Function_point Which is also a kind of development “funny money” but which have a somewhat rigorous method to arrive at estimates.
    - rerdavies 2y ago
      Agreed. Team velocity is a poison number. But entirely necessary in order to provide a data-driven approach to converting story points into time predictions (with appropriate disclaimer of risk) that people outside the team need. Data driven! How could that possibly be a bad thing? Maybe best to just treat it as a classified secret that nobody actually needs to know. People inside the team just need to know that their stories are arranged in correct order of priority. People outside the team actually do need time axes on their burndown chart. But they don't need to actually know the toxic voodoo that was performed to produce the conversion. :-P But actually seriously. Nobody needs to know that number.
  - rerdavies 2y ago
    Right. So you don't do that. No development process ever has provided bulletproof predictability. Your job as a project manager is not to provide bullet-proof predictions; it's to manage risk, and expectations, and make sure that development work is correctly prioritized. And of course to keep your development team protected from external insanity, because happy, stress free development teams are productive development teams. (But that's a separate issue). Here's the feature list; here is where on the list we'll definitely get to, here's where on the list we definitely won't get to, and everything else is some shade of inbetween. Now, would you like to adjust the priorities of any of those features, or would you like to change the deadline?
- _heimdall 2y ago
  I don't know if this is properly part of scrum, but it is how I've seen it implemented on every team I've been on where scrum was implemented. Sprints end with some kind of demo, retrospective, and sprint planning designed almost entirely to keep PMs and managers in the loop and happy. Reports are generated, spreadsheets with a few quarters worth of tasks are updated, and PMs or managers get to run that further up the chain, presumably to make it clear that great progress is being made under their supervision and well run scrum methodology.
  - lo_fye 2y ago
    There are no PMs in actual Scrum. Scrum Teams are self-managing, so there's no need for a PM. There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum. Scrum is iterative, by design. It's supposed to evolve with the CLient's needs and desires. They want to be able to change the scope, the price, and the timeline on a whim. If you aren't billing per-Sprint, then you're going to have a constant "charge the Client for a change request" mentality, which makes them feel like they're being Nickel and Dime. It's much better to say "We welcome your changes at any time for any reason. It may not fit in the next Sprint, but we can always put them in the one after that." In Sprint-based projects the Client has to be free to terminate the agreement at any time, if they feel they're not getting enough value in exchange for their money. This is why constantly delivering value to the Client is key. When they charge a flat fee, they feel they need a PM to make sure they don't lose money. And how can you know if you're losing money? You force people to track their hours back. It all gets toxic. When the Client pays per Sprint, as long as each Sprint is profitable and delivering value, it can be a huge profit center that has no end date. Often times, Clients will just keep adding features forever instead of stopping at the flat fee end date.
    - _heimdall 2y ago
      I could have been more clear there, "PM" has many different meanings these days. I've never been on a team using scrum that didn't have a project manager or product manager as part of scrum (or both). Most often they have been my scrum leader. Scrum is supposed to be self-guided, but I have never seen it implemented on a team of any scale. I also wouldn't expect a team without PMs, whether that's project managers or product managers, to be very effective. Someone needs to be focused on keeping the project moving, and often the skills needed for a scrum leader/master overlap greatly with project managers. Someone also needs to be focused on the product and how the team's efforts fit into the longer term product goals. If that isn't anyone with a PM title it will be someone else playing that role with everything but the title.
- pie420 2y ago
  they give managers visibility, deliverables, stuff to fill their calendars with, and automates their job into easy, if inefficient daily meetings.
2-3-7-43-1807 2y ago
1) scrum is even more democratized than agile 2) no matter what "agile" was supposed to mean - managers anyway interpret it as devs having to be very agile for them all the time ...
- jrs235 2y ago
  And by "devs having to be agile" you mean "devs having to be interruptible during managers hours and flexible in doing their work after all the bs office hours are over".
  - 2-3-7-43-1807 2y ago
    exactly ... i mean even without hindsight "agile" is a rather poor choice as the label. it just evokes the wrong ideas too easily.
    - slim 2y ago
      it's not poor, it's clever. that marketing is what made agile the dominant paradigm nowadays. remember agile was adopted in entreprise despite IBM pushing RUP
whiteboardr 2y ago
From experience i haven’t come across any “agile” organization that runs true to the manifesto. There’s been plenty of discussions why the “what could have been” got buried in certain people jumping in, creating weird layers and interpretations of some process for their own profit and ego. Chinese whispers then lost in translation.
- _heimdall 2y ago
  I worked at a small startup that actually handled that distinction well for a while. We did 2 week sprints, but that really was more to keep a remote team regularly in touch and updated. Sprint work was very much up to each dev, and at the end of the sprint anything that changed or slipped was just chalked up to lessons for future work. That did change eventually, both as the team grew a bit more and funding started to run low. Eventually we had the worst of both worlds mentioned in the article, sprints with more rigid goals leading to a quarterly goal driven more by marketing goals than anything else. Throw in the fact that the still rather small company ended up with one person making product, marketing, and even technical decisions and we devolved into glorified code monkeys pretty quickly.
- whstl 2y ago
  My team works in an agile fashion. I simply stay out of their way and every week they finish what they promised to finish. The team is high-quality and hasn't missed targets or estimates. Most of our "ceremonies" are purely for socialization, as decided by the team. But this is extremely fragile, because it takes a lot of energy to fight external people (often product people) who want to remove the self-management aspect. Unless this is in the DNA of the company, you can't have agile or real Scrum, because it threatens those kinds of power-grabs. For this to work, you literally need someone threatening to fire people who attempt to micromanage others.
replwoacause 2y ago
We use Agile at our company and let me tell you, it sucks. Maybe straight up scrum would be worse, but honestly agile is invasive and just feels like you’re being babysat and forcing people to give BS updates at standups because they’re afraid of sounding unproductive.
- prepend 2y ago
  I find Agile is like democracy. It does suck, but it’s better than everything else. What would you prefer besides agile? I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Everyone should just work on things until they are done. He argued this earnestly and didn’t recognize that there are opportunity costs and conflicting priorities and the need to choose what to do. He earnestly argued that every single user story should be worked on in order of entry until it was completed. It would have been precious how clueless this suggestion was if he didn’t spent 20-40 minutes a week arguing this as an explanation for why his items weren’t done and why he was civil disobediencing to refuse to estimate or report time on tasks.
  - rightbyte 2y ago
    I'd have the straw man variant of waterfall every day in place of agile. Like, the constant micromanagement and process lawyers pushing you down makes me misarable. At least with classic project processes you'd have some oversight plan to follow.
  - pyrale 2y ago
    > I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Plenty of learned people have made defenses for having no estimates. If you want to make the opposite claim, you don't need to use a junior dev as a strawman.
    - prepend 2y ago
      I think estimates are wrong but useful and necessary. I don’t think it’s a strawman argument at all. For simple activities you can get by with no estimates but with dependencies estimates become more and more necessary.
lo_fye 2y ago
"Keep managers happy" isn't part of Scrum, either. If you read any of the Scrum books by the creators of Scrum, you'll find that the way 95% of companies implement Scrum is nothing like what Scrum was intended to be. They mess it up, essentially in the name of marketing, and not wanting to truly change their ways.
JohnFen 2y ago
> Agile is about exactly what you said: empowering devs to get shit done. Sure, that's the goal. In reality, though, that's very nearly never what it does in practice. That's why I have come to view "agile" shops with an extremely skeptical eye.
philwelch 2y ago
Most “Agile” process are agile in the same sense that the Democratic People’s Republic of Korea is democratic.

benfortuna 2y ago

But what does it mean to "empower devs". Do you give them requirements and say I'll check in on deadline day in 6 months? Presumably you would still use iterations to track progress, Epics/Features to break down requirements, some kind of estimation to track if you're ahead/behind schedule? I certainly wouldn't go back to Waterfall days, but I suspect many current devs never experienced that.

shaunxcode 2y ago
as things are ready to be shown you will see them : this is how you will know
Retric 2y ago
There’s a world of difference between checking back in 6 months and daily standup meetings + a host of weekly meetings. If you don’t trust your team to be productive for 2 weeks without communication something is deeply wrong. Individuals should be in constant communication, but few things need to be said to everyone. Scrum style management may be useful for highly dysfunctional teams, but it frequently adds a great deal of unnecessary overhead.
gridspy 2y ago
- One on Ones to discuss roadblocks and thoughts every week. - Issue tracking as a common place to describe what needs to be done and thoughts / details on how it is solved. Something lightweight like Trello is ideal - A Kanban board so people have an organised way to pick up new issues when low on work - A weekly showoff meeting where there are few 5 minute presentations and a 30 minute "I did something really cool or learned something really cool" - 6 month task split into 1 month ish deliverables, with a flexible deadline for each. Presentation of finished work each deliverable.
- cvoss 2y ago
  This is basically how my team does it. I love it. My manager spends much of her time figuring out how to help remove our roadblocks and planning the 6 month to 1 year horizon (with our input). I lead the weekly meeting where we do the showing off, PSAs, or light brainstorming on issues with broad relevance. Two scheduled meetings per week = tons of dev time and freedom to explore / innovate! (Ok, three weekly meetings if you count the product-wide meeting, which is usually a waste of N-5 people's time, and I usually have it on the background while I continue working.) We are remote, so ideally there's also one in person gathering per year to do the big vision casting and major high level brainstorming. We still have room to improve, especially in the area of ad-hoc dev-dev communication. Always interested to hear how others do it!

justmarc 2y ago

Absolutely right. Well put.

bdangubic 2y ago

After 26 years in the industry this is the only process that actually works - hire the right people and get the F out of the way

tcgv 2y ago
> hire the right people That’s no easy feat and often oversimplifies the challenge of building competent teams. I think it’s achievable if you have a large budget to hire only senior/experienced devs and a mature hiring process/team. Plus, if your company has strong tech branding, it becomes easier to attract top talent too. But if you’re at a startup with limited funding and possibly no branding at all, you’ll likely face this situation: - Hire inexperienced but honest, motivated people with the potential to grow, and invest in mentoring them.
- bdangubic 2y ago
  I do not disagree with anything you said at all! Though chances of success diminish here. If you have to introduce some "process" - whatever that "process" is - because you do not have competent people and you feel like "process" will fix it, your chance of succeeding are a lot smaller IMO...

bfrog 2y ago

Pizza sized teams that can directly interact with customers don't need management. Management is playing telephone with someone in the middle with their own interpretation of everything which is 99% wrong.

patrickmay 2y ago
It sounds like you've had bad management (like we all have). Good EMs will unblock you, deal with conflicting priorities from stakeholders, provide you with air cover to have focus time, and help manage your career growth (among other things). If your EM isn't doing that, find another one.
- randomdata 2y ago
  > Good EMs will unblock you, deal with conflicting priorities from stakeholders, provide you with air cover to have focus time, and help manage your career growth (among other things). Those don't really seem like things you'd want to outsource, no matter how good the outsourcee is.
ozim 2y ago
Sounds like you mix up management with product people. Product people are not management at least not where I worked. I see how it might be a problem if your manager is talking to the customers. Product people are or should be equal to dev, engineering. They should indicate priorities but should not in any way evaluate engineers especially if they have no technical expertise.

mrits 2y ago

The reality is even good devs tend to work hard on the wrong thing. Accountability comes from your peers as much as your manager. If this makes you angry you are one of the bad ones.

skydhash 2y ago
Everyone tends to work hard on the wrong thing if it what they like to do most currently. Everyone. A conversation is all that is needed to remind them of the team priority, non need to create a creativity carcan with processes.
randomdata 2y ago
Give good devs a direct line to the customer and they're apt to always work on the right thing, but will spend a lot more time dealing with the customer and a lot less time in development in order to do so. Leave good devs to play telephone through a middle-man, what we call the manager, and they almost certainly will work on the wrong things, but will have a lot more time to do it. I wonder which is actually more productive? Agile (of the Manifesto kind) posits that the former is most productive, but Agile (of the fake kind) seems to always want to revolve around the latter. The general sentiment is that fake Agile is the one that gets it wrong, so presumably cutting out the manager is what is most productive, but more data is welcome.
- SoftTalker 2y ago
  Disagree. The customer often has tunnel-vision on their needs, and doesn't know what's possible, and might have trouble even describing it except that their manager told them that their foo task was a problem. The devs have the opposite problem, they can imagine all sorts of new technology that would be fun to use (for them) in helping the customer solve their problems with doing foo, and even if they understand foo from the customer's business perspective they they may not have a great understanding of how big a problem it is in the grand scheme of things and what commitment of resources and expenses are justifed in solving it. Managers talking to managers can (in theory) draw some boxes around scope and priorities and get the right development problems solved at the right time. They may talk and realize that doing foo isn't even really a great idea and they should be doing bar intstead. Line-level employees working directly with developers will not be as likely to realize that. Developers can fall into the trap of thinking that because they are smart (mostly) at building software they are automatically smart about all the business processes and problems and goals of the company. They should certainly be informed about those things, but they are not experts in everything.

Lutger 2y ago

I've heard a lot of push back against all kinds of process on this forum, and it always surprises me. But reading the article made something click: it is not about the specific process, the (lack of) autonomy is what really matters. I guess I got lucky to work a lot in teams where we largely controlled our own process, so even if we used bits and pieces of scrum, kanban or other methodologies, it was always of our collective choosing and when it didn't work, we changed it. I did like to have rules, principles and process. A simple playbook for a daily meeting that made us not forget important things and sped up the meeting. Making things in small increments meant that I didn't have to review thousands of lines of code. Having a visual overview of work neatly spelled out means I don't have to re-think every time I pick up a new item to work on. This also prevents useless work because one of your teammates decides to work on the same thing as you without telling it. All these things make me happier and more productive working together on some big thing. The key is that the team should be in control of the process, not some manager who isn't part of the team and affected by the process. You need to have a stake in it. The only other factor that undermines this is 'process for the sake of process'. Every part of the process needs to earn the inevitable cost its implementation is bringing. Some people seem to be happy paying the pricing without getting the value.

mrmetanoia 2y ago

It seems we go astray when we start defining and evangelizing things that may have worked for some group of people to push them on others. Somewhere in all this process stuff, I see maybe what some teams were doing but I doubt it was as rigid and I doubt they indulged in it when it made no sense. Once these teams or people are asked what they're doing right - it eventually gets defined into rules and then evangelized to people made to feel they can't deviate or improvise when the framework makes no sense. "Trust the process." So people start wasting their time going through the process rather than using the process as a framework/tool for getting things done, they 'do' the process. Their job is standup, their job is scrum, tickets, and points, and as a result their job is only marginally to do the things that need doing. Company's might take more issue with this inefficiency if the workforce didn't double as something to manipulate pre and post head/tailwind to make the stock rise.

SoftTalker 2y ago

All of these methodologies (and most formal software architectures as well) have as a their main sales pitch the idea that you can hire average/entry-level developers and build good software with reduced defects and on a defined schedule if you only follow these magic guidelines. It refuses to learn from The Mythical Man-Month and recognize that building software has an essential complexity that cannot be avoided. You need smart people to implement and manage it, and you'll have to pay them what the market says they are worth. Building software that's more complicated than a standalone CRUD system is hard, it will always be hard, and unpredictable, and to some degree stressful. No methodology will ever make it anything else because the methodology used doesn't change the nature of the problem.

bunderbunder 2y ago

My first and second experiences with Scrum couldn't be more different. And they were successive. Actually, they happened on the same team, same people, same project. Before: the team had internally decided to use Scrum. Other teams were not using it, and inter-team coordination used traditional project management methods. It was fantastic; the team worked like a well-oiled machine and I really did feel more productive. We never had crunch time. I did not feel the "end-of-sprint mini crunch" that this post describes; instead the norm was that, by the last couple days of the sprint, people were starting to finish up whatever tickets they had taken and pivoting to helping teammates get the rest of the work done. Oftentimes we'd close out all the user stories a day or so before the end of the sprint, and have all that time for tidying up the codebase, fixing small technical debt items, experimenting with new tools, or planning ahead for the next sprint. So, if anything, it was the opposite of what the article describes: the last few days of every sprint were downright relaxing. After: The executives got wind of Scrum, and decided to standardize the whole company on it. We stopped work for a week so that we could have a famous Agile coach do an all-hands Scrum workshop. Which was fun, but the middle and senior managers were conspicuously absent. And then, after that, things kind of went to heck. The way our team did Scrum rapidly started to change as our team manager started getting explicit instructions on how to do things. We also started experiencing pressure to keep or maintain velocity. We started getting questions about why our velocity was so much different from other teams'. We could explain that the story point scale is team-specific and you can't compare story points across teams, but that didn't go anywhere. As I said, the middle and upper managers skipped the Scrum training. They weren't interested in being lectured about what I'm sure they perceived as pedantic little bullshit details. I left that company and went to another where leadership didn't mandate any Agile methodology. My team did a homegrown Kanban-like thing. A team I collaborated closely with used Scrum. It also seemed to work pretty great. Again, possibly because we chose it for ourselves. I don't think the other team would have done as well on Kanban. Scrum wouldn't have worked so well for our team. I didn't see a problem with that. We each had different business domains that warranted very different "rules of engagement" with our stakeholders and ways of organizing the work. Since then it's been a couple more companies where "Agile" was mandated from the top, and, apologies to Tolstoy, but they were both miserable in the same way that the first one was after the Scrum mandate got handed down from above.