Author: Paul Oppong

Can You Really Play Agile SAFe?

Written by Paul Oppong on September 5, 2019. Posted in Articles.

Agile SAFe has been touted by some as being a good solution for the implementation of agile in larger organisations.

However, ever since the idea was first initiated it has been a cause of controversy and disagreement in the agile community. It is helpful to assess whether organisations can really play agile SAFe, considering its benefits and challenges. It is also useful to think about practical factors associated with its implementation, to try and make any use of agile SAFe as beneficial as possible for organisations. These points are considered below.

What is Agile SAFe?

Before progressing, it is important to understand what is meant by agile SAFe. SAFe is an approach that was put forward in 2011, with a view to aiding software development teams to get improved products to market at a greater speed. SAFe stands for Scaled Agile Framework, and since its conception, organisations have been working to build tools that can help with its implementation within larger organisations. SAFe is a framework that aims to help in situations where scale is a factor. Working within SAFe, there is thought to be improved collaboration, especially across different teams, and the making of decisions is centralised. SAFe generally works with a Scrum central to the process, but there is a larger sprint which operates across several teams. Each of these teams use smaller sprints.

Benefits of SAFe

Advocates of the SAFe approach argue that this framework allows its users to use agile at scale. It is suggested that SAFe offers an increased level of agility and a more thorough agile implementation. Proponents of the approach argue that while SAFe may not be as effective as putting a pure agile system in place, in fact it does at least offer a starting point for bigger organisations to put in place more of an agile system. It is therefore suggested that SAFe is not really an absolute target, but rather that it may be used to get organisations moving in a direction towards real agility. It provides an opportunity for large organisations to gain some of the benefits of agile, when they otherwise might not be able to. This may be considered benefit enough by some organisations.

Challenges with SAFe

While SAFe appeared at first to offer an excellent solution as a scaled approach, in fact, evidence suggests that it has not delivered the hoped-for benefits. One of the problems with it has been unrealistic expectations within organisations. It is tempting to believe that SAFe can deliver magical results with little energy expended to achieve this. This is not the case. SAFe requires a transformation of mindsets, not just a few days of training. In fact, in 2017 the Association for Project Management found that mindset change is more important than changing methods. As such, SAFe requires fundamental change to organisational activities and behaviour to make it a success. This takes years rather than months to bring about, so it requires significant commitment and effort. It is not a wonder drug that can suddenly deliver tremendous results. In my experience, business leaders do not necessarily appreciate this. Those who believe SAFe is not helpful also argue that no organisation has ever said that it has been hugely beneficial for them. This is problematic.

Thoughts on Adopting Agile SAFe

Many agile experts argue that SAFe should not be adopted as it is not bona fide agile. Further, SAFe has been dubbed “unSAFe” by some of these same individuals. It is felt that SAFe works against one of the fundamental principles of an agile approach, that of focusing on people and their interactions rather than tools and processes. While on paper it might seem that this framework will offer flexibility, it goes against this when it is aimed to implement it from a practical perspective.

On the other hand, it cannot be ignored that agile SAFe may offer some benefits for organisations that want to start along the journey to true agility, and that this framework does offer an important opportunity for larger organisations that might otherwise not be able to make agile work. While SAFe may be a very imperfect solution, it does help with starting to address some of the challenges of project management within larger organisations.

At best however, it is worth noting that agile SAFe is likely to only work in some organisations, and even then, only some of the time. Each organisation will need to consider its own circumstances and the extent to which it can work on transformation towards an agile mindset as an end goal, for this to be of benefit.

For those that do want to play agile SAFe, it is highly recommended to put in place monitoring and measurement of certain goals. After all, any change ought to deliver benefits including some sort of return on investment. It is worth considering metrics that measure customer satisfaction, productivity, quality (fewer defects), cycle time and release time, stabilisation and employee satisfaction to identify if any of these have improved as a result of putting in place agile SAFe. If not, then the program is not worthwhile.

Summary

Agile SAFe has created a lot of controversy in the agile community. While SAFe does have the potential to bring about some change in working towards a scaled agile approach in larger organisations, there are serious concerns that it may be seen as a “wonder drug” and that many organisations do not put the time or effort required into delivering the transformation of mindsets needed to be truly agile. This can lead to SAFe being considered “unSAFe”. Those large organisations that do want to implement SAFe should perhaps view it as an important starting point along the road to eventually becoming truly agile, realising that the journey will take years rather than months. Having in place a system of measurements to ensure that return on investment is achieved through the use of such a program is highly recommended for those organisations that want to play agile SAFe.

Your Agile Might be Fake

Written by Paul Oppong on July 3, 2019. Posted in Articles.

“Agile” is a term commonly used in organisations of all shapes and sizes these days.

When I go into organisations, I hear leaders saying, “We use agile”, yet digging deeper, I find things aren’t quite, well, agile, in fact sometimes not at all. A fake idea of agile implementation is commonplace, and managers say the agile words without really understanding the principles and concepts behind them. This means that the team is not truly agile at all, and not reaping the rewards of being agile either. But what does fake agile look like, and how can this be diagnosed in an organisation?

Symptoms and Signs of “Fake Agile”

There are numerous signs and symptoms that an organisation is not being genuinely agile. One of the most common is perhaps the idea that a team can take the elements of agile that they like and use only these, discarding the rest. People who have implemented this approach will make comments saying that they use agile techniques while then going on to say, “Well, it’s not quite agile, we used what we liked from a few different models.”

Another common challenge is not really understanding the core concepts of agile, while still believing the team is working within them. For example, agile is fast, meetings should be fairly quick, while covering the activities of yesterday and today, and discussing barriers. The idea of a daily Stand-up meeting for instance in a Scrum or Kanban agile implementation is to keep it concise and to the point. Some teams find they are having stand-ups that last multiple hours. This indicates the agile implementation might be what it is meant to be and not really working. It might mean that the meeting probably has too many attendees, and in which case it might be possible to work in smaller groups instead. Alternatively it can mean the team is working in a hierarchical manner, which is not the point of agile.

When a team is truly agile it will continuously deliver value to customers. This is a critical underpinning principle of agile. The reason for introducing this concept to agile, was that in the past, developers would work on a project for months, deliver it to the end customer, and by the time it was delivered, requirements would have moved on, or it would not do quite what the customer needed. This means that there is a need to understand customer needs throughout the development process. This is an idea that agile is built around, and hence the principle of continuously delivering value. This leads to the ability to pinpoint other clear indicators of fake agile. It follows that if teams are not securing feedback from customers regularly, and looking at it quickly, then they are not continuously delivering value to them. Feedback is a regular and integral part of agile. What is more, if no time or money is budgeted for change to the project then the team is probably not agile. This is because continuously providing value will invariably require looking at ways to change the development, so it more closely aligns with customer needs, once feedback is received.

Three Key Questions to Diagnose “Fake Agile”

There are some questions that can be posed to those leading so-called agile programs to determine if they really are embracing agile concepts. You might ask, “Do real users see iterative working version of the product, and if so, how often?” If the answer is no, agile is not in place. It is also a problem if customers only see iterations every few months. This is not agile project management either. The end users should be seeing and feeding back on iterations with regularity.

Another question that you could ask is, “How frequently is feedback from users converted into work activities for teams?” If the answer is never, the team is clearly not agile. If the leader responds that this happens within time frames of less than one month, then it is possible that agile is operating as it should. After all, as we have seen above, agile operating is all about meeting customer requirements by taking on board feedback and incorporating it into the project.

A third key question to ask is about team empowerment. You may ask, “What level of empowerment do team members have? Can they change processes and requirements based on user feedback and on what they learn?” Empowerment of team members is a core principle of agile operating. Leaders that say any answer that includes, “Yes they are empowered but…” are probably not following agile methodology. Any indication of hierarchical, top-down decision making goes against the agile way of working.

Summary

Many business leaders think they are being agile. They also like to say it, because agile is a popular buzz word. That does not mean they actually are agile. Any so-called “agile” approach that just takes the parts of agile the leader likes and ignores the rest is not truly agile. Underlying agile is fast, iterative development, with feedback taken on board along the way, to continuously deliver value to customers. Where an “agile” solution does not do this – beware! It is almost certainly going to be fake agile.

Yet another enquiry to make is whether the whole project operation is agile. This will help pick out those leaders that think they have got the best of both worlds by using some agile principles combined with other more traditional forms of project management because these are more palatable with their idea of control and command. If the answer is no, then the team is not working in an agile manner. In fact, if the answer is “Partly”, this is also still true. When agile teams work in an agile way to start with, and then use bureaucracy later on in the process, this is not agile operating. The only correct answer to this type of question is, “Yes” without any caveats being applied.