SAFe: Scaled Agile Framework – or is it?

Last week I’ve had the pleasure of taking part in a Leading and Implementing SAFe course. During this four-day course I would be introduced to the Scaled Agile Framework, learn how to implement it, and learn how to share it with others.

To summarize the outcome of course in just one line: it sucked.

How is SAFe a framework?

To me, a framework is a light-weight set of boundaries within which there is a lot freedom to do as one sees fit. If you see the SAFe Big Picture you’ll understand my initial skepticism at the term ‘framework’. Nonetheless, I was looking forward to having my skepticism rebuked and to learn how to see and use SAFe as a framework. All this in order to be able to better help organizations that need scaling scale.

Whether organizations actually need scaling or a scaling framework is an interesting discussion. I think that if you need scaling you should first look at your products and your architecture. Self-organizing teams with the help of a clear vision and a good architecture can get a long way.

Unfortunately, the way I interpreted the way SAFe was put down this week was as a methodology. These are small selection of some of the concerns I have after having taken the course.

Let’s start with the roles: Release Train Engineer, our “facilitating” Super Scrum Master; Release Management, the Super Product Owner of the Release Train; System Architect, who together with the RTE and PM act like the steering committee of the Release Train (also, drawn above the teams, like hierarchically superior). All set and ready to go, all required.

The format in which work should be sent to the teams is also set for you: User Stories coming from Features or Enablers, coming from Epics; Enablers that are used for work supporting other User Stories or Features; and if you open the Value Stream level there’s something called Capabilities as well. Additionally, there’s a selection of templates available for most of these items to fill out. All having been done during the course and available from ScaledAgile’s website for your day-to-day use.

My biggest concern, however, was the ‘Agile Release Train’. Calling a Release Train ‘Agile’ when the recommended time-box is 10 weeks is beyond me. Sure, teams could release more frequently (and I quote, because of “individuals and interactions over processes and tools, and stuff”). But once you’ve seen the monstrous PI planning board with all its dependencies between teams you may wonder how that could ever happen.

In other words: my skepticism was not only not rebuked, it was definitely reaffirmed and has even worsened.

SAFe the way I would have liked to see it

If SAFe really is a framework, I would have loved to see it like that. Perhaps with a various complementary practices that would make it work for specific scenarios, in which alternatives to certain practices would have also been discussed.

The power of SAFe to me is keeping synchronized across teams and Release Trains in a larger organization, in which each release train is an independent part of the organization focusing on a specific product or value stream. There would be direct contact between the customer(s) and the teams in each release train, where each release train would have their own tools and practices to handle how work comes in. Whatever works for the teams should be the practice, not whatever someone else tells them to.

I love the end-of-increment Inspect and Adapt opportunity, but without all the practices that SAFe introduces and without the compulsory interval of 8 to 12 weeks. It’s great to inspect and adapt with a bunch of teams working on the same product or value stream, serving the same customers. Just like the PI planning: a high-level “planning” event which can be used to identify dependencies and remove them on the spot. I’d call it PI refinement rather than planning and I would never give commitment to finishing a list of work or reaching certain objectives for the next 10 weeks. I’d be doing my customer a disservice in nailing down what we’re going to do for 10 weeks rather than giving them the opportunity to take a different course at a shorter interval. But I like the synchronization nonetheless.

I’d have loved to see SAFe as an enabler for Agile at scale, because that is what organizations need. Practices come from experience and that’s where coaches come in: to help an organization find a practice that works from them, in which there is multiple practices to be compared. That is what SAFe (or any other scaling framework) should enable.


Looking at this constructively, I see SAFe as an intermediary step for very large and very traditional organizations towards true agility. I think it’s loads better than sticking to a waterfall-approach and if an organization implements SAFe the way I heard it, they’d be far better off.

To reach true agility you’d need to take a lot of additional steps. Mostly you’d need to experiment, see what works for your organization, your teams, keep inspecting and adapting and changing things if they make more sense. And to me, that’s the danger of a methodology over a framework: it makes things fixed rather than up for change. Whereas a framework should give you those boundaries in which your organization can shine.

A response to ‘Agile does NOT work!’

I recently read a blog post on LinkedIn from Oleg Vishnepolsky from DailyMail Online and stating that ‘Agile does not work’ and ‘And never did’. The blog contains some interesting statements and asks for responses. Well, here is one:

1) Short-term thinking that results from following short iterations and daily stand-ups

Where does this short-term thinking take place? Who does it? What have you tried to change that?

I think you do want your development teams focusing more on the short term when it comes to what value they should deliver rather than on the long term. That doesn’t mean the long term isn’t important though, and being agile doesn’t mean you should forget the long term either. It means you should use the frameworks, tools, and methodologies that allow you to respond to an ever-changing world.

In fact, long-term is quite important in order to be agile. You need to focus on quality and prevent technical debt. You should invest in test automation. You should focus on creating the right amount of documentation (be it code documentation, infrastructure as code or something else). You should invest in gathering and sharing knowledge. Those are all examples of the long-term thinking required.

If someone doesn’t think about these things, I’d say they’re doing themselves and their company a disservice. You should help them understand why these things are so important, especially when you want to be agile, and help them keep focus on them as well.

2) Architecture that often times can not be deployed piecemeal

What kind of architecture are you talking about? What challenges are you facing when trying to deploy your architecture? What’s the relation of this to being agile?

One could argue that delivery and deployment aren’t the same thing. I’ve seen cases where entire work-flow systems were being replaced and in certain cases that wasn’t being done one piece at a time, simply because it was either too costly or too complex. That doesn’t mean those teams didn’t work iteratively and didn’t go get feedback as soon as possible. It just meant the final deployment to production was postponed to such time where the work-flow could be implemented as a whole.

I do believe that there’s only a certain number of situations in which piecemeal deployments, for software, are extremely hard or impossible. But in order to do piecemeal deployments your application or architecture does need to support it. In most cases I’ve seen, piecemeal deployment is hard because the architecture isn’t right in the first place.

3) Complex infrastructure in production that is supposedly continuously getting deployed over. If you are Facebook, you can afford automation. Can you ?

What kind of deployments are you talking about and what is blocking you from doing them continuously? What makes your infrastructure so complex you can’t deploy continuously? It could be your infrastructure isn’t ready for continuous deployments yet.

But yes, I believe every company can afford automation. Because every company that I’ve seen that doesn’t invest in it pays the price in the long term. They struggle rather than grow and have to invest in automation along the road anyway, but at an increased cost.

I would like to note that deployment should be a business decision. While you’d want your bug fixes out ASAP, I could imagine not wanting to change your functionality continuously. It’s perfectly legitimate to do some deployments every X weeks and introduce them properly to your users. I’ve had a company offer customers the option of either continuous deployments or one every 6 months. Those that chose the 6 months were still involved in the development effort and gave feedback frequently, but they only got the changes after they had prepared their staff for it.

4) Business expectations that they do not need to give you any requirements and that they can change their mind at any time.

I’m especially curious where this one comes from? How are development teams expected to deliver value without having any requirements? How are they expected to focus when they can change direction from second to second? How could the business be expected to be less involved when the development effort needs them to be more involved?

In my opinion the business has the responsibility to talk to development teams and explore the requirements together. Naturally they can change their mind at any time, but a proper preparation may prevent changes of mind down the road. Because changes of mind are often the result of questions being asked too late or too little, as new insights lead to new solutions. If you don’t have a transparent situation to begin with, how are you expected to inspect and adapt to that situation properly?


Yes, Agile is being used as a buzz-word and yes, there’s probably some Agile Coaches whom are in it for the money rather than to achieve true agility as meant by the Agile Manifesto. That doesn’t mean agile isn’t good or dead or whatever. Agile isn’t easy. Being agile isn’t easy. I do believe it’s the right option and the right way forward, but it takes time and continuous investment in order to be and remain agile.

A note to the author of the original blog post: my questions are genuine and I’d be more than happy to discuss these topics with you.

WebHostScene is live!

WebHostScene is live! It’s a website I started recently when I found myself needing to write a tutorial and to write about web hosting. There’s not too many content on it yet but that will definitely change over time.

Having WebHostScene means I’ll obviously spend less time blogging here. No worries though for those few of you that do like to read my occasional ramblings. They will still appear ever now and then!

For now, please enjoy WebHostScene and I’d love to get your feedback on it!

Merry Christmas

I just noticed that ever since I’ve started looking for a new job in October 2014 I haven’t posted something on my own blog anymore. While I could go into all the reasons for this, I’d rather share with you what my plans are with regards to my own little website (especially put in the context of me having left my position as LowEndBox/LowEndTalk community leader).

So, here’s an overview of some of my plans:

  • Blog more often. Yes, really.
  • Build a “database” of quality yet easy to understand tutorials.
  • Blog about cars. I love cars!

Nothing is set in stone, but I’m pretty sure I can live up to this little plan and hopefully be of value to some of my visitors!

Merry Christmas!

Some unexpected downtime

Over the past few weeks, my website has been badly reachable. Apparently, I have pissed someone off by banning him from a forum I manage: LowEndTalk ( As a result, he has been pounding my IPv4 address with attacks resulting in the IPv4 being permanently null-routed. I’ve now moved my website to a VPS with OVH where it benefits from their standard DDoS protection. I hope this will prevent any further attacks from causing downtime.

A new actual blog post will be up soon.

Base16: proper theming of vim, Gnome Terminal, Sublime Text, Cygwin and more

As a DevOps Engineer, I use several applications on a daily basis, on different operating systems. The ones I use most are vim, Gnome Terminal, Sublime Text, and Cygwin. For a long time, I’ve been having different themes on these applications and frankly, it was driving me crazy. Not only did my eyes need to get used to a different theme all the time; even while using the same theme on some of these applications there were still minor differences in appearance, as none of the themes were identical for all these applications. Being lazy and not willing to fix this myself by designing all the themes by hand, I went to look for some proper ones that could be used in all these applications.

I’ve had a bit of a hit-and-miss relationship with Solarized over the past few years, so I wasn’t necessarily looking for that. Gnome Terminal (or Cygwin for that matter) has always been a bit problematic with Solarized, as the colors weren’t always perfect (especially in htop). With Gnome Terminal being the more problematic application theme availability-wise, I decided to use that applications as a basis for my search. After doing some duckduckgoing (I say: word of the year 2014) for nice themes, I found the base16 project.

Enter the party zone

I was like a kid in a candy store! This project does not only contain quote some themes that have been specified properly; it also has them for a wide range of applications. On top of that, there is a project called base16-builder. This project contains all the color schemes of all the themes included in the bas16 project and lets you generate theme files for a long list of applications. So even if the templates aren’t in the base16 project, you can either generate them with base16-builder or add the theme templates yourself and then generate them!

Right now, I am still impressed with the amount of different color schemes the project includes and how properly they have been specified. It even includes a version of Solarized that doesn’t hurt my eyes in htop. But frankly, due to what’s available in the project, I haven’t been using Solarized anymore. I’m currently hung up on Base16 Default Dark, which I now use as my default theme for all the applications I mentioned before.

Give it a shot and give back

Everybody should try out these themes, as the project has something for everone. If you find a theme template that isn’t complete or not present yet, please add it to base16-builder and add a pull request in GitHub.  The more people contribute, the better this project will be.

Switching hosts – May 2014

Part of the reason for me to start blogging again was to try out a variety of hosts (as in: VPS providers) and share my experiences with them. The first month or so this blog was hosted on a VPS with GreenValueHost (GVH), a really cheap one I may add. After GVH had been bashed and ridiculed at, I thought: let’s try out these guys. The VPS cost only $8/year, so the risk was really limited.

Although the machine felt snappy at first, after a week or so I experienced the occasional lag (as in: really slow disk performance). IPv6 connectivity never worked properly, despite me sending in a ticket and providing plenty of information on what the actual problem was. I me experience, the support I received wasn’t the best. When you send the output of an MTR run with 250 cycles and over 90% of the packages gets dropped at the gateway, I think a provider should be able to figure out where the problem is. Then again, I was paying $8/year for this machine, so I didn’t expect any support as all. The fact that they did respond is good, though that didn’t solve my problem. But the thing that made me move elsewhere was the fact that when GVH’s site was under a DDoS attack, the staff simply went to bed and only came back to look at it the following morning. I don’t expect people to give my any support for a $8/year VPS, but I do expect a company’s “CEO” to at least care a bit.

So, after that month or so, I moved this site to my Xen-PV VPS in Pune, India. I got this machine from Prometeus [affiliate link] when I purchased a load of iwStack credits in December. The performance of the machine is just fine; in fact, it performs really, really great. It being in India does provide a challenge when working on the machine, though. It’s not really close to where I live, so working on the CLI has some minor lag. That’s not a real issue though, as I only need to SSH into the machine occasionally!

For now, India it is. It gives me some time to think about where to move my blog next! Any suggestions are welcome, of course!

The major problem with SolusVM’s IPv6 implementation

SolusVM, the well-known VPS control panel, has supported IPv6 for a couple of years now. There has been one major problem, though: it’s terrible implementation and the consequences of that.

The implementation

SolusVM assigns IPv6 addresses to users by randomly handing out individual IPv6 addresses out of a larger range. Not an actual block; SolusVM requires you to give a set range of addresses from which to generate random ones. This allows the SolusVM Administrator or Reseller to assign up to 200 individual random addresses to an actual VPS.

IPv6 wasn’t designed for individual addresses, though. It was designed to give end users a block of addresses, the smallest one being a /64. The reason behind this being that the last 64 bits of the 128-bit IPv6 address are used as the interface identifier. It defines a unique interface inside a network, a subnet. This ensures that wherever an interface is, the last 64 bits should never have to change, only the first 64 bits, meaning an address inside a network is theoretically always available. This makes NAT completely unnecessary. More importantly, though, the last 64 bits are used for several IPv6 features: Neighbor Discovery (ND), Stateless Address Autoconfiguration (SLAAC), privacy extensions, and others. Not having a /64 assigned prevents people from using those features.

The problem

With SolusVM not assigning /64 blocks to end users they not only not get all the features of IPv6. They get a free problem with it: incompatibility with those that do use those features.

The best example of this is Google Mail. When you have VPS backed by SolusVM (no matter the virtualization technology) and with statically assigned random IPv6 addresses, you cannot send e-mail to Google Mail addresses using IPv6! Why not? Because the addresses you have come from a /64 (or worse, even smaller) and all your friendly neighbors who have a VPS with IPv6 addresses from that same block, will probably also try sending mail. Google Mail just looks at the /64 when receiving mail via IPv6 and notices that there is a lot of activity coming from that block. No wonder, because there could literally be hundreds of servers with an address from that block of IPv6 addresses. So, Google Mail considers it SPAM and starts blocking every address from that entire range. The result: you either have to disable IPv6 on mail sent to Google or you cannot send mail to Google using IPv6 (your mail server determines which address to use, IPv4 or IPv6).

And that’s just one example…

The solution

SolusVM should start implementing IPv6 the way it should have been years ago: giving users the option to assign a /64 to their VPS and then enable addresses from that /64 to the VPS (so they are actually available in the VPS). This way you don’t have to assign millions of unused addresses to the server and you give the users an address block that is in accordance with IPv6’s design and implementation. It will not only solve the Google Mail problem, but also other (and potentially future) problems.

Hello world!

Welcome to my blog! It’s been a while. I’ve decided to write blog posts regularly again, either long or short, on a variety of topics. This website will also contain some more information about who I am and what I do.

For now, this will have to as the first post.

Hello world!

© 2016

Theme by Anders NorénUp ↑