I’ve been at two companies that use the Scaled Agile Framework to plan changes. At the first company I do not remember anybody actually calling it “SAFe”, but that model is essentially what we were doing.
This is not a post about what SAFe is, there are many other resources that can explain the theory and practice much better than I care to do here. Instead, I want to explore some of the differences I’ve seen in these two companies, and some general observations/thoughts.
First, some differences. At one company, the planning meetings were really kind of up-building meetings, where people seemed to still have fun, even though there were definitely some difficult discussions to be had. We had a focus on personal interactions, and made sure everybody was heard, and felt like their concerns were addressed. The projects we talked about were well-defined enough to have intelligent conversations about, but not already designed (there was still some design and architectural flexibility). Most of the folks in the room were already fairly familiar with the projects.
At the other, there was no desire whatsoever to get people together in the same room; virtual was the name of the game. In fact, being in one room was really seen as a downside, you were all but encouraged to stay home and join the meetings virtually. There was no uplifting or building-up activities, and the only real camaraderie was around how crappy and long the meetings were. If you had something to say about how risky something was, or how unlikely it was to hit deadlines given the parameters, your concerns were met with harsh words of how unacceptable that was, and quickly swept under the rug. Projects were somehow at the same time not well defined, but already designed (and always in the hardest-to-build way). Ideas for improving things were almost always met with “it’s too late to change this now, and unlikely to help anyway”. Because everybody seemed to be double or triple booked, Product was nowhere to be found when they were needed.
Obviously, from my biased portrayal here, you can tell which planning meetings were more enjoyable. It is lunacy to try and get a team to work together, without actually getting them together. Getting the team together in person would be ideal, but even just keeping the team together virtually is a must. Splitting the team up to go to different “work streams” means you don’t have a team; you have a group of individuals that share a common manager, and sometimes happen to work on similar projects, and that’s it. Have pre-meetings with the whole team, where everybody is brought up to speed on the projects, current statuses, etc. is also a must for effective planning meetings. There’s no easier way to make half the attendees in a meeting tune out than to talk either below their level, or way above their level. You don’t have the time during the planning event for that kind of background education; it must be done beforehand.
As for the projects (I chose the term project because these can be called any number of things, like Epics, Features, etc. but they are all projects), I think they should be formulated similarly to User Stories, with a formulation like “As a <persona>, I want <feature> so that I can do <thing to be accomplished>” and some kind of acceptance criteria. At this level, to make everybody’s lives easier, the projects should also come with some kind of estimated revenue, so that returns on investments can be swiftly calculated and projects easily prioritized. Oh the number of projects that Product was sure would be sure-fire wins and sold executives on and we spend months (years!) building out only to find that no customers actually wanted the thing…
It also strikes me that if the company/division is so large that it is actually a chore to get all the needed people together in a room for 3 days or so to talk about the things you are going to work on, the company is probably too big. Or maybe just managed very poorly? I’m not sure, probably both! It definitely shows that the lines of communication that should exist definitely do not exist.
But what can be done? A grassroots movement to make these meetings more useful seems far-fetched. I can at least do the best I can, to pay attention in the meetings I am a part of, speak up on the faults and risks as much as possible, and help my team form the best plan we can.