My team introduced Scaled Agile Framework or SAFe and we already started the first iteration. A quick glance at their documentation reminded me of Martin Folwer’s “Agile Industrial Complex”.
I did some more research on what other people on think about it:
Mary Poppendieck@mpoppendieck
I am often asked what I think about scaled agile frameworks. This slide does a good job of summing up my viewpoint, except for the last point. We need more research on how successful large companies coordinate the work of small autonomous teams to achieve larger goals. twitter.com/TotherAlistair…15:37 PM - 11 Dec 2019Alistair Cockburn @TotherAlistairI'm really liking the writing on this slide. I hadn't thought of it that way, good to see. https://t.co/TgkkBjY1fU
Daniel Terhorst-North@tastapod“SAFe is just another word for nothing left to lose”22:12 PM - 13 Oct 2018
See also Daniel Terhorst-North’s in praise of swarming.
Some one even compiled a list of comments on SAFe. Which lead to me video from Alistair Cockburn, which I sum up as follows:
- Yeah, standardize vocabulary 👍,
- but investing into collaboration and your ability to deliver could yield better results.
Finally I stumbled over the following quote from ThoughtWork's Technology Radar Vol. 24 sums, which matches my feeling:
We've come across organizations struggling with SAFe's over-standardized, phase-gated processes. Those processes create friction in the organizational structure and its operating model. It can also promote silos in the organization, preventing platforms from becoming real business capabilities enablers. The top-down control generates waste in the value stream and discourages engineering talent creativity, while limiting autonomy and experimentation in the teams
So why did we introduce SAFe?
We are a young team and we need strategic alignment with company goals. Direction and support is needed to transition our team to do the right things.
But we are only one team, so we for sure miss scale. Some tools might provide good input, but introducing them all at once deprives us from learning. We will not understand what caused positive effects and will be overwhelmed by too many new techniques.
But why does it feel so wrong?
For example I think, it's a good idea to have cycle and a prior week reserved for communication and planing. In my experience predictability is rated too high, but that's for a different article. Nevertheless predicting a long cycle (10 weeks) and forcing the team to predict 5 minor cycle (2 weeks) limits team autonomy, produces overhead and creates a constant environment of pressure. All this with little to gain, since the 10 weeks were already estimated. Maybe the team would have even chosen two weeks sprints.
We can only dedicate about 50% (or even less) for work on features. We have a lot of bugs and operational work. We need to clean up. I don't think that you should separate cleaning up your architecture from your business work. Not separating those, leads to a more aligned cleaning up of technical debt and to culture where quality is built-in, rather than an afterthought.
Introducing a Product Owner to take care of customer interactions and product vision, but leave the developers out of it, seems a bit strange to me. Especially since I experienced communicating to be the major part of software development. There is an ongoing discussion about the Product Owner role (see here), but SAFe's definition seems to match the negative aspects.
So stay safe from SAFe!?
I admit that I made up my mind early. Finding out that https://www.scaledagile.com overwrites the HTML copy event to add a copy right disclaimer, increased my resentment. Maybe this should not be part of the evaluation, but it's a weak indicator that it doesn't fit my view of software development.
I think the fundamentals (e.g. lean, agile, team topologies) used and quoted by SAFe are legit. Reading up on those helps a lot and all of them are aware of context. Having a standardized way to plump all tools together would be great, but we are just not there yet.
Top comments (0)