Over the past year, I’ve trained several teams and organizations on SAFe® concepts and practices. I will be writing a series of articles that outline the lessons learned, common misconceptions, gaps and anti-patterns I’ve observed throughout these various engagements


One of the great aspects of training and consulting is the opportunity to be exposed to a large number of organizational cultures, practices and implementations in a very short period of time. My past year as a SAFe® trainer and consultant has found me engaged with hardware companies, software companies, manufacturing, payment processors, healthcare, large system integrator, Fortune 100’s and even a multi-national Bio-Pharmaceutical.

Each has it’s own set of challenges and peculiarities, but they also have some interesting similarities that run a vein through all their SAFe® journeys.

One of the most pronounced common problems I’ve observed is a lack of focus on the technical practices of the development teams. I’ve seen numerous cases where the teams are assumed to be well versed in Agile Software Engineering practices – as if developers, testers and even architects somehow are imbibed with the skill set to design, build, test and deploy agile software out of the womb.

Agile Software Engineering, as a discipline, is not often (like, Never) part of Computer Science or Information Technology degree programs. Due to the overwhelming majority of software “in the wild” still relying on waterfall methodology, unless a developer, tester or architect has had the good fortune of being part of a WELL IMPLEMENTED agile workplace – he/she will not have the agile design, development and technical skills necessary to achieve success in a Scaled Agile framework like SAFe®.

During one of my first engagements with a development team who worked for a large insurance company, some team members perceived the term “Agile” as marketing hype. They had the misfortune of being in “Agile in name only” environments and didn’t see the benefit in short test, code, delivery, learning cycles. They viewed daily stand ups and other ceremonies as wasteful meetings that took away precious coding time.

Ultimately, it took the fact that I had almost 2 decades of developing, designing and deploying enterprise software to convince the team that learning and practicing Agile Software Engineering would yield tremendous benefit. Their reaction, however, was not surprising to me. IF teams have not had the good fortune of working in a GOOD/EXCELLENT Agile environment, where do we expect them to acquire the necessary skills to function in one?


How do we expect Agile Teams (developers, testers and even architects) to acquire the correct Agile Software Engineering knowledge and practices necessary to succeed in a SAFe® environment?

Towards that end, Scaled Agile, Inc. has developed a course and certification aptly called Agile Software Engineering (ASE). I was one of the first trainers to get enabled for this course, as I saw it fill a glaring gap in many organizations’ agile transformation journeys.

As the months have gone by since the inception of this course, however, I’ve observed it to be one of the least offered and taken courses in the SAFe® curriculum. I chalk that up to a couple of reasons – the primary one being that I think most SAFe® trainers, consultants and advocates come from a management pedigree rather than a development one.

I don’t think many SAFe® advocates really understand the drastic gap that exists in the knowledge and practice of Agile Software Engineering.

Modern software design and development practices such as Extreme Programming (XP), Behavior Driven Development (BDD), Test Driven Development (TDD), Domain Driven Design (DDD) are not commonly understood beyond terms and buzzwords… and more likely than not, have never been put into practice appropriately. Their implementation and realization of continuous value delivery and elevated built-in quality in software solutions cannot be realized by teams that have not been properly trained in these behaviors and practices.

If organizations understood how vital this knowledge is, and how quickly their development teams could realize huge

gains in productivity, quality and agility by learning and practicing correct Agile Software Engineering, they would be clamoring for the ASE training and certification.

Having almost 2 decades in software, I can firmly say that leading your flock of developers, testers, architects (and even Scrum Masters and Product Owners) with solid Agile Software Engineering practices will accelerate and enhance your SAFe® transformation journey.


Achieving this is one of the lowest hanging fruit in terms of Scaled Agile Success.

Ultimately, for those of us who understand that the Agile Teams (developers and testers, Scrum Masters and Product Owners) is where the “work” is done – we have to advocate for the learning and implementation of Agile Software Engineering. As 2020 approaches, there is a huge opportunity to highlight this need to organizations on their SAFe® journey.