Agile Coach

Discussion in 'App Development' started by fan27, Dec 10, 2018.

  1. fan27

    fan27

    Can't believe "Agile Coach" is a real position....quite often see adverts for it popping up in my LinkedIn feed. It's one thing if you are a software dev manager with "Agile" experience but to hire a dedicated Agile Coach is beyond ridiculous. Just send one of the dev managers to a training or have them read a book in between attending meetings and typing emails and they can be the go to person for all things Agile.

    When my previous company switched from waterfall to agile, we hired a dev manager with Agile experience. He gave us a half day training and we were ready to go. A week later he quit to go somewhere else making a lot more money. Crazy!
     
  2. JSOP

    JSOP

    Why don't you become an "Agile" coach yourself? If you know something and nobody knows it but want to learn about it, capitalize on it aka turn it into money before everybody knows it and there is no more demand. Happy "Agile" coaching!! :)
     
    fan27 likes this.
  3. Sprout

    Sprout

    Demonstrating agility right there!
     
    fan27 likes this.
  4. fan27

    fan27

    Haha...should of screened him to make sure he was not too Agile :)
     
    Sprout likes this.
  5. fan27

    fan27

    Rather sell a "Learn to trade for a living with your $500 Forex account" trading course.
     
  6. To be honest, you need a coach to keep you in line. Software developers are generally prima donnas who think they know best but actually they're morons and if they don't have a daddy to keep them in line, they will fuck up your project. The purpose of an Agile coach is to get the prima donnas to follow the procedure in a somewhat natural manner (Agile is pretty natural - most people agree that you SHOULD meet up, SHOULD give updates, SHOULD NOT plan architecture for features that "may" come in 12 months, etc).
     
  7. Sig

    Sig

    We used to call that person a manager/supervisor/leader? Seriously, if a company makes a business decision to use a particular software development style then it becomes an inherent part of the company's management, not some outside "coach". It's only when you elevate it to cult status that you end up with this nonsense.
    I agree with you, much like lean/six sigma and before that TQM these things are generally good ideas that everyone should agree with in general. I think the problem with all of them is that they so easily veer into being treated as a religion and the focus becomes on dogmatic and unthinking adherence to a set of rules rather than just leaders leading with a particular philosophy or business model. I blame it on the evangelicals, but then I do that a lot:)
     
    Sprout and fan27 like this.
  8. Sprout

    Sprout

    Who better than the evangelicals, by their own admission they are all guilty of the original sin.
    :D
     
  9. Let's say you want to become a trader. Boom, the next day you are successful.

    Obviously, it doesn't work like that. The purpose of a coach is to find the errors in what you're doing that is giving you bad results. Yes, a lot of "Agile" is bullshit, but having run many software teams over the years, with varying degrees of professionalism and experience, I would much rather have someone on hand who can help me fine tune things in that one particular area. For example, one major aspect of agile development is having a groomed backlog. This can quickly devolve into design discussions if you don't have someone who understands that this is not the goal.

    On the other hand, as the team lead/owner, it is your job to keep the Agile coach in line! For example, if they start becoming dogmatic instead of practical, you need to give them a warning. It's very easy to see when this happens because they cite rules for the sake of citing them.
     
  10. Simples

    Simples

    Firstly: The people originally inventing "The Agile Manifesto" (TAM) are mostly vehemently against everything called "Agile", "SAFe", et. al. these days, which is more a product of external consultants selling hours and classes, rather than substantial R&D into their so-called "Best Practices" (remember: ITIL / ITSM is also "Best Practices"). The 2-day course religion is BS, but there's some fundamental core that may still be healthy and learnt from.

    Scrum with standups is one practice that seems to be working to some extent, although nothing to do with TAM, it's hard to screw it up too much these days. Similar can be said about Retrospectives, though need to be followed-up seriously by leaders, aka "the people of means". Demos offer a way to share in plenum that became a lost art over the years of Scrum..

    "Agile Coach" (AC) is sort of two-edged: A true AC will stay in your company and transform it over many years. Think about what that means contra the short-term BS about burnup, burndown, WIPs, effectiveness vs efficiency and constant overselling the same overhyped methods and processes, inevitably leading to introverted siloing and isolation.

    So nothing to do with taking a 2 hour course or reading a book. AC, as with Scrum Master, is not typical leader or manager at all. Most people cannot even emphasize enough to understand.
     
    Last edited: Dec 11, 2018
    #10     Dec 11, 2018