SAFe thread - constructive edition



  • For going off the rails or offensive posts, see here

    I'm wondering how to drill down to the real problems.

    So far, I got.

    Pros:

    Multiple Team coordination of dependencies and deliverables.
    Open communication with Stakeholders.
    Cons:

    Another layer of meetings.
    Process dependent. So, management tends to like to take it as is without questioning it.



  • Capturing from garage.

    @magus said

    @xaade

    More Cons:

    • Too much prediction - completion dates are completely unreliable
    • Too proscribed - if a task cannot be done in a sprint, it will be done in 4x as long as it would have been done.

  • kills Dumbledore

    For those of us who've never been subjected to it, how about a link to a definition?


  • Fake News

    @jaloopa The acronym has come up before but I guess @xaade couldn't be bothered to link to those threads. In any case:

    SAFe = Scaled agile framework

    I'm blissfully unaware of any further details



  • @xaade -

    I actually like SAFe, but with a qualification that should apply to nearly everything in line - when it is appropriate! Alas, again like many things in life, it is often applied (or an attempt is made) in situations it was never really designed to support!!!!!

    In situations where you have 500+ developers [my personal, subjective point at which SAFe really starts to make sense] and the work of all of the teams (so talking 50+ teams) needs to be coordinated to a high degree - the overhead of SAFe should be dwarfed by the benefits.


  • Discourse touched me in a no-no place

    @xaade I'm not sure if you're introducing agile from scratch, or if you're already on agile and want to use scaled agile to co-ordinate several teams, so here's some general advice for anything to do with agile:

    Do whatever makes sense for your team. If your team isn't getting much from a specific part of the process, then don't do that part.

    Remember, agile isn't a one size fits all methodology, and it is highly encouraged to tailor it to the specific needs of your team. It's very likely (and also recommended) that each team in your organisation will practice agile in different ways.

    Also, remember that agile is about empowering the team to get work done with the least friction possible. Try not to be too prescriptive. This is the most common mistake that I see from scrum masters, they try to be too much of a dictator, rather than a facilitator like they should be.

    Remember to listen to your team (or each team), and refine the process to help them get the most out of it.


  • kills Dumbledore

    Agile methodologies definitely need changes when scaled up to large organisations.

    People always talk about how it's easier to turn a canoe around than a battleship, but the two aren't really comparable. A large "agile" organisation would be more like a huge fleet of canoes. One of those turning around is easy until it runs into the path of another. Turning the whole fleet around is vastly more complex than turning the one large ship, requiring a lot of coordination between each boat and probably a lot of planning that starts to look very waterfally



  • @doctorjones said in SAFe thread - constructive edition:

    @xaade I'm not sure if you're introducing agile from scratch, or if you're already on agile and want to use scaled agile to co-ordinate several teams, so here's some general advice for anything to do with agile:

    Do whatever makes sense for your team. If your team isn't getting much from a specific part of the process, then don't do that part.

    Remember, agile isn't a one size fits all methodology, and it is highly encouraged to tailor it to the specific needs of your team. It's very likely (and also recommended) that each team in your organisation will practice agile in different ways.

    Also, remember that agile is about empowering the team to get work done with the least friction possible. Try not to be too prescriptive. This is the most common mistake that I see from scrum masters, they try to be too much of a dictator, rather than a facilitator like they should be.

    Remember to listen to your team (or each team), and refine the process to help them get the most out of it.

    If one uses the word "Agile" in the context of the Agile Manifesto [which I do], then many of points take on a different context.

    Also teams basing their methodology/process on the Scrum Framework [Scrum is neither a methodology or a process] may or may not be focused on Agile Values and Principles. While there is no inherent conflict between the new reference views, they are more commonly orthogonal than collinear]



  • @thecpuwizard My company decided we were doing it, absolutely to the letter, with 3 teams. Nothing got done. There were no changes allowed, it was pure SAFe, no questions.

    I'll freely admit that it may make sense at the scale you mention - but you'd hopefully not make all devs stop working to sit in meetings for three days every month.


  • ♿ (Parody)

    @jbert said in SAFe thread - constructive edition:

    @jaloopa The acronym has come up before but I guess @xaade couldn't be bothered to link to those threads. In any case:

    SAFe = Scaled agile framework

    I'm blissfully unaware of any further details

    Both of these threads make so much more sense now.


  • Impossible Mission - B

    @magus said in SAFe thread - constructive edition:

    make all devs stop working to sit in meetings for three days every month.

    Wow, you've got it so much worse than we do. Here it's 2 days every quarter, and everyone (except management) agrees that's really horrible.



  • @masonwheeler They caused that project to nosedive into total destruction, and then all the people responsible left, and we got pulled into less awful projects.

    The worst part is, the architecture was worse than the process on that project. Our next one, the architecture was only half as bad, but we got some control over the process (Something like kanban), so it was more bearable.

    Now we get to work on a project with good architecture, which comes with slightly more robust process from before we picked it up. All in all, it's been a steady improvement.



  • @masonwheeler said in SAFe thread - constructive edition:

    @magus said in SAFe thread - constructive edition:

    make all devs stop working to sit in meetings for three days every month.

    Wow, you've got it so much worse than we do. Here it's 2 days every quarter, and everyone (except management) agrees that's really horrible.

    2 days per quarter is typical [never heard of 3 days per month] for the quarterly release planning meeting. I have experience plenty of that were horrid, and a few that were fantastic (both "big-room" and "small-room"). For the best ones, the time was completely filled and quite productive.

    Once a project grows beyond a few teams (remember, I tend to deal with SAFe in 500+ developer environments, and do not generally recommend it for smaller groups), coordinating all of the dependencies (And there will be dependencies) across teams is an important element of effective success.


Log in to reply