I started a new series of posts where I will answer some actual problems/ideas presented in an I&A problem solving workshop as part of open space facilitation. This is the third of a few dozen that I plan on covering. If you have any comments, please, let’s learn together.

Problem/Idea #3:

“Outside team interference and noise; unnecessary outside team involvement”

 

A SAFe Answer

This problem is not unique to the SAFe or Lean-Agile space. It exists in every organization I’ve encountered.

It is, however, a big, common problem. How many times have you or your team been “redirected” to work on the latest fire fighting drill? Was this time accounted for in the waterfall/traditional silo planned WBS that you are working against? I’m certain your manager and project managers always go back to the integrated master schedule (IMS) to reflect lost productivity. IMS’s always account for production down, maintenance, operations? Sure they do. Especially when the team doing costing gets to review the proposal and “tweak” the final numbers. [insert massive sarcasm]

If we are to root cause the problem it is likely poor planning was involved. Generally, I don’t believe it is a skills gap as even basic knowledge of the work at hand and common sense leads teams to understand the entire body of work that must be accounted for.

So what is it? Outside influencers who are not close to the work causing the interference? The usual culprit. It isn’t that these other stakeholders and disinterested parties don’t care about the product and/or doing a good job. It is just likely that the system was poorly designed as a group of independent islands / silos that have no desire to interface nor integrate with each other. Fiefdoms, silos, my cheese. Many of us have been to this party and experienced the unhappiness of overbearing command and control, inflexible process, and angry hateful people.

Why do organizations grow into models and culture that read like an interference horror story?

FEAR. Fear of failure. LACK of LEADERSHIP AND VISION. Leaders who can’t do and don’t care enough to understand. Organizations with no coherent vision. A complete lack of innovation. Maintain the status quo at all costs. Token attribution to improvement disguised as “continuous” but a reality of checking boxes and writing checks to acclamatory standards organizations who deserve more ignominious regards.

How do we address this problem?

The SAFe addresses this problem the same way we do with any culture hacking framework. We CHANGE the underlying culture by replacing bad behaviour driven by shitty value systems with a benevolent value system.

Constant interference and noise is solved in sports the same way we solve it in organizations building products and/or delivering services. We create rules and penalties for breaking them. Teams must learn to deal with noise as part of the game just as opponents do playing the Tigers at Death Valley. Certain types of interference, which are not necessarily waste, are built into the system to manage flow. WIP limits? Others are purely muda (waste) and must be improved out of the system holistically. It is important for teams to understand the differences between noise, positive disruptive interference, waste interference and the various influences that affect the team. Has the team created an influencer matrix? Does Scrum teach teams to do this?

In Scrum, there is a role dedicated to shielding the team from muda interferences. And managing necessary interferences. The Scrum master. If you are a Lean-Agile or a Kanban team the equivalent role is “Lean-Agile Servant Leader”, “Champion,” “Servant Leader,” again a “Scrum master,” or even a “manager as servant leader.”

The Scrum master is a role whose primary purpose is to protect the team from unnecessary outside influence. If organizations and teams are truly committed to the Scrum framework at the team level (EVEN WHEN USING THE SAFe) then the committed servant leader Scrum master will succeed in defending the team from inappropriate interference.

The problem at scale

When you start scaling Scrum and Lean-Agile principles across a large organization or product development team the simple constructs in Scrum become insufficient to address larger organizational culture challenges. Such as the problem described in this blog post.

Daniel Gullo makes this point in his book, “Real World Agility“, where he quotes Jeff Sutherland: “Many agile programs struggle or fail. One major cause of this is simply bad Scrum.” I agree with Jeff’s latter point, but. I’ve already railed against the abuses of terminology through reckless overloading and assumptions in other blogs. I’ll say it again, “The Scrum framework is not Agile.”

Daniel takes a few swipes at the SAFe, which are his rightful opinion, by claiming the SAFe does not implement Scrum in its correct context stating, “That is, most practitioners of true, well formed Scrum would consider these changes harmful to Scrum and contrary to its successful usage.” To be fair to SAFe and Daniel he only took one SPC course. I’ll be honest here. I didn’t really, deeply, understand SHIT about SAFe after taking the SPC course. Same for the Scrum Alliance CSM and CSPO courses for Scrum. I learned 90% of what I know about these things by DOING THEM, for years.

I disagree with several of the assertions that Daniel makes about SAFe in his book. SAFe doesn’t do anything without people. AFAIK the SAFe does not prescribe anything outside of vanilla Scrum other than opening the “possibility” of a part-time Scrum master. It recommends a portfolio cadence of iterations at two weeks, which is fully compliant with Scrum, and program increments of 10-12 weeks. Also fully compliant with Scrum. As a SAFe program consultant, I always recommend full-time scrum masters. This option hardly de-values SAFe in any way nor does it make Scrum in the SAFe a malformed miscreant. I will address more of Daniel’s commentary on SAFe in my book review of Real World Agility.

The Scrum framework by itself does not do enough for scaling across hundreds, or even thousands, of practitioners. With pure vanilla Scrum at scale it requires very, very sturdy consultants and lots of work to build out constructs using Scrum. Which would look remarkably like SAFe after being built. If you don’t believe me, go and research for yourself how Jeff Sutherland, Mike Beedle and other “Scrum” zealots now have scaling frameworks of their own — based on Scrum +. Why is that if Scrum is enough? Why did the Scrum thought leaders need to create ScrumPlus?

Why do Scrum based scaling frameworks exist, created by the creators of Scrum, if Scrum is enough?

How to improve and innovate the muda interference out of the system

The answer lies in systems thinking. Scrum is awesome for the team. Really great with a handful of teams. But it quickly becomes problematic when Scrum masters and Product Owners try to scale Scrum to hundreds of practitioners. This is why the scaling frameworks exist. If we only fix the way of working at the team level then we have done nothing to increase flow and quality for the entire organization.

The problems of waste interference are derived from crap culture (theory X) at all levels of an organization. How do we fix this at the executive level? Customers? middle managers? directors? siloed teams? You can try with vanilla Scrum and lots of really dedicated consultants who will coach and build a way of working that successfully hacks the culture for the better. It will take a very long time. Or, you can take the short cut with a higher rate of success and choose an appropriate scaling framework that addresses the entire system. An organizational view on the holistic system where a mindset/value system/principles are applied at scale.

SAFe, for example, integrates the Scrum framework (as intended), Lean, Kanban systems, systems thinking, big room planning, relentless improvement as one holistic approach to scaling the goodness of “Agile” across an organization. The SAFe is just a tool in the toolbox. One of many tools a good consultant will bring to bear when hacking culture. Addressing the subject problem concerns critical and significant hacking of the organization’s culture. This requires dedicated change agents who have the experience and skills necessary to fight the good fight. To be tough as iron when necessary, and soft, caring, patient and loving as a modus operandi.

 

Acronyms:

PI – Program Increment
PIP – Program Increment Planning
RTE – Release Train Engineer
POPM – Product Owner/Product Manager
ART – Agile Release Train
DoD – Definition of Done
LPfM – Lean Portfolio Management
STE – Solution Train Engineer

 

I encourage all readers to check out the SAFe© guidance articles on the subjects before reading this article. SAFe© and Scaled Agile Framework© are registered trademarks of Scaled Agile Inc.