Paradise Lost: SAFe banned from the Agile Heaven?

The Scaled Agile Framework (SAFe) recently seems to have fallen from grace in the agile community.

Most of us noticed that something went wrong with Agile. The Scaled Agile Framework now gets stigmatized into the role of the traitor of the True Agile Mindset™, it serves as the negative showcase how the original Agile ideas are corrupted by The Enterprise.

I almost get the impression that nowadays every Agile guru has to pick on SAFe, to prove that he stays truly Agile:

 

• Ken Schwaber (one of the two founders of Scrum): unSAFe at any speed

The boys from RUP (Rational Unified Process) are back […] They would be at a waterfall conference, but they are no longer.

A core premise of agile is that the people doing the work are the people who can best figure out how to do it. The job of management is to do anything to help them do so, not suffocate them with SAFe.

 

• David Anderson (Pioneer of Kanban in IT): Kanban - the anti-SAFe for almost a decade already 

This seems awfully similar to Rational Unified Process (RUP) from the 1990s but updated to include Agile practices from the 2000s

 [The SAFe] approach is the antithesis of the Kanban Method!

 

• The IT risk manager: Two Legs Good

I did not encounter a single person who had successfully implemented SAFE.

Someone just shot the Agile brand in the back of the head.

 

• Scrumorakel.de: A critical View on SAFe

This means that we are back to the good old days where there was a chasm between product management and development rather than working hand-in-hand as it is intended in Scrum.

Teams are not allowed to self-organize their alignment and predictability is the goal rather than maximization of value

SAFe accepts the status quo in many enterprises and distinguishes between Product Owner and Product Management. [] This does not help collaboration but is a tayloristic division-of-labor approach.

People don’t have to change with SAFe – they can just go on as they always did and call themselves Agile now.

SAFe believes that the world is good as it is [...] so the status quo has to be accommodated. Agile believes that the world is not a good place (at least for people working in software development) and should be improved. The status quo – especially the tayloristic thinking - has to be changed. This doesn’t fit together. SAFe isn’t Agile.

 

Update 2014-03-03:

• Ron Jeffries (one of the founders of Extreme Programming): SAFe – Good But Not Good Enough

SAFe wraps those ideas [of Lean and Agile] in a package that is designed — intentionally in my opinion — to appeal to today’s managers and executives who do not understand Agile, but who know they have a problem to which Agile may be the solution.
If everyone in the organization were to read the fine print in SAFe, then the organization might very slowly evolve to the level of effectiveness that real Agile provides. That’s not going to happen. Managers and executives are too busy to read the fine print. They are too busy doing their job to study how to do their job. They will too easily fall into old patterns of management behavior, and when they do, SAFe will be installed in a fashion that won’t just fail to support Agile, but that will suppress it.

 SAFe assumes that you need a big “solution” and then provides it. More than likely you don’t need a big solution. 

/ch/open Workshop Tage: JavaScript Bootcamp for Java Developers

Last week Marc and I held a workshop at the /ch/open Workshoptage:

JavaScript for Real Developers: A Survival-Bootcamp

 

The goal of the full-day workshop was to give typical Java enterprise developers an overview over the current landscape and ecosystem of JavaScript development. Typical undifferentiated prejudices that exist towards JavaScript should be refuted (or confirmed with facts).

The topic we focused on were:

• JavaScript as a language (concepts, patterns, parallels to other OO languages …)
• jQuery as a de-facto standard library for client-side JavaScript development
• The JavaScript toolchain (setting up a professional development and build toolchain)
• Integration of a JavaScript project into a Java project (using Maven and/or Node.js)
• Modern Web Architectures (JavaScript for the frontend, Java for the backend)
• Client Side MVC

The exercises and demos can be found in our Github repository.

I had the idea for this workshop some time ago, when I was working in several enterprise web projects, and I realised that JavaScript is getting more and more important for any kind of (web) projects, but typical enterprise developers (like me) try to avoid the topic at any price. Usually all abstractions (like JSF or GWT) break at some point and JavaScript leaks through. But then it is mostly too late to start dealing with JavaScript professionally, because the project has already progressed into a phase where it's not possible to lay the necessary groundwork for serious JavaScript development. 

The workshop seemed to hit a nerve in the current Java enterprise community: It was fully booked within a few days after the program for the workshop days was published (because there are hands-on exercises in the workshop, we limited the maximal number of attendees to 20).

Thanks to the organisers of the workshop days, we could schedule the workshop a second time at the same workshop days. Also this second workshop was booked out within several days.

I enjoyed the two days of teaching very much and working with Marc was great fun. From both workshops we also got quite good feedback (the official feedback is published here), so we guess that it was also a good experience for the attendees.

I hope there will be the possibility to repeat the workshops in the future. We are open for any suggestions...