SAFe is an excellent framework for bringing more agility to teams as a break through the glass ceiling between development teams and the rest of the business. This leads to improved delivery and less frustration at all levels of the organization. Sounds amazing, but unfortunately it’s not all as easy as it sounds on paper. You can easily end up cargo culting or having bad scrum practices. Let me explain why.

AUTHOR: Kevin Shine

Some background

For anyone that has implemented scrum at a team level, you will probably have faced two common issues for any team implementing scrum.

Problem number one is the team requires more organizational support to help resolve problems raised in retrospectives, these issues may be outside of the team’s control. If a scrum is implemented at a team only, then these issues often remain and the team becomes demotivated.

Problem number two is the prioritization of work and how the organization operates is managed in a classic waterfall way but teams are implementing using scrum, this leads to top-down push of work and causes teams to not really and truly be agile. The pressure and lack of upward feedback cause teams to cut quality, analysis time, and testing time become squeezed in order to meet a set of fixed requirements and dates. This results in highly brittle and spaghetti code style complexity issues that lead to systems being overly complex and error-prone. This type of feedback loop is slow but steady and can be seen by rising production issues and people that are seen to be system specialists that cannot operate in other areas of the system. IT operation costs or a growing production issue count are about to go up, and they will keep going up unless the cycle is interrupted with positive change.

These brittle systems are often the cause of low adherence to technical excellence and rushed development. As these “specialists” start to increase, your delivery speed becomes crippled by dependencies on these key specialist people to produce working software. This dependency issue coupled with the fact that these people are trying to keep production issues down while dealing with multiple delivery requirements at the same time forces them into a very rushed and pressured downward spiral that essentially compounds the problem further. Slowly but surely you need more people to keep the delivery speed up or alternatively you start cutting corners and reducing quality. Neither of these is desired outcomes. The path back to well-balanced teams and high quality is often a long and difficult one. All of this because you are not optimizing globally and implemented scrum at a team level only. To be fair, this problem is not at the team level nor does it have anything to do with scrum. Teams actually try to avoid all these problems by implementing scrum, but scrum alone is not enough.

Implementing SAFe

SAFe is a framework that starts at the top of the organization and involves a Kanban approach to project management, creating visibility and feedback at all levels of the organization. This Kanban approach introduces managers and key stakeholders in the business to a pull system that takes into account the speed of the teams implementing and allows for a low-stress high communication and collective approach to delivery.

The SAFe framework is a welcomed addition or as I see it “snap on front” to the scrum framework.

Using this framework, you can identify and address issues such as those raised earlier with an all-important global view of the system.

SAFe implementation problems

It’s not all as easy as it sounds, however, and yes this ranges from company to company but certain common issues arise.

Acceptance of the framework and training

In order for SAFe to work there needs to be company-wide acceptance and understand of the framework and why it works. Lack of training or the inability to bringing key people along for the journey will lead to frustration and ultimately partial failure. I say partial failure because certain areas may have improved, but without good guidance from a change management team that understands the framework, it’s easy to lose in the framework and forget the key concept of getting work out the door as fast as possible while improving quality and reducing risk all at the same time. This is not a SAFe problem, it’s a change management problem. When people are learning new things they could focus on a set of things and forget about other important things.

Lack of change support and too few scrum masters

Support in the form of skilled scrum masters is required. Scrum masters operating in more than two teams are doomed to fail or at least fail some team somewhere. When teams are failing the SAFe framework begins to break down and trust is eroded between the delivery teams and those prioritizing the work on the portfolio and program level. Training is required all the way from the top to the bottom of the organization with those people involved in any way with the ideation of, management or delivery of work. Deciding to roll out SAFe in waves or not training at the top will lead to a clash in culture and agendas. It’s not advisable to train just the delivery teams as this will put you back into that glass ceiling problem that SAFe is specifically trying to solve.

No product owners

When Teams are getting work from all angles and multiple stakeholders they struggle to know what they are required to do when. Just like vanilla scrum, the lack of product ownership can lead to delivery failure. Product owners are required in order to prioritize and order the work according to the program and portfolio. Together with the scrum master, the product owner ensures a specific order to the work and reduces team interruption by managing stakeholders. Product owners working with more than two teams are also going to face problems being effective.

Following the Kanban portfolio and program

If work is pushed into the teams and there is an opt-out of the Kanban flow, meaning work arrives suddenly without proper planning then delivery problems relating to quality arise. Teams should stick to the definition of ready and only take work into the sprints that they can commit to. Dropping work into the system and expecting sudden delivery leads to failure regardless of the framework you follow.

Another way to fail is to have program and portfolio boards that are managed by the delivery team. Those responsible for the management and prioritisation of work are required to manage these boards, not the systems or delivery team. while the systems team works with those ordering the work, they are responsible for pulling work and provide estimations on delivery. They are not responsible for the order of the work of keeping the boards up to date on their own.

SAFe assigns an RTE, this role is similar to the scrum master role but at the portfolio and program level and who’s role includes making sure that the Kanban delivery system is adhered to. However, having an RTE that nobody cares about or listens to is powerless to help improve the system. Ignoring the RTE is similar to telling everyone you stopped smoking but then sneaking a smoke or two when nobody is around. You’re only fooling yourself into thinking you are doing SAFe. SAFe requires intentional and mindful discipline and control as do all Kanban implementations. An RTE simply helps keep everyone honest as does a referee in a football match. As such the RTE is a servant leader and not a control gatekeeper but essential in the SAFe context.

Inspect and Adapt and sprint 5

Following the principals or kaizen sounds like a nice idea. Everyone always agrees in principle, but in practice, it’s a bit harder. However, not allowing teams time to stop, check, and improve means you are going around in circles improving almost nothing. You can’t then start to wonder why you have seen no improvement from implementing SAFe. Often I see teams and companies stopping and checking and then going back to doing. People always feel better when a crisis is over and then see no reason to look back and improve, but If nothing changes, pretty soon they find themselves back in the same boat with a similar issue. This is because they failed to identify steps to improve in the inspect and adapt, or they failed to run a sprint 5 to improve and take action on those steps identified.

It’s important for everyone, not just the development teams to meet and discuss what worked and what didn’t work in the last 8-10 weeks and then put processes in place to correct these things.

Just like Scrum has retrospectives, the entire delivery team from concept to implementation need to jointly assess their issues and successes in the form of the Inspect and Adapt session.

These sessions stop mixed messages from getting to the top of the delivery chain. If feedback is given by the manager to the manager, then the story seems to get better and better as it moves from the delivery team up the hierarchy of managers. That or the illusion of resolution seems to take place as people cover up the issues in order to appear as good high performing product managers. It’s not that these managers are out to cause harm, it’s just that the hierarchical systems are usually designed in a way that creates this behavior as it’s expected that managers lower down deal with issues and not raise them further up the chain. Often managers get told to “Just deal with it” and this forces them to bury issues they know can’t be solved without senior-level participation. Inspect and adapt is a simple but highly effective way to prevent this and get everyone watching the same movie so to speak. That said it’s a high trust environment so executives and managers need coaching on what to do and how to behave in these situations. Shouting at a team for poor performance is often the worst thing to do.

Old mindset, new practice

This is probably the hardest to solve, and requires executive coaching and training to fix. Pushing teams to deliver beyond their ability, creating KPI measurements that are negative for the team and a lack of trust between management and teams will kill any agile implementation including SAFe.

Doing the same old thing or bypassing the SAFe framework to go back to the old way of delivering certain items of work will kill the SAFe implantation and teams quickly learn that we talk SAFe but do other stuff to accommodate certain managers who are not bought into the framework. This leads to work going underground and tracking and metrics that help teams and companies improve become meaningless numbers.

Again, coaching and training are required along with an RTE and good scrum masters in order to gain success and help people out of their old patterns.

The need to keep people busy

This comes from optimizing peoples rather than optimizing delivery time. Scrum has a way of pointing out who has nothing to do and teams usually deal with this themselves. Starting more than you can finish keeping people busy is a crazy idea and leads to waste but it’s hard to see this waste unless you are managing the entire delivery system and optimizing for delivery speed. When implementing SAFe you should optimize delivery time over-optimizing people’s time. That’s not to say there is no value on the right but concentrate more on the left.

Sharing people between teams

While it seems like this is a good idea on paper, the people in these situations struggle, and when issues arise in both teams that need this shared person, delays now begin to take place. However, these delays are being managed by the shared person and not at the correct level which is the program and portfolio. This leads to a sudden slowdown of two or more items of work as both teams are now waiting at certain times for this key person. Add a few of these people in different teams and you have escalating complexity that leads to the inability to manage predictable delivery teams. That’s not to say it will happen all the time, but who needs the stress and predictability issues of when it does happen? Another important point is that these key people often begin to experience burnout, and if they leave, the organization delivery suffers further setbacks.

Improving automation and CI practices

At the heart of all agile practices including SAFe are CI, DevOps, and automation. This is because you are baking quality into the product rather than waiting for a regression cycle to check your success. Failing to improve these things keeps you in the waterfall cycle of development. This brings us back to the ever-important sprint 5 to allow teams to do these required improvements.

Many people, including me once upon a time, reject the idea of having a sprint 5, but trust me, it makes all the difference especially when moving from waterfall. As is see it, high maturity teams with CI, DevOps, and automation already up to date and running will probably not need sprint 5 to improve this, but will then focus on other improvements in the system.

Closing

So, as you can see managing all of these issues is complex, but concentrating on optimizing the whole rather than local team optimization is always a win-win situation. Attention is required at all levels of the implementation and failing in certain places can lead to fear and people simply gaming or manipulating the system to make it look and feel like SAFe but smell and behave like waterfall. I

t’s important to have a change company like Kaizania with skilled scrum masters and change agents to assist you to navigate these issues with the lowest negative impact on the organization and get you on the path to predictable and high performing teams.

Just remember, as Nelson Mandela said, it always seems impossible, until its done.