By Dennis van der Spoel

With growing concern do I watch practitioners within the agile community bashing anything that is not up their alley. As with any community, there will always be a number of persons who feel that it is their duty to ‘protect’ the community against influences they consider impure. I call those persons “the fundamentalists”. Usually, I just let them be and trust that progressive forces always overcome conservative forces if something is meant to be. It is the positive nature of change. But I cannot stay silent when populism meets conservatism in ever growing numbers. Where conservatives usually have some very strong arguments that require due consideration, populists only have wishful thinking based on a distorted worldview. 

​What I am getting at are a series of publications, of which I will highlight the four that raise the greatest concern because they seem to be well-received by the community. Those publications are:

By: Dennis van der Spoel

​Whether you are using a silo or a value stream approach to portfolio management, strategic alignment remains a major challenge. In the silo-oriented project portfolio management-approach, this is often due to segmentation of budgets and accountabilities. In lean-agile product/project portfolio management this is due to the focus on the short-term value of initiatives. In both cases, impact mapping offers a solution. In silo-based portfolio management, impact mapping helps to align and prioritize all initiatives across the silos. In lean-agile portfolio management, impact mapping helps to discover and communicate the longer-term business value of potential epics. If you would like to learn more about the issues with portfolio management, you might be interested in benefit mapping as well.

By: Dennis van der Spoel

Any company working with more than, say, 80 people on the development of a single product or solution will not manage with just Scrum as a guideline for an agile way of working. Fortunately, several frameworks have been developed to make agile ideas workable in larger companies. Sometimes small concessions have been made to the autonomy of individuals and teams for the sake of coordination. This has led to discussions about what is still agile and which framework should no longer be allowed to wear that predicate. The framework that is most popular and also the most under fire is the Scaled Agile Framework® (SAFe). Is that rightly so?
 
If we look at frameworks such as Nexus, LeSS and especially SAFe, the criticism mainly focuses on the alleged lack of space for people to find their own way of working and the alleged lack of simplicity. Those frameworks have caused this themselves. For example, the SAFe Reference Guide consists of 800 pages, where Scrum fits on just 17 pages.

At first glance, therefore, SAFe seems 40 times more complex than Scrum. But that is not the whole story. It is precisely the lack of 'guidance' that inhibits the adoption of Scrum (and therefore agile) within larger organizations. Scrum does not offer a solution for every context. The idea is that Scrum teams themselves discover an optimal way of working. That works well with a single team. With two or three teams that is often fine too. However, once you really start scaling, cooperation between teams no longer comes naturally. Consultants and coaches, as yours truly, build their entire business model on this issue. But that is not sustainable.
 
Forgive me for the detour that I am about to make in my reasoning. At the end of this article I will come back to the criticism of the most important agile frameworks in general and SAFe in particular.

By: Dennis van der Spoel

Every fall the ceremonies to define the organizational and departmental budgets for next year are the same. Each cost-center creates a spreadsheet of their forecast of next year’s income and expenses. Usually, these include revenues, wages, overhead, IT, and training. About 80 percent of the expenses is earmarked for business as usual. About 20 percent is reserved for planned change initiatives. And the total budget should preferably be within a 5 percent deviation from last year’s budget to avoid intense debate. ​

By: Dennis van der Spoel

​Wie meer met dan 80 mensen aan een product werkt, komt niet weg met alleen Scrum als leidraad voor agile werken. Gelukkig zijn er diverse raamwerken bedacht om het agile gedachtengoed ook werkbaar te maken in grotere bedrijven. Soms worden er kleine concessies gedaan aan de autonomie van individuen omwille van de coördinatie. Dat heeft ertoe geleid dat er discussies zijn over wat nog agile is en welk raamwerk dat predicaat niet meer zou mogen dragen. Het raamwerk dat het populairst is en tevens het meest onder vuur ligt is het Scaled Agile Framework® (SAFe). Is dat terecht?
 
Als we kijken naar raamwerken als Nexus, LeSS en vooral SAFe, dan richt de kritiek zich vooral op het vermeende gebrek aan ruimte voor mensen om hun eigen werkwijze te vinden en op het vermeende gebrek aan simpliciteit. Dat hebben die raamwerken zelf veroorzaakt. Zo bestaat de SAFe Reference Guide uit 800 pagina’s, waar Scrum past op welgeteld 17 kantjes.
 
Op het eerste gezicht is SAFe dus 40 keer complexer dan Scrum. Maar dat is niet het hele verhaal. Juist het gebrek aan ‘guidance’ remt de adoptie van Scrum (en dus agile) door grotere organisaties. Scrum biedt niet overal een oplossing voor. Het idee is dat Scrum teams zelf een optimale manier van werken ontdekken. Met een enkel team gaat dat goed. Met twee of drie teams gaat dat ook vaak prima. Zodra je echt gaat schalen, werkt die samenwerking tussen teams echter niet meer. Daar verdienen adviseurs en coaches als ondergetekende dan weer goed aan, maar dat kan niet de bedoeling zijn.
 
Vergeef mij de omweg die ik nu ga maken in mijn betoog. Aan het eind van dit artikel kom ik terug op de kritiek op de belangrijkste agile raamwerken in het algemeen en SAFe in het bijzonder.