Dennis van der Spoel Consulting
  • About
    • English >
      • Introduction
      • What we stand for
      • Where we thrive
      • What we offer
      • Where we come from
    • Nederlands >
      • Introductie
      • Waar wij voor staan
      • Waar we gedijen
      • Onze propositie
      • Onze wortels
  • Training & Events
    • Agile @ Scale
    • SAFe
    • Training
  • Blog
  • Info
    • Contact
    • Careers

Is there such a thing as Fake Agile?

30/5/2019

17 Comments

 
By Dennis van der Spoel
Picture
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:
  • “Understanding Fake Agile” by Steve Denning: https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/#2ab887c34bbe
  • “SAFe No Longer - My Final Farewell” by Bob Galen: https://www.agile-moose.com/blog/2019/4/7/safe-no-longer-my-final-farewell
  • “SAFe: the infantilism of management” by Dave Snowden: http://cognitive-edge.com/blog/safe-the-infantilism-of-management/.
  • “Why SAFe Is Not the Scaled Agile Approach You Need” by Renee Throughton: https://agileforest.com/2018/06/24/why-safe-is-not-the-scaled-agile-approach-you-need/
​What the first two are basically saying is that any attempt to scale agile beyond a team is to be considered “Fake Agile”. While this utopian view of independently operating high-performance BusDevOps teams may be appealing, it is far from realistic in most larger organizations. It is not that I do not understand the urge to simplify and descale; half my time I spend coaching startups. But the other half of my time I coach large enterprises and government agencies in their agile transition. And there is a world of difference between startups and monoliths.

The third article brings little relevance to bare, and one has to dive into the comments to find the author making his case in reply to responses. However, it shows that the author has spent very little time to acquaint himself with the framework he’s bashing.

The fourth article isn’t criticizing agile scaling or SAFe per se but warns against agile in name only implementations. This I fully support, but I am not happy with the title of the post. Then there are some misconceptions about the SAFe framework I would like to address.

​Let me address my concerns one by one by debunking the arguments made in these articles.

Fake Agile

​My primary concern is the dogmatist and fundamentalist mindset that actually brings people to proclaim something “Real” or “Fake”. Saying that newbies at agile are doing “Fake Agile” because they need a more extensive framework to guide them is like saying Little League Baseball is not baseball. You may prefer to play in the Major League, but it’s all baseball. The authors should understand that for the leadership in most organizations, trying out agile is like the first swing of a bat. You cannot expect any degree of success or adherence to the rules of the game right off the plate. A complete agile transformation takes 8 to 15 years, and a scaling framework gives them the training wheels they need when they favor an evolutionary approach.

​Steve Denning takes the revolutionary approach as he introduces three “laws” to test whether agile is real or fake. These laws are:
  • the Law of the Customer—an obsession with delivering value to customers as the be-all and end-all of the organization.
  • the Law of the Small Team—a presumption that all work be carried out by small self -organizing teams, working in short cycles and focused on delivering value to customers—and
  • the Law of the Network—a continuing effort to obliterate bureaucracy and top-down hierarchy so that the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers.
And, although I find some value in these statements, I just don’t feel that they should be used to discriminate between those well underway in their agile journey and those taking first steps by labeling them as real or fake. In fact, Steve acknowledges this as he explains how agile journeys can stall and talks about “Agile In Name Only” (AINO), where he differentiates between being agile and doing agile. Then he states that it’s all about the mindset. As a certified change consultant, I have learned that mindset follows behavior. Most agilists, unfortunately, believe the opposite. They insist on mindset first, which is a recipe for disaster. A new mindset cannot be sold or taught; it has to be trained. In order to instill new believes we have to grind in new behavior. We change culture by developing new routines. So, it’s okay to do agile before being agile, as long as every ceremony is facilitated by a professional change coach who can take it a step further with every iteration. If this sustains long enough across the organization, at some point it will just ‘click’ the agile mindset in place.

My beef is primarily with the “value to the customer”-bit of these laws. Any organization has many stakeholders that require value FROM it in return for value TO it. As organizations grow larger, the slice of attention paid to customers grows thinner. This is only natural. A lot of organizations don’t even have paying customers (e.g. government agencies and NGO’s) or their customers are divisions of the same conglomerate. This is also true for many functional silos within organizations experimenting with agile. Employees, investors, suppliers, financiers, sponsors, donors, interest groups, government, regulators, media, and many others all bring value to organizations, and want something in return and will not be neglected. All these stakeholders have needs and requirements that need to be fulfilled by the organization.

Another issue I have with most agilists is their focus on delivering value, as this is often translated as building new features. This often gives way to an increase in technical debt. But more importantly, it often reduces retrospectives to pointless ceremonies. I prefer my agile teams to primarily focus on relentless improvement of product and process, then value delivery to stakeholders speeds up automatically over time. Focusing primarily on value delivery often has the opposite effect.

​Further, I have questions about the optimum size for the Small Team. Within large organizations, one can easily identify over 300 different specialist roles and disciplines. How does one cramp them into a team of, say, nine people that can carry out all the work? Even with E-shaped teams, it’s a naïve presumption. So, we need to scale and find a way for teams to work together with as little bureaucracy and hierarchy as possible. At least we agree on one thing.

Bureaucracy

Scaling frameworks, and SAFe in particular, are blamed for being too big and bulky. Agilists do like simplicity and hate bureaucracy. Let’s take a closer look at some of the comments made.

“It (SAFe, red.) reminded me too much like RUP and other bloated frameworks that were basically created to introduce “management process” to software organizations. It creates far too many roles, layers, flows, etc. It’s too big, far from the principles of simplicity at the heart of agility.” – Bob Galen

“A particularly worrying variant is the Scaled Agile Framework or SAFe. Essentially this is codified bureaucracy, in which the customer is almost totally absent. The insignificant role of the customer in the chart above is indicative of the problem.” – Steve Denning


Are agile scaling frameworks bloated? I think that is a matter of opinion and taste. But the “frameworks” I am familiar with (Nexus, LeSS, SAFe, Spotify, etc.) basically scale Scrum. And if you find Scrum complex, then I’ll just rest my case. Sure, an overview of Full SAFe looks impressive on paper, but in essence it’s just Scrum on multiple levels. In addition, most organizations will not need to go beyond the Essential SAFe configuration, which is very similar to LeSS, Spotify and Nexus. And it is agreed that you are being SAFe if you adhere to the four core values and nine principles of SAFe. Everything else is just a collection of suggested best-practices that can be tailored to fit your specific context. Also, there is no management process in SAFe, or any other scaling framework for that matter.

​“There is one last important discussion on the function of leadership in SAFe. Of all the roles affected, none is more changed than the traditional functional manager... SAFe emphasizes the value of self-organizing, cross-functional teams; it is the cornerstone of Agile development. This supports a leaner management infrastructure, with more empowered individuals and teams. Traditional, day-to-day employee instruction and direction are no longer required.  As a result, this challenges the role of executives who have been responsible for both managing development and fostering the personal and career growth of their direct reports. … Lean-Agile leaders … guide the activities necessary to understand and continuously optimize the flow of value through the organization. They organize and reorganize around value. They continually focus on eliminating waste and delays. They eliminate demotivating policies and procedures. They inspire and motivate others. They create a culture of relentless improvement that provides the space required for teams to innovate.” - © Scaled Agile, Inc.

So, is SAFe too big and far from the principles of simplicity at the heart of agility?

“Building enterprise-class software and cyber-physical systems are one of the most complex challenges our industry faces today. For example: Building such software and systems requires millions of lines of software. It combines complex hardware and software interactions. It crosses multiple concurrent platforms. It must satisfy demanding and unforgiving Nonfunctional Requirements (NFRs). And, of course, the enterprises that build these systems are also increasingly sophisticated. They are bigger and more distributed than ever. Mergers and acquisitions, distributed multinational (and multilingual) development, offshoring, and rapid growth are all part of the solution. But they’re also part of the problem. Fortunately, we have an amazing and growing body of knowledge that can help. It includes Agile principles and methods, Lean and systems thinking, product development flow practices, and Lean processes. Thought leaders have traveled this path before us and left a trail in hundreds of books and references to draw on. The goal of SAFe is to synthesize this body of knowledge, along with the lessons learned from hundreds of deployments. This creates a system of integrated, proven practices that have improved employee engagement, time-to-market, solution quality, and team productivity. Given the complexities discussed earlier, however, there’s no off-the-shelf solution for the unique challenges each enterprise faces. Some tailoring and customization may be required, as not every SAFe recommended practice will apply equally in every circumstance. This is why we work hard to ensure that SAFe practices are grounded in fundamentally stable principles. That way we can be confident they’ll apply in most situations. And if those practices do fall short, the underlying principles will guide the teams to make sure that they are moving continuously on the path to the … shortest sustainable lead time, with best quality and value to people and society.” - © Scaled Agile, Inc.

Yes, SAFe comes with a substantial body of knowledge. But rightly so, as the organizations for which it has been designed have grown to become extremely complex. Reducing this complexity is a long and painful process which might take years, if not decades. SAFe is simply a toolbox to assist on that journey.

​The last concern voiced by Steve Denning is that the voice of the customer seems to be marginalized in SAFe. He draws this conclusion from the fact that the customer icon is only placed once on the map that provides an overview of SAFe. Being a visual critter myself, I understand his concern. But as a certified SPC I know that the authors of SAFe didn’t want to clutter the map with redundant icons. In SAFe, stakeholders like the customer are front and center. However, this is sometimes by proxy, as customers rarely know what they want or need until they try it.

​“Even when they don’t yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf. No customer ever asked Amazon to create the Prime membership program, but it sure turns out they wanted it, and I could give you many such examples.” - Jeff Bezos

Cash Cow

​One accusation made is very curious at first glance. Branded agile, which includes all the various agile frameworks, is shamed for making money through training and consulting.

“Agile Frameworks, SAFe in particular, are a business. And businesses make money. It’s too focused on certifications and training – a cash cow. It’s created a community of SPC’s and other consultants who think being agile is about…SAFe. … Did you know that Scaled Agile claims to have produced 400,000 SAFe-trained professionals in 110+ countries? Take a breath and wrap your brain around that for just a minute. And ask yourself, does the world need that many SAFe’ers …?” - Bob Galen


​In a free capitalist market, this is peculiar quote at best. So, what is behind this? I believe that the authors do not understand organizational change and the role that trainers and consultants play in the economy. Many authors promote an organic approach to agile. This basically means: “let them find their own way of working”. This doesn’t work for three reasons:
  1. It scares the hell out of managers, so it’s not going to happen. Trust and mindset are built over time, and it is a fragile process. Starting out by letting each team find their own way of working is a hard thing to sell. Build trust first. Consultants and trainers sell trust. They help managers to build up courage to allow experiments to validate hypotheses around this new thing called “Agile”.
  2. Few people are programmed to stretch themselves, and most are not naturally inclined to improve themselves without a sense of personal urgency. Would you say that we could select a bunch of new recruits and expect them to self-organize into a high-performing Navy Seal team? No! We tell them that they will be dropped behind enemy lines in six weeks. Then we introduce a CO (product owner) and a drill-sergeant (scrum master) who will give them tough love and a lot of training for six to 10 weeks. They even bring in specialized trainers for specific subjects. While they grind in new routines, they learn to act as a team and think as a Navy Seal. Why would it be different for agile teams? Why do we expect spectacular results when most agile teams receive much less than six weeks of intensive and relentless training?
  3. Large corporations and government agencies do not operate in an agile bubble. There are many standards, rules and regulations to comply with. Most agilists do not recognize this, primarily because they have never held a senior management position and therefore not understand the strain and oversight senior managers are under. Consulting firms of fame and industry standards such as SAFe, help legitimize decisions made in the boardroom and divert some accountability for these decisions. This includes decisions in support of the agile transformation. Hence the need for external coaches, consultants, and trainers. Without them, senior management would become even more risk averse. 
​As a final note, I’d like to add that I find it rather strange to blame someone for creating a thriving community. It surely must be taken as a sign that something has been done right.

Silver Bullet

Another point of critique made is that scaling frameworks could be perceived as a silver bullet and therefore impede real change, especially among line management. This is a just concern, but the frameworks are not to blame. This is something of all ages. We have seen it with every new trend and fad that came along. But let’s address these concerns nonetheless.

“It’s (SAFe, red.) sold to leaders to control their organizations – a costly silver bullet. It’s created lazy organizations who think that the framework does the heavy lifting of transformation for them.” – Bob Galen


Well, SAFe is not about control, and it is not sold to this end. But it is true that I have met leaders in my Leading SAFe class who acted like they discovered the holy grail. This does concern me. Anything can be misused. This includes SAFe. I’ve seen it before with PRINCE2. That best-practice has earned a bad reputation because 95 percent of its application was PINO (PRINCE2 In Name Only). Today I see a lot of SINO (SAFe In Name Only).

“My strong and increasingly passionate argument was that SAFe is not only a betrayal of the promise offered by Agile but is a massive retrograde step giving the managerial class an excuse to avoid any significant change.” – Dave Snowden


“On the positive side, SAFe is one of the earliest certification bodies to focus on leadership training explicitly. The content is also quite good. If you are lucky, 5% of your leaders will really listen and get it, but most won’t invest time to be trained.” - Renee Throughton


While I strongly disagree with SAFe being a betrayal of the promise offered by agile, I have seen in practice that the managerial class often decides that 2 hours of training suffices for them, after which they run off with a single snippet of learning that is pulled completely out of context and then becomes their north star for the rest of the journey. That’s why I stopped working with organizations where senior management refuses to get certified as SAFe Agilists (SA) before we do anything else. True leaders dive in first and eat last.

“It is now pervasive in large firms because it (SAFe, red.) gives the management a mandate to call themselves agile and keep doing what they have always done. Essentially it subordinates the agile teams to the bureaucracy, rather than doing what is necessary to achieve business agility, namely, transform the big monolithic internally-focused systems into arrangements where the budgets, HR, Finance and so on are flexible and externally focused in support the Agile teams in operations.” – Steve Denning


I hope that I have already refuted the bureaucracy myth and explained the role of management in SAFe. And I agree with Steve about what to do to achieve business agility. I just don’t agree on the timeline. Transforming the big monolithic internally focused systems into arrangements where the budgets, HR, Finance and so on are flexible and externally focused in support the Agile teams in operations is a long and winding road. This simply doesn’t happen overnight. Meanwhile, the monolith needs less oppressive structures to replace the traditional structures, to create space for the transition while ensuring that dependencies are being managed for as long as they exist. SAFe even offers practices to make budgets, finance and HR much more agile. SAFe is not an end-state, it’s often the first step beyond software teams on a never-ending agile journey.

“Most organizations take five to ten years to complete a transformation across all its people. Agile really isn’t a sprint, it is a marathon, a 3100-mile self-transcendence marathon. In fairness this is not a SAFe callout, or even a scaled agile issue. This is tremendously prevalent in the whole Agile community.” – Renee Throughton


​I concur with Renee, but in my experience an agile transformation is never over. I’ve seen organizations with 15 years under their belt still struggling with the agile mindset as there is a continuous influx of new staff.

PRINCE2

​PRINCE2 was the predominant best-practice to manage projects. Well, at least in much of Europe and Australia. There are a lot of misconceptions about PRINCE2 in and beyond the agile community. It is often perceived as overly bureaucratic and waterfall, while it was in fact designed to be agile. PRINCE2 was ahead of its time and therefore largely misunderstood and misinterpreted, and thus misused.

​As an intermezzo, let me provide you with some design principles of PRINCE2 in agile terminology:
  • Continued validation of the outcome hypothesis.
  • Continued learning and adapting through retrospectives.
  • Just enough design and planning upfront, work out the details for the next increment/iteration only.
  • As long as a person or team is operating within agreed tolerances for duration, costs, quality, scope, risk and expected outcomes, there is no need for a higher authority to make decisions. Individuals and teams can self-organize within these boundaries.
  • The only measure of progress is accepted product. That’s why product-based planning (as opposed to task-based planning) is mandatory.
  • Only the end-user, or the senior user as a proxy, can accept and approve deliveries or authorize and prioritize changes.
  • It is mandatory to adapt PRINCE2 (processes, roles, information requirements, etc.) to the size, characteristics, and requirements of each individual project, thus creating a unique instance of PRINCE2 for each initiative. 
Now, doesn’t that sound agile? The only problem is that PRINCE2 has never been used that way. Bureaucratic application gave PRINCE2 a bad rep. SAFe is under that same threat.

“Put brutally SAFe seemed to be PRINCE II camouflaged in Agile language. SCRUM as an approach was emasculated in a small box to the bottom right of a hugely overcomplicated linear model. The grandiose name of a dependency map was applied to something which is no different from a PERT chart and in general what we had is an old stale wine forced into shiny new wineskins.” – Dave Snowden


I am not sure what Dave saw in that particular presentation, but I suspect it to be the Program Board as it might be perceived as a simplified PERT chart. I am not going to debate the differences between a PERT chart and a Program Board. I’ll just admit that Dave would have a point if we would still require a Program Board when we are well into our agile journey. It may take a couple of years to reduce dependencies between teams by redistributing team members among teams, reducing complexity in our systems, improving CI/CD capabilities and our architecture, and slicing features in a more effective manner. Until such a time we need to visualize dependencies. The Program Board is a way of doing that, but I’m open to suggestions.

​And to raise the stakes, I will now go on record stating that it is a good thing that SAFe feels very familiar for organizations already acquainted with PRINCE2, MSP and MoP, or AgilePM, AgilePgM and Agile PfM for that matter. It helps them to cross the chasm. By the time they realize that it is a different thing altogether, they have already made the jump and taken the first steps on their business agility journey. Should they linger there? No, of course not. If you need “SAFe by the book” for a prolonged period of time, you are not progressing on your journey. But SAFe can be very helpful during the first couple of years.

Massive batching

Some authors are concerned that an increment-cadence on top of an iteration-cadence encourages massive batching and productivity-loss because attention is spent on preparing for the next increment while delivering on the current increment. In SAFe, iterations and increments are treated very similarly. We refine the next iteration and increment while delivering the current one. It is a standard Scrum practice, and I do not see the problem. We can still release on demand, every second if needs be, so there shouldn’t be any large batches. And productivity-loss because of context-switching shouldn’t increase either, as the understanding gained during an increment refinement will speed up iteration refinement. SAFe introduced increment planning to enable product management to make more reliable product roadmaps and for the teams to uncover dependencies with other teams. Agilists do not like working under deadlines, but in the real world, stakeholders like legislators, customers and media would like to have some estimation on a particular feature or epic. Whether we need to implement new legislation across 1200 applications before it comes into effect or to present a new self-driving electric car at a tradeshow, timing is crucial. SAFe strives to balance these requirements with an agile mindset.

Scaling Agile

Is scaling agile the wrong track? According to the authors it is.

“A particularly unfortunate form of “branded Agile” concerns scaling frameworks. These are schemes aimed at helping firms that have some teams implementing Agile practices and want to resolve the tension between the Agile teams and the back-office systems of the organization (such as strategy, planning, budget, HR, Finance) which are typically monolithic and bureaucratic. The challenge is usually presented as one of “scaling up agile.” The issue here is that if the firm is thinking about " scaling up agile", it is already on the wrong track. The challenge of genuine Agile is how to descale big monolithic, internally focused systems into tasks that can be run by small self-managing customer-focused teams.” – Steve Denning


​This is, again, an issue of timing. When we scale agile, we are merely matching the current organizational complexity with agile and lean practices. I wholeheartedly agree that from there on we should descale. But descaling agile should follow the descaling of the organization, not vice versa. And I envision that there may be a limit beyond which we cannot descale any further because of the nature of large organizations.  

Misunderstandings

​Before I wrap this up, I would like to clear up some misunderstandings that Renee Throughton published in her post. 
  • PMOs still exists, but only on the portfolio lane. Portfolio Management, in SAFe, as well as in P3O and MoP, is a PMO function.
  • Funding processes do not remain unchanged. Funding in SAFe is moved from funding work (projects) to funding capacity (teams through value streams).
  • Gating processes remain largely unchanged but will become lighter. Epics require a business case and a go/no-go decision, much like projects did. The difference is that the business case no longer serves to secure funding. Instead it should be focused on obtaining a high priority status. Generally speaking, this will translate to much lighter business cases.
  • Capex/Opex models remain unchanged. This has nothing to do with agile. This has to do with compliance. But even so, SAFE offers a couple of suggestions on how to deal with that.
  • Release management processes are eventually affected by implementing SAFe. SAFe promotes DevOps and Release on Demand as capabilities that should be developed. While teams and ARTs work on cadence, any team or ART can release at any time market and governance conditions warrant. In other words, the planning and synchronization cadence does not mandate the release cycle. They are two separate things entirely.
  • Performance management, rewards and renumeration do not remain unchanged. And neither do people hiring and onboarding processes:
“SAFe challenges Human Resources (HR) to realign their people approach with this new way of working. It imposes a far-reaching transformation to bring HR into the 21st Century by shifting from a process-oriented HR Management to an empowering Lean-Agile people operations. It changes the face and significance of HR forever. In a SAFe whitepaper, we describe six basic themes that can guide Leaders and their HR Partners on how to address various aspects of more contemporary Lean-Agile people solutions in the Lean-Agile enterprise. These are:
  • #1 – Embrace the New Talent Contract
  • #2 – Foster Continuous Engagement
  • #3 – Hire for Attitude and Cultural Fit
  • #4 – Move to Iterative Performance Flow
  • #5 – Take the Issue of Money off the Table
  • #6 – Support Impactful Learning & Growth” - © Scaled Agile, Inc.

Conclusion

Every day I come across online commentaries and debates where the pros and cons of agile frameworks are discussed. The debate between simplicity and complexity will probably never cease to exist. Some people love a certain framework and others don't. Both have valid reasons when we look at their specific context. Most of the contributors to these debates, however, have never been in a senior management role in a huge and complex organization or enterprise. More often than not their context is a limited number of teams. From their point of view, their criticism of agile scaling seems solid. However, you could look at it this way; to repot a plant you might prefer a garden shovel, and to replant a tree an excavator might be handy. But using an excavator to repot a plant somehow doesn’t feel right. The problem is that most humans are fundamentalists by nature. Once we are into something, everything becomes about that and we start using excavators to repot plants or garden shovels to replant trees. Most of the critique that frameworks like, for instance, SAFe receive comes from people in the business of repotting plants. Most decision-makers that buy into this framework are in the business of replanting trees. Debating preferences between them is pointless.

I hope we can all agree that Scrum as a framework has brought us many benefits, but it has significant limitations when we need multiple, if not dozens of teams to cooperate on a single value proposition. The more teams we need to support a single value stream the more cross-team coordination we may need. This doesn’t necessarily mean that we need additional roles and layers. This depends on the organizational maturity, system complexity and existing culture. But it may very well be that many organizations do need structures apart from Scrum while transforming to - and scaling - an agile way of working. This doesn’t necessarily have to be an end-state. Agile transformation is about maturing and changing one’s culture. Eventually, many structures may become obsolete once they have served their purpose.

On one hand you could argue that some frameworks are too big and complex. On the other hand, so are some organizations. Any solution should fit the problem. So, Full SAFe, for example, is meant solely for huge and complex organizations. Looking at Essential SAFe, it is very similar (in size and simplicity) to the Spotify model, LeSS and Nexus.

​So which framework is right for you? Looking at the most popular agile (scaling) frameworks that I have experience with, I have arrived at the following rules of thumb, which of course are completely arbitrary and will cause offence 😉
​Suggested Number of value streams or products in a portfolio
​Suggested Number of people supporting each value stream or delivering each product
​Suggested experience with Agile practices beyond software development
​Inter-team dependencies at start of Agile Transition
​Suggested Framework
1
​80-125
​Low
​High
​Essential SAFe
1
125-800
​Low
​High
Solution SAFe
3-8
80-125​
Intermediate
​High
​Portfolio SAFe
Infinite
150-1200
Low
​High
​Full SAFe
​1
25-70
Intermediate
​Intermediate
​Large-Scale Scrum (LeSS)
1
70-350
High
​Intermediate
​LeSS Huge
1
25-70
High
​Low
​Scrum of Scrums (SoS)
1
25-70
​Intermediate
​Intermediate
​Disciplined Agile Delivery (DAD)
1-2
25-400
​Intermediate
​Intermediate
​Disciplined DevOps
1-2
25-400
​Intermediate
​Intermediate
​Disciplined Agile IT (DAIT)
Infinite
25-400
​Intermediate
​Intermediate
​Disciplined Agile Enterprise (DAE)
1
50-1500
​Intermediate
​Low
​Spotify Model
17 Comments
Dave Snowden
16/6/2019 21:52:03

I did think about providing a response but then found that comments are only posted after you approve them. Not really prepared to participate under those rules I’m afraid. Not that impressed you feel the need to impose them. I’ve never done that on my blog; stifles debate and allows you to control the timing of the exchange.

Reply
Dennis van der Spoel
18/6/2019 11:02:33

Dear Dave, although you are absolutely on point with your critique, I have tried to do without an approval process. But I found that, apart from a lot of spam and hate, I have had to remove pornography and jihadic messages. An open forum without good AI filtering is just not viable anymore.

Reply
Snowden Dave link
16/7/2019 13:14:58

To be frank that is nonsense. Normal spam filters handle protography etc. My blog is fully open - as you can see from the link you posted and I encourage open contribution. In over a decade I've only had to block two trolls and manually tag less than three posts as Spam.

I understand that approvinge comments allows you to control the timing of when the post is made and your response. I also understand that this type of post (yours) is designed to sell services but it doesn't feel right to me.

Dave Snowden link
17/7/2019 13:54:40

This blog post (https://cognitive-edge.com/blog/scale/) discusses scale and links to a 2014 series on the subject I’ll be teaching this in the context of Agile in Berlin later this year. SAFe for me is wrong a priori given the way it puts things together.

We just did a two day session on ToC and Cynefin and game up with a series of practical methods on five aspects - especially goal creation - those will be published shortly.

To speed up the journey I would pick intractable problems and use complexity approaches there - more willingness to experiment. Agile also tends to the all or nothing approach and SAFe makes that worst. Key (and this is what Cynefin is about) is to legitimise what they are already doing, but get them to realise the context in which it works and that there are other contexts where a different approach is needed. Finding the intractable or wicked problems makes that easier.

Piet Syhler
18/6/2019 10:14:22

My words exactly...don't blame the frameworks for being fully agile in 6-12 months. It's just hard and takes a long time...

Reply
Sune Lomholt link
16/7/2019 11:38:41

Dennis - Thank you for such a well written and proper challenge to some of the ramblings against frameworks. I agree with most of it and it seems that people forget what a framework is. Namely a basic structure where you need to fill in the details. Additionally, as you note the framework you choose should depend on the problem you are working with.

I have previously been part of creating a development model for a large organisation. The initial ideas and aim was to make a simple model, where you should focus on only 9 questions to cover your engineering process. We added some (simple) modelling techniques and that was all. However, than people needed more details, how do I do this and that etc. Eventually, we ended up with a relatively large body of content. Suddenly, people started to do "everything by the book" - i.e. they started on page 1 and then just did what ever the model/framework told them. The result being a lot of wasted effort and confused people. So any framework, guidance etc however small or large requires people to think and reflect is this suitable for me? And when I try this out how how will I know it worked?

Reply
Sarah Freiesleben link
15/1/2020 13:54:08

You mention that "It may take a couple of years to reduce dependencies between teams...(&) complexity in our systems", but is that in fact the end game? Being from the Bible Belt I can appreciate your aversion to fundamentalism, and I can also appreciate the importance of applying systems thinking and lean principles to complicated things or predictable complexities (such as DevOps), but for innovation or transformation to truly occur, shouldn't we be trying to catalyze our unpredictable organizational complexities instead of simplifying them? And as a side note, if we hire for cultural fit, as I see one of the HR principles aims to do, isn't that just feeding the same status quo additions that created monolithic problems to begin with?
Signed, a recovering senior leader from a huge complex organization :-)

Reply
Dennis van der Spoel link
16/1/2020 00:24:47

Dear Sarah, It all depends on what you are trying to achieve. In the post, I am assuming that we aim is to accelerate innovation. This is hard to do if teams are continuously frustrated by waiting on other teams before they can finish a work item. Reducing dependencies is one of the solutions to increasing flow. In addition to reducing WiP and Cues, of course.

And by hiring for cultural fit I meant mostly the desired culture, and not necessarily all of the current culture. Although it is important to recognize and appreciate aspects of the current culture that made the organisation to what it is today. Hire people with an agile mindset.

Reply
Sarah Freiesleben link
16/1/2020 09:55:45

Thanks for your reply, Dennis. I can certainly see how it makes sense to reduce unnecessary dependencies, (I'm guessing you mean "queues"?), and WiP items. No one wants that. But those things evolved in our organizations because we didn't have better tools to support the integration of relevant perspectives. I don't think we should "throw out the baby with the bath water" by fooling ourselves that the way to promote innovation is to reduce variation. Efficient innovation is great as long as it is not at the cost of effective innovation. And now I understand your comment about the hiring goal better. Being a supporter of agile mindset, it would make life easier to hire others like me, but again, "hiring for likeness" is what got us into this mess!

Dennis van der Spoel link
16/1/2020 14:37:28

Dear Sarah, I'm afraid that you confuse separate issues. Dependencies for me are of a technical or organizational nature, resulting in one team needing something done by another team before being able to finalize their own work item What we should like to see is a single team being able to deliver real value end-to-end and full stack.
No-one is suggesting that we should reduce variation.
And diversity is great for creativity, but bad for efficiency. So the balance needs to be struck that matches your context. The point I was trying to make was to hire individuals that are able to adopt an agile mindset rather that more of the people that match the current way of working.

Sarah Freiesleben link
20/1/2020 20:58:34

Hi again, I think we have the same definition of a dependency and I still believe their nature is not arbitrary; rather, linked to what was at least at one time, some variation that was considered necessary. But if your perspective is one that says I'm confused instead one where you are curious to understand mine, then I don't suppose there is much more of a learning experience either of us can take from this discussion. It's a shame, since the space between our opinions is probably where emergent thought lies. Thank you for your time and engagement about the topic.
Cheers,
Sarah

Reply
Dennis van der Spoel link
21/1/2020 14:14:21

Hi Sarah, point taken. However, I wasn't stating that you are confused, but that you were confusing two topics that to me seemed relatively unrelated. Perhaps I should have stated that your comment confused me. I currently see no direct relationship between dependencies and variation other than variation adding to the problem of dependencies. Please enlighten me.

Reply
Sarah Freiesleben link
27/1/2020 13:30:41

Hi Dennis,

Thank you for your openness. I can see why you would consider it confusion since you do not see the relation. In my experience, annoying and time wasting dependencies have evolved in processes due to a need for varied input to be captured that is either no longer relevant or that legacy tools did not have the funtionality to handle in the straightforward ways they do now.

For example, a pre ERP purchasing process might have lots of people involved with ensuring a service was actually received, the price being billed is accurate, the vendor being used was the right one, etc. before paying it, but modern ERPs can handle this automatically if set up properly. Yet they still rely on segregation of duties and varied inputs which are important. Unfortunately many ERPs cannot set this up correctly and therefore more and more work around processes get created to manage necessary variation.

Having an objective to reduce dependancies without understanding the contextual reasons for the dependancies' existence can cause serious problems. Which is why I find it problematic for people to take an approach to reduce variation just because the method by which it has been incorpotated into the process may not be streamlined optimally.

Hope this makes sense and you can see why I believe variation and dependancies have a lot to do with each other.

Cheers
Sarah

Reply
Dennis van der Spoel link
27/1/2020 15:07:59

Hi Sarah, Thanks for the response, but I stil do not see what you mean. Perhaps it is wise to exchange our definitions of variation.

To me, variation, or variance to be more precise in the context we are discussing, is the deviation from normalized estimates (baselines). For instance, we have various work items that have been given the same T-shirt size estimate or the same number of story points. However, they do not take exactly the same amount of time to deliver. This can mess up the planning for a sprint or increment. It is true that variance, causing delay in one team, might cause a delay in the dependent team. And it is likely that an impediment in one team cascades through all dependent teams. But most variation can be absorbed as agile teams mature and gain experience.

What I see as most problematic with dependencies is that there is no alignment between dependent teams when they each have a product owner with an independent will and separate backlogs. One team might need the other team to do something, but that team's PO does not consider that a priority. That alone would for me be the reason to remove dependencies between teams. I come across this problem a lot in very large corporates with huges amounts of legacy and big monolithic systems. To me, resolving this issue by reorganizing teams, architure, processes and roles so that there are less dependencies is crucial for an agile transformation to succeed.

What is your definition of variation?

Sarah Freiesleben link
28/1/2020 09:46:56

Hi again Dennis,

I think I see where our paths diverge and understand your perspective now. I certainly have more of a layperson definition of "variation" but I don't think that is where we got off track. Picture this syllogism which I think represents your last comment.

Variation is deviation from baseline,
and deviation from baseline causes problems
(on these 2 premises we agree);

Then I understood your suggestion to be that removing variation is the answer, but what your example illustrates is that improving the baseline to be the least prone as possible to destructive or unecessary variations is your goal. And I completely agree with that :-)

Anyway, I think we are saying basically the same thing. Thanks for the chat and engaging on this.

Regards,
Sarah

Reply
Rajesh kumar
16/2/2021 20:35:36

When the people who created the agile manifesto have problems with the ideas like sAFE, one has to acknowledge the problem.

But since agile has spawned a cottage industry in itself which is worth billions of dollars, 'coaches' like you will obviously object to them.

Some of the articles that you site hit the nail on the head. If you want to scale agile, you are doing something wrong fundamentally. Big organizations did this without 'scaling'
- like Spotify. Neither does Google or Amazon or Apple does sAFE.

On the contrary, it is the cottage industry 'coaching industry' together with nonsense tools like JIRA which is wrecking the real agile transformation.

I can point to videos from the original agile manifesto creators but it will be falling on deaf ears.

Reply
Dennis van der Spoel link
17/2/2021 10:47:21

Hi Rajesh, thanks for your input. I understand that this debate could go on forever. There are two sides to the debate that have dug in, both probably full of assumptions about the other side. One of your assumption being that I am in this for the money, therefore my intentions must be wrong. But SAFe isn't the only commercial framework out there. Scrum certifications are a multi-billion dollar industry as well. The fact is that knowledge is money, and therefore costs money. It's the basis of our knowledge society.

And let's face it, the fact that someone just happened to be in the right place at the right time to put his name on the agile manifesto does not give that person any authority on the matter. There is no place for heroes in agile. Besides, most of them are selling their own courses and are fishing in the same pond. It's only logical that they are bad-mouthing a competitor.

Second, Spotify, Google, Apple, Amazon, and Microsoft do scale. There even is a scaling "framework" named after Spotify, no matter how hard they deny it. I've visited the office where Microsoft develops Bing, that 600 developers working on the same browser. If that isn't scaling, I don't know what is.

I'm with you on where you stand regarding Jira, I prefer a butcher paper obeya on the wall too.

The fact of the matter is that scaling frameworks are popular and in demand. There is an undeniable need for them. Coming from customer centricity, I find it peculiar that agile-minded people would deny their customers this value.

Whether it's Spotify, Nexus, S@S, SoS, SAFe, DA, LeSS, or any other scaling framework. They are basically the same. They scale lean and agile principles, and most of them are based on scrum. So, I just don't understand what the fuzz is about.

Reply

Your comment will be posted after it is approved.


Leave a Reply.

    RSS Feed

    Archives

    August 2020
    May 2019
    January 2019
    December 2018
    November 2018
    October 2018

    Index

    All
    Agile
    AgilePfM
    AgilePgM
    AgilePM
    Agile Transformation
    Ajax
    Art Of Action
    Auftragstaktik
    Backlog Refinement
    Batching
    Benefit Mapping
    Bureaucracy
    Clausewitz
    Coaching
    Compliance
    Enterprise Strategy
    Fake Agile
    Feijenoord
    Governance
    History
    Impact Mapping
    Innovation
    Lean
    LeSS
    MoP Management Of Portfolios
    MSP Managing Succesful Programmes
    MSP Managing Successful Programmes
    Nexus
    Portfolio Management
    PRINCE2
    Product Vision
    SAFe
    Scaled Agile Framework®
    Scaling Agile
    Scrum
    Silver Bullet
    Spotify
    Strategic Alignment
    Tuckman's Team Development Model
    Value Proposition
    Von Moltke
    Waterfall

Services

Training
Consulting
Transitioning

Company

About
Home
More...

Support

Contact 
Terms of Use
​Privacy Policy
Disclaimers
Terms & Conditions
© COPYRIGHT 2017-2020 - DENNIS VAN DER SPOEL PRODUCTIONS. ALL RIGHTS RESERVED.
Photos used under Creative Commons from EpicTop10.com, Book Sprints
  • About
    • English >
      • Introduction
      • What we stand for
      • Where we thrive
      • What we offer
      • Where we come from
    • Nederlands >
      • Introductie
      • Waar wij voor staan
      • Waar we gedijen
      • Onze propositie
      • Onze wortels
  • Training & Events
    • Agile @ Scale
    • SAFe
    • Training
  • Blog
  • Info
    • Contact
    • Careers