|
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:
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. 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:
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:
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:
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.
“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:
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 😉
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.
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. 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. 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.
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... 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. 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? 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. 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! 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. 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. 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. 27/1/2020 13:30:41
Hi Dennis, 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. 28/1/2020 09:46:56
Hi again Dennis,
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. 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. Your comment will be posted after it is approved.
Leave a Reply. |
Archives
August 2020
Index
All
|
RSS Feed