In response to an interwebs blog… “The SAFe® System Team is an Anti-Pattern”
No, it isn’t actually. Let us explore why.
The blog post includes some analysis that clearly misses the point that Dean makes with regards to Systems Teams in the SAFe®.
We could consider the “ART” construct in SAFe® is a complex adaptive system (CAS) in of itself in some ways. But the intent is still to reduce complexity and improve business outcomes in a social construct with feedback loops. In this, the construct is quite effective. The goal should still be a simple adaptive system.
From Scaled Agile®:
The System Team is a specialized Agile Team that assists in building and using the Agile development environment, including Continuous Integration, test automation, and Continuous Deployment. The System Team supports the integration of assets from Agile teams, performs end-to-end Solution testing where necessary, and assists with deployment and release.
Read more at: http://www.scaledagileframework.com/system-team/
Copyright © 2010-2017 Scaled Agile, Inc.In an ideal SAFe® implementation the “Systems Team(s)” are part of (baked-in) the team of teams (Agile Release Train [ART]) and self-organized around a DEVOPS mindset and mechanics (see the SAFe® CALMR approach). An ART should be cross-domain capable (aligned with the strategy of the product/organization) consisting of domain purposed teams that are themselves cross-functional. For many organizations, this is a giant leap in structure, HR, and policy & procedures. None-the-less, this DEVOPS concept is the best known best practice for many IT/IS/Software [enterprise scale] shops struggling to remove dependencies and destroy the massive inefficiency of silos (that also destroy morale).
If you can’t do true DEVOPS then at least allow the people who do the work to self-organize into domain purposed Systems Teams in the ART. Enterprises usually have enough of these type of resources to make it happen easily. Remember the anti-pattern of fractional assignment. Don’t move the people around fractionally. Always allow people to self-organize at 100% allocation to a team. In fact, it is a bad move to push people around to the work in general when there is complexity and uncertainty in your business. Let the work flow to, around, and from the teams of teams.
Don’t blame the guidance for poor implementation, poor coaching, or toxic players.
Other Thoughts
A scarcity of resources or strategy can result in systems teams being “on the spanning pallette” meaning they support the entire portfolio in a SAFe® implementation (but are not specified in an ART). I actually hope that in the next version of SAFe, the methodologists and fellows clear up the confusion about systems teams by moving them completely off of the spanning palette and onto the program level. The remaining scarce resources actually fit more logically into “Shared Services” in the SAFe construct.
Shared Services represents the specialty roles, people, and services that are necessary for the success of an Agile Release Train (ART) or Solution Train but that cannot be dedicated full-time.
Read more at: http://www.scaledagileframework.com/shared-services/
Copyright © 2010-2017 Scaled Agile, Inc.It is interesting to get into discussions about tribes, chapters, guilds, and squads (spotify). The idea of formations from OrgMindset is even more interesting as a concept with SAFe as a more fluid and dynamic approach at enterprise scale.
Don’t let your biases and assumptions get the best of you
There will always be anti-patterns/fragile potential if the principles and value systems proposed are not in play in the social and cultural construct. Systems Thinking must apply too.
References
Leffingwell, Dean, and Donald G. Reinertsen. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2012.
Leffingwell, Dean. “Scaled Agile Framework – SAFe for Lean Enterprises.” Scaled Agile Framework, Scaled Agile, Inc., Jan. 2018, http://www.scaledagileframework.com/.
Kniberg, Henrik. “Spotify Engineering Culture (Part 1).” Labs, Spotify, 20 Sept. 2014, labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/.
errata: Tevanlinna, Antii. “The SAFe System Team Is an Anti-Pattern.” Anttitevanlinna’s Blog, 18 May 2017, anttitevanlinna.wordpress.com/2015/03/05/the-safe-system-team-is-an-anti-pattern/.
I’ve watched by a few Safe-like large-scale agile endeavors. I’ve personally been “in the system team” for a period of time. I’ve never seen it work optimally. The idea is logical, but it just doesn’t seem to work. Let me tell you why. In case you don’t know what I’m referring to visit the official description
The root of the problem seems to be the classical system pattern of the Tragedy of the Commons.
The tragedy of the commons is an economic theory by Garrett Hardin, which states that individuals acting independently and rationally according to each’s self-interest behave contrary to the best interests of the whole group by depleting some common resource.
The tragedy of the commons manifests in SAFe and any multi-team endeavor in the common resources, as in any system. A long while back I tweeted the following:
- #tragedyofthecommons in #multiteamagile: Poor system-level test automation
- #tragedyofthecommons in…
View original post 261 more words
blogagility.com 