6 ms·

My current job is my first truly agile software development position. I have never spent this much time in worthless meetings ever before. I also never saw a te

• scaryclam 9y ago
  Sounds like someone where you work swallowed a book on "Agile development" and is not capable of actually making it work for your company. I always encourage teams to take whatever agile process they're trying to use with a pinch of salt and make changes to / cut out parts of the process that are in the way, causing delays or don't make sense for that team. It's just bizarre when you see a team bothering to have retrospectives but don't have any power to change how they work.
  • Traubenfuchs 9y ago
    I am working in one of MANY scrum sized, agile teams that all need to cooperate -there'd be no viable way to push back against the upper management. Also, my direct superiors are in love with the agile process, while pulling their hairs out puzzling over why it isn't working.
• michal-franc 9y ago
  Have you shared this feedback with the team? Things you have mentioned should be a source of changes to make the process better.
  • Traubenfuchs 9y ago
    I don't think telling my "scrum superiors" that our management sucks and that we'd be twice as efficient by removing 80% of all agile bullshit would give us the velocity improvement they oh so desperately long for is a smart idea. Sorry, I have got to go now, there is a 2 hour workshop about how we can improve our velocity.
• matthewmacleod 9y ago
  My current job is my first truly agile software development position. That's the problem there – the job you describe is not on a 'truly agile' team. It sounds like almost exactly the opposite – a focus on process, rather than 'whatever works'. I work on a definitely 'truly agile' team – one estimation and planning meeting per two-week sprint, for a team of three developers, lasting about an hour. And it's great!
  • Traubenfuchs 9y ago
    "focus on process" -yes, that's it.
  • skookum 9y ago
    Your response, as do most such Agile defenses, suffers from the No True Scotsman fallacy. The problem is that if, when faced with example after example of something labelled 'Agile' not working, one discounts each as not 'truly Agile', then once one subtracts all those examples of Agile not working from the Agile literature there's nothing concrete left to prescribe other than "keep trying stuff until you find something that works for you."
    • zzalpha 9y ago
      That's a misuse of the fallacy. There are some basic practices that are required for an organization to adhere to an agile process. Transparency, accountability, introspection... it really is basic stuff. And either they're doing them, or they're not. If they're violating the definition of the process, they're not implementing the process. If someone got into a car accident and didn't have a license, and I said "Yeah, but they aren't a qualified driver", you wouldn't invoke the No True Scotsman fallacy, would you?
      • skookum 9y ago
        > Transparency, accountability These are concepts, not practices. And 'introspection', while arguably being a practice, is really, really not basic stuff. Introspection with actionable outcome is about as basic a practice as "finding inner peace" is. > If they're violating the definition of the process, they're not implementing the process. As seen even in just the comments on this submission, if someone follows the definition of the process as laid out in the literature, they are dismissed as being too process-focused and not truly Agile. If someone doesn't exactly follow the definition of the process as laid out in the literature, they are dismissed as not following the rules of Agile.
• gonzo41 9y ago
  Welcome to hell. j/j If your read the manifesto (you know who else had a manifesto..;) The tone of the manifesto is all about getting shit done and communicating often. I guess thats the point. A lot of developers look normal, but are pretty terrible at communicating with the business, especially the non tech savy that are at the other end of things. Agile like what your talking about kind of does this. But as other have stated, someone went on a course and is adopting agile like a cult. When the premise is actually to be flexible and allow for change etc. TL:DR Agile helps bad communicators communicate a little less badly. But people usually fall back to trend.
  • Traubenfuchs 9y ago
    "Getting things done" would be nice. I only ever had that in a small company that used something I'd call "anarchy management".
• dkersten 9y ago
  > I feel like this is all a big fat joke. Its not, but many companies get it wrong (sounds like your one does too). In my opinion, a big part of the problem is that you get some manager types who thinks they're "doing agile" just by cargo culting it a bit and then wonder why it didn't work. Another big problem is when teams make up their own pseudo-agile (that is, they pick only some parts and change others saying things like "we work differently so needed to change it to suit us") and then complain that agile doesn't work when it fails. That's why I like the GROWS Method [1] -- its designed for customisation because it acknowledges that every team actually is different and has different needs, but its also split into tiers that you should progress through and customising the process is a higher tier: you need to be experienced enough in agile to know what works and what doesn't work for you before you start to change or twist it into something else, otherwise you end up with an incoherent unworkable mess that adds more overhead than the problems it solves, or you have some pretend-agile that doesn't actually achieve anything. You need to get beyond that to what agile is (in my opinion) really about: getting shit done, aligning stakeholders and team members, communication. [1] http://growsmethod.com/ http://growsmethod.com/
• piva00 9y ago
  The big fat joke is thinking that agile are the processes and methodologies developed from the manifesto. Read the manifesto, apply some techniques, methodologies, frameworks that you hear about but always keep the manifesto motto of "constant communication and improvement of the process" in mind. You and your team should try different approaches and learn from them on what is working for you while keeping: 1. Communication 2. Constant feedback and improvement 3. Knowledge sharing If only 20% of the people can contribute you have a problem with your team, not with the agile process to be honest.
  • Traubenfuchs 9y ago
    Do you sit in a team with magical dev-ops unicorns only?
    • piva00 9y ago
      No, I sit in a team where I'm the magical devops (I've been a backend developer for more than 10 years, took DevOps roles in 2 different companies, had front end and mobile experiences at some startups, etc.) and I love to share and teach my teammates when I'm the only person with the right skillset. My work ethics motto is to work for my own obsolescence, if you are in a team for more than 3-6 months and there are still people that really can't participate anyhow in a part of your tasks then your team is failing. Of course I wouldn't apply this for a team where MAJOR higher education skills are necessary (like a PhD on some specific IA or statistics background) but really... 90% of this industry isn't in a team like that so there's a lot of room for improvements. And please, be civil, I don't appreciate snarky comments (and neither does HN).
      • cmcginty 9y ago
        Well said. I wish there were more people like you in the industry.
• zzalpha 9y ago
  Well, unfortunately, this all comes down to communication. Agile meetings serve a few basic purposes: 1. They provide a venue to communication requirements from Product to Development. 2. They provide a venue for Development to communication questions, concerns, or technical details back to Product. 3. They provide a venue for external stakeholders to observe progress and provide further input on requirements. 4. They facilitate communication inside the team, both on basic status, but also in refining and improving internal processes through introspection. You could avoid a lot of this by, instead, writing lots and lots of documentation covering requirements, processes and procedures, etc. Or, you can hold regular meetings and talk stuff out. You pick. No process is perfect, but every process has to provide these communication channels in one form or another. Of course, to a single dev, communication always feels like overhead. It's not. That said, just a couple points in response to your rant: Estimating story points for tasks when we know there is only one who has the skills to do it Then your team should do more cross-training or be more creative about sharing work. Just because one person can code, doesn't mean other people can't test, perform code reviews, assist in writing documentation, participate in pair programming, etc. Alternatively, the team is just too damn big. Including Scrum Master and Product Owner, you should be at no more than 9 people, and preferably 7. At that size, it's pretty hard to have only one person work on anything. It's an absolute sign of dysfunction if, in your team, people think "only one person can work on that"... you're being myopic. direct conversions between time and story points. You're not supposed to do that. Your process is broken. Countless hours spent in splitting and combining "stories" to make them agile sized bites. That's a good thing, not a bad one. Small pieces of work are achievable and predictable. Estimation meetings that take half a day, Your process is broken. There are many ways to streamline these activities. Introduce timeboxed backlog refinement meetings. Ensure the PO is adhering to a strict Definition of Ready. Have a discipline Scrum Master who shuts down irrelevant ratholing. And why aren't these issues raised and addressed in your retrospectives? where for every story only 20% of all the people who sit there can contribute. See above.
• natoliniak 9y ago
  I have been working in Agile or "Agile" for the past 7 years, across 3 different companies and noticed similar patterns: - complete failure to adapt to unplanned interrupt driven work, such as mid-sprint escalations, QA issues etc. Management rarely pull anything out of the sprint when a developer gets pulled to work on unplanned tasks. - countless meta discussions about what constitutes a story point and whether it should be tied to time and just exactly what it means to be "agile". Agile discussions are starting to turn into "no true Scotsman" arguments. - grooming and planning discussions often overlap in scope leading to exact same things being discussed twice - management/senior staff pressures to trivialize tasks complexity leading to pressure to underestimate and little thought is given that not all developers work at the same pace across all technologies. - sprints rarely finish exactly as planned, so a lot of tasks either get carried over to the next sprint or if they are finished early, it leads to even more unplanned meetings to decide what should be pulled into the sprint. I recently noticed among my colleagues who complete tasks early to just "ride them out" until the end of sprint.
  • Traubenfuchs 9y ago
    We might as well be working in the same company.