So this may not be fair, but you lost me quite a bit with the positive take on SAFe, which is the worst, most unproductive experience of any process I’ve had.
I also do not understand the queues and capacity issue. I have never been in an environment where we do not have so much work that we cannot meaningfully see past the end of the queue. I don’t necessarily view that as a bad thing.
There will always be something else to do, that is definitely true. In this context we are talking about taking a chunk of that and trying to create an expectation of when it can be ready.
In a Sprint, for example, you take a slice of work from that queue, a few stories with the goal of trying to get it completed in the next couple of weeks (hopefully). That creates a new queue for the sprint, essentially.
You've controlled the flow of work based on the teams historic capacity using some metric, which has previously been velocity.
Overloading that capacity is what happens when new work sneaks in. Support items. Requests from people outside the team. Long meetings. A team member unexpectedly being out. Either the amount of work has gone up or capacity has gone down. If anything that was planned is much larger than initially expected, you're going to end up way behind. That will push everything else farther behind at the same time.
The moment you start scrambling to try to get it all done, you're going to start making mistakes. People are not going to take the time to refine things. Errors will happen. They'll take longer to fix or worse they'll end up in production and create new problems...that will create more unplanned work for the next time.
Yeah that helps. I thinks sprints are a bad approach to work, so probably some fundamental disagreement there.
I also strongly believe that all processes are downstream from people, team culture, and organizational incentives. If you don’t get those right, your processes won’t matter, and if you do get those right, your processes won’t matter very much.
Oh, I agree on all points except that processes are inevitable in a sufficiently sized organization. Understanding how they affect people is critical to making them work.
I’ve read the horror stories on here and I understand. There’s what it is supposed to be, what is taught and how it ends up.
Rigidity is probably the biggest issue. It’s supposed to be adapted to an organization leveraging what works well, handing more control to developers and addressing some communication gaps.
When people try to implement it strictly and force the company into the example template it creates a lot of friction.
When I’ve previously explained on here what it should look like, it’s typically nowhere close to that in the horror stories. Developers should have significantly more control in a SAFe environment fwiw. I’ll explain it more if you like though.
I have to run out but I’ll come back to explain the queue stuff too.
I do totally agree on the SAFe bits. I've seen it implemented extremely well when 1) everyone got regular training (biannually or quarterly) and 2) senior leaders adopted their appropriate SAFe roles.
Quite often i see organizations do a SAFe kickoff and then nobody ever learns more about it and senior leaders view it as a team level thing only. It doesn't work then because nobody's actually doing it.
Alright, comment part 2 since I have a little more time now.
First, the SAFe explanation. I've been a software developer for a little over 22 years. My first experience managing a team was 12 years ago and I shifted to it full time in 2018. My entire motivation for doing this was living through environments that were painful and unproductive for everyone involved.
I found Reinertsen during a lot of reading when I was trying to learn the best ways to do things and get a clearer picture of things that I didn't understand because I hadn't had a view of them in my dev/arch/ops roles previously. When I picked up that book I periodically shouted, "YES! EXACTLY!" while I was reading because it showed the math to prove just about everything I'd experienced. Then I used his methodologies to lead two teams with a great deal of success from my perspective.
What I was not doing a good job of was communicating with the business side of the company regarding what was prioritized, why and how. That lead to a lot of back channel grumbling from other people in leadership who had different priorities. I'd just spent months talking with everybody about what their priorities were and mapped out a plan to have it all done in about 6 months. I was extremely confident in this plan at the time. It was beautiful.
One of the senior guys, who I will call "Squeaky Wheel" torpedoed the plan because his top priority wasn't first. That was the moment that I realized I needed to find a better way to get these folks involved in the process that wouldn't blow up all of the great things we had happening.
Long story short, I found SAFe and the CEO sent me for training after I explained my rationale. Here's what appealed to me about it.
1. WSJF - All facets of the company come together to agree upon the value of different initiatives. Sales, Support, Product, Legal, Marketing and other senior leadership when necessary. Following the discussion all of the back channel "we should be doing this" stops because everybody knows exactly why we're doing what we're doing.
Then you combine that with an effort estimate to get a projection about the best value for your time. This will naturally end up prioritizing a bunch of small stuff that has been ignored for a while first, but once you get through that you start more cohesive conversations about larger initiatives. In that first experience, Squeaky Wheel had a low value high effort project that went to the bottom. Aside from him, it went beautifully for everybody else.
2. The PI process - After people have put in the effort to agree on priorities, PI planning happens where Dev gets to lay out the plan for the best way to achieve those priorities. You spent a couple of days planning it, presenting, reviewing and everybody comes out knowinng what the priorities are for the next 8-12 weeks. Then as a dev you get to execute without dramatic shifts in direction. Now, when somebody in sales doesn't close and tries to make a case to change everything you're doing he's directed to make a case to product for WSJF consideration for the next PI. This brings sanity to the dev process.
The PI plan also involves capacity planning so you build in a natural buffer too. As a side benefit, you find out most of the vacation plans of your teams over the next quarter well in advance. One of the big goals of PI Planning is building camaraderie and skipping future meetings with people who may need to provide input. This factor is significantly more difficult in a remote environment.
3. The "Solution" Backlog - Part of the process is that dev gets to keep and prioritize its own backlog of technical priorities for the next PI. You typically split the capacity planning 70/30 or 80/20 across the Feature/Solution backlog. This gives the tech side of the house the ability to ensure work that they know needs to be done, gets done without having to make a case to the business about why. This gives time to improve processes, automation, reduce tech debt, refactor, performance tune, etc if it hasn't already been built in.
When those 3 things happen every developer's life should get easier. Unfortunately, it doesn't always work that way and you'll end up with more layers of control + dictation rather than handing over control to interested parties.
The fundamental assumption here is that you are in such a fantastically stable environment that you can spend days planning the next 8-12 weeks, and then that plan is actually reliable.
My experience was that maybe 20-40 percent of the plan ended up working (blocked by external factors, shifting market landscape, missed or unexpected work coming up), and then there was a huge amount replanning and time wasted.
I just cannot reconcile that 8-12 week cycles is in any way conducive to agile development.
I also do not understand the queues and capacity issue. I have never been in an environment where we do not have so much work that we cannot meaningfully see past the end of the queue. I don’t necessarily view that as a bad thing.