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!

Your Sprint Reviews suck, and that's why!

Do you have the impression that your Sprint Reviews suck, that they are a waste of time? 

Are you missing real users, are attendants squirming for the meeting to end as soon as possible - or have they found something else to do with their time that has more value, for example counting the holes in the ceiling?

Or is your Review already a sausage party where nobody except team members attend, because everyone else has decided to vote with their feet?

I've sat through many a Review, and found some common patterns that have a high tendency to lead to terrible Sprint Reviews.

In this article, I list some of the most egregious sins and how to avoid them. 

Sin #1 - Activity Reporting

Imagine you're going to a Genius Store, looking for the newest features on the latest iPhone - and the salesperson starts by saying, "We set up a new chip factory, but it was a lot of trouble to buy the grant for the land, to get a building permission, and you know all those new building regulations - we had to hire a whole department of lawyers just to go through the paperwork, and then there was that issue with ..." - for heaven's sake, you'd run out of that store screaming, never to return!

And yet, that's what teams consider a "normal" thing to do during Sprint Review. Why? Let me formulate the intention of the Sprint Review as a User Story, using the Connextra Template:

As a user of your product, I want to know about the latest changes so that I can decide whether I like them.

That's all a user wants to know. If this is not the #1 top priority of your Review, you have nothing to say and are wasting everyone's time.

The fix? Think what a Review from that fancy new (insert product) would look like for you to want to attend. Not the Behind the Scenes - the Product Review Session that you would pay to get a ticket for! Like, BlizzCon, for example! And then, move your Reviews in that direction.

Quick fix: Forget about YOU. Talk about THEM (the customer!) and their needs in terms of the Product!

Sin #2 - Ticket Management

When the team whips up their ticket management first thing upon starting the Review, I already know it's going to be a waste of everyone's time. Regardless of whether that tool is Jira, Excel, Trello or whatever - I know that this team can't think from a user's perspective.

Seriously, would you come to this blog if you had to first click through a summary of the work I did before you could find out about the content I produced? Probably not. And that's how users feel when you confront them with the work you did.

Rather than describing what work you did, you should start with something called a "value proposal". Let the users know very briefly why they're here, what they're going to be investing time into and which benefit they're going to get out of this. If this hasn't been achieved within the first minute, you might as well stop and cancel right there.

Quick fix: Forbid the use of ticket information during the Review.

Sin #3 - Powerpoint

Yet another great indicator of a Review that is going to suck is that the center of attention is a slide deck, not the product itself. When I see slide decks and no usable software, I immediately make a mental note, "The team doesn't know what is useful." While in some rare cases, Powerpoint has a beneficial effect, our usual text-filled or bullet point lists describing details are a great method of getting people to divert their attention elsewhere.

The center and focus of attention of the Review is the Product and the User. Everything else is secondary or irrelevant. If you can't show it in the Product, you better have a damn good explanation why it's relevant for the user!


Quick fix: Forbid the use of Presentation software during the Review.

Sin #4 - Disconnect

When users can't see why they benefit from the items the team has completed during the Sprint, there is a deep rooted problem somewhere in how the team works. This can't be fixed in the Review, and the Review is neither the place for the team to earn sympathy points from the users, nor is it the place to brag about how much work you achieved.

The Review is a synchronization point between team and users, where users learn what's new in the Product and where the team leans how users like the new features. If this synchronization is broken, the Review is pointless.
When the Review becomes a show where the team demonstrates themselves, their work or their outcomes without actively listening to the Voice of the Customer, you might as well scrap the Review.

Quick fix: Make user statements in the Review lead to real change in process and product.

Sin #5 - No Action

At a minimum, I, as a user, attending a Review, expect to see Real Action with the product. I may not expect something fancy, but I expect to see how the Product works. Preferably, I expect to fiddle with it myself. When I don't see the Product in Action, I haven't seen anything. And I have wasted my time.
I can form my opinion best when I get hold of the tablet/mouse/keyboard connected to the Real Application, but when this isn't possible, I at least want to see what the product looks like. In descending order of catching my interest as a user are:

• #1 - I get to use the product
• #2 - I see you using the product
• #3 - I see a video of someone using the product
• #4 - I see pictures of the product
  ....
• #999999998  - I hear you talking about what the product can allegedly do.
• #999999999  - I don't even get that.

Quick fix: Hand the product to the user and see what happens.

Sin #6 - Filling the timebox

Another great way to waste people's time is to feel pressured to use the Review's timebox. If you only have a 5-minute topic, the Review can be over in five minutes. Keep it short and simple. Get the information out that needs to go to the users, and get the feedback in that you need.

Your users' time is precious, as is yours. Don't extend the Review meeting. If you feel that you have too little to show, that's a great topic for a Retrospective, but no reason to bloat up your Review.

Quick fix: Focus on essentials, keep the Review as short as possible.

Setting up a good Review

So then, what is a good Review?
First, you start long before the Review. You start with the Sprint Planning. What's the team's compelling Sprint Goal? Why is it important? Which user problem are you setting out to solve? What are the individual pieces of the puzzle contributing to solve the user problem (e.g., "user stories")?
How is your solution valuable for the user? What is the users' newfound benefit?
If you haven't thought about this right from the beginning, you won't fix it in the Review.

Tell a compelling Story:

1. What is the user problem you tackled?
2. What is the pain the user has had?
3. What is the solution you provided?
4. How does the user benefit from your solution?

And then - let the user do the talking!

The six-step agile transition coaching model

What does a coach do - and how does a typical agile coaching engagement look like? 

This is my personal model - it may also serve as a discussion basis for others.

"What does an agile coach do?" - this model is an attempt at answering the question.

Stage 1 - Engage 

(with the as-is-system)

Judge not, that ye be not judged.
For with what judgment ye judge, ye shall be judged: and with what measure ye mete, it shall be measured to you again.

- The Bible, Matthew 7:1-2

In the first stage of a new client engagement, I engage with teams, management and business stakeholders. Even though I may have (deep) industry expertise already, I start with a blank slate. I look around, I listen, I ask. Regardless of what I encounter, I remind myself that people have reasons for doing what they do, for thinking what they think - for saying what they say.

I have no opinion in this stage. I am like a dry sponge, absorbing information.
In the Engage stage, my notebook fills rapidly, maybe 10-20 pages a day and not much precipitates, because nothing of what I write would be new for anyone who has been within the organization for a while.

The outcome of the Engage Stage is nothing more than a book of notes which nobody except me gets to touch.

How long does the Engage stage take? Depending on the complexity of the organization and intended change, anywhere from a few days to several weeks.

Stage 2 - Prepare

(the as-is-system for change)

Grace to accept with serenity the things that cannot be changed,
Courage to change the things which should be changed,
and the Wisdom to distinguish the one from the other.

- Reinhold Niebuhr, "The Serenity Prayer"

Every organization has to deal with certain circumstances. Some are mutable, others immutable. And even some of the mutable things may not be ready yet. Change strategy and communication is a very unique process, different for every single organization.

In this stage, I make proposals and verify them for feasibility. I still don't seem to be "doing" much -  the approach needs to be tempered by the current reality of my client. Bringing my client to a different reality doesn't depend on me - it depends on them: what they can see, what they are ready for and what they are willing to do.

The outcome of the Prepare stage is a transition strategy picture - I prefer to have a single page showing the Vision, main Objectives and a transition backlog with prioritized, sorted Key Results.
(it would be preposterous to say that the picture doesn't change - that's what being agile is all about!)

Depending on how available and open clients are for providing input and feedback on the strategy, this, too, can take anywhere from a few hours to several weeks - it becomes a drag in organizations where people are continuously "too busy to improve" and really fast if I can get people into a Workshop.

Stage 3 - Build Up

(something new with the people)

I'm focusing on the issues that bring people together and build broad majorities.

-Doug Ducey

In this stage, I work with the transition backlog to establish agile processes, practices, structures and mindset. The backlog allows me to focus and not overburden the client with too many parallel changes. What gets built up how in this stage depends on where the client stands and what they are ready for. It's not a linear process, it depends on continuous, deep feedback.

People can be built up in various ways: Formal training in frameworks such as Scrum or Kanban or methods such as BDD can open new horizons. Practical guidance, such as support in setting up the Backlog or offering insights into how to hold effective Reviews, boosts capability. When the a process gets reworked, I may propose unknown alternate approaches and then encourage independent experimentation with the process. 

This stage is the main stage where my own understanding of agile practices matters most, as the client usually simply doesn't know what they don't know or why the things they do won't get them where they want to go.

The outcome of the Build-Up stage are people - teams, managers and stakeholders - who have gained a new understanding and are equipped and ready to try out something new.

Since there is no universal definition of what it means to be "Built Up" and no objective standard for "feeling ready", this stage also depends strongly on the client's people and culture. The coaching process starts to become diffuse here, as some people might be in the "Strengthen" or "Support" stage already while others are still in need of building up.

Stage 4 - Strengthen

(new beliefs and practices)

Difficulties strengthen the mind, as labour does the body.

-Seneca

During the Strengthen phase, I help people to familiarize themselves with the new practices and ideas in their daily work. That could be anything like taking a look at the Kanban board and asking about queues or WIP limits, helping teams increase the effectiveness of their meetings, moderating Retrospectives to bring forth significant change and also individual coaching on the job - such as pair programming with developers, developing value propositions with Product Owners or walking Gemba with management.

The outcome of the Strengthen stage are people who feel confident in using new practices and who are willing to think in new directions.

It depends too much on the individual to answer how long it takes to continue through the Strengthening stage, as this is really a highly individual matter.

Stage 5 - Support

(others as they go their own way)

Believe that anything is possible when you have the right people there to support you.

-Misty Copeland

In the Support stage, my coachees anchor a new mindset. I work mostly to build up a self-sustained habit of feedback and growth while the show belongs entirely to the client (both teams and managers), who often habitually fall back into old behaviours and thoughts.
I coach by reminding people of their positive achievements, helping them discover and take the next step on their own, while also holding them accountable when they resort to behaviours they had decided to abandon.

The outcome of the Support stage are people who have made feedback and reflection a habit, who have no need of myself in their daily business.

The Support stage can be stable with a low amount of engagement over a prolonged period of time, but may be optional when the client has established internal mechanisms to create closed feedback loops.

Stage 6 - Journey onwards

(to new horizons)

Every day is a new day, and you'll never be able to find happiness if you don't move on.

-Carrie Underwood

Every journey comes to an end as the destination is achieved, and a new journey with a new destination starts. The end of my journey with a client is the beginning of their journey without me.

When bidding farewell, I like to part ways knowing that my client knows where they are heading and which are the next steps they will take, so we best close with a Retrospective to create a clear vision for the future of my client.

The "Journey Onwards" stage ends with the order - although I may still retain informal touchpoints  irrespective of budgets or commercial gain. After all, we're human beings whose relationships shouldn't depend solely on money.

Closing words

Sadly, most clients only plan budgets until Stage 3 - "Build Up", which oftentimes results in organizations reverting to old habits and practices, lacking understanding how they are damaging their own progress.
Although this is the normal case, I prefer to work with clients who take care to complete what they have begun.

Equally saddening is to see coaches/consultants who purposely create dependencies upon themselves, never enabling the client to take autonomous control because doing so would dry up their revenue stream.

I feel it fair to inform my clients that "A Transformation isn't done with 1-2 months coaching", and that my engagement will quickly diminish once I am confident that they can do it, which neither means that I am suddenly disinterested nor that it's already a good time to stop.

You have to be crazy to hire consultants

"You have to be crazy to hire consultants." - I repeat this sentence quite frequently after arriving at this conclusion almost a decade ago. Being a consultant myself, I think this statement is merely a reflection of the way how many clients see consulting work. Let me explain. 


Before we start, this article isn't about outsourcing services far outside your core value stream - for example, I myself resort to the services of a tax accountant, because studying tax law in detail would derail my value focus. This article is about consultants dealing with the core competencies of your organization.

Pervasive Taylorism

Most organizations are still set up according to the principles of Taylor - workers do the work with managers ensuring that they do the right work right. In knowledge management, "doing the work right" is known best to the workers and not to management, so that leads to the first level of craziness:

Organizations both expect and reward managers for being in control. Managers are expected to be responsible for coming up with solutions to known problems. Workers, on the other hand, are being overburdened with work and couldn't care less about resolving endemic problems, since that's not what they were hired for.

And like this, the most qualified people don't do that which would help the organization most and the least qualified people often decide on changes that don't help at all - and nobody sees a problem with the approach.

Inability to solve problems

When a problem arises, team members are neither enabled nor available to solve it. Management would then often demand, "Bring me solutions, not problems" - although teams working in a local context are often incapable of doing this when the root cause is outside their sphere of control. When the teams themselves have no solution, the obvious solution is to bring in consultants to provide a solution, since managers are busy with their other responsibilities.

And this is the second level of craziness:

1. People with the skills to solve the problem don't get time to think why the problem exists.
2. People in a position to solve the problem don't have the skills to solve the problem.
3. People hired to solve the problem won't have to deal with the consequences of the solution.

Absurd Incentives

Dysfunctional organizations thereby create absurd incentives, the third level of craziness:

• Team members willing to solve problems get punished with overload because problem solving time isn't factored into their already full workload
• Team members might be reprimanded for wasting time when their solutions are ineffective, making "doing nothing" the preferred option
• The separation of management and doing work renders managers who solve problems ineffective in their management role, rewarding managers who do not spend time to solve problems.
• Not investing time into active problem solving rewards managers who delegate problem solving to others.
• Project organization rewards managers for band-aid solutions with a life expectancy not much longer than the project's duration.

The need for consultancy

Thereby, organizations reach the fourth level of craziness:

Team members and management are likewise incentivized to not assume personal responsibility for sustainable improvement - thereby incentivizing management to hire external consultants, who get paid to solve problems nobody else benefits from solving and who can conveniently be blamed when the solution doesn't work out.

In conclusion: the amount and frequency of resorting to external consultants are a decent measure for the level of organizational craziness.

Fixing the root cause

You'd think it should go without saying that the solution here isn't hiring more consultants to do an Enterprise Transformation, yet that's what organizations do: the ultimate level of craziness.

So, if more consultants aren't the solution - what is?

To make a long story short, rather than adding further layers to the problem, we need to dig down to the root cause: the distribution of responsibilities within the organization and the perception of what management in a knowledge era means.

Fundamental change must start there, and the people who have to make the change are the people of the organization themselves!

While consultants and trainers can provide options for a different way of doing things and can assist in the transition - the change must ultimately be determined, owned and executed by the people of the organization themselves!

Coaching or Consulting?

Draw your own conclusions.

Finding fertile soil for coaching

There are hundreds of poorly written job offers for "Scrum Masters" or "Agile Coaches" out there - mostly because clients don't understand what they should be looking for. And who can blame them? Why would they need you, if they did?

It's not Cockaigne

I have talked with numerous "Scrum Masters" who require that a Scrum Master job ad be written properly to represent the role of a Scrum Master as based on the intention of the Agile Manifesto and healthy Scrum. They already screen the job interview for any hints that the organization may not be agile and disengage at the slightest hint that the company "doesn't get it".

In my personal opinion, these people are cherry picking. A very important part of being a Scrum Master is creating a healthy Scrum environment - to expect that it already exists means taking the easy route.

And since life isn't a bed of roses, even seemingly perfect environments have challenges.
I heard the personal stories of Scrum Masters who were sorely frustrated upon being confronted with un-Scrum-like elements in their organization and having to deal with people who interefered with team autonomy. Those stories make me wonder: "What did you expect?"

There will be challenges. There will be mindset discrepancies. There will be arguments. And that is part of the job.

Good descriptions can be bad jobs

There might be a huge discrepancy between written words and unspoken expectations.
Here are just some examples of hidden pitfalls:

• "Guide the team in their self-organization" could mean "Track who does what, when and how long it takes"
• "Establish agile ways of working" could mean "Enforce adherence to the 'Agile' Jira workflow"
• "Help people adopt an agile mindset" could mean "Developers need to work faster and harder".

And that's just the tip of the iceberg. Below lurk further dangers:

• Your influence is limited to the team
• Rigorous adherence to rules
• You're expected to optimize for efficiency or utilization
• The need for supervision and control
• Pressure to meet quota

All of these are serious concerns, yet nothing to be afraid of - there are problems everywhere, so why should any specific company be any different?

A good basis

As agile coach, change is your job - you just need to be aware when you're fighting an uphill battle and are up alone versus an armada. In some cases, steering clear of a confrontation is better than running headlong into your demise. So, how do you know the difference?

It's about people

"People and Interactions over Processes and tools" - for none is this truer than for an agile coach. Take a note of how people behave in their interaction with others.

These character traits from members of the organization are hints that existing problems and challenges can be overcome:

• Trust: Invite and extend trust to and from others. Build networks of trust.
• Humility: Able to admit that not only things, but also they themselves aren't perfect.
• Kindness: Reach out in a generous, open-hearted way.
• Openness: Share and receive ideas.
• Accomodation: Give people a break for being in situations beyond their control.
• Consideration: Take care to minimize inconvenience for others.
• Curiousity: Ready to try out something completely different, even when the outcome is unclear.
• Mindfulness: Willing to consider cause, effect and circumstance.

As a counter-indicator, when these character traits are either absent or even exploited within an organization, this will pose a challenge that won't be overcome by a single Scrum Master.

Summary

The importance of human virtues and relationships in picking the right place to make an impact as a Scrum Master should not be underestimated. Forget the job descriptions and have a conversation.

Shift the focus away from what people currently believe about how Scrum should look like and take a closer look at the character which people within the organization exhibit.

Coaching and change are much easier when there are positive character traits visible. At the same time, when these traits are compromized, there's a massive chance that coaching will not have an impact and no change will happen.

Don't try to help everyone. Pick the people who are willing to receive it.

Addendum

A very good article with good interview questions a Scrum Master / Agile Coach may want to ask can be found here:
https://www.toptal.com/project-managers/scrum-master/5-scrum-master-questions

Where the benefits of SAFe come from

Are the advertised benefits of SAFe real? 
The Scaled Agile Framework claims the following benefits of a Lean-Agile transformation:

Benefits of SAFe, taken from scaledagileframework.com

These benefits are definitely realistic when the right levers are pulled in a traditional organization -  Let's take a look at how!

This article will focus on statements by William Edwards Deming and examine how SAFe implements these for visible benefits.

Productivity increase

Productivity isn't nearly as much a function of doing the right thing, as it is a function of stopping the wrong thing. Deming hypothesized that 95% of productivity is attributed to the system and only 5% to the individual:

"The fact is that the system that people work in and the interaction with people may account for 90 or 95 percent of performance." - attributed to Deming

Working in an ineffective system can reduce the performance to a twentieth of what would be possible - so when a theoretical 2000% boost is possible by creating "the perfect high productivity environment" (and hyperproductive teams prove that this is, indeed possible) - 20% is a single percent on the scale in an average corporate system(!)

Just having senior managers think about stopping some of the most egregious ways of wasting productivity and turning these into actions will result in the mentioned benefits.

Here are some ways in which SAFe addresses systemic productivity waste:

• Reducing overly large delivery batch sizes
• Increasing mutual understanding of requirements
• Reducing the amount of handovers in the process
• Reducing context switches for team members

SAFe's magic ingredient to productivity is the PI cadence with the ART.

Quality increase

Quality is the result of strategic decisions executed by the workforce. That is, by setting incentives and defining a route promoting low quality, the outcome will inevitably be low outcome. Impediments to quality are usually created above the team level:

"Quality is made in the board room. A worker can deliver lower quality, but she cannot deliver quality better than the system allows." - W.E. Deming

Some of the main drivers of low quality are lack of information and deadline pressure.

As Deming stated elsewhere, it's not enough that senior managers state that they want high quality (doesn't everyone?) - they need to get active in resolving impediments to quality. For this, they must examine and change those systemic constraints which lead to low quality.

Here are some ways in which SAFe addresses systemic impediments to quality:

• Generating clarity of customer intent
• Bringing the people together who should talk
• Allowing teams to determine scope per time
• Agreeing on a "Definition of Done"
• Introducing meaningful feedback cycles into delivery

SAFe's magic ingredients to quality are the PI planning event and the System Demos.

Time-to-market decrease

It's not like people aren't trying, that they aren't busy, that they wouldn't be working fast enough. The problem is that they are often torn between many things and have no idea which of these is the most important or why these are important now:

"It's not enough to do your best: You must know what to do, then do your best." - W.E. Deming

That's why there is a lot of work in progress, many context switches and clogged delivery pipelines. According to Little's Law, Time-to-Market depends on how much work is in the system at any given point in time. Add more work to an overburdened system - and time-to-market goes up.

SAFe addresses time-to-market indirectly, albeit very effectively:

• The PI Planning sets the focus for the upcoming 3 months.
• Using an Economic framework scraps low-value work.
• The PI cadence limits work in progress (WIP).
• Iterations allow setting team-level course biweekly.
• Continuous Delivery gets Done stuff shipped faster.

 If your organization had a history of delivery times 12 months and up, the 3-month cadence alone will easily reduce the Time-to-Market by 50% or more.

SAFe's magic ingredients to Time-to-Market are the PI cadence and the resolution of large batch delivery.

Morale increase

Organizations are great at demotivating employees by deriving their work of all meaning. People quit their job is when they hate it - when they can no longer identify with why they should be doing it. This happens most often when they can lo longer see the meaning of their contribution:

"When one understands who depends on me, then I may take joy in my work." - W.E. Deming

SAFe addresses detrimential impact on morale in the following ways:

• Setting clear PI objectives 
• A Program Board visualizing what the work contributes to
• Working with "User Stories" makes the consumer visible
• Allowing teams to focus on reaching a "Done" Increment
• System Demos with real user interaction

In many large organizations, most of the work is - just work: long, arduous status meetings, constantly shifting priorities and binning unfinished work, creating documents which nobody will ever read etc. 

By abolishing these mechanisms, people get more satisfied - and when they are then replaced with real customer interactions (occasionally even with praise for a job well done), morale naturally gets a massive boost.

SAFe's magic ingredient, again, is the PI cadence and the System Demo.

Summary

The key benefits of SAFe are quickly realized by:

• Clear Objectives
• Dedicated teams and dedicated teams-of-teams
• Cadences
• Getting to Done
• Closed feedback cycles

If one or more of these mechanisms is "adjusted for pragmatic customization", then SAFe becomes a relabelling exercise and the benefits become elusive.

There are other ways of setting up these mechanisms, SAFe is just one of the means to establish them.

Once these mechanisms are in place, that's not the end of the journey. it's just the beginning thereof.

As hinted in the article, it's even possible to achieve benefits exceeding those proposed by SAFe by a factor ten or higher - although few organizations have the dedication and courage to improve so relentlessly as to realize them.

Making sense of Agility

"I know this doesn't make any sense, but ..." - aren't you all too familiar with this response towards questioning a specific process or practice? I have started the agilecartoons series to highlight the absurdity of practices and ideas some organizations hold dear. But is absurdity sufficient reason to say "That's not Agile"? I myself am not a big fan of either using the "Big-'A' -gile" nor about branding anything or anyone without understanding their context. So let's drill in.

Transparency

We need to be able to understand what's going on around us. Awareness of what's happening is very important when making decisions. With more transparency, we can put our ideas, actions and options into a more appropriate context. As transparency goes down, we resort to doing more and more guesswork and the probability of poor decision making increases.

So, here's the first sense-making question:

Does it make sense to make a decision with the understanding we currently have?

Inspect

Rather than just doing work, this work must be seen in context, the big picture. And then we need to take one step back and determine whether our actions, choices or ideas fit into the picture and whether that picture looks odd.

This brings us to the second sense-making question:

Does it make sense to do the things we're about to do next?

Adapt

Upon discovering that something does indeed not make sense, does it make sense to do that thing? If you answered "Yes", I will rest my case. Otherwise, we need to look for the most sensible option at our disposal. I carefully avoid the term "right", because right and wrong may only be visible in retrospect.

This brings us to the third sense-making question:

Does it make sense to do something else instead?

Feedback

When acting within an complex system - and organizations tend to be inherently complex - then our predictions about what would make sense are often not very accurate. We could be anywhere from outlandishly wrong to precisely correct with the choices we made. Fire-and-forget decision making often results in heaping one more dysfunctional approach over another. When we tried something, we need to look at our current situation by asking:

Did the things we just did turn out to make sense?

Does it make sense to "go Agile"?

If the answer to the sense-making questions is "No", hesitation, reluctance or even resistance, then - sorry to say - what you do doesn't make any sense, by design. As long as there is a mental barrier to getting to "Yes", no amount of "Agile" frameworks, methods, practices or concepts will make you agile. Your system is broken and you should examine that first.

If, on the other hand, everyone can wholeheartedly say "Yes" to the four sense-making questions, then you may find value by experimenting with those agile frameworks, methods or practices that make sense.



P.S.:
The avid reader may have noted that the first three elements are called "The Pillars of Scrum" (and/or "Empiricism") - and at the expense of stating the obvious, your willingness to uphold these elements is essential in determining whether it makes sense to introduce Scrum.