A Framework is just that - a Frame

Webster says about framework: a basic conceptional structure (as of ideas), or a skeletal, openwork, or structural frame.

If that is the proper definition of a framework, why do we then again and again see examples of frameworks being read as were they the universal answer to everything, a bible of sorts, and taken 100% literally? no room for additions, modifications etc?   The following focuses on SAFe since that is the framework in my focus these days, but I am pretty sure I could repeat this article for many frameworks - no critical thinking skills in used when applied...

Currently I am a bit frustrated when I see the way SAFe is implemented in many companies. The model is implemented literaly as the website says, professional change agents support the implementation and transformation and it is done exactly "by the book". But that book doesn't cover everything you need! remember .... it's a framework! you need to add/modfity/remove to make it work in your context! You might have things specifically for your company that needs to be handled - there are no such thing as a "turnkey solution" to a way of working, no one size fits all.

One of my favorite examples of that (since I am a tester) is "we need to really cut to the bone and only do the essential implementation - so we will not address testing in our implementation" (yep seen that several times so far). Another version could be; the framework doesn't say anything about the test manager role, so we will fire all the test managers (yep also seen that several times).

But implementing the test part in retrospect is really not the way to do it! Implementing supporting test activities should be a crucial part of doing a good agile transformation - no matter whether you choose to scale or not - remember the principle; "Working software is only measure of progress". And there is not a universal solution on how to do this, CONTEXT matters! If you have an extremely complex system landscape and a train covers many systems and large end-to-end workflows to support the business, then you need a very different approach to test than if you have a train covered by a more simple landscape and fewer systems and workflows. That is why we have this thing called a test strategy...

If you take an existing system of systems that has lived for a long time... and are not supported by a proper automated regression test suite, and doesn't have a solid unit test suite - then CI is not the only answer. Yes you need to prioritize getting automation started , but you also need to find a way to handle all the manual regression test.... again; test strategy.

If your development team doesn't have any testing competences (yes test competences is actually a thing, it is not something random people can do if you want it done well :-) ) then you need to find out how to give them those competences, or add the competences in the form of a tester who can then teach and coach the rest of the team.... need to say it again; test strategy.

And who is going to:

• identify and implement the test approach across the train
• Support and coordinate testing across the train
• Ensure implementation of test automation suite?
• Coach and teach teams in testing?
• Ensure sufficient focus on non-functional testing across the train
• Ensure that final acceptance is done if you have a contract with a customer who requires this?
• and many other test "things" that doesn't just happen by themselves?

The System Architect? the Release Train Engineer?The Product Manager? the Teams?- well if they have the time and competences then yes that is a great solution. But often they are slightly busy even without those tasks, and not really into all that testing stuff, so that is maybe not the best solution. (I am NOT saying that the teams shouldn't take responsibility of the quality of their deliveries - they should! but there are MORE to quality than just what happens for the individual user story and feature.)

When I had my SAFe SPC training I asked that question, and the trainers recognized that the framework didn't say much about testing, and nothing about who could actually take the responsibility of this. They suggested that maybe the System Architect is not just one person, maybe it is a small team of architects with different focuses... one of them a Test Architect.

Or maybe you have a test manager on  your train - you can call him test master, test lead, quality coach - you can call him/her whatever you want (if you don't like the manager word) but have someone who focuses on the quality for the train as a whole, who can focus on the quality of the quality for the whole value stream! someone who can support the teams in improving their quality, and someone who can support the team in owning the responsibility for the quality of what they create.

And there are other examples of things not covered than just stuff about testing. People management, company specific requirements for reporting etc. The thing is; it is just a framework - a skeleton.

If you build a house it is not enough to put up a skeleton - the frame, you need a foundation, insulation, interior walls, exterior walls, heating, windows and doors. And you don't wait until the end with doing the insulation that will keep you warm, you do it as a part of creating the foundation and walls of the house, that is the most practical and effecient way to do it.