Addressing some SAFe concerns

Quite often, I encounter concerns with the Scaled Agile Framework. When looking at the Big Picture, and what many companies make out of SAFe, these concerns are valid - and should be taken serious. On the other hand, none of these concerns couldn't be addressed by a capable SPC and a management who cares about making a meaningful difference in their ways of working. In this article, I'm looking at some of them.

SAFe- Blessing or curse?

Typical Concerns with SAFe

Before digging in: I do believe that the skills and experiences of your SAFe Practice Consultants are critical for the success of SAFe. If you rely on people who don't understand the consequences of any advice they give, you're in for a rough ride. An SPCT friend of mine recently said, "Having the wrong SPC's - or skipping the guidance of an SPC altogether - will easily cost you tenfold of what a good SPC would cost you." I agree. Good SPC's are worth their weight in gold. Unfortunately, they don't grow on trees ... but that's a different story.
Now, let's take a look at some of the concerns I typically encounter, and what we need to consider.

SAFe caters to traditional mindset

SAFe acknowledges and respects that many organizations transitioning to agile practices still have a traditional mindset. Therefore, a lot of material in SAFe is written in a way that might be more palatable to people who have a low understanding of agility. This is the idea of "meet people where they are." Yes - that's contentious, but it's by far better than affronting the very people you need in order to make a change. What happens after we met them - that depends a great deal on their motivation to change, and the ability of the SPC to lead change.

Complexity overkill

First things first - if you don't have the problems SAFe addresses, don't use it. With that out of the way, SAFe can't - and usually shouldn't - be applied completely. Much rather, when we spot a problem for which SAFe proposes a solution, we can look at what SAFe says, have a discussion on whether that's worth a try - and if it is, then go for it. That neither means that you need to do things that solve problems you don't have, nor that you have to do things the way SAFe says if that doesn't work for you. For myself, when someone comes to me and says, "We're using SAFe, and have this-or-that problem," I commonly refer to a SAFe article, and the original source pointers SAFe refers to, and take the discussion from there. To me, SAFe is a discussion starter - not the panacea for all ails.

Dependencies everywhere!

SAFe recognizes that dependencies can be a challenge in complex organizations. It provides clear guidance and practices that make dependencies visible, and then offers a way to address these dependencies systematically. In many organizations, dependencies are inevitable - but at least we know which troubles we have because of them, and can start the discussion of what to do about them. I have encountered more than once that teams found their dependencies unworkable and decided to re-organize. A great discussion to have.

Length of planning intervals

SAFe employs a cadence-based planning approach with fixed-length Planning Intervals (PIs) typically spanning 8-12 weeks. Longer planning intervals provide stability and predictability for teams at the expense of flexibility. However, you can adjust the duration of PIs based on your own context. I have seen Agile Release Trains running 3 1-week Sprints plus a 1-week IP Sprint. That even fits Scrum's old slogan of, "Working Software in 30 days or less" - at scale! Try what works for you, and have the discussion.

Top-down planning processes

Maybe we have the wrong picture in our heads, but who can blame us - when we've been conditioned to think in hierarchies? In a SAFe context, we'd like to decentralize that which makes sense - but not everything makes sense to decentralize. For example, the Product Management function in SAFe could be staffed from team Product Owners, if they have the skills and capacity to succeed in that role, so it doesn't need to be hierarchical. What we need is a clear focus on the bigger chunks of value, and align all teams around them. How this happens can vary per organization, but having each team decide by themselves - doesn't bode well. Please be aware that SAFe encourages active involvement and empowerment of teams and individuals in making decisions.

Not proper Scrum

SAFe is not a strict implementation of Scrum, but rather a framework that incorporates agile principles and practices from various sources, including Scrum. Since many teams already run Scrum and are familiar with the core concepts of Scrum, SAFe has taken advantage of that and it retains the fundamental principles of transparency, inspection, and adaptation. When I coach SAFe teams, I quite often refer to the Scrum Guide, and suggest that understanding and practicing Scrum really well helps a lot getting the scaling part right. Unfortunately, what I see quite often is that organizations have already used a highly dysfunctional Scrum for years, and now want to change that. If anything, the SAFe transformation could be an opportunity to fix the Scrum stuff that was always broken and never got addressed.

Teams become Feature Factories

That's already a dysfunction - because SAFe features should focus on value, not on maximizing quantity of work delivered. We should only have a single ART Kanban that's prioritized by value - and teams should collaborate on shared objectives, using common backlogs and cross-team events to ensure a cohesive system solution that maximizes value. While sometimes, we see that individual teams may focus on delivering their own features irrespective of value, SAFe provides mechanisms such as System Demos and Inspect and Adapt events to ensure they don't go off on a tangent and do a large quantity of low-value work.

Fallacious estimation processes

A lot could be said about SAFe's estimation process, and I have my own opinion on the guidance they give. To keep it simple: its guidance is only for people who don't know how to get started. Coaching and empiricism should lead to an approach that meets the needs of those who need the estimates. We should realize that in larger organizations, where quite often multiple stakeholders, other teams and potentially large amounts of money depend on making fairly accurate forecasts for completion, estimation may have implications that don't exist in smaller contexts. My own go-to example is that we need to absolutely know whether the feature will be ready for the Trade Fair, or whether we need to mitigate. But "Well, we might or might not be ready in time for the fair" - could lead to a major PR disaster, and is probably unacceptable.

One Continuous Improvement event every 3 months is too little, too late

While the Inspect and Adapt (I+A) event occurs at the end of each Planning Interval (PI), SAFe encourages continuous improvement throughout the PI, with both the Scrum-of-Scrums (SoS) and Retrospectives being opportunities to surface and address cross-cutting issues. I myself like to give the guidance that teams are expected to make their own changes and improvements independent of the I+A event, and even share learnings with other teams during that event. I expect teams to bring short-term issues to the SoS, and only bring issues to the I+A which require longer preparation and observation periods, and have an impact far beyond the team boundaries. Most of all, we need to consider that the I+A is a point of reflection, where we detach from the daily routine, and come together as a team-of-teams to discuss the things we need to discuss that we never got to discuss before. There's always something. Yes, we could have such events more often - if you feel that it could help, there's nothing in SAFe stopping you. Try it.

Conclusion

I agree that the Scaled Agile Framework (SAFe) has areas of interpretation and concerns. Expecting it to be a silver bullet is completely unrealistic. It does provide a structured approach for larger organizations trying to make sense of this entire "Agile" thing, though - but that only works if they have someone who understands more than just what the material says. When you can address the complexities of large-scale development, cross-team collaboration and overall alignment while continuously improving, you've succeeded with SAFe. To get there, you absolutely must customize SAFe, and use it wisely - otherwise it will become a mess, and that's why you need some folks who know what they're talking about. And I've seen that mess: The shambles take years to clean up. The people who support your change initiative need to be able to address critical concerns based on their own experience and learnings. And the people in your organization who have concerns need a time and place to voice these concerns - because only then can we truly improve.

Team archetypes: basic setups

 "Which kind of team setup should we choose?" - a common question in many organizations with the luxury of having an IT department bigger than a single team. First of all: there's no universal best answer - the choice is often constrained by factors outside the teams' control - such as HR, legal,  company politics and so on. Irrespective of such details, let's explore what the archetypes are.

As long as there are only enough people for a single team, the question "which setup do we choose?" is - fortunately - moot: build a team and get to work. Approaches like Skunkworks, which predate software development, conclude that a single team is always less overhead than multiple teams, and the overhead can become a performance killer - down to the point where a single, effective team can outperform half a dozen teams struggling to get their act together.

This entire article is written under the premise that a single team isn't enough to get the job done, and that we already exhausted all feasible options of doing the same with fewer people - hence: there is an indisputable need to set up a multi-team structure.

Four Team Archetypes

Let's take a look at the team setup chart. For simplicity's sake, let's just assume that the only functional specializations are Analysis, Coding and Testing. The key points of the article don't change if we have further specializations, such as Frontend/Backend/Database development or include Operations. If anything, the problems caused by specialization would be exacerbated.

Component Teams

One of the most common setups for organizations with just a handful of teams is the Component Team: each team consists of the people required to deliver a single component. This works splendidly as long as there are only few components, and they are loosely coupled. In that case, each team can perform their work independently. It becomes an entirely different ballgame when components are tightly coupled, interdependent - or worse: co-dependent.

Key questions to ask when setting up component teams include:

• Will each team have all the skills and means to complete the delivery lifecycle of their component? If the answer is "No," component teams will quickly find themselves blocked and unable to consistently deliver value. Proceed only if the answer is "Yes."
• How close is the coupling between each component? If the answer is, "Tight", component teams will likely find themselves rendered ineffective. Proceed only if the answer is, "Very loose."
• How dependent are the components on each other in delivering end user value? If the answer is anywhere on the scale from "Master-Slave" to "Closely interlinked", at least one component team will be a bottleneck, and overall delivery performance will depend on the constraining team.

Specialist Teams

The staple setup in corporations with hundreds, potentially thousands of IT people is the Specialist team: each team consists of specialists performing a single function in the software development lifecycle. In case of very large organizations, we often see a double specialization - each component having their own specialist teams performing only a single type of task. 

This kind of "industrialized, conveyor-belt delivery" process optimizes resource efficiency over effectiveness, and typically ends up with massive bottlenecks diminishing flow efficiency of value delivery close to Zero: Regardless of how many people are involved, "there are always too few people." The problem is less the amount of work than the immanent optimization favoring workload over results.

Key questions to ask when setting up specialist teams include:

• Where will the bottlenecks be? You will have at least one bottleneck, and if it's not where you want it to be, you won't understand why your organization is so ineffective.
• How do we keep flow across teams balanced? Managing flow in specialist teams requires understanding the intake, throughput and flowback rates of every single team. If these are out of balance across teams, work will get stuck.
• How will people communicate? The classic Waterfall-style "communication by document" is slow, inefficient, ineffective and error-prone. Proceed only when you have a feasible solution for communication flow.

Feature Teams

The key reason for feature teams is to reduce the cross-team friction caused by delivering unusable component work which requires integration efforts at a later point in time. Feature teams minimize the handovers across team boundaries which lead to additional communication and waiting queues. 

Neither component nor skill boundaries will stop the flow of work from demand to delivery in a feature team. The way of working in feature teams is very natural - people sit together, do whatever it takes, and get the job done.

Key questions to ask when setting up feature teams include:

• Which organizational impediments prevent us from setting up feature teams, and how do we overcome them? The barriers are often more centered around management, structure and contracts, not at shop floor level.
• How do we keep team size low and still make sure people know what they're doing? Feature teams require a lot of initial learning as every team member is confronted with a vast amount of things they don't know.
• Which engineering practices will we use to ensure that teams won't constantly step on each others' toes? If you have no solutions, you need to find these before proceeding.

Generalist Teams

The generalist team is often considered the holy grail of Agilists. A generalist team is multi-skilled both in software engineering, and in the product domain: each team consists of individuals who can exercise multiple functions in the development lifecycle, and who are able to work on all relevant components of their product. Generalists hardly find themselves in bottleneck situations, and are always able to contribute value. Setting up generalist teams has a massive learning curve, requiring continuous multi-learning. In return, generalist teams minimize the concern of "truck count," and they are able to flexibly take on any feature that maximizes value.

Key questions to ask when setting up feature teams include:

• Where are currently our knowledge constraints? Generalist teams immediately expose where the number of individuals with either product domain expertise or specific lifecycle expertise are too rare to ensure each team has seed knowledge to get started.
• How much specialization is really required? If you're working on teams where lacking deep domain knowledge becomes a life-or-death decision, generalization may not be your primary choice. These cases are rarer than we would think. Based on the Pareto Principle, 80% of the work requires 20% of the knowledge - and generalists can do that.
• What does it take to set up generalist teams? How do we get started? Can we start right away, should we upskill feature teams or component teams? Do we need to re-organize entirely?

The most common concern towards setting up generalist teams is, "Not everyone can do everything." Indeed. It takes time and learning, and not everyone will specialize deeply in everything. There are two key points to ponder: the starting point, and the optimum point. 

At the starting point, we set out with people who may find themselves unable to contribute outside their specialization, and based on where the team's constraint is, that's what they need to learn first.

At the optimum point, team members can offer basic contribution wherever it is needed - and "wherever" isn't "everywhere." A generalist team is effective when there are no skill-related bottlenecks in the team, not when everyone is a master of everything. It could mean that a tester understands some basics of coding and can make simple changes by themselves - not that they need to establish profound coding expertise. 

What's the difference between generalist and feature teams?

Feature teams are a lower standard. We can easily set up a feature by putting an analyst, a developer and a tester into one team and giving them access to all the modules they need to work with.

Generalist teams should be feature teams. Only some feature teams are - or evolve into - generalist teams.

A generalist team consists of coders who can analyze or test, testers who can analyze and maybe write some code, and analysts who can also code or test. People who worked in smaller companies are often used to this way of working - people from a corporate environment are often unable to even grasp this concept as it's too detached from their reality.

How about Generalist Component teams?

Small teams of people, each of whom can do most of the work on their own components. This pattern is very typical in modern organizations opting for microservice architectures.

Dissolving specialization boundaries within teams is desirable to increase "truck count," and definitely useful. We minimize delays, handovers and information gaps within the team. On the other hand, the effectiveness of the overall development organization remains constrained by the lowest performing component team. Component team organizations can't solve this fundamental flow impediment, hence the teams' generalization ends up being a local optimization.

We can even find this local optimization working against us - the highest performing teams might create overload on other teams, further reducing the overall performance of the organization. High-performance generalist component teams might render the entire organization ineffective, despite best intentions.

What to choose?

In other articles on the topic of team archetypes, we will explore a little further what the implications of each archetype are. The topic is complex, hence there is no simple answer. The best answer is: "Caveat emptor." Know what you're opting for and what the consequences of your choices are.

What about Mix-And-Match?

Should every team within an organization have the same setup? Wouldn't it be better to mix-and-match? A few component teams doing bulk haulage, supported by a few specialist teams for Feature Analysis and End-to-End testing, maybe with a Task Force Feature Team for high urgency tasks? 

That's actually what we find in many organizations, so it's definitely a realistic scenario. Our question is less about "Can we do that?" than it's about, "Should we do that?" - and again: there's no simple answer. As a product matures and growth reaches a plateau, that's most likely what we're going to find. For emerging products, the suggested mixed setup is probably not going to provide the necessary performance to succeed. 

Where to start?

Try starting with the simplest setup, and only add complexity when inevitable.

And that simplest possible setup is a small number of Generalist teams. If you can, try that first.

PI-Planning: Factors of the Confidence Vote

 The "Confidence Vote" is a SAFe mechanism that is intended to ensure both that the created PI Plan is feasible, and also to ensure that people understand the intent behind creating the common plan - what it means, and what it doesn't. Implied in SAFe are two different kinds of confidence vote with slightly different focus.

Train Confidence Vote

The "Train Confidence Vote" is taken on the Program Board - i.e. the aligned, integrated PI plan across all teams. All participants of the PI-Planning are asked to simultaneously vote on the entire plan. Here are the key considerations, all of which should be taken into account:

Objectives: Feasibility and Viability

First, we should look at the ART's PI objectives realistic, and does it make sense to pursue them? Do we have our priorities straight, and are we focused on delivering maximum value to our customer?

High Confidence on PI objectives would imply that these objectives are SMART (Specific, Measurable, Ambitious, Realistic, Timebound) within the duration of the PI.

Features: Content and Scope

Do we have the right features, do all of them provide significant progress towards our objectives, did we pick a feasible amount, and did we arrange them in a plausible order and are the right people working on them? Is the critical path clearly laid out, and is the load on the bottleneck manageable?

High Confidence on Features would imply that everyone is behind the planned feature arrangement.

Dependencies: Amount and Complexity

If we have too many dependencies, the amount of alignment effort throughout the PI will be staggering, and productivity is going to be abysmal. You also need to manage external dependencies, where the Train needs something from people who aren't part of the Train, and you need to pay extra attention when these people didn't even attend the PI-Planning.

High Confidence of Dependencies would imply that active efforts were made to eliminate as many dependencies as possible, and teams have aligned already how they deal with the inevitable ones. When people either mark a high amount of dependencies without talking about them, or you feel that some weren't mentioned, that should reduce your confidence drastically.

Risks: Quantity, Probability and Impact

Risks are normal part of life, but knowingly running into disaster isn't smart. Were all the relevant risks brought up? Have they been ROAM'ed properly? How likely will you be thrown off-track, and how far?

When you consider risks well under control, that can give you high confidence in this area - when you feel like you're facing an army of gremlins, vote low.

Big Picture: Outcomes and approach

After looking at all the detailed aspects, take one step back: Are we doing lots of piecemeal work, or do we produce an integrated, valuable product increment? Do we have many solitary teams running in individual directions, or do we move in the same direction? Do you have the impression that others know what they're doing?

When you see everyone pulling on the same string and in the same direction, in a feasible way, that could give you high confidence. When you see even one team moving in a different direction, that should raise concerns.

Team Confidence Vote

During your breakout sessions, the Scrum Master should frequently check pulse on team confidence. The key guiding question should be: "What do you need so that you can vote at least a 4, preferrably a 5, on our team's plan?"

Your team plan is only successful when every single member of the team votes at least a 3 on it, so do what it takes to get there. It's entirely inacceptable for a team member to lean back comfortably and wait for the team confidence vote and then vote 2, they should speak up immediately when they have concerns. Likewise, it's essential that teams have clarified all the issues that would lead them to vote low on their team's plan before going into the PI confidence vote.

When your team can not reach confidence, do not hesitate - involve Product Management and the RTE immediately to find a solution!

Here are the factors you should consider in your team confidence vote:

Objectives

Does your team have meaningful objectives, are you generating significant value?

Understanding

Do you really understand what's expected from you, how you're contributing to the whole, what makes or breaks success for you - what the features mean, what your stories are, what they mean, and what's required to achieve them?

Capacity and Load

Do you understand, including predictable and probable absences, how much capacity your team has?  How likely can you manage the workload? Have you accommodated for Scrum and SAFe events? Would unplanned work break your plan?

Dependency Schedule

Can you manage all inbound dependencies appropriately, do you trust the outbound dependencies to be managed in a robust way? What's your contingency plan on fragile dependencies?

Risks

Are you comfortable with the known risks? Do you know your Bus Count, and have you planned accordingly? Do you trust that larger-scaled risks will be resolved or mitigated in time?

Readiness

Right after the PI-Planning, you will jump into execution. Do you have everything to get on the road?

Closing remarks

This list isn't intended to check each factor individually, and it isn't intended to be comprehensive, either. It is merely intended to give you some guidance on what to ponder. If you have considered all these, you probably haven't overlooked anything significant. If you still feel, for any reason, that you can't be confident in your plan, by all means, cast the vote you feel appropriate, and start the conversation that you feel is required.

It's better to spend a few minutes extra and clarify the concerns than to find out too late that the entire PI plan is garbage.

SPC Competency - what companies can do

In a recent post, I gave my opinion about the condition of the SPC. I have received some pushback, in multiple directions:

1.  I'm being too negative.
2.  The problem isn't limited to SAFe or the SPC.
3.  What's the solution?

Let me address these points quickly before digging in.
First, I made this post because I care. Not to place blame, but to spark a discussion. And I did.
Second, I agree. The growing problem of ersatz agile coaches would still be getting worse even if SAFe didn't exist. But I don't give a hoot about the ever-growing number of pointless certing schemes out there. I would prefer if we could improve the SPC community.
Third, I don't know. But I have ideas based from what I have seen.

So - let's make this article about point three.

Getting out of the dilemma
I base these ideas on personal observations (in italics) made from one client - they know who they are.
This article is a kind of action-item list for things you may want to do in your organization to maximize the likelihood of having "good" SPCs.

The certificate is nothing - what matters is the person who bears it!

Dismiss Ersatz SPCs fast

When you identify Ersatz SPCs in your organization, you should let them go quickly. Preferably, you don't give an external SPC a prolonged contract to begin with - start with monthly contracts that you can simply choose to not prolong.
When you hire SPCs as internal staff, use a probation period to see if they're worth their salt.
The challenge is that you need further mechanisms to determine where prolonging makes sense.

My contracts are often limited to supporting ART launches. Although I believe that this isn't how you build up a sustainable Lean-Agile enterprise, I am currently considering to offer fixed price services like ART ramp-up support with success clause.

Check your metrics

By looking at the wrong metrics, you run a huge risk of ditching the right people and relying on the wrong people. Metrics such as numbers of ARTs launched (fewer is better), amounts of people trained (irrelevant) or teams converted to "Agile" create effort and trouble without value. Success metrics should be business relevant figures, and success should be measured in terms of how your organization creates value.

Transformation metrics like customer satisfaction, time-to-market and product quality are much harder to game and let you know whether your SPC is making show or progress.

Avoid wholesale packages

This one is key - because too often, organizations look to a single large consultancy to take care of the entire staffing question.

When you ask an agency to bring in droves of SPCs to do an Enterprise transformation, you're going to get a few good ones and a lot of bad apples. It's inevitable. Don't hire SPCs by-the-dozen. Create a process where you, as a client, are in control of every single SPC so that you can decide to terminate Ersatz SPCs without getting contractual problems.

I see Business Owners interview every SPC individually, and being from one specific agency can't be a success guarantee to be placed. Steer clear of "bargain bins" here - if Agency A allows you to place a second candidate at a discount, that's probably not to your advantage!

Rely on Expert opinion

Do not rely solely on Business Owner or RTE opinion as to what makes a good SPC, as the art of snake oil selling includes deceiving the Ignorant. You don't want Snake Oil.
When a Business Owner has a bad feeling, they should immediately turn to an SPC for advice.
Create a stream of communication between Business Owners and SPCs who aren't invested in the ART.

I have been invited to observe PIP's and offer feedback to the Business Owners. This approach strengthens well-meaning SPCs and exposes Ersatz SPCs.

Give SPCs a role in strategy

SAFe isn't just about lumping development teams together in ARTs, The key to Enterprise Agility is bringing different parts and layers of the organization together in transparent alignment. Experienced SPCs can help there, if you let them. Especially, don't determine what the SAFe organization should look like and then just delegate it to SPCs. This attracts Ersatz SPCs who will act as willing execution agents for poor strategy.

Include external SPCs in your Transformation team, while avoiding to delegate the Transformation entirely to external SPCs. Offer the SPCs transparency into the Transformation - and figure out ways to let them contribute beyond ART level.

Avoid One Man Shows

It looks tempting to put a single SPC in charge of a single ART launch - which creates two major risks: First, if that single SPC is a washout, you'll discover that after the PIP failed. Second, if that single SPC gets stressed out, you stand empty handed. Try distributing the load.

Involving multiple SPC's with each ART increases transformation quality and decreases risks. It's good to at least have other SPCs check in on a new ART occasionally, to see if the lead SPC requires support. Ideally, don't save on SPC capacity. 1-2 SPC per 50 people isn't too much.

Separate concerns

SAFe is a huge topic. For starters, we have the domains of strategy, training, value streams and technical aptitude.

Consulting isn't coaching isn't counseling. Process change, teaching people new practices and structural reorganization are different pairs of shoes. Managers have other needs than developers than product people. 

Few people can take care of all of that. Most excel in one area, some in two or three. Even if someone could do everything, they'd spread themselves too thin if they would do all of it at once.

Hence, allow people to play out their strengths. Let SPCs determine how they can contribute - and let them do exactly that.

Always involve multiple SPCs to launch an ART. Not everyone needs to be around full-time, as long as you ensure that people do the thing they're good at, not the things that are really not their strength.

Pair and Shadow

Once you have identified some competent SPC's, ensure that they are present at key SAFe events, such as the Value Stream Workshop and the PIP. An hour of observation and a short conversation between them and the other SPC will be very revealing.

I have very much enjoyed the conversations with a senior SPC who critically probed the dysfunctions he observed during my ART launch PIP.

Build an SPC Community

When skilled SPCs talk, discussions get interesting. By having a community of peers, you will quickly see:

1. Who contributes and who doesn't.
2. Whose contribution adds value and who blathers.

The SPC's you want in your organization are those who care to make a difference. Observe those who don't want to join the SPC community as a vehicle to have a bigger impact - they might have something to hide!

I enjoy every session of my client's SPC community, because it's a great way to look at the big picture and avoid local optimization. Personally, what I like most is the ability to draw attention to enterprise-wide issues.

Create a Central SPC Work Backlog

Nobody is Superman. We all have strengths and weaknesses and nobody can do everything. We should focus on the things we're good at. There's a lot of SPC work, starting with awareness sessions, Value Stream Workshops, going over trainings, program backlog workshops, PIP support, Inspect+Adapt events and many more. The SPC community should have a backlog where all known work can be made visible, so that SPCs can pull the items where they're confident to add value.

I have been "One Man Army" Coach before. It's terrible. Being able to access an SPC activity backlog where one can get items covered that one isn't good at and pull items that make the organization successful is a quantum leap.

Identify Organizational Antipatterns

Current Culture has an impact on Agile Transformation. No single SPC sees the big picture, it becomes visible when we put our individual perspectives together. This helps us identify systemic change potential and levers going much beyond the scope of a single ART. Ersatz SPCs might reveal themselves by claiming antipatterns that aren't, or claiming clear antipatterns are fine.

When we had the idea in the SPC community to collect antipatterns, I had a hundred things on my mind. It was fascinating to learn where I was victim of my own bias and where others shared my observations.

Meet. Face to Face.

In large corporations, it's easy to remain anonymous. This creates a hiding place for Ersatz SPCs. When you meet for a day in a setting like Open Space Technology or Liberating Structures Workshops, you can learn about who you're dealing with. Many minds breed new ideas.

The best you can do is create an Open Community Meetup in your company's location. This creates a time and space where you can meet your own peers. It can likewise become a mechanism to learn about one's own organizational bias and be a vehicle for recruiting interested outsiders who could make a valuable contribution.

Fuckup Nights

Talking about where "you dun goofd" isn't easy, but we all do. I do. All the time. Maybe my last article was a goof - I'll let you determine that. Provide a forum where people can talk about their mistakes openly. We can help each other out, and we can learn from others' mistakes as well.

The Agile Academy

I've taken two barrel loads of shots against the Agile Academy - and it might appear as I am totally against this idea. I am not. Indeed, I mentioned before that I believe that a properly set up Agile Academy is an essential instrument in sustaining and nurturing Enterprise Agility. I am against using this approach too early, exclusively or as a false dichotomy.

Use Neutral Trainers

An Agile Academy is very dangerous when it relies on people with local bias as trainers, who in their worst case have built their own curriculum based on their personal understanding and then proliferate this in the organization. Bringing in a mix of reputable external trainers to conduct trainings on Lean/Agile basics irrespective of your local context is more costly, but it provides a balancing instrument in the organization.

The client who is running a quite successful "Agile Academy" has a number of training partners who are not part of their organizational culture. This ensures the trainers get neutral market feedback and do not adapt to cater to your current status quo.

Trainers must be Doers

A very common mistake in Corporate Agile Academies is that you raise fulltime Inhouse Trainers who lose touch with organizational reality. 

My heart jumps when I hear that people who are doing the work in the trenches are giving trainings and feeding back their learnings from the training into their daily work, and vice versa.

Every ART SPC must take a role in training

When the Agile Academy creates a disjoint between trainer and the ART SPCs, that may be efficient from an organizational perspective, but it's terribly inefficient from a learning perspective. The Lead SPC of an ART must be in the training room, ideally as a trainer or at least as co-trainer. This strengthens the bond between them and the people they work with on a day-to-day basis. They can link training content to their daily work - and see from the training questions where further support after the training is required.

Ideally, the Academy relies on SPCs who also work in the trenches and has a standard process where the ART SPC is part of the training process.

My client didn't do this initially, and this created negative feedback swiftly as Agile Academy processes weren't synchronized to ART launch processes.

Choose candidates wisely

SPCs are multiplicators either way. A good SPC spreads a good culture. A bad apple spreads a bad culture. Is it better to err on the side of caution? I don't know. But what do you do if you have an internal SPC with an anti-agile attitude? Do your processes accommodate for that? Maybe they will use their accreditation to wreak havoc elsewhere. Although that may not be your problem - it affects the global SPC community.

Wait before you train inhouse SPCs

Being an SPC is a high responsibility. I believe that training people without agile experience as SPC is setting them up to fail. Especially if you have no Agile history in your organization, you will be challenged to find people who have enough background to succeed as an SPC. Wait before moving the SPC role "in-house". Give people time to collect experience as Scrum Masters or Release Train Enegineers before you move them into an SPC role.

My client went through an Agile Transformation years ago. There are Scrum Masters with vast experience on their back, and they have the battle scars to prove it. Such people make great SPC candidates.

Avoid role poker or favors

Internal SPCs will carry the burden and responsibility of fostering and sustaining Lean-Agile Practice long after the Externals are gone. They need to be the people who care to do this. If you select Internal SPCs by means of favoritism or to appease political demands, that's a signal that you're preserving a status quo where power play beats performance.

I have participated in deep discussions with Business Owners over the implications, pros and cons of nominating SPC candidates for the Agile Academy. As part of my coaching, I also had 1:1 conversations with the candidate to see if this is how they personally felt they could add most benefit to the organization.

Be picky

There should be no guarantee that a candidate nominated as SPC becomes an SPC. Let some time pass between nomination and training. Peer interviews by SPCs and collaboration with SPCs who are outside the line responsibility of the nominating Business Owner are a good way to do this.

The first SPC candidate I mentored for my client was probably at least as capable to meet this responsibility as I am. He shadowed me and asked questions. I coached him for a few months. This was part of his onboarding process before he went for training.

Provide ongoing support

An SPC training is nothing more than basic awareness. It doesn't make an SPC, and it doesn't equip an SPC to bear their responsibility within the organization.

SPC Candidates should ...

1. join the company's SPC Community as early as possible.
2. have a mentor/coach even before their SPC training.
3. be able to rely on their mentor/coach after their SPC training.

I have observed others becoming SPC in a slow process, where seasoned SPCs were always present to support one in growing into the role. Combined with the above items from the community, this keeps weird outcrops under control.

Don't cut ties with external SPCs too quickly

I have mentioned the Dunning-Kruger Effect in the original post: how do you know what you don't know? And how do you know when you're ready to move on alone?

Fading out external support slowly is, in my opinion, imperative. Don't throw out your Externals on the day after PIP launch. Consider a prolonged period before the SPC moves on. I'm talking about months, potentially years before the last External finally moves on.

Why? Otherwise, you reward SPC's who create fire+forget show effects.

Make sure that an external SPC is responsible for a first successful PI with valuable outcomes, and give them the opportunity to make this happen.

I have seen ARTs reduce the involvement of external SPCs to I+A event attendance, PIP coaching, call-on-demand and many other means of slowly breaking dependency without cutting ties.

Plan the future for external SPCs

Some organizations rashly and harshly cut ties with External SPCs after the ramp-up phase. 

Even after the SAFe rollout is over, I strongly suggest to keep some brains close for collecting feedback, new impulses and ideas.

Part of the phase-out process needs to be creating a strategy for sustaining an influx of valuable external knowledge without falling for dependencies. And here, I'm not talking about maintaining external trainers for the Agile Academy - I'm talking about people who stand where the rubber meets the road, that is: in the trenches.

That's it.

I hope this is a more positive outlook on how I envision corporations contributing to a better SPC community in the future.

Agile Academy - McKinsey, you get it all wrong!

In a recent Whitepaper (LINK), McKinsey publised an approach for "growing your own Agile Coaches", i.e. creating an "Agile Academy". While I may even agree with the general idea and some major points and ideas proposed in the paper, it fosters and relies on a few massive misunderstandings that could plunge your company into disaster.

Executive Summary

With their whitepaper, McKinsey have proven that they themselves are indeed nowhere near what they claim that you need to become an agile organization - so don't take their advice, they've disqualified themselves!

Since the below article is quite extensive, let me provide an abridged version:
McKinsey demonstrated that they have a low understanding of what agility is, what agile coaches actually do, they argue fallaciously to suggest a solution to a problem that you don't even want to have: the need for masters-of-all-trades.
The suggested solution doesn't match the problem statement: They ignore the temporal dimension of the problem and move it into a different domain to make it look like it addresses the proposed challenge. The approach doesn't yield what they claim you need.

By following the McKinsey approach, you will end up with a lot of people with decent, but limited understanding who won't have what it takes to make a breakthrough change.

What McKinsey gets right

Some of the key points that they get right:

• "Scaling Agile" isn't done by copy+paste. An Agile PMO isn't a solution, either - as agility and PMO are contrary approaches.
• In a VUCA world, we must move away from consultants who "implement best practices". It's more sustainable to use coaching to help people learn and discover.
• Without good coaches, your chances of becoming or sustaining an agile organization diminish rapidly.
• Enterprise agility also requires taking care of processes anchored outside IT, such as budgets or performance reviews.
• You can't ignore current reality - agility isn't a cloud castle.

You don't become a master by attending a course.

I also agree that a 2-days course doesn't make one a "Scrum Master", especially not an "Agile Coach" and that just the prospect of a higher paycheck inspires people without even the remotest form of qualification will appropriate these titles in their profile.
I'll even concede that people who have little to no understanding of agility will rewrite their CV's to make it look like that their project manager Command and Control role in a classic Waterfall project which gloriously went down the drain was actually an "Enterprise Transformation Agile Coaching" project - and that makes it incredibly difficult for classic HR mechanisms to filter out who is indeed a qualified coach.

Where things get fishy

There are many assumptions in the article that I'll just put into question, as they haven't been backed up.

McKinsey clings to a number of beliefs that are questionable and will not help your agile transition.

• For what and how many "Agility Coaches" do you really need? Why even introduce yet another role instead of helping Scrum Masters learn to expand their horizon, when self-organized teams need a supportive environment, not even more complexity?
• How can there be "a clear approach to enterprise agility" when the entire problem is that in the VUCA world, there is no One-Size-Fits-All solution - which is the reason why we need agility to begin with? And if so, how is this approach better than approaches like SAFe or LeSS, which have been around much longer and have been used in a broad spectrum of organizations?
• Why do they believe that "the role of the Scrum Master is limited when it comes to scaling agile" when all they quote as reason for their beliefs are antipatterns on how not to be a proper Scrum Master? Isn't that like saying that you believe ships are unfeasible because you threw a rock into the river, and it sank?
• Why define "the vision and scope of the agile transformation, informed by assessment of the organization today"? Is this how you do strategy? Wouldn't it make a lot more sense to define goals by where the organization needs to be than by where you currently stand?
• How do you define an "Agile Blueprint" if the entire point of agility is that adaptability to circumstance isn't universal, a point they themselves made in the introductory section?
• Why do they talk about "the agile operating model" rather than about being flexible, responding to change - which isn't a model, but an attitude and capability?
• How can you change your reality by operating within current reality? Wouldn't establishing a new reality require going beyond current reality? And isn't "reality", as described in the article, merely a perspective held by people without agile experience?
• If we realize that the problem of Enterprise Agility is that complex system change isn't molecular, but rather molar in nature - how can we succeed by focusing on subsystems within an otherwise static environment? 

Where it gets really problematic

The article creates a false dilemma and then so conveniently proclaims a solution, which isn't even one.

McKinsey sets up a false dilemma to sell their "solution".

Setting unrealistic expectations

A person who can do everything at mastery level won't be interested in a limited role.

The "Agility Coach" as defined in Exhibit 2 has a role complexity that shrinks the amount of people who could meet that responsibility to Zero.
Just ask yourself: How many people do you know in your organizations who have management skills, facilitation skills, developer skills, agile framework skills, technical skills, business skills - and the time to do all of this at a Mastery level? Each of those domains requires focus, otherwise mastery will wane rapidly. Top it off with that person also being creative, innovative thought leader, and you're looking for a Jack-of-all-trades, master-of-all.

Typically, a developer who learns management will lose their technical edge within a few years. The line manager who works strongly to coach and grow their people will not be spending time to learn facilitation techniques. The manager who moves in strategic management will have little time to work on empathy and listening skills, simply because their responsibilities lie elsewhere. The business expert will not be a technology expert - and vice versa. And finally, being innovative and a though leader doesn't combine well with being tied to a single organizational context.

Now imagine that you put up mastery in all of these areas as a mandatory requirement - and answer: Why should such a person work for your organization rather than start their own business?

Basic training

Even a 20 weeks curriculum won't remotely give a person the breadth and depth to be an "Enterprise Agile Coach".

Don't get me wrong. I love the idea of an "Agile Academy" and I have worked with organizations who have one. And I have worked with people who went through Agile Academy curriculums. They're great people to work with, as they do indeed both understand the basic tenets of agility and their specific role within the organization.
But a 12-20 week course (3-6 months, taken generously) in addition to the regular work isn't going to make the cut, either.
A Scrum Master training is just a starter, a teaser, a foretaste. It's nowhere enough to say one has mastered agility. A 12-20-week part-time academy is definitely one step further, but still a far shot from the experience and qualification that professional agile coaches bring.

I have stated in another article that the Scrum Master journey, if taken seriously, over the years, might take a person into the domains of technology, personal and team and systemic coaching, quality, process, general and strategic management, mathematics, psychology, sociology and philosophy. Just two days on each of these subjects, and we haven't covered any business domain yet. There is no way that even a 1-year part-time curriculum will give a person even a remotely viable understanding.

Moving the Goalposts

There is no single curriculum to do what McKinsey claims is required.

Participating in an "Agile Academy" program doesn't produce anything that even remotely resembles the Jack-of-All-Trades proposed by McKinsey's Exhibit 2. An academy program has to set a clear focus and may give teasers on fringe areas. The outcome of participating in an Agile Academy is not a technological mastermind who can innovate, coach teams and management, develop a strategy roadmap and lead enterprises to success. It's simply people who are decently equipped to meet a specific function within an enterprise,
There would be different programs for people who would:

• support one or multiple agile teams ("Scrum Masters"),
• professionally coach individuals ("Coaches"), 
• organize and facilitate larger events ("Facilitators"),
• train organizational units who are yet unfamiliar with agile approaches ("Trainers"),
• accompany agile organizational units with methodology advice ("Consultants"),
• take care of the transition itself ("Organizational Change Managers"),
• lead program and product development from a business perspective ("Product Owners"),
• create and innovate ("Developers" / "Designers"),
• fill day-to-day coordination roles ("Managers"),
• have people responsibility ("Leaders").

And this isn't even talking about the domain of technical mastery yet, where a decent training program outdates before it's completed.

If we would - for argument's sake - say that a person goes through all of the domains listed above, then each domain gets like a day or two: does that qualify for "mastery"? How much trust would you place in a Change Manager who has taken a single course? Would you put anyone on your Board of Directors whose management experience is limited to one day of training and a week of practice?

While it's indeed possible that one individual goes through a series of such academy programs, and while indeed many of us senior agile practitioners on the free market have enhanced capability in multiple of these domains, let's be blunt: You can't have a Master-of-All.
Finally, a person who ran through ten quarter-year programs to gain "mastery" has been in education for a minimum of two and a half years - and that's definitely not something that you will have at the start of a transition.

Limited quality

Part-time focus isn't the same as full-time focus

There's a reason why world thought leaders like Marshall Goldsmith don't excel in all of the domains proposed by McKinsey. To be the best in your field still requires full-time dedication and serious effort. Nobody becomes a thought leader by spending a couple weeks in a training academy. The best people coaches aren't software developers, the best software developers aren't people coaches. Taking the "T-Shape model" - people who have a broad insight into many domains lack depth in at least one of them, worst case - in all.

I like to use the circle illustration. A person has 100% of their time, and it doesn't matter whether we're talking about lifetime, work time or agile coaching time. Let's just talk about 100% of their time. What would you want them to invest this time into - you can choose anything.
You will realize that as you put the items into the circle, each additional item decreases the proportional share available for all the remaining ones. An increase in focus on agility automatically decreases the focus on everything else - and putting four items in there ("Self mastery", "coaching", "agile mastery", "commercial acumen") would mean that at least one gets neglected unless the person spends no more than a quarter of their time on each of these domains.
You will not become a "Master" by spending 25% as much time on a domain as a full-time dedicated expert would - and definitely not a "thought leader!"

McKinsey started with the broad claim that they have a clear solution to the self-created dilemma of finding people who have a large list of qualities, but the solution is setting up a pool of people who, if following their proposed suggestion, will not have any of the qualities on the level they insist are required!

Ignoring the setup

Agility is based on empiricism. You have to start by inspecting and adapting, not by setting up an academy.

Starting your own, internal "Agile Academy" isn't done overnight. To create curriculums that match your need, address your challenges and have a sufficiently high quality of materials is a high-effort process and relies on having the expertise to begin with. This is essential to keep agility flourishing over the years, but if this is your first step, you're not going anywhere in the next couple of years.

As agility is based on empiricism, you need people who can bring both the theoretical and practical experience of empirical ways of working into the organization. These are the people who typically get hired as "Agile Coaches". There is no way to eliminate this step, and you can't copy+paste another organization's curriculum to circumvene it.

You have to run agile development within your organization to learn what works - and what doesn't. After you did this, you can roll this out in whatever way you choose - for example, by seeding multiple teams, pulling in additional units, doing a strategic rollout, setting up an academy or whatever (I have opinions on these approaches, but that would be too big for this article). But the first step of bringing in seasoned practitioners who can shine some light into how agility practically works within your specific organization is inevitable.

The big lie about agile practitioners

"outsourcing these key roles will often lead to an influx of agility coaches who are disconnected from a company’s culture and want to dogmatically apply agile the way they know it rather than the way it needs to be molded to a particular organization" - McKinsey

Basing a core statement of the paper on a lie about agile coaches doesn't further your cause.

Let me call it for what it is: a lie, as if McKinsey had any experience in the field (which I will take for granted, otherwise the entire whitepaper is moot), they would know that the last attribute that can be used to describe proper agile coaches - is dogmatism.
I would therefore disagree with the sweeping statement that agile coaches who do not come from your specific organization are often dogmatic and will insist on pushing their pet framework rather than understanding and working with your current reality.

The first big part of the lie is that a person who pushes a specific agenda isn't a coach to begin with. 

The second part of the lie is that anyone who has experience with agile enterprises will know that enterprise transition is a long, strenuous process that requires deep understanding of systemic interactions, specific attenuation and oftentimes, compromise. 

There's even a community of so-called "Agnostic Agile" practitioners, which I would highly recommend looking into, who reject framework dogmatism, because dogmatism isn't agile. 

Not addressing the real problem

If you don't know what qualified external people are, why would you do a better job in selecting internals?

McKinsey proclaims that companies often find themselves hiring external coaches who are, in short, utterly unqualified. I agree. This happens. Organizations who aren't agile often have trouble selecting for the right people and qualified agile coaches are not dime-a-dozen.
They then proceed on the very flawed assumption that organizations who find themselves incapable of identifying who the right externals are would do a significantly better job at identifying the right people internally.

What we see here is a classic bait-and-switch: "You have no way of figuring out who the right external coaches are" [Reason: You don't know what the right mindset is and your HR mechanisms often make it impossible to onboard the right people] "so just identify people internally and grow them" . This doesn't answer the question how to identify what this right mindset is that you couldn't identify when selecting for external agile coaches. It also doesn't answer how to fix the broken HR processes which prevented getting qualified people on board. And to draw a full circle, if you can't even spot the right mindset when recruiting - how are you supposed to teach it?

If you can't find the right people externally (where a few fairly talented people exist) - what makes you think you're better at doing it internally (where definitely nobody with all the requirements from Exhibit 2 exist)?

Closing Remarks

Every company has employee churn, just by statistics. Some people leave, others come in.
Everyone in the company should be familiar with the company's specific ways of working. Agile principles and practices should be understood by everyone.
An Agile Academy, which sets up both starter curriculums and ongoing education in which interested employees can choose to participate is a feasible way of achieving this. Formulating your own curriculums to bring people with overarching responsibility "into the know" is an effective way of moving forward.
I do indeed support agile academies as an ongoing mechanism of sustaining enterprise agility.

However
An agile academy is not strategically viable to start an agile transition - and it is not a replacement for onboarding external expertise in the early phases.
Finding the right external agile coaches in the beginning is essential to get your initial seeds of agility to flourish, and it's important to ensure the curriculums aren't imprinting the Peak of Ignorance as per Dunning-Kruger-Effect, because that would kill enterprise agility before it could ever start. By just following the ideas proposed in the initial whitepaper, this is exactly what would most likely happen.

Even when an "Agile Academy" is set up, there are a number of immense dangers:

• Curriculums focus too much on specific methods and practices, thereby being limited in usefulness and outdating rapidly
• Standardization" or "blueprinting" is anti-agile, any curriculum aiming in this direction doesn't go in the right direction
• Forcing or coercing employees to participate in the Academy invalidates the entire idea
• Senior managers and HR need to lead by example and go through the curriculums lest the Agile Academy becomes a mockery of itself.

Five sentences that will kill your Agile Transformation

There are some massive faux-pas statements with which senior management, potentially without even realizing, can kill an Agile Transformation within less than five seconds.

I normally avoid the term "Agile Transformation", because I think the idea itself is a dangerous suggestion that this is a time-limited process which can be completed to create a final stage, but let's look beyond that for a moment to focus on organizations who have explicitly started an Agile Transformation initiative.

While there are a near-infinite amount of ways to mess up something as complicated as Organizational Change Management, here are five sentences that can put an entire initiative to a screeching halt:

"Fund the change from your project budget"

There's no easier way to apply Larman's Laws than to apply existing accounting structures to an Agile Transformation. What do you think will be the outcome of such a transformation program, except an organization that still has the same line / project matrix organization which created the entire mess you're currently in?
And which project manager in their right mind would spend their project budget on necessary changes that will come into fruition much after the project deadline is reached?

The proper statement would be: "We have to re-examine our entire accounting structure in the mid term, and we will create a specific change fund for this initiative."

"Limit scope to IT"

Ignoring both the impact and consequence of an artificial limitation of scope fundamentally contradicts the concept of systems thinking, which relies on acknowleding both the implicit and explicit relationships of the whole system.
I always use the clockwork metaphor: If you try to speed up a single cog, there are three likely outcomes: The surrounding cogs will absorb the change, the watch will tick wrong, or the cog will break. IT is a cog of an organization, and the results will be accordingly.
If you have this approach in mind, either abandon the idea or the change altogether. It will save you a lot of pain later on.

The proper statement would be: "Start where you are, and when you hit an organizational boundary, pull in people as necessary."

"You can do this"

What sounds like a great motivational statement betrays yet another pillar of systems thinking: Management was responsible for creating the current status quo, and unless management actively contributes in changing this status quo, it will remain unchanged.
As long as management doesn't do their part, statements like "We trust you on this" are adding insult to injury, setting teams up for failure, creating negativity and bad blood in the long term.
If you're a manager and not going all-in, you are going to be an impediment!

I'll take it with Deming:

"Support of top management is not sufficient. It is not enough that top management commit themselves for life to quality and productivity. They must know what it is that they are committed to — that is, what they must do. These obligations can not be delegated. Support is not enough: action is required." - W.E. Deming

The proper statement would be: "We can do this."

"We're already good"

I am baffled when I ask managers what they expect from their agile transformation, and they limit their answer to this sentence: "We're already good, we're just looking for ways to become more efficient."

While I'm not going to argue whether they're indeed good, the attitude behind this sentence will make it extremely difficult to realize that an agile transformation is not needed if indicators like Customer Satisfaction, Time-To-Market and Product Viability are good. If these things are not good, then "getting more efficient" is entirely the wrong direction!

"This is not important"

It's a jaw-dropping moment to sit in a room with over one hundred developers, hearing a Senior Manager introduce the new way of working to the audience with the words, "SAFe is not important". Okay. SAFe is a placeholder, it could be any other framework as well.

Well, if it isn't, why did you opt to go this route for your agile transformation? Did you bother defining your organizational goals, current deficits, map them with the different frameworks and see which approach is most suitable to meet your needs?
If you didn't do that, you simply didn't do your homework, and you shouldn't have chosen a specific framework before doing that!
And if you did that, you might as well inspire people by giving them something to aspire, rather than planting a dismissive notion in their minds!

The proper statement would be: "We chose this framework as a basis to reach our goals - and we will relentlessly Inspect, Adapt and Improve to get better every day!"

In Summary

A Whole Systems Approach is fundamental to any organizational change initiative, be it Agile or otherwise. When managers reveal that they either haven't considered the systemic impact, or simply don't care, they give everyone a good reason to doubt the success of the change from Day One.

When not to scale Scrum

Typically the first question I hear after a company decided that Scrum may be the way to go forward in their IT organization, the next question I hear: "But how do we scale it?"

As mentioned in a previous post, there are reasons why you shouldn't even try to scale. Aside from that, you may simply not be ready to scale.

Before you attempt to scale your Scrum, maybe you want to go through this non-exhaustive check list. It only exists to give you an idea of what to improve on before plunging into Scale.
Maybe you want to answer these on a scale of "Definitely not (1), Unlikely (2), Somehow (3), Usually (4), Definitely yes (5)" - then decide areas for improvement based on feasibility and value.

So, here is your checklist:

1 - Delivery

• We are able to deploy the last merge to Master to a productive system within less than 15 minutes.
• We can release partial work at any time, because we use Feature Toggles to disable unfinished features.
• There is no more work to do when we call a story "Done".

2 - Teams

• We have stable teams that have a routine of working together.
• Our teams autonomously get stories "Done". They do not depend on anything from anyone outside the team. This includes activities (such as testing or deployment) as well as sign off.
• Our teams have what they need to succeed. They do not require permission to use applicable tools to get their job done.

3 - Scrum Masters

• Scrum discipline within the team works without having the Scrum masters say or do anything.
• Scrum Masters act as mentors and supporters, not as managers.
• Scrum Masters are seasoned experts in Scrum. They have seen Scrum in multiple contexts and are aware of the difference between avoiding pain and healing the pain. They avoid going the easy, wrong way.

4 - Product Owners

• The "someone who calls the shots" is the Product Owner. Not other stakeholders.
• The PO is not a business analyst detailing features to become implementable, this can safely be left in the domain of the team.
• Product decisions are based on Net Present Value, Opportunity Cost, Customer Retention, Market Share etc. - as opposed to politics.

5 - Outside Organization

• Company priorities and objectives are aligned across all areas, including IT as well as Marketing, sales, finance. Conflict of interests is resolved on top management level.
• External stakeholders fully understand their responsibility in enabling successful delivery.
• Managers enable the team and do not require non-value adding activity, such as reports

6 - Continuous Improvement

• We know our 3 top pressing impediments
• The most pressing impediment is actively being resolved
• Minor changes which help increase productivity are readily implemented without further mention.

7 - Technical Debt

• It is widely accepted that technical debt must be controlled
• We measure and are aware of our technical debt
• We don't release any code with significant technical debt

 Summary

The model of Shu-Ha-Ri applies to Scaling more than anything.

An organization in the SHU stage of Scrum multiplies their problems, not their solutions, at scale. When you can't frequently and reliably deliver value with 1 team, you won't be doing that with 5 or more teams, either!
Successful scaling requires coaching by RI stage Scrum experts and an organization that is at least on the HA level.

As long as you don't have a working implementation of Scrum within individual teams, don't even think about scaling!

The "4 Re of Complexity"

How to deal with complexity? Too often, I hear "But it's so complex". As sparked by another one of my recent posts about the often prematurely assumed need for tools, here is a small model how we should approach complexity:

The 4 "Re" of Complexity

The 4 "Re" of Complexity

Resist the introduction of more complexity

You should resist the temptation of introducing complexity that you neither have nor need. Additional complexity introduces risk and effort - you want neither. Simplicity requires actively struggling against complexity. Both effectiveness and efficiency require minimal complexity.

Sometimes, you just can't avoid complexity that you neither have nor want - for example, when it's forced on you by regulatory compliance. Still, you should do your best to prevent that complexity from creeping in. Try to do the absolute minimum necessary rather than see "what else might be needed".

Reduce the need for new complexity

Sometimes, you need additional complexity of some sort to work effectively. Maybe you think about automating a process? This increases your technical complexity in an effort to reduce the complexity of manual effort. That makes sense - as long as the complexity you add to increase the efficiency of one task should be lower than the complexity you are removing.
For example, if you would use an automated testing suite with maintenance effort higher than manual testing, it doesn't make sense to automate. You would be adding more complexity than you remove - a bad deal.

Remove unnecessary complexity

Complexity is like dust on a shelf. It just adds up over time until you can only fathom the thing you originally put into place. Processes are often religiously followed without an understanding of what is needed why. When you discover that you have complexity that could be abandoned without any detriment to your business outcome - do it.

Reinvent existing complexity

Do you remember the days when you wrote a letter on a typewriter, then printed it out, only to fax it? Why don't we do that any more? Because email achieves the same purpose much faster, easier and cheaper. Even complexity that exists in your environment can be scrutinized for improvement potential. Discovering completely new ways of achieving a goal with less effort is advancement. Chances are, if you found an ingenious solution, others will benefit, too.

Summary

Never be content with complexity. Finding ways of doing the same thing simpler is essential in order to not be overwhelmed. The "4 Re of Complexity" help you dealing with complexity in an effective manner.

Common misunderstandings of SAFe

SAFe is becoming increasingly popular - and with it's popularity, we encounter the issue that people with a superficial understanding harbour inaccurate concepts about what SAFe is or does. Here, we want to debunk a few of the most common misunderstandings. There are also others, which we will discuss at a later time. 

#1 - SAFe is too ...

A common issue around SAFe is that allegedl, people consider that it is ...

• Heavy
• Complicated
• Complex
• Restricted
• Restrictive

Regardless of which of these are bothering you, first consider the following: SAFe is a framework intended to aid you on the journey of developing highly complex systems in a dynamic marketplace. If you can do that with a single team, then - by all means, do that. SAFe is not a way of making simple things complicated.
When you are dealing with a complex, adaptive system, then any simple solutions will be snake oil - based on wishful thinking. SAFe does not claim to dissolve the inherent complexity. On the other hand, it reduces the unnecessary complexity induced by legacy organizational structure.
SAFe does become restrictive and constraining when it comes to structure in the same sense that Scrum does. SAFe discourages bloated, inefficient structures without customer value. In SAFe, there is no place for complex reporting processes, time-squandering status meetings or wasteful accounting structures.
SAFe encourages optimizing structure and processes constantly, applying Lean and Agile principles. Many people say that SAFe, at it's core, is really just plain common sense, even "too obvious to be special". Except that too many organizations don't apply common sense - and don't see the obvious.

#2 It’s just another name for Waterfall

Common arguments include:

• Each PI is a Waterfall
• SAFe is just another PMBOK style waterfall.
• It’s just RUP Reloaded

The basic premise of the Waterfall is a phase-based model, where analysis is succeeded by design, by development, by test, by releasing. While SAFe considers all of these activities as useful, it neither prescribes doing any of them in a specific fashion - nor does it suggest these be done sequentially with an implied handover process.

SAFe supports the continuous delivery of Working Products, within each PI - within each Sprint - and within each team. SAFe's delivery model is highly inconsistent with a phased model.

The PI is an abstraction layer of an iteration. Unlike a traditional program, there are no phases assigned to Increments. Every Increment results in a Working Product Increment, and at the end of each increment, the "Proceed/Stop" decision is based on inspection of valuable deliverables. Artifacts like documentation or un-integrated code are not considered value.

While SAFe has so-called "Programs", a SAFe Program is not a classic large-scale Waterfall project. A SAFe program is, first and foremost, a larger group of people working together towards a common vision. It does not imply sequential phases or separations of concerns.
SAFe has specific suggestions how to get started and be successful in a very short period of time, the key idea behind SAFe's program structure is this: As organization size increases, non-value added coordination also increases (i.e. anti-scaling). Therefore, SAFe suggests an organization both in terms of structure and process which significantly reduces non value adding coordination.

SAFe does permit you to integrate with a Waterfall organization either on lower or higher levels of abstraction, yet this type of integration suffers from the same maladies as a Scrum team would suffer when being forced into a Waterfall mode of delivery. SAFe intergration with Waterfall is possible, albeit wasteful and extremely risky. Both the waste and risk are endemic to the Waterfall and transferred onto SAFe.
SAFe encourages abolishing Waterfall structures as fast as possible and suggests converting the entire Value Stream towards SAFe in order to minimize the impact of Waterfall practices.

#3 - SAFe doesn't fit

People are quick to dismiss SAFe before understanding how to fit it into their organization, for example:

• We are too big / too small for SAFe 
• SAFe has to be tailored to fit
• We have to modify SAFe so that it works
• SAFe processes do not fit into our organization

Let's start by stating the obvious: SAFe is a scaling framework. When you can avoid scaling, please do that!
Even when you aren't really scaling, the SAFe values, SAFe principles and SAFe mindset are useful. Of course, you won't be using SAFe structures and processes to solve a non-existant problem. SAFe is a way to approach the problems you already have and it's excruciatingly good at highlighting where they are.

When it comes to "too big", SAFe is probably the framework that has proven to work with the largest organizations of all scaling frameworks. The Value Stream layer, introduced in SAFe4.0, basically allows you to organize thousands of developers working on the same product. If you think you go beyond that, it is more likely that you only think you need so many people because your organization is so ineffective - not because your development challenge is so big.

There is significant danger in modifying/tailoring SAFe: SAFe follows the Shu-Ha-Ri learning principle. At first, do the motions until you understand - then you adjust the practice to get better results - finally, you transcend everything to obtain the same outcome without the initial motion.
For companies new to agile, it is highly recommended to first learn the basics before jumping into modifications. Just like in Karate, you don't go into a Dojo and tell the Sensei "Well, I like this Karate thing - but we need to modify it a bit so it suits my needs" - you need to get a grip on SAFe before meddling with it. The odds that you are modifying something that is actually essential to success increase with lack of understanding.
An expert agilist would definitely approach SAFe differently from a beginner, yet it is often self-proclaimed "experts" that do the darndest things.

SAFe has been proven to work in thousands of companies across the globe, spanning all kinds of industries. While it is possible that your company is such a special case that you just can't make use of SAFe, chances are that in these cases, neither is any other agile framework, including Scrum or Kanban.
Most likely this means that your optimization goals are not compatible with the following common optimization goals: Value, Time-To-Market, Customer Satisfaction, Effectiveness, Learning. In that case, SAFe has nothing to offer.

Some organizations are already so agile that SAFe is a step backwards. Congratulations! You're already in the top 0.1% of your industry! Keep it up. We'd like to learn from you. You may still refer to the vast experiences collected by SAFe to get some ideas and simply grow and improve on what you're doing.

#4 - SAFe isn't real Scrum!

Here's some common statements:

• SAFe does not include Kanban/Scrum
• SAFe dilutes Scrum/Kanban
• SAFe doesn't support Continuous Delivery

Let's start with the simple things first: SAFe encourages using Scrum or Kanban on team level. Unlike Scrum itself, it's not prescriptive in stating "You MUST do Scrum or you're doing it wrong!!!!11oneoneeleven". When teams are more comfortable with one or the other, they have options. SAFe is equally compatible with either. SAFe's main constraint here is that the teams need to be able to integrate continuously and should be cross-functional.
While this implies that it's possible that you have a SAFe implementation without Scrum at the team level, SAFe actively encourages at least trying out Scrum first.

A little more challenging is the topic of "diluting Scrum". There are modifications to Scrum, based on the idea that a team is not fully autonomous when they are merely a component within a complex system. Pure Scrum has nothing to say about the interaction of teams when interests are in conflict. SAFe redefines the Scrum Master as focusing more on the team, accepting that issues within the organization at large might overburden the Scrum Master.
Scrum equally has no suggestions when the product itself is so big that one PO can not both maintain the entire product and be sufficiently available for all teams. SAFe attempts to provide a meaningful way forward, stating that final product decisions are - just like in Scrum - single person (not committee) decisions, effectively de-valuing the PO role as product/value focussed person within the team - putting a PM in charge of what we'd typically call a "real Product Owner".
The principles and values of Scrum are retained. Similar statements would apply when a team chooses to apply Kanban, except that SAFe purposefully considers the roles of Scrum Master/PO vital to team success - so SAFe suggests having PO/SM even when teams use Kanban.

Continuous Delivery is clearly supported by SAFe, as are other XP practices. While SAFe accepts that for some organizations, Continuous Delivery is still a huge stretch, SAFe encourages these companies to set "Be able to deliver any time" as a key goal for value creation.

#5 - SAFe isn't Agile

Some people claim that SAFe does not manifest agility. The arguments are these:

SAFe equals Big Bang releasing

SAFe is Non-Agile and doesn't support the Agile Manifesto.

The "But it's not agile" guns are quickly pulled and fired, in classic Western Style "Shoot first, ask later".

SAFe acknowledges that large products, such as "The new iPhone" are typically released as major updates, including big and costly upfront marketing and sales activity. At the same time, SAFe encourages the continuous, fast delivery of value both for commercial and innovation reasons.
Regardless of which approach to releasing is suitable for your specific product, SAFe is fine with that. While frameworks like Scrum are completely neutral regarding large-scale effects such as "Super Bowl", SAFe suggests putting major commercial events on a calendar, then planning potential scope around these events to leverage maximum business value. This idea is not conflicting with the continuous and early delivery of value.

In regards to the Agile Manifesto, SAFe emphasizes the Agile Manifesto equally - or even more - than frameworks like Scrum or Kanban. While agility at scale is significantly more complex than team-level agility, SAFe acknowledges that both the values and principles of the Agile Manifesto are valid. A thorough understanding of - and support for - agility is a prerequisite to succeed with SAFe.
A culture that does not support the Agile Values will not succeed with SAFe. Let's just be brutally honest here: That kind of culture will not succeed with agility regardless of framework or approach.

Conclusion

Well, that was round 1 of SAFe misunderstandings. There are more to discuss later.

SAFe does not claim to have all the answers. SAFe is a good way to get started on your journey to Enterprise Scaled Agility, and "Here's something you can try" is better than "Well, you have to find out ..." for many people. After introducing SAFe, you will constantly inspect+adapt to discover better organizational processes and structure.

Think about why you hold specific reservations about SAFe. Maybe the problems are caused by your perception of SAFe, not by SAFe?