3 Problems In A Quality Assurance Playlist In The Spotify Model Of Scaled Agile
3 Problems In A Quality Assurance Playlist In The Spotify Model Of Scaled Agile
The Spotify model of scaled agile methodology has a cult following in the corporate world.
I understand that the aim of following such an organizational structure is to improve collaboration, and transparency and bring about an autonomous delivery of new releases in a product across teams.
As a Chapter Lead working within a Quality Assurance Team, I failed to see any of these benefits.
Organizations clearly understood that such structure cannot be lifted as is, it needs to be altered as per the needs and personnel in an organization. They did exactly that and made it worse.
The good parts still exist:
-
Collaborative
-
Transparent
-
Autonomous
-
Less Formal
The emphasis on the community over structure is evident but not effective.
I am looking at it from a point of view of one specific layer of a software development process, the Quality Assurance and/or Testing. The view is an obscure mess of unbaked releases that hamper the overall product. A fog of a failing system.
A Quality Assurance Team has to test from the point of view of end-user keeping the end product in mind.
Let’s have a high-level look at the 3 problems for QA-
-
The Squads in a Spotify model work in an autonomous mode delivering a small chunk of a product. To add to it, if a squad does not have an overlying Tribe to align these small chunks, the end goal of a Quality Assurance Team is never met.
-
The personnel in a squad and a chapter with different objectives do not align with a common goal and thus, the benefit of collaboration quickly loses its effectiveness to a lack of accountability towards the end product.
-
The core belief about transparency and autonomy do not go well together . The system quickly fails when two autonomous teams have to collaborate for the greater good of the product. A QA suffers. The Spotify Engineering Culture is a great concept for personal growth. It also works to provide greater autonomy in theory. If I look at it from a Quality Assurance perspective, it creates more problems and diverts a Quality Engineer away from the end goal.
Read this post and more on my Typeshare Social Blog
← Back to essays