Empowerment in Agile
A colleague recently completed a SAFe training course and afterwards sent on this article, asking for my opinion on whether the conclusion, that SAFe is evil, is a fair and balanced opinion. The article brought up a lot of good points and thought it would be good to share an insiders experience on the topic, to help further the discussion.
To start, I have never been a big fan of SAFe either, I adhere to it because that is the framework we chose for the 300+ engineers working on our solution, so I mostly just get on with it. Fair warning, this will not be a glowing endorsement of the framework, given the opportunity to do it all again, I would advocate looking at one of the many other models out there and would suggest that anyone starting into some form of “scaled” Agile do the same. As I have no experience with other models, I will not make any recommendations. To each their own.
So there is no confusion, I am on the same page as the author for pretty much all of his criticisms of SAFe, I mainly just disagree with the conclusion. The reason for this is down to an initiative we have started at work, one focused on redefining our culture as a company. One of the sub-tracks that I am involved in is Empowerment, hence the title. I am looking at how employees need to go after their own empowerment and not wait for it to be handed to them by management. This is a core belief of mine, that empowerment “given” is an oxymoron, you need to take responsibility and ownership if you want to have power. Jocko Willinks puts it best in his talk on Extreme Ownership, well worth a watch. Looking at the criticisms laid out in the article through the lens of seeking empowerment, there are a number of ways to reframe them.
Be the change you want to see
While the phrase is a bit of a cliche, the idea is not, especially in this instance. Any branded version of Agile, though more specifically SAFe, is a reflective framework, more so than it is predictive. Dean Leffingwell did not go to the top of a mountain to gain the tablets of truth for the best way to work. He looked at what was working well in industry and regularly adopted the bits that could be assimilated into the framework. This is why there is a SAFe 5.0, it is iterative. Companies can then choose whether they want to implement the latest updates in their company. So out of the gate, it is an unfair assessment to say that a system that routinely tries to improve itself, based on how others are doing things, is inherently evil.
To quickly address a point made about the frequency of I&A’s in SAFe. The framework guidance is to do this once a PI, for the PI based aspects. For everything else there are the nested basic Agile practices. So if your SAFe implementation is using Scrum, then you should be retrospecting once a Sprint. In Kanban, you should be doing continuous retrospection when there are areas to improve. Bottom line, you can tailor the amount of reflection and adapting to suit your organisation. Given it is an Agile framework you can also change it in flight, as demand dictates.
Given the reflective nature of this system, people have the power to change it, simply by implementing ways of working that are better than what is out there. Doing so is completely in line with the core belief of the agile manifesto:
We are uncovering better ways of developing software by doing it and helping others do it.
Working from within SAFe to improve the framework is exactly what is asked of Agile practitioners. I say capital A agile here, as we are all doing some branded form of Agile. No company wants to start completely from scratch, as that would miss out on the learnings gathered by others over the last 20 years. We are all buying into the best brand, the one we think is the right fit for our company. The great part is, that in doing so, we have the opportunity to change it from within but this requires a positive mindset.
Starting positive movement within a system is a lot more involved than just criticising the system. As humans, we have a negativity bias that makes us more susceptible to looking at the the bad in a situation and leaning into it, rather than actively trying to fix it. Which is precisely what we could do here, see that there is room for improvement and actively work to reshape the system, rather than just trying to demolish it and scare away users.
To that end, while I said that I follow the guidelines of SAFe, I never stop challenging why we do things the way we do. I’m certain there are many that roll their eyes when they see my name come up in relation to SAFe. I consistently poke at decisions, making people justify why they want to adopt something and over time, hopefully, help them see an alternative way to do things. This is not just complaining, that is easy, it takes effort to point out where the flaws are and offer an alternative.
The ease of criticism is demonstrated in the article, it is a quite detailed demolition of SAFe but what alternative is offered? What alternative can be offered that suits every company? I’m in no position to answer that and would argue that neither is the author. Everyone is different, for some SAFe works, for others there are better alternatives. Some companies just have to try it, so that we can either learn from its mistakes or change it, as we are empowered to do so.
There another good point made in the article, one that fits neatly with an early description of SAFe, that I feel still applies. SAFe is Agile for companies that don’t want to let go of top down management. Yes, that sucks but there is a remedy for it…
Take extreme ownership
As one of the unfortunates that is using the full Solution level version of SAFe, I can attest to the authors worries that it is truly awful. It completely strips autonomy and power away from the people closest to the work, in such a way that they feel completely disempowered. Decisions take months to agree on, requiring multiple workshops to discuss dependencies and conflicting priorities on things we all know need to get done. So much so, that those doing the work don’t feel they get any real say in anything and are nothing more that “resources” to get work done.
However this doesn’t have to happen. Teams can avoid allowing their organisation to grow into a monster, provided they take the necessary ownership over everything in their control. SAFe is only a framework, how far you take it is entirely up to the company and those working in it. In principle you could do it with almost none of the additional overhead of the Solution level. To achieve this though takes vigilance and dedication, you need to see the warning signs of power being eroded, as it is gradual and might only be seen looking back at it.
One of the core places this can happen is where products grow more complex, to the point the team needs to be split. Issues immediately start to arise, as self-organisation needs to kick in, new dependencies need to be established but that takes time and consistent delivery is something that is expected throughout. In a misguided attempt to smooth over the process the decision will often be taken to put in a PM (Product Manager), they will handle disseminating asks down to the teams from the customer (or Portfolio) and become responsible for the delivery of both teams. This seems sensible in principle, however there is a fundamental problem here. Where are we getting these PM’s from? Hire them externally? Bring in fresh perspectives to the problem? Nah! That’s expensive! Just “promote” a PO. It’s basically the same job and they already know the product, so will have a head start in getting the coordination going between the two new teams.
This isn’t just faulty thinking to try and save a few quid, it is a dangerous mindset to give someone going into a new role. If a PO is promoted to PM on the assumption it is essentially the same role, of course they don’t let go of the feature writing to focus on the asks, because they are not trained to do so. They stay fixed with the same PO mindset, now overseeing multiple other PO’s. This then leads to the situation where PO’s are demoted to story writers, as they have a super-PO, not a PM. This is another area where teams need to take control.
The first group who need to do this are the PO’s, they should stop and say “Hold up! We can manage our products just fine, we don’t need a supervisor to manage them for us.” The PO’s should sit together with their teams and flesh out the agreements on how the new teams will work, taking ownership for any slippage they foresee during the transformation. Alternatively they might decide there is a need for someone to occupy a role of disseminating customer asks down to the teams, so they do want PM. As part of that agreement they should clearly outline the boundaries and who will take ownership of what.
In this case, the PM also needs to adopt their own responsibility, especially if they are being promoted. They need to go to their manager and say “I need to be trained in how to write high level asks, as all I know is how to write features.” This might seem silly to some but asks are fundamentally different to features. They are not meant to be detailed and technical, they are meant to provide direction, taking the vision of the customer and distilling it for the PO’s to turn into features. This is something that Simon Sinek talks about a lot. When people are promoted and their role changes, if they are not trained in how to do their new role, they are being set up for failure.
A large part of this comes back to culture, PM’s and PO’s need to understand that they need time to grow into these roles. However as many are promoted while under pressure to keep delivering, they just muddle on the best they can. This is where the power of saying NO comes in. Teams forget that they can do this. Instead of just accepting poorly written features from PM’s, who likely feel overloaded doing the job of multiple PO’s, teams can just point back to the book and say “This isn’t good enough, you’re operating at the wrong level, let us own the areas we’re supposed to.” Many forget they get to define the boundaries of their own role, regardless of whether they are doing SAFe or anything else. Though it is understandable that some don’t want to invest the time, as they feel another transformation is just around the corner.
The problem with Transformation
This goes to another topic touched on, this whole deal is supposed to be transitory, a move towards some greater Agile utopia. However, as is rightly pointed out, most don’t know where that is and there are those that don’t want us to go. Lock-in a huge part of this, naturally SAFe wants you tied to them forever. It is worth remembering, they are not running a charity or open-source community, they are running a business. As is every other supplier of Agile practices. If you want something free, something truly agile, then you’ll likely have to build it yourself but that is going to be a much tougher hill to climb, as you will not have the resources and training that these companies have accumulated through their work and are happy to sell.
It also goes to another reason why most large companies choose to adopt SAFe, because they are already scaled and their whole system is big and messy. They need the rigid structure, as it help funnel them towards something better. Even if they don’t quite know where the destination is, it has to be better than where they are. There is a simple phrase that summarises where a lot of these companies find themselves;
Your architecture is a reflection of your organisation.
In my experience this is completely true. We started our journey into SAFe big and complicated, in both regards and we have continued to grow, as we are creating new products and shifting to meet changing markets. Like a lot of companies this has led us to becoming a bit of a monster, we don’t kill off low usage applications, we don’t pay down our technical debt, we prioritise shinny business features over maintainability. These problems are not easily solved by any form of Agile or agility, not at scale anyway. They are fundamentally business priority problems. Industry as a whole is moving faster than anyone can possibly keep up with, so we are all searching for the silver bullet that can give us the edge. Individual teams who take ownership of their products can do a better job than those that leave it up to Portfolio but this is difficult if the teams have allowed their power to be eroded to the higher levels.
There are guidelines that we should have followed from the foundations of Agile or Lean. (As an aside, I agree that Lean-Agile is largely BS, they are two well structured things, leave them that way.) A favourite of mine is WIP Limits. Had we implemented them properly, as per the guidance of SAFe, either in our Sprints or in our Kanban processes, we could have avoided the situation where teams are pressured into making poor choices in what work they bring in. They could have put a solid stake in the ground to say, this is how much we are willing to take on.
This again goes back to empowerment, too often we play the victims, that we couldn’t say no to company pressure. We had to take on new work! We had to keep expanding, never finishing work, as there was always a higher priority. This is also BS, most teams gleefully take on more work than they can handle, even when presented with data that shows they will not deliver, their optimism wins out. This is compounded when they are not accountable for delivering, as that has been abstracted away to someone else. As a result they trigger the above scenario, where top-down management see the need to grow to the next level of the monster. Teams aren’t taking ownership for failing to deliver as promised (SAFe has promises in the form of PI Objectives) and so there needs be more Product Management, when that fails, more Solution Management.
Taking ownership of those failures from the get-go would build trust in the team's ability to deliver. Acknowledging the failure to deliver as a team issue, paradoxically empowers you to say no later, as you are demonstrating you know where your breaking point is. Instead if the failure is blamed on the poorly written asks, the lack of time or changing requirements, trust is eroded, as these are a given in Agile. Putting frameworks like Epics in place is the natural consequence to this, if the ownership is not there at the lower levels, it must be addressed by adding more top down controls.
All that said, even with ownership it also requires effort and purposeful direction to chart a course to a better place. Simply wishing for a utopian microservices architecture, that will allow teams autonomy and flexibility does not happen overnight. The structures; technical, cultural and organisational all need to be carefully deconstructed and rebuilt. All while keeping the plane flying. That requires a framework and coordination, as well as support from on high. We have begun to do this and are restructuring our teams into logical domains, that should work together to reduce dependencies. This requires a form of Agile that strikes a balance of structure and flexibility, so something like SAFe is the preference of those that pay the bills, even if it doesn’t suit those that do the work. Again there is a remedy to this…
Use the Data to make change
The last point of how teams can self-empower themselves and drive changes is unfortunately one of the most common challenges levelled against any sort of Agile. They are using numbers against us! In a past life, I rallied against this. I still do. Metrics have to be used very, very carefully!
Again, I agree with the criticisms of rolling up team Story Points to make predictions on how a bigger function, like a train, is expected to operate. That just doesn’t work. Digging into the mindset of those that do this, which I have done, it often goes back to the same problem, teams are not owning their backlog and so are unpredictable. Management doesn’t like unpredictability, they like regular delivery, as promised by all the books. Going back to the first point, this is where you can drive the changes you want, as metrics go both ways.
If your team is struggling to deliver and you have exhausted all the actions you can own, leaving only the external influences, like poor quality asks or lack of direction. First, demonstrate actions taken within your sphere of control, then quantify the cost of those externalities. I know many will dislike the idea of putting a dollar value on a person's time but reality is, we’re not getting paid to sit around. We are here to make money and if we want to see change then we need to talk in a language that the decision makers speak. Cold, hard cash.
There are many models for this, a simple one is to get an average cost of an engineer per hour and then cost out your refinement sessions based on the number of team members in it, calling specific attention to where extra sessions are needed to understand the fluffy nonsense you have been handed from above. From that make a case that the team is investing more effort clarifying the vague asks, than it is actually doing the well defined work written by the team. Consistently show that and you will satisfy the core value of people in Portfolio, demonstrating predictability and taking ownership of fixing the issues and any unnecessary layers can be stripped away.
Armed with numbers, teams can say no more easily. Too often I see teams pushing back with gut feelings that things will be too hard. While I would generally support listening to your gut, it is not a sustainable business model. Data drives much more powerful decisions, especially when it can be translated into dollars. This is not an evil of SAFe, it is a fundamental part of doing business. Doesn’t make it any less evil, just need to be careful where you direct the scorn.
Does SAFe have a long list of things that make it terrible to use for the engineers on the cold face? Absolutely.
Are there better ways of doing Agile at a large scale? I’m sure there are but suitability will vary by company and the stage you are at. Do your homework on what is likely to work for you and plan your transformation as best you can. Remember, they’re all trying to sell you something.
Can we adapt and improve the way that we work, shaping SAFe into something that is much better for everyone? I believe we can. It requires a constant conversation and freeing more minds to see the ways of improving the system, rather than just abandoning those trapped inside of it.
Should we abandon any attempts at doing Agile and try to build our own brand of agile development? You know your company best, if you have the right people for it, I’d love to hear the results but suspect you will align to one of the many forms of branded Agile, as there has been a lot of investment into them to make them successful.
SAFe is what it is, an answer to the question, how can I make a transition from 80’s style development, to something approximating the right way to do things, while still keeping a lot of control?. It is neither good nor evil. It is a framework that allows teams a lot of flexibility in how they chose to structure their development practices. Most importantly it is a framework that empowers us to shape it from within, using our practices to create positive feedback loops. This is foundational for anything that claims to have the agile manifesto at its core, which SAFe does, under all the bureaucracy and complexity. In order to continue shaping it we must first free ourselves from the mental block that we can’t change it or that we have to demolish it.
Maybe by SAFe 100.0 we’ll have it right.
This is all the opinion of a single cog in a massive machine. There was no fact checking done, so entirely open to any corrections or contradictions. Experiences may differ with other SAFe users and the opinions of those that have shared my journey may be wildly different to my own. I admit I may even be suffering Stockholm Syndrome and should be far more critical than I am but will see with the test of time.
I used PM’s and PO’s as the main example in this, if you are in this role please don’t feel I’m putting the entire responsibility on you. The same issues exist between SM’s to RTE’s to STE’s, Tech Leads to Architects to Solution Architects and any role that attempts to scale. Humans are simply not designed to! I focused on the PO/PM role as they should own the backlog, so can achieve the greatest degree of empowerment. If anything, I see your role as the best hope of changing this situation. Editorial comment: I actually changed the way I framed my observations on the dynamic between the roles to be more fair. (Hopefully)
Quick one, Rally sucks, 100% agree! That said you can choose other tools if you fight hard enough for them. Do experiments and use data to show where using a different tool makes the team more productive.
I briefly touched on a more foundational topic of whether business as a whole is evil. As that was not the question I was asked, I didn’t go into it much but for clarity; ya, business is pretty evil. I’d love to live in a world described by Simon Sinek (full talk), where companies value people over profit but thinking through this gives me quiet optimism that agile principles could be the trojan horse to make that happen. We are starting to look at practices to minimize the evil that we do people and reframe what it is to succeed. I will end on that slightly optimistic note.