Is SAFe safe?

 

Stay safe

Recently I was at a Scrum discussion group hosted by Tobias Mayer. Noel Warnell posed the question, “Why scale?”. That was about as clickbaity as the title to this article and certainly attracted attention; and the conversation led me to the following realisation.

When we talk about scaling, we fall into one of two camps: either we are looking to grow our delivery capability and realise we will have too many people for a single team, or we already have lots of teams and are looking to make their delivery better. These two situations are enormously different and SAFe is suitable for one, but not the other.

When there is only a single team, likely collocated and cross-functional, then things are probably working well. The relationships within the team will be strong enough as to not require any compensating processes and you’ll find the Scrum guidelines will be a fairly comfortable fit. With this situation, if you need to grow, then your focus will be to not break things. You want to increase delivery rate BUT maintain all the great stuff you have with that engaged team.

In contrast, consider a situation with lots of teams all working together, in a borderline anarchic system, chances are things have grown organically or possibly as a result of an acquisition. I would expect multiple locally optimised groups, possibly clustered around technical components that are drowning in dependencies and technical debt. Having seen this many times and find it often stems from a misalignment of objectives and a “too busy to improve” culture. Commonly there is failure to appreciate it is attitude and relationships, not individual talent, that make great delivery. In this situation the objective is to fix the system rather than grow it.

When we talk about scaling we need to be clear whether we mean to GROW something, or FIX something, and the solutions to that challenge are likely to be very different. This brings me to SAFe.

Returning to that single team, all keen and dynamic and you put the SAFe picture on the wall and proclaim proudly that one day we’ll be a huge machine all using this approach, chances are you’ll get some strong feedback. There are very clear and understandable reasons why not a single signatory to the Agile Manifesto currently endorses SAFe, and many are vocal opponents; it isn’t really very “Agile” in the original context (and for more context and a few rants, Google is your friend). What you’d probably be looking for is something more like a hive mind, a network of highly engaged teams each swarming over their own challenges, connecting over common values and simple clean components. Pretty sure that isn’t SAFe.

However in the other situation, if you have an anarchic system with a lot of effort but little value, high utilisation but little alignment, then the introduction of something with significant structure and assurance for those that are trying to make sense of the madness is not the worst thing to do.

We need to consider how we naturally would look to improve a complex system. I suggest we’d take the following steps:

  1. Impose order to understand the current state
  2. Identify opportunities to divide the system into simpler parts
  3. Ensure a simple interface between potential parts to ensure they can separate without immediately rejoining or breaking
  4. Reorganise to break the system into smaller parts
  5. Improve each part in a custom fashion for what you need it to be

If you consider that Scrum is a delivery framework for solving complex problems, then this approach isn’t too far from that. Apply order (sprint), break work down with clear interfaces, deliver…

Realistically if you discussed the situation with senior management, the chances are they would like to reach stage five for their teams but are very nervous as to how to achieve it. The challenge is always to be able to improve whilst maintaining delivery expectations; change the plane’s engine while keeping it in the air. Very crudely, the LeSS framework looks to get to stage 5, but rather optimistically looks to leap to step 4 and hope that through strength of character things will pan out well. SAFe, on the other hand, is a lot less disruptive and so compliant to the status-quo governance and culture, that it really doesn’t have ambitions beyond the step one above.

If you are on a building site and it is on fire, it doesn’t matter how spectacular the architect’s plans are, what you need right now is a fire extinguisher. That is how I see SAFe: it is a coping mechanism. Once the fire is out, then you can start building. Awareness is a critical prerequisite to change, and SAFe brings that clarity, however it won’t really fix the situation. SAFe also comes at significant cost to surface and manage all those dependencies, and doesn’t really suggest how to remove them, but once you have visibility of what is happening, what value each role adds, or could add, then you can appreciate how to improve further. The real benefits come from moving beyond SAFe, not moving onto it.

So SAFe is safe as long as what you have is already broken, but only remains safe if you don’t stay SAFe forever.

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter: @philagiledesign 

You can buy Agile, but should we sell it?

Here is your Agile Transformation sir, I even put a ribbon on the box…

11092_ff2b6714-3be6-46f3-95f2-2bdf8f4c2180_grande

I enjoy reading the opinions and debates within the Agile community on social media, even contributing from time to time. Of late a few articles have stood out, maybe it is because I am seeing a growing trend of concern, concern for ourselves. The deepest concerns focus on the topics of “selling Agile” and “imposing Agile”, although I feel the question of imposing agile is related, in part, to resenting a revenue stream that others are achieving through “Selling Agile”.

Agile, at its heart is about feedback, about giving back and learning. Those who initially consolidated their ideas down into a written manifesto did for the best of intentions, the second line of the manifesto even states “… and helping others do it”. The point here is that the concept of Agile approach is a gift, for all. It was never created to make money.

There are very few things that have been created and given away for the betterment of the world, Penicillin is the poster child, but the concept of the internet could also be considered. The problem is what happens next – look how much money is now made from the internet. Wherever there is the opportunity to make money, someone will attempt to, and the more successful they are at doing it, the more others will be encouraged to follow.

Tragically Agile has moved from a theoretical ideology backed with a reasonable description, to a commodity. There are many many people bemoaning this slow transition, nearly all of whom are culpable – myself included. As they invested their time and efforts to gain skills and experience in this new concept, they needed to feed their families and pay their mortgages and started to sell what they had; in the knowledge that was “valuable”… You can either sell a service or a product. A service is customised to the client and is typically high value but being so customised is not very scalable,  it can’t be resold. Products on the other hand are consumer agnostic, one iPhone X is the same as another. Products are much cheaper than services, but they leverage economies of scale to enable huge profits. This is what has slowly happened.

There is now an “Agile Industry”. This used to be a few independent consultants contracting into organisations to support their self improvement along Agile principles, that work slowly morphed into what we call an Agile Coach. Then came engagements with larger organisations that required more work and the concept of the Agile transformation started turning up and that introduced the money pot of Agile training. The final step in the transition to a commodity was the certification; which is really an attempt to patent an idea. Now we have a multi-million pound industry ranging from independent consultants to large dedicated organisations selling transformation. The ultimate Agile product is the “Scaled solution” a highly comprehensive, easy to understand, standardised, easy to pitch, silver bullet offering rainbows and unicorns to all….

The problem with the product of “Agile” though, is that while most know of it, and everyone wants it, very few really know what really good feels like. We are now in the incredulous place with some massive multinationals investing in “Scaled solutions for Enterprise Agile Transformation” not because they really know what it is or means for them, but because other companies near them are investing in it. These companies are buying into their competitors decisions without actually having any competitor results to compare against. All companies want to improve, but few will naturally invite change because that is disruptive and risky, so if someone offers improvement, without making any necessary changes clear, then it is tempting to buy it. People are buying a transformation where nothing changes, a real twenty-first century emperor’s new clothes.

This is the salesman’s dream, the ability to sell something to someone who will buy it only because someone else has. If you can sell something without needed to tie a value return to your product then you can make millions, and millions are being made.

This is not to say that I don’t believe that an organisation becoming more Agile will be beneficial to them, I am just deeply uncomfortable that I can sell promises and dreams, and retire rich; free from the responsibility to ensure that those promises come true. If you don’t have to worry about the success of your product then you can afford to tailor your offering to maximise profits, which typically will mean to standardise the offering, shift it from a service to a product. To refer to a great Dan North quote, “Behaviours are practices in a context”; to get the desired behaviours you need to tailor your practices or change your context, or ideally a bit of both. However if you are selling a standard product then you need to be context agnostic, which means the results will be extremely variable.

Having worked in numerous organisations trying to make things better, I have concentrated on introducing practice at the bottom and changing my context through engaging at the top. If you can’t engage high enough in the organisation then you’ll struggle to impact the context you are working in, and the culture slowly erodes your efforts. If you only engage at the top, then the practices you are advocating will feel imposed and inappropriate which will manifest as resistance and failure. In my experience the lasting changes come from bottom up activity, enabled with top down intent based leadership, you need both. Importantly both come from within. It’s really quite hard to do this from outside and impossible to do without a locally customised approach.

I recently have had the opportunity to discuss Agile transformation with some of the most prestigious strategy and management consultancies. They are rightly reluctant to engage in snake oil promises to their prestigious clients, their reputation is worth too much to risk and they have seen their more delivery focused competitors flounder and suffer through overly commoditised transformation initiatives. However all are now feeling there is opportunity here; whether they all have the sufficient business agility to adapt their typically structured engagement models to support the more adaptive, immersive approach necessary to achieve real value change, I am not certain, some do for sure. If you start with the premise that we can do a rapid assessment followed by some predetermined structural and process changes from a standard playbook where the constraints to success are your own innate talent and efforts, then I struggle to believe you be successful. Things are likely to be different, but better?

If you want to help an organisation to become more Agile I firmly believe you need to have skin in the game of the improvement, you can do this as an external contractor, or a team of consultants but in both cases these people need to get inside the organisation, to be part of it, mutually learn with it. It is more of an experience based model than an assessment based one. Change comes from within, you can’t impose it from the outside. If you as a person want to be happier then that comes from within, from the outside I can dress you in jolly colours and paint a smile on your face but on stepping back, I now just have a sad clown.

The Agile industry isn’t really selling Agile, what is being sold is an ingredient in a recipe for success that also requires a lot of time, a lot of effort from within and no small amount of discomfort, but that doesn’t seem to sell quite as well. We aren’t selling cakes, we are selling flour, and the buyers need to be informed they’ll have to break some of their own eggs to get any benefit.  

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter or here at @philagiledesign

 

For supporting perspectives and related ideas read these excellent articles:

https://blog.agilityscales.com/can-big-consultancies-deliver-agile-transformations-56bd3c54c87f/

https://guntherverheyen.com/2019/01/07/the-illusion-of-agility-what-most-agile-transformations-end-up-delivering/

https://www.leadingagile.com/2019/01/raise-no-more-devils-improving-organizational-capacity/

https://www.linkedin.com/pulse/rethinking-transformation-tobias-mayer/

https://www.linkedin.com/pulse/adopting-agile-youre-aiming-wrong-target-tim-snyder/