12 ms·

At my last company we used SAFe and I was blown away at how effective it was. Once a quarter, we had a 3-day event in which the entire next 3 months were planne

At my last company we used SAFe and I was blown away at how effective it was. Once a quarter, we had a 3-day event in which the entire next 3 months were planned out, with dependencies between teams, with wiggle room/flexibility, by the end of the event. I understand this can depend on how well it's implemented, but in my experience I've never seen anything like it before or since.

bl4ckm0r3 4y ago
How big was the team and what type of project? And what amount of level of detail did you put in the planning/roadmap? Did you also had experiments and investigations taken into account?
kqr 4y ago
> Once a quarter, we had a 3-day event in which the entire next 3 months were planned out, This is the part I don't understand. What sort of business are you in where you can actually meaningfully predict which will be the most valuable opportunities and ideas that will come your way in the next three months?
- ThalesX 4y ago
  Three months!? Is this the stability we expect from companies in our day and age? I would think it's a lost company, one that couldn't somewhat predict what the next three months are going to look like.
  - pflenker 4y ago
    Just look back 3 month and assess how many of the things that happened were predictable (keeping in mind the fact that hindsight is 20/20). I wager every company in the world was affected by the world wide changes right now. Those who cling to plans are at disadvantage against those who have the ability to quickly adapt to the change.
    - ethbr0 4y ago
      > Those who cling to plans are at disadvantage against those who have the ability to quickly adapt to the change. https://en.m.wikipedia.org/wiki/OODA_loop https://en.m.wikipedia.org/wiki/OODA_loop
      - doctor_eval 4y ago
        > The OODA loop has become an important concept in litigation,[2] business,[3] law enforcement,[4] and military strategy. According to Boyd, decision-making occurs in a recurring cycle of observe–orient–decide–act. An entity (whether an individual or an organization) that can process this cycle quickly, observing and reacting to unfolding events more rapidly than an opponent, can thereby "get inside" the opponent's decision cycle and gain the advantage.
    - kgwgk 4y ago
      "In preparing for battle I have always found that plans are useless, but planning is indispensable."
    - hef19898 4y ago
      Just throwing things to the wall and see what sticks is not agility, nor is it just mindlessly running after any random car like a dog chasing the mail man.
      - tikhonj 4y ago
        Who said anything about "mindless"? Just because work wasn't planned in detail in advance does not make it mindless—the people actually doing the work make creative, nuanced decisions as they're working. Not pushing a top-down, up-front plan gives people more room for careful nuanced thought. That isn't "throwing things to the wall" or "mindlessly running around", that's trusting a team of professionals to make effective creative decisions.
        hef19898 4y ago
        I agree, if you have team of experienced professionals tgat is. If not, well, stuff to the wall it is. If wrapped in sometjing something agile, at least it looks good.
  - sanderjd 4y ago
    "Somewhat predict" is incredibly different than "make a detailed plan for". I like strategic planning in 3, 6, even 12 month increments, but doing the detailed work toward those high level plans in much shorter and less static increments.
    - ThalesX 4y ago
      Let’s assume you have a strategy for the next 3 months. You identified / endivisioned a need in the market and came up with a reasonable solution; you locked in the budget, you allocated the resources. How many times are you going to change these in the 3 months?
      - sanderjd 4y ago
        But that's not the kind of plan that comes out of these planning sessions. What you're describing is more like the effort to put together organization / unit level OKRs. That is a good thing. But getting everyone together to guess ahead of time how they'll execute that solution in detail is a poor use of time in my opinion. I think the planning exercise is useful for cross organization alignment at a high level, but for individual contributors, I think it at best makes their eyes glaze over and at worst makes them frustrated and demoralized, and then once the planning is done everyone goes back to doing the actual work, which of course doesn't match the plan very closely.
- mvdwoord 4y ago
  I would honestly like to reverse this question... What sort of business can't look three months ahead?! Seriously, updating business logic rules to catch a trend or adjust for changing external conditions, I understand. But for software development?!
  - kqr 4y ago
    Sure! I often start to make things which seem like a good idea at the time but after 1--8 weeks of A/B testing (or other verification methods) it turns out the market was not what I thought and it would be a waste of time to pour more work into it. At that point I can either "stick to the 3 month plan" and do something which I know has at best no value, or... try something else.
  - marcinzm 4y ago
    Your team is working on a dozen features for the next three months. After looking through the code to start implementing one feature (4 weeks into the 3 months) the team realizes there is need to change another team's API. The other team already has all their time booked with feature. Cue a cascading set of slightly changing priorities. Now multiply that by every team in the company hitting something like this.
    - roguecoder 4y ago
      Collective code ownership is a prerequisite to most Agile processes for this very reason.
      - marcinzm 4y ago
        In my experience most companies specialize teams to various extents which makes true collective ownership difficult. An iOS team is likely going to have difficulty dealing with the ML code. This becomes even worse if the change is complex or touches the domain specific patterns.
        drran 4y ago
- Yizahi 4y ago
  For example the sort of business which supplies hardware needed to write yours or mine comment. Not everyone is deploying to production every day or even every two weeks. Not everyone has feature development measured in hours.
- tonyarkles 4y ago
  > What sort of business are you in where you can actually meaningfully predict which will be the most valuable opportunities and ideas that will come your way in the next three months? I've got one foot in the pure software world and one foot in electronics hardware. I've worked with a number of startups, and some larger organizations and government. The SaaS startup world is the exception here, not the rule. Virtually any business that is not "we're ready to pivot on a dime" SaaS should be able to plan 3 months out. Generally speaking, any kind of strategic initiative is probably going to take longer than that to roll out. If there's any kind of manufacturing involved then design, V&V, manufacturing, and QA are likely going to be running on at least 3 month cycles. Sometimes things do pop up and it makes strategic sense to do a mid-quarter tactical shift to attack an extremely valuable lead, but that should be exceptional. Even in the SaaS world, people tend to jump on new "valuable opportunities" without really sitting back and assessing the cost of delaying everything else. This kind of organizational ADHD (one board member at a company called it "chasing butterflies") tends to result in a bunch of half-finished projects/products that all could have been valuable in their own right if they'd been run to completion instead of abandoned in favour of the next "golden opportunity".
- cortesoft 4y ago
  If you have a company that has more than 200 developers, there is a certain level of inertia involved in everything you do. You can’t be shifting projects nearly as quickly as when you have 10-50 developers. Having worked at both very large and very small companies, people who have not worked in the other just don’t understand what it is like at the other scale.
skeeter2020 4y ago
>> I was blown away at how effective it was. Once a quarter, we had a 3-day event in which the entire next 3 months were planned out Yep, you get this, a 13 week PLAN. Just adopting plan-old maligned waterfall can give you a plan lasting years! Unfortunately software development teams are supposed to deliver more than plans. You can totally do quarterly planning without SAFe, cross-team colaboration can be achieved, and having teams spend time digging into future work is immensly valuable. SAFe leeches from these positives without actually enhancing them, while adding an imense amount of overhead and real costs.
tsimionescu 4y ago
What happened when two months in the priorities changed, or when a feature that looked like it might take a turned out to take a month?
- JamesSwift 4y ago
  Priorities changing is one thing, but the answer to the second one is that priorities are priorities. If something to the left-side of a timeline now takes longer, it usually shifts everything else to the right. Thats just the reality of the situation, and the point is to have the awareness of the impact and be able to adjust accordingly.
- Yizahi 4y ago
  You change priorities then. If a set of features takes much longer due to whatever reason, you just pare them down or postpone release accordingly. If you have important customers waiting for the release, you then first talk to them and then cut or postpone depending on their opinion and common sense. Delaying release doesn't summon demons or cause apocalypse, despite what some managers try to bs us.
  - sanderjd 4y ago
    I think maybe this is the confusing thing to me. What "release"? It seems like plenty of people are doing this for service-oriented software where these "releases" are totally arbitrary. Most of us are not putting CDs in boxes...
JamesSwift 4y ago
It sounds like you had a healthy org. The problem with most other orgs is that they do the same planning, with the same care and attention paid that yours did. But then 2-4 weeks after, everything that was discussed and agreed upon and planned around is upended when "priorities changed" or "something else came up" (i.e. the wind slightly blew). For whatever reason, they feel like they are making more effective planning decisions now, by the seat of their pants, than they did when literally everyone was in the same room and putting real thought into the whole thing. Can you tell I'm not a fan?
- hef19898 4y ago
  Why does that sound so awefully familiar? Even worse when you throw in good old re-inventing the wheel, not revise the decisions that should be and giving Agile coacjes and scrum masters more influence over the content of what should be delivered than the actual domain experts doing the work. I'll let you guess what role I have in all of that right now...
  - ResearchCode 4y ago
    Imagine taking a two day course and then going into the office of a law firm or a hospital and micromanaging the staff. Tragic that software engineers put up with this.
- quickthrower2 4y ago
  If something else came up is not allowed it means you need a perfect plan that survives contact with reality. This is possible for short tasks perhaps but not an entire team for 90 days. If they have completely ignored company priorities that is bad but often it is some technical glitch has come up that moving a box 1px to the left really wasn’t as easy as first thought.
  - sanderjd 4y ago
    Yeah, "company priorities" is the level I like longer horizon planning to be at. "It's important that we achieve X, Y, and Z in the next quarter", with well thought out priorities and clear communication, then let teams figure out how to deliver.
tapatio 4y ago
Same. I found it to be very effective, especially having a bunch of release trains in sync. Obviously this applies to large organizations.
zogomoox 4y ago
Even if it worked, who wants to be in a 3 day long planning meeting every quarter? It sounds like a worse kind of hell to me.
- user_named 4y ago
  In our scrum process, I spend 6 days spread out over three months in sprint planning.
  - sanderjd 4y ago
    Yes, but quarterly planning does not preclude sprint planning... You do both.
sanderjd 4y ago
It's interesting to me that you saw this as such a success story. In my organization, people have worked hard to get it down well under three days, and to me it still feels like a ton of effort for dubious benefit, because no plan survives first contact with the enemy.
config_yml 4y ago
I’ve been there. A meeting with over 900 people, half of them in a different timezone, looped in via video feed on a big wall. Fortunately it was also my last meeting of such kind. The following 3 months were a total waste of time.

bl4ckm0r3 4y ago

How big was the team and what type of project? And what amount of level of detail did you put in the planning/roadmap? Did you also had experiments and investigations taken into account?

kqr 4y ago

> Once a quarter, we had a 3-day event in which the entire next 3 months were planned out, This is the part I don't understand. What sort of business are you in where you can actually meaningfully predict which will be the most valuable opportunities and ideas that will come your way in the next three months?

ThalesX 4y ago
Three months!? Is this the stability we expect from companies in our day and age? I would think it's a lost company, one that couldn't somewhat predict what the next three months are going to look like.
- pflenker 4y ago
  Just look back 3 month and assess how many of the things that happened were predictable (keeping in mind the fact that hindsight is 20/20). I wager every company in the world was affected by the world wide changes right now. Those who cling to plans are at disadvantage against those who have the ability to quickly adapt to the change.
  - ethbr0 4y ago
    > Those who cling to plans are at disadvantage against those who have the ability to quickly adapt to the change. https://en.m.wikipedia.org/wiki/OODA_loop https://en.m.wikipedia.org/wiki/OODA_loop
    - doctor_eval 4y ago
      > The OODA loop has become an important concept in litigation,[2] business,[3] law enforcement,[4] and military strategy. According to Boyd, decision-making occurs in a recurring cycle of observe–orient–decide–act. An entity (whether an individual or an organization) that can process this cycle quickly, observing and reacting to unfolding events more rapidly than an opponent, can thereby "get inside" the opponent's decision cycle and gain the advantage.
  - kgwgk 4y ago
    "In preparing for battle I have always found that plans are useless, but planning is indispensable."
  - hef19898 4y ago
    Just throwing things to the wall and see what sticks is not agility, nor is it just mindlessly running after any random car like a dog chasing the mail man.
    - tikhonj 4y ago
      Who said anything about "mindless"? Just because work wasn't planned in detail in advance does not make it mindless—the people actually doing the work make creative, nuanced decisions as they're working. Not pushing a top-down, up-front plan gives people more room for careful nuanced thought. That isn't "throwing things to the wall" or "mindlessly running around", that's trusting a team of professionals to make effective creative decisions.
      - hef19898 4y ago
        I agree, if you have team of experienced professionals tgat is. If not, well, stuff to the wall it is. If wrapped in sometjing something agile, at least it looks good.
- sanderjd 4y ago
  "Somewhat predict" is incredibly different than "make a detailed plan for". I like strategic planning in 3, 6, even 12 month increments, but doing the detailed work toward those high level plans in much shorter and less static increments.
  - ThalesX 4y ago
    Let’s assume you have a strategy for the next 3 months. You identified / endivisioned a need in the market and came up with a reasonable solution; you locked in the budget, you allocated the resources. How many times are you going to change these in the 3 months?
    - sanderjd 4y ago
      But that's not the kind of plan that comes out of these planning sessions. What you're describing is more like the effort to put together organization / unit level OKRs. That is a good thing. But getting everyone together to guess ahead of time how they'll execute that solution in detail is a poor use of time in my opinion. I think the planning exercise is useful for cross organization alignment at a high level, but for individual contributors, I think it at best makes their eyes glaze over and at worst makes them frustrated and demoralized, and then once the planning is done everyone goes back to doing the actual work, which of course doesn't match the plan very closely.
mvdwoord 4y ago
I would honestly like to reverse this question... What sort of business can't look three months ahead?! Seriously, updating business logic rules to catch a trend or adjust for changing external conditions, I understand. But for software development?!
- kqr 4y ago
  Sure! I often start to make things which seem like a good idea at the time but after 1--8 weeks of A/B testing (or other verification methods) it turns out the market was not what I thought and it would be a waste of time to pour more work into it. At that point I can either "stick to the 3 month plan" and do something which I know has at best no value, or... try something else.
- marcinzm 4y ago
  Your team is working on a dozen features for the next three months. After looking through the code to start implementing one feature (4 weeks into the 3 months) the team realizes there is need to change another team's API. The other team already has all their time booked with feature. Cue a cascading set of slightly changing priorities. Now multiply that by every team in the company hitting something like this.
  - roguecoder 4y ago
    Collective code ownership is a prerequisite to most Agile processes for this very reason.
    - marcinzm 4y ago
      In my experience most companies specialize teams to various extents which makes true collective ownership difficult. An iOS team is likely going to have difficulty dealing with the ML code. This becomes even worse if the change is complex or touches the domain specific patterns.
      - drran 4y ago
Yizahi 4y ago
For example the sort of business which supplies hardware needed to write yours or mine comment. Not everyone is deploying to production every day or even every two weeks. Not everyone has feature development measured in hours.
tonyarkles 4y ago
> What sort of business are you in where you can actually meaningfully predict which will be the most valuable opportunities and ideas that will come your way in the next three months? I've got one foot in the pure software world and one foot in electronics hardware. I've worked with a number of startups, and some larger organizations and government. The SaaS startup world is the exception here, not the rule. Virtually any business that is not "we're ready to pivot on a dime" SaaS should be able to plan 3 months out. Generally speaking, any kind of strategic initiative is probably going to take longer than that to roll out. If there's any kind of manufacturing involved then design, V&V, manufacturing, and QA are likely going to be running on at least 3 month cycles. Sometimes things do pop up and it makes strategic sense to do a mid-quarter tactical shift to attack an extremely valuable lead, but that should be exceptional. Even in the SaaS world, people tend to jump on new "valuable opportunities" without really sitting back and assessing the cost of delaying everything else. This kind of organizational ADHD (one board member at a company called it "chasing butterflies") tends to result in a bunch of half-finished projects/products that all could have been valuable in their own right if they'd been run to completion instead of abandoned in favour of the next "golden opportunity".
cortesoft 4y ago
If you have a company that has more than 200 developers, there is a certain level of inertia involved in everything you do. You can’t be shifting projects nearly as quickly as when you have 10-50 developers. Having worked at both very large and very small companies, people who have not worked in the other just don’t understand what it is like at the other scale.

skeeter2020 4y ago

>> I was blown away at how effective it was. Once a quarter, we had a 3-day event in which the entire next 3 months were planned out Yep, you get this, a 13 week PLAN. Just adopting plan-old maligned waterfall can give you a plan lasting years! Unfortunately software development teams are supposed to deliver more than plans. You can totally do quarterly planning without SAFe, cross-team colaboration can be achieved, and having teams spend time digging into future work is immensly valuable. SAFe leeches from these positives without actually enhancing them, while adding an imense amount of overhead and real costs.

tsimionescu 4y ago

What happened when two months in the priorities changed, or when a feature that looked like it might take a turned out to take a month?

JamesSwift 4y ago
Priorities changing is one thing, but the answer to the second one is that priorities are priorities. If something to the left-side of a timeline now takes longer, it usually shifts everything else to the right. Thats just the reality of the situation, and the point is to have the awareness of the impact and be able to adjust accordingly.
Yizahi 4y ago
You change priorities then. If a set of features takes much longer due to whatever reason, you just pare them down or postpone release accordingly. If you have important customers waiting for the release, you then first talk to them and then cut or postpone depending on their opinion and common sense. Delaying release doesn't summon demons or cause apocalypse, despite what some managers try to bs us.
- sanderjd 4y ago
  I think maybe this is the confusing thing to me. What "release"? It seems like plenty of people are doing this for service-oriented software where these "releases" are totally arbitrary. Most of us are not putting CDs in boxes...

JamesSwift 4y ago

It sounds like you had a healthy org. The problem with most other orgs is that they do the same planning, with the same care and attention paid that yours did. But then 2-4 weeks after, everything that was discussed and agreed upon and planned around is upended when "priorities changed" or "something else came up" (i.e. the wind slightly blew). For whatever reason, they feel like they are making more effective planning decisions now, by the seat of their pants, than they did when literally everyone was in the same room and putting real thought into the whole thing. Can you tell I'm not a fan?

hef19898 4y ago
Why does that sound so awefully familiar? Even worse when you throw in good old re-inventing the wheel, not revise the decisions that should be and giving Agile coacjes and scrum masters more influence over the content of what should be delivered than the actual domain experts doing the work. I'll let you guess what role I have in all of that right now...
- ResearchCode 4y ago
  Imagine taking a two day course and then going into the office of a law firm or a hospital and micromanaging the staff. Tragic that software engineers put up with this.
quickthrower2 4y ago
If something else came up is not allowed it means you need a perfect plan that survives contact with reality. This is possible for short tasks perhaps but not an entire team for 90 days. If they have completely ignored company priorities that is bad but often it is some technical glitch has come up that moving a box 1px to the left really wasn’t as easy as first thought.
- sanderjd 4y ago
  Yeah, "company priorities" is the level I like longer horizon planning to be at. "It's important that we achieve X, Y, and Z in the next quarter", with well thought out priorities and clear communication, then let teams figure out how to deliver.

tapatio 4y ago

Same. I found it to be very effective, especially having a bunch of release trains in sync. Obviously this applies to large organizations.

zogomoox 4y ago

Even if it worked, who wants to be in a 3 day long planning meeting every quarter? It sounds like a worse kind of hell to me.

user_named 4y ago
In our scrum process, I spend 6 days spread out over three months in sprint planning.
- sanderjd 4y ago
  Yes, but quarterly planning does not preclude sprint planning... You do both.

sanderjd 4y ago

It's interesting to me that you saw this as such a success story. In my organization, people have worked hard to get it down well under three days, and to me it still feels like a ton of effort for dubious benefit, because no plan survives first contact with the enemy.

config_yml 4y ago

I’ve been there. A meeting with over 900 people, half of them in a different timezone, looped in via video feed on a big wall. Fortunately it was also my last meeting of such kind. The following 3 months were a total waste of time.