Key Safe Problems
Riitta Palazzo
Last week I published my monthly newsletter with the post below as the content (Not on my mailing list? You should subscribe here.) As you can imagine, it stirred up quite a few feelings. Many folks reached out in support of the post. Several folks were, well, less pleased. This makes perfect sense. If the work that someone does centers around the Scaled Agile Framework my post below, attacking this framework, can feel like a personal attack. I feel this way when someone launches an attack on Lean UX so I have a bit of experience here.
One thing I pride myself on is an open mind and a growth mindset. Every single person who sent me constructive feedback (ad hominem attacks go right in the bin) critical of my thesis I invited to share their experiences, case studies not just with me but in a public forum where they can build more goodwill towards this method. Most declined. One agreed. (Stay tuned for when and where that will take place.)
This is understandably at odds with the business needs of predicability, but none the less this is the case since the beginning of commercial computing, and has only improved incrementally with the advent of better technology and methodologies.
SAFE, is an attempt by organization to bring management control into agile. Agile by nature has very limited management involvement , agile teams has a very flat distributed non managerial structure. Large organizations adopt SAFE as a means to bring structures in agile, so no SAFE is no agile but a waterfall reincarnation:
Interesting perspective. Having joined a company 18 months ago using SAFe I can see some of the point of view. I still question agility when you are fixing work for the next time period (PI). I see lots area where SAFe is trying to offer support and guidance and I see lots of area where it falls over. But is this just he fault of the execution. Failure to effectively manage a backlog of work that can be executed does not help, lack of assessment of execution, retrospective will not help you to continuously learn and adapt.
For me like many things SAFe is a framework, it even includes this in the name. As such I take this as a guide that you can adapt to your own business needs. The same with any other methodologies. Just hitting the key markers and getting everyone to give you a thumbs up is not going to get you anywhere.
Whatever methodologies or frameworks you use there are some key practises you need to include, as Jeff has included in this article. Key to this, as with most things these days, is the people (employees & customers). Making sure they are involved in supporting these processes as well as guiding them.
If you were to compare Scrum with Kanban, you could easily argue that Scrum is not at all agile in comparison to Kanban because Scrum is quite formal, process, ceremony and role based. While change is welcomed, there is strict timeboxing (sprint) and fixed scope within that timebox that discourages change. Kanban in comparison is extremely light on process, has few roles, does not timebox and change can happen on an hourly basis if you wish, as opposed to outside sprints only.
That said, would I recommend that a traditional, process dependent organisation transform from Waterfall to Kanban in one jump because Kanban is the most agile of the methodologies? absolutely not. Simply because the change required at a systemic and people level, would be so great that only an already nimble organisation like a start-up could implement that level of change successfully in one jump.
Your point is valid, but it is the context that I would question. If the organisation and its people are already nimble, there are many more suitable approaches to scaling agile like LESS, Scrum of Scrums or build out your own with Lean Change Management. But if you have a more traditional, matrixed, process dependent organisation who does not have a history of implementing significant organisational wide process transformations and people transitions, then a step-by-step approach is likely to be more successful in the context of organisational change.
Agility, like all change is a journey. It starts with understanding why change is needed, then what is our current reality, then what needs to change, committing to the change, tackling obstacles to that change and finally measuring our success.
The problem, as I see it, with SAFe is in how it is implemented. It it is supposed to be a framework, a tool kit, but practitioners are dogmatic about its structure. While companies are investigating heavily in the window dressing of SAFe, they are ignoring the less sexy fundamental practices; integrated teams, prioritizing based on capacity, acceptance criteria, Wip limits, and the validation of outcomes.
If you actually read about it and go through the trainings, you will discover that it actually does teach, in black and white, most of the things that detractors say it does not in the original post and comments above.
Before jumping to conclusions about my intentions, please understand that I am not defending one framework or another, and instead trying to illustrate that none of them are, in my view, the cause of the problems noted, nor a path to solution.
As an organisation scales, how *are* we supposed to run 20, 40 or more teams, working on a programme that requires a degree of dependency and coordination between them (i.e. they are contributing to the same product, platform, service, whatever)? Each team cannot be purely self-directed and pivoting on a dime, as other teams are relying on them to deliver things their plans are depending on. Not everything can be done immediately, so things get queued waiting for a dependency to be fulfilled. even the learnings often span multiple teams, or can only be realised once multiple teams have delivered their contributions to the feature. This all seems to require a level of coordination and forward planning that is beyond Agile.
Scaling agile in a corporate environment is difficult and challenging. For me it is about remembering what we are trying to achieve and at the heart of this is the ability to release working software in small incremental chunks that is aligned to business value.
I know these elements are included in the diagrams and training. How much of this actually gets implemented? Where has this happened? My experience tells me that the majority of this gets ignored when SAFe is implemented.
The problem with SAFe and its implementations is that the resulting change is usually a change in the way of working (terminology, ceremonies..) instead of changing in culture, top mng. egos and mindsets. Also terminologies and entire framework is pretty hard to grasp so usual implementation of SAFe is that IT part of organisation now uses new terms and way of working, rest of the company stays same. Maybe CTO/CIO and his B-1 level changed too but rest of the org is not much on board.
BUT IMHO it is not entirely fault of SAFe but rather that too much attention is put into changing processes and structure rather than heads of top and senior mng. Obviously this is supported by SAFe business model as money comes from certifications that tests terminology and definitions knowledge. And change leaders are in illusion that if you change org chart and how you work you become agile enterprise.
Various business owners let small groups of people having similar kinds of work or goals in their organizations set up their own goals and design products. They strive to achieve success in this manner by giving freedom of expression to their employees. They apply Agile methods like Scrum and Kanban for this purpose. And these Agile methods work very well when the group is small. However, large companies also wanted to use Agile methods extensively in their organizations for large groups, departments, or cross-functional teams. But they faced trouble because of the limitations of Agile. Due to this, Dean Leffingwell and Drew Jemilo released SAFe in 2011 to help large organizations meet customer requirements in a better way.
SAFe is used to scale the Agile methods at a more extensive level. Transforming the thought process and working in a large group is difficult. The motivation in the group is not consistent, and the members of the large group may be too used to following the instructions of their superiors and may not be in the habit of taking the initiative or working independently. This is where SAFe steps into it. It allows Agile to be scaled to suit the requirements of a large group or enterprise. But scaling Agile is by no means an easy task, particularly for a large group of people. It poses many difficulties to even those Agile Developers with a lot of experience. Many people find SAFe quite helpful, but at the same time, many find implementing SAFe troublesome.
There are many Agile methods, but SAFe seems more inflexible than others. The approach is rigid to the extent that it leaves no scope for modification or change, so you can't customize it according to your company's specific requirements. More often than not, in SAFe, the team members stick to their assigned roles only because there is no room for them to experiment. On the contrary, in other Agile methods, the team members flourish because they are the owners of their tasks and are asked to take responsibility for their goals. They are allowed to use their knowledge, effort, and skills in different ways for the organization's benefit. Scaled Agile Framework confines team members to their specific roles, not giving them much flexibility or freedom.
Unlike other Agile frameworks, decision-making in SAFe is incredibly centralized and is generally in the hands of top managers or leaders. When the decision-making is left to the leaders at the top, Project Managers are unnecessarily burdened. The essential things are taken care of at the portfolio level, and the decided features are incorporated at the program level. Then the team is asked to build and test accordingly. This model will tempt large corporations or organizations because of the mindset that people at the top have more knowledge about what needs to do and how to do it than the people who have to do the work. This demotivates the team members and disengages them. However, this thought process is directly opposite to the Agile ideas and contradicts the principles used in modern management. In the present scenario, companies are better served by pushing responsibility and authority down the line. Unfortunately, SAFe is not conducive to that. So, the team members feel that SAFe does not offer anything different from what they have been doing or experiencing earlier. They lack the initiative and are reduced to order takers only.
c80f0f1006