Wednesday, 17 September 2014

Scaled Agile Framework is not Agile (with a speck of irony)

Does the old and good "Working software over comprehensive documentation" still ring a bell? Do you recall the very first time when you and your team mates were showing proudly an end-to-end working piece of a software product on the scrum demo? Do you remember how good it felt back then just opposed to skimming through a dreary project status update email? If so then stay tuned because scaled agile framework does not share the same view and they are on their way to take over a sizable piece of the market.
One of the greatest french philosophers Jacques Derrida argued that every thinking domain posses a kernel, a central meaning around which all other concepts are built. Try to move the kernel and you will shake the intrinsic structure of the domain bringing about its own destruction eventually. In the aftermath of those actions a brand new domain will appear containing the same set of concepts but with different relative meaning.
SAFe's kernel contains many concepts and one of them is "system". Even though SAFe touts "product" as playing pivotal role in their framework it is "system" which when removed tears SAFe apart. Therefore it's a system-level software incrementation and thus not product incrementation what's being delivered by the agile team in SAFe. But systems in the modern enterprise tend to be large and complex, concludes SAFe profoundly. As a result hundreds of people may work on a one single system simultaneously. Here we get a serious scaling issue though which SAFe resolves by means of handing over all integration related concerns to the higher layer. System integration team and component integration team come than handy ensuring that all parts of system-level incrementation work together. Consequently there is a need for infamous hardening sprints, but of course that's an option only. On the demo day there are two sort demos: team's demo handled per agile team and system demo where stakeholders and product people are present with (as in every decent meeting of high-class representatives) developers being absent.
Agile manifesto doesn't mention product in its core values at all. Instead it says something about interactions, working software and adaptability to changes. However just a short look on works of people who shaped agile movement in its infancy sheds a new light on the matter. Scrum for example, origins from the article "The new new product development game" by Hirotaka Takeuchi and Ikujiro Nonaka. The sprint goal in Scrum is to deliver product incrementation as written in "Agile Software Development in Scrum" by Ken Schwaber and Mike Beedle. Last but not least there is product backlog and not system or software-piece backlog in scrum. Just a short read of Mike Cohn's "User Stories Applied" learns that an user story must specify a tangible goal related to the product and thus not system needs. Additionally SAFe claims to be inspired by Lean so I've spent hours to find system orientation in Mary and Tom Poppendieck's books and guess what I've seen product everywhere and system in technical context only.
So what's wrong with swapping product with system? Both Agile and Lean stress for an active collaboration between product people and teams in order to make sure that what's in the brains of the former ones find place in the brains of the latter ones. Otherwise the risk of wrong technical assumptions (the technical architecture foundations does not reflect product evolving strategy), delivering mistaken requirements or wrongly planned product releases raises significantly high and can't be neglected. And that's precisely what SAFe tries to reintroduce in our landscape. Detachment and alienation of development teams from what the product is about. That's why teams make increments of system. That's why all those system parts are integrated together outside team context and results are discussed on the product managers and key stakeholders meeting. Does this sound familiar? I bet so.
In the best case scenario SAFe might be a staged delivery framework as suggested by Johanna Rothman. However, one may argue that SAFe is really a hidden waterfall system with long waterfall iteration on the system level and teams residing one level beneath and caring out technical details (just as Prince2 teams do and who says Prince2 is agile?).
The sheer scale of large systems is not an obstacle for agile software development. There are great pure agile ways of doing that as described by Bas Vodde and Craig Larman or Johanna Rothman to name just two of them. SAFe is not how Google deals with the topic of how to organise work between development and product. Just read "How Google tests software" and you can't help the feeling that they have done it differently.

That being said I don't claim that everyone should use agile. No, I'm very far from stating that. SAFe may fit perfectly for some organisations and that's great news. It's just this deep belief that different things should be named as different and this feeling of being proud on the demo seeing working piece of a product what inspired me to write this post.

1 comment:

  1. I've got interesting conversation on this subject with one of SAFe supporters which is to be found here: