Nexus/SAFe/LeSS/"Spotify-model" etc. - don't they actually limit empiricism if blanketed over an organisation?
Hi.
I'd like your reactions on my opinion, and hopefully some alternative opinions to discuss! Thanks in advance.
I've seen some environments where a team of "agile coaches" and/or scrum masters was "flown in" to help with transition management. Environments where fiery informal language is suddenly used in internal mails, pizza meetings are held, table-soccer tables and large touch-screen boards for Jira boards are carted in, adjustable sit/stand paperless desks are placed and people are spoken to in large groups by guys with 5-o-clock shadows in carefully chosen casual clothing and running shoes, talking about "The such-and-such 3.0" and "X is the new Y". (Satirically put, but with a big kernel of truth IMHO...)
These organisations' intentions are typically just fine, but often, the higher-ups, management teams, well-paid agile coaches, HR departments and such seem to have determined that The Right Way to implement "agile" is to bet everything on "The Spotify Model", or Nexus, or SAFe, or LeSS.
I don't like choosing the implementation of such a framework as a departure point for an organisation. They are typically fine cookbooks that unlock a lot of potential, and it's often better than what came before. But by importing such systems, you're risking missing the biggest chance of all, namely discovering YOUR optimal system for YOUR environment and YOUR people and stakeholders. This is what empiricism to me is all about, and that risk is where it fails to win the hearts of the people inside and out of the organisation, because it's still telling them what to do and how to do it, instead of departing from the core realisation that the whole point is to embrace not knowing and then discovering.
My actual hobbyhorse when people ask me about LeSS/SAFe etc. is to argue that these methods look cool (maybe actually are cool) because they evolved as the optimum where they arose. They are not the source of Agile working, which is how the aforementioned transitioners often choose to view them, they are a result.
What do you think of my reasoning?
It can be tempting to cut a thin representative slice across one’s more successful experiences, and then present that slice as an agile scaling framework. Unfortunately, the more elaborate the prescription, the more restrictive it is likely to be. It might work again in its original context.
The glass can be seen as half-full in so far as a thin slice can find its way to management’s heart. It can look like a proven, industrial-strength turn-key solution to an organization’s problems, and is rather more likely to secure executive sponsorship than discovery and emergence. Although unlikely to be successful in the long run, a thin slice can sometimes plug a gap until organizational leadership matures.
This is a topic I am passionate about so I will weigh in with my observations and my personal experiences and opinion.
I've been in the consulting/contracting space for a long time and have seen some consulting Agile Coaches (who are trained in multiple frameworks) prescribe an enterprise transformation (top-down) that is a mix of multiple frameworks and methodologies (Scrum/SAFe/Kanban). This is not the method I advise my clients on because leadership are not the ones developing products so to them, being agile means regular workshops and agile ceremonies. To them, if it looks agile, and they have acquired a popular tool for capturing stories and reporting on progress, they have succeeded in being Agile.
When I advise clients on Agile transformation, I ask them to bring in experienced Scrum Masters/Scrum Trainers (as consultant or employee) and to create cross-functional teams assigned to work towards a Product(s) Vision. The experienced Scrum Masters/Scrum Trainers can be Agile Coaches but in this case, they are working with multiple teams at the team level. The Scrum Masters/Scrum Trainers will work with these individual teams and cause change at the team level. If the people doing the work are high-performing and are producing quality and innovative products, and the client is happy, the organization as a whole will be successful. This, to me, is a better method for Enterprise Agility. There are two important points here. The leader needs to make it clear that the organization's vision and goal is to be Agile (so current employees/contractors are prevented from overtly resisting change). Leadership gives the Scrum Teams a high-level goal but lets the Scrum Teams decide how they will get there, what work will get done, how they will accomplish it and how they will measure it. Personally, I don't prescribe one reporting/tracking tool over another. If the Scrum Team wants to use Excel and Powerpoint, that's their decision.
Enterprise Agile transformation = Not in my opinion
Team-level Scrum transformation which will improve the Enterprise = Yes in my opinion
Thanks for your observations. Looks like you both more or less agree with mine. I was wondering, however, what you thought of my reasoning, and/or if you had alternatives :) Maybe it should have been a blog post.
Anyway. A reaction.
@Ian, very insightful as always :) I do believe we seem to agree. However, your terseness is always thought-provoking, and to me it tends to sound like you're letting something dangle that you're hoping the other will discover on their own :) I am not ashamed to say that my arts and skills are diverse and varied, but I wish I had that in my range.
The stop-gap thought could work, sure, but still, it would feel like putting the cart in front of the horse. To put it bluntly, IM(ns)HO my job as a scrum master is to convince people to be open about everything and to want to embark on this journey of discovery, not to help people put blinders on their heads and then writing "this is a blinder" on the outside of the blinder :)
@Mark, thanks for your observations as well. I do trigger somewhat on your sentence "The leader needs to make it clear that the organization's vision and goal is to be Agile (so current employees/contractors are prevented from overtly resisting change)."
Apart from the fact that I'm not sure who or what position/role you are talking about when you say "the leader"...
Does there actually need to be a leader expressing agility as a goal? Is preventing people from resisting something actually a good thing?
One of the organizations I consulted for was a small, less-than-two hundred person shop. I advised the CEO of this organization to make it clear to the organization as a whole that they will need to adopt agility. I made it clear to this CEO that in my experience, if the workers think that organizational change is optional, they will opt-out. They will also rebel and resist any attempts at improvement. In a hierarchical organization, there is a leader. And if a change in the way business is done is coming, that message needs to come from the CEO, before the Scrum Master/Scrum Trainer can help facilitate it.
I understand, and thanks for explaining, but now I disagree more than before :) You and I seem to disagree on what Scrum actually helps to enable, facilitate and unlock. You hold some views that in my opinion could be counterproductive. I can elaborate if you want. But if so, then please take a moment to hold your last post against the value of "respect" and the "servant leader" and "change agent" Scrum Master stances and see if you can predict where I'm coming from.
Agility at scale topics appears in most of the conversation nowadays, either to solve multiple teams coordination issues working on the same initiative, in the name of business agility, or enterprise agility. There are numerous frameworks those claim to solve or provide solutions for agility at scale. Do they all retain core values even at scale? Check this blog to find that if we really need SAFe, LeSS, Spotify, or Nexus to be agile?