It's still about agile teams

With all the ranting around SAFe recently, I want to address one of the most common, and likewise most severe, dysfunctions in many SAFe implementations: The lack of a solid foundation in agility.

To make my point, I will take a heavily biased stance, and I am fully aware of the bias I present.

Cracking the crust paved by traditional organizational structure requires patience - and it's a slow process.

Why SAFe sucks

We start with a hierarchical organization that wouldn't know Agile if it slapped the CEO right in the face. Then, we bring in a swarm of consultants, do some Leadership training. Everyone's excited. Management huddles together and conceptualizes the new hierarchy, called "Large Solutions" and "Agile Release Trains".

When this is done, we select the members of the new hierarchy, called "Train Engineers", "Architects" and "Product/Solution Managers" and train them for their new role. All of them have been selected based on their importance in former power structures, giving each of them at least as much power as they had before.

Once that is done, we forcefully rearrange formerly functional teams in order to meet the new structure, which relabels "departments" to "value streams", "project managers" to "Product Owners" and "Team Leads" to "Scrum Masters". Off for another round of trainings, also including team members for two days and then ...

We do a PI Planning where the Waterfall Agenda is presented to the teams and then everyone has to created a detail upfront plan and commit to management's unrealistic expectations.

Done. Well, almost. Teams now report and get tracked against their 2-weeks micromanaged commitment until the next PI Planning, where the last plan is supposed to be finished.

That's the Real World!

It would be a lie to say I haven't seen this happen. The amount of dysfunctions in this approach are so numerable that it would take hours to list them all out.

Here are just the few biggest problems with the approach:

1. SAFe is considered a management methodology, not a development approach.
2. Management buys into something they didn't even understand.
3. Developers were never asked for their opinion.
4. SAFe was immediately adjusted to preserve the existing system.
5. Mindset never changed.
6. SAFe was introduced as a structural change, not as a way of changing how value is produced.
7. No effort was made to even attempt and understand what "Agile" means.

Is this the fault of SAFe, neglect on management side, time pressure or some evil consultancy's attempt to screw over someone for a quick buck?

I don't know, and I will not argue, because the issues described are generic and root causes could be different in different places. 

The basis is still the Agile Team

What people forget: SAFe is quite clear that the basis of an Agile Release Train and the SAFe organization is still an Agile Team.
SAFe is the only agile framework which does acknowledge that Agile Teams can have their own, individual mode of working that may or may not coincide with Scrum, XP or Kanban - the only constraint is that the team needs to be agile!

Sadly, organizations do not invest into team level agility before pushing in SAFe. For whatever reason - SAFe oftentimes becomes a dysfunctional relabelling exercise because no effort has been taken to agilize teams.

The illusion of fast results

While Agile teams can deliver high quality Working Software in short cycles, the amount of effort required to bring a team to this level is immense. Many times, management just declares, "We are now Agile" without investing into team building, sustainable engineering practices and agile mindset.

This doesn't work and it will be a flash in the pan. Results will remain elusive, as the organization will effectively accumulate further organizational debt without addressing the underlying issues.

Teams do not become Agile by declaration, and they also do not become Agile by pushing a framework like Scrum or Kanban onto them.

Investing into Agile Teams

Agility is a slow, challenging process with a long and steep learning curve. A two-day training is not much more than waving the "Go" flag on a race track, and some organizations are even cutting corners there - thinking that "it's already enough when we sent Scrum Masters to training": NO!

To be agile, a team needs:

• Operational Excellence
• Technical Excellence
• Drive (ref. Dan Pink)

Based on my experience, the willingness of organizations to invest time and money into these items decreases exponentially in descending order of the list, and it often starts at a staggering low.

Raising Agile Teams

Agile teams are in little need as by definition, they are already self-organized, understand their domain and deliver amazing results. When a team isn't described by these three attributes, they aren't agile to begin with and do not meet the minimum requirements for a SAFe organization!

Teams that are not on this level need a lot more care and support.
Some of this is achieved by management action: changing processes, structures and constraints in order to enable the teams to get there.
Another big enabler is coaching: working with the teams, helping them discover the necessary means  to take control of their work and adopt the practices which help them deliver excellent results.

Coaching is a slow process. It can't be done in a day or two, and workshop sessions - while indeed helpful for specific aspects - aren't sufficient to establish a new culture.

Unfortunately, many organizations invest insufficient time and budget into the necessary groundwork for raising agile teams. Is it suprising then that teams - and ultimately these organizations - struggle?

Sustaining Agile Teams

Agile teams stay (and grow more) agile when their environment supports agility. When an agile team is shoved into a non-agile box, the constraints will force the team to reduce their own level of agility to meet external constraints. 

When SAFe is adopted carelessly, imposing non-agile constraints on otherwise agile teams, the organization's overall level of agility will be limited accordingly. 

In order to get the most benefits out of SAFe, the question should be more along the lines of "Which organizational constraints become superfluous or redundant due to having a SAFe organization", rather than, "Which constraints do we need to add on top of a SAFe organization?"

When organizations abuse SAFe in order to introduce impediments to team-level agility, poor outcomes are the logical consequence.

Nurturing Agile Teams

Agile teams will find a supportive environment highly beneficial in order to deliver even higher business value. Where individual agile teams oftentimes struggle at arbitrary organizational boundaries - from fixed department structures to other "autonomous" agile teams - organizational change, overarching alignment and the occasional global optimization at the expense of local autonomy are indeed a benefit to systemic agility.

SAFe can then be used to provide minimal guiding structure to teams operating in larger environments, referring to common patterns addressing challenging systemic impediments.

The very reason for having experienced SPC's on board would be to both stop the people who lack agile experience from over-engineering upfront, and then pointing out exactly those SAFe patterns which can be considered when a systemic impediment becomes significant.

Unfortunately, we see too many organizations pre-conceiving "the perfect agile organization" as fast as possible and as closely as possible to the SAFe Big Picture - and then implementing it by following a plan without responding to change (which never works).
Managers are quick to proclaim that certain solutions are needed when no team has raised an impediment, and thus un-necessary structure is implemented on a whim.

Agile Management

You can't manage agile teams without being agile yourself. Before managers have changed their own mindset, attitude and understanding, they will not succeed at creating an agile organization at scale.

Most managers fail at the very simple exercise of becoming agile themselves in order to serve agile teams.

Management failure occurs at three levels:

1. Thinking that "Agile" is for development teams only
2. Limiting "Agile" to IT
3. Not investing time into changing themselves

Until management comes to see their own role in the current system, and that change relies on them lifting their own anchoring of an old status quo, agility will remain a fluke.

Management philosophy and practice change is essential for SAFe to result in an Agile Organization.

My Advice

SAFe without a foundation of agile teams is madness.

SAFe driven by the organization without considering agile teams is pointless. 

SAFe imposed by management against the will of teams is craziness.

When an organization does these things, any SAFe initiative is pretty much doomed.

My advice is to take the following steps:

1. Establish agile teams to begin with. If you can't do that, don't even think of SAFe.
2. Invest as much into your agile teams as needed. If you aren't willing to do that, SAFe is waste.
3. Create an environment where your agile teams can thrive. If you think you can't, SAFe isn't going to improve the situation.
4. After you did 1-3, seriously consider which challenges you want to address and where your teams struggle. Do not introduce SAFe as a solution to problems you don't have!

Need Gap Reduction

Let's cut straight through the bullshit. You want to become agile and ask yourself, "How do we know if we're making progress?"
This one simple metric tells you if you're moving in the right direction.

If you're not reducing the Need Gap, you're doing it wrong!

The Need Gap

A "Need Gap" exists between the time when I, as a consumer, realize that I would need something - until the need is satisfied. 

The difficulty of many classical projects is that the need may be satisfied in other ways outside the project's scope or it may completely disappear even before the project's outcomes are delivered.

In economic terms, that is the "opportunity cost of delay."

Why not ...

There are other common metrics. Couldn't we also choose them?
Okay, I'm cheating a bit here. The "Need Gap" is two-dimensional, so it's actually two metrics, so I'm not ditching common agile

Time-To-Market

Time-To-Market is simply an incomplete metric. It doesn't account for the (potentially massive) time lapse between making the solution available and the solution achieving its purpose.

Value

Value is related to wealth obtained by providing the solution, although the amount of wealth benefit that can be monetized depends on many factors. To avoid having to go into a full economics discourse on game theory, we can simplify this by saying that value is again an incomplete metric.

Learning

In a business context, "learning" is related to an unfocused metric that needs to have context. Things we might want to learn should ultimately lead to a bottom line.

For example, learning:

• Expressed, unexpressed and upcoming needs
• Better ways of meeting needs
• Monetizing customer wealth gain

Ultimately, learning is an enabler to addressing the Need Gap.

The Need Gap

A need gap indicates both a delay in satisfaction and an impact on wealth.

Time to Satisfaction

The time to satisfaction is the lead time plus delivery time plus customer reception time, including any potential feedback cycles until the customer is happy with the outcome.

Impact on Wealth

Customer wealth is a function both of money and other factors. 

Cost reduces wealth - as does the unmet need itself, whereas the customer's own ROI increases their wealth.

Economic customers are looking to increase their wealth, so the cost spent on meeting the need should be lower than their loss of not having met the need.

Rising Need Gap

The need gap grows in multiple ways:

• When the time between feeling a need and meeting its need, the need gap grows
• When the customer's wealth is reduced

As the need gap grows, the customer's self-interest in discovering alternate solutions also grows. 

Reducing the Need Gap

Ideally, there is no "Need Gap" from a customer - by the time a customer realizes a need, they have their need met:

• When the Need Gap is low, there is little customer benefit to making changes in the way of working.
• When the Need Gap is high, the customer benefits from making changes that reduce this need gap.
• When the Need Gap doesn't get reduced, then the customer has no benefit from any change made in the process.

A reduction of need gap implies the goal-focused

• increase in customer value, 
• reduction of processing time,
• keeping of development cost to lower than the delivered benefit,
• improvement of value management and discovery,
• closure of feedback loops,
• optimization of monetization

Measuring the Need Gap

The Need Gap is quite easy to measure - look at the time between when people first speak of a need until people stop talking about it and how (un-)happy customers are during that time.

There's no such thing as a DevOps Department

"Can we set up a DevOps Department, and if so: How do we proceed in doing this?"
As the title reads, my take is: No.

Recently, I was in a conversation with a middle manager, let's call him Terry, whose organization just recently started to move towards agility. He had a serious concern, and asked for help. The following conversation ensued - (with some creative license to protect privacy of the individual) :

The conversation

Terry: "I'm in charge of our upcoming DevOps department and have a question to you, as an experienced agile transformation expert: How big should the DevOps department be?"

Me: "I really don't know how to answer this, let me ask you some questions first."
Me: "What do you even mean by, 'DevOps Department'? What are they supposed to do?"

Terry: "You know, DevOps. Setting up dev tools, creating the CD pipeline, providing environments, deployment, monitoring. Regular DevOps tasks."

Me: "Why would you form a separate department for that and not let that be part of the Development teams?"

Terry: "Because if teams take care of their own tools and infrastructure, they will be using lots of different tools."

Me: "And that would be a problem, as in: how?"

Terry: "There would be lots of redundant instances of stuff like Jira and Sonar and we might be paying license fees multiple times."

Me: "And that would be a problem, as in: how?"

Terry: "Well, we need a DevOps department because otherwise, there will be lots of local optimization, extra expenses and confusion."

Me: "Do you actually observe any of these things on a significant scale?"

Terry: "Not yet, but there will be. But back to my question: How big should the department be, what's the best practice?"

Me: "Have you even researched the topic a little bit on the Internet yet?"

Terry: "I was looking how many percent of a project's budget should be assigned for the DevOps unit."

Terry: "And every resource I looked pretty much said the same thing, 'Don't do it.'.But that's not what I am looking for."

Me: "Sorry Terry, there is so much we need to clarify here that the only advice I can give you for the moment is to reflect WHY every internet resource you could find suggested to not do it."

Why not?

Maybe you are a Terry and looking for how to set up a DevOps department, so let me get into the reasons where I think Terry took a wrong turn.

• Terry was still thinking in functional separation, classic Tayloristic Silo structures, and instead of researching what agile organizations actually look like, he was working with the assumption that agile structures are the same thing.
• Terry fell into another trap: not even understanding what DevOps is, thinking it was only about tools and servers. Indeed, DevOps is nothing more than removing the separation between Dev and Ops - a DevOps is both Dev and Ops, not a separate department that does neither properly.
• Terry presumed that "The Perfect DevOps toolbox" exists, whereas every system is different, every team is different, every customer is different. While certain tools are fairly wide-spread, it's up to the team to decide what they can work with best.
• Terry presumed that it is by default centralization is an optimization. While indeed, both centralization and decentralization have trade-offs, centralization has a massive opportunity cost that needs to be warranted by a use case first!
• Terry wanted to solve fictional problems. "Could, might, will" without observable evidence are probably the biggest reason for wasted company resources. Oddly enough, DevOps is all about data-driven decision makings and total, automated process control. A DevOps mindset would never permit major investments into undefined opportunities.
• Terry was thinking in terms of classical project-based resource allocation and funding. Not even this premise makes sense in an agile organization, and it's a major impediment towards customer satisfaction and sustainable quality. DevOps is primarily a quality initiative, and when your basic organizational structure doesn't support quality, DevOps is just a buzzword.

Reasons for DevOps

Some more key problems that DevOps tries to address:

• Organizational hoops required to get the tools developers need to do their job: Creating a different organizational hoop is just putting lipstick on a pig.
• Developers don't know what's happening on Production: Any form of delegation doesn't solve the problem.
• Handovers slowing down the process: It doesn't matter what the name of the handover party is, it's still a handover.
• Manual activity and faulty documentation: Defects in the delivery chain are best prevented by making the people with an idea responsible for success. 
• Lack of evidence: An organization with low traceability from cause to action will not improve this by further decoupling cause and action.

How-To: DevOps

• If you have Dev and Ops, drop the labels and call all of them Developers. Oh - and don't replace it with the DevOps label, either!
• Equip developers with the necessary knowledge to bear the responsibility of Operations activity.
• Enable developers to use the required tools to bring every part of the environment fully under automated control,
• Bring developers closer to the users, either by direct dialog or through data.
• Move towards data-driven decision making on all levels: Task-wise, structurally, organizationally and strategically.

And that is my take on the subject of setting up a DevOps department.

The Management-Coach clash

When an agile coach or Scrum Master is brought into a traditional line organization, there is a high risk of misunderstanding and clashing, oftentimes leading to frustration. Why is that so? Let us explore the traditional expectations towards different roles.


Upton Sinclair said it all with his famous quote:

It is difficult to get a man to understand something when his salary depends upon his not understanding it.

As I had these discussions multiple times in the past, here is a short diagram to illustrate what causes the clash. We will explore below:

Asserting authority

Managers get paid to be in control of their domain. When things aren't under control, they are expected to bring them under control. A good manager is expected to be able to state at any time that everything happens according to their provision, and nothing happens that wasn't agreed beforehand.

A consultants' authority is granted and limited by their hiring manager, and the consultant is expected to exercise their authority to drive their specific agenda in service of their manager.

A coach doesn't assert authority over others, and won't drive a predetermined agenda. Instead, a coach helps people realize their own potential and freely choose the course of action they consider best - although clearly within the scope.

And that's where coaches and managers clash:
Managers might think that coaches will exercise authority over the team and thus be sorely disappointed when they see that the coach isn't in control of the team's work, and the coach will be sorely disappointed when management reveals that they think the coach is doing a crummy job for not taking control.

Solution focus

Managers are expected to have a solution, and do whatever it takes to get one. The proverbial statement, "Bring me solutions, not problems" is descriptive here. When higher ranking people within the organization ask a manager about something within their domain, the only appropriate answer is either "This is our solution" or "We are working on a solution."

For consultants, the only appropriate answer is "This is the solution", or maybe "I need x days and then I will give you the solution"

Coaching is an entirely different book: "The solution is within you. I will help you find it." - maybe the coach does have a clear understanding of the solution, maybe not. This isn't even relevant. Important is that the coach guides others in finding their solution.

And that's where coaches and managers clash:
Managers might think that coaches are problem solvers. With this expectation, either the coach should take proactive steps to install a solution before the problem occurs or immediately resolve any issue once it occurs.
Looking at the flip side of the coin, the coach may argue that they can't work with managers who always look to the coach for the solution and aren't willing to spend time and reflect on the situation.

Getting people to think

In traditional management, managers are considered intellectual, "thinkers". Their job is to think, so that others can do. (Let's ignore for argument's sake that most managers' calendar is so cluttered with appointments that they have zero time left to think.) Statements like "This is above my paygrade" are epitomes for a corporate culture where thinking is considered the responsibility of management.

A consultant has a higher self-interest in getting some people to think - at a minimum, the hiring manager should put enough consideration into the consultant's proposal to understand how their solution will affect the organization, preferably in a beneficial way.

Coaches take another stance: Ideally, they encourage others to think by asking probing, critical questions and being skeptical about other people's solution - in order to help people get beyond preconceived notions and think in wider horizons. The more thinking a coach does for the organization, the less sustainable the solution will be once the coach leaves.


And that's where coaches and managers clash:
Managers might expect the coach to use their free time to think of better ways of doing things and then come back with a clear list of improvement suggestions that just needs to be ticked off.

A coach might not do that, which neither means the coach is lazy nor that the coach isn't smart enough to do that: The coach will have a number of items in mind that need to be worked on, and help the organization get to these points one by one, when they are ready. Maybe the only thing management sees is that coaches asks a few key questions so that people will think about what's really going on and which systemic changes will improve the situation.

Defusing the conflict

Misalignment of expectations is the main cause of frustration between coaches and management. Early and frequent communication helps. Coaches need to understand how managers tick, what they get paid for and what they expect. Likewise, managers should be cautious about hiring coaches before they understand how a coach works.

For a manager, it's okay to get a consultant rather than a coach, and indeed that may be better than hiring a professional coach and expecting them to work as a consultant. It's also okay to tell the coach to tone down on the coaching and dig more into consulting.

For a coach, it's okay to start a serious discussion whether coaching or consulting is more congruent with management expectations, and propose switching into a consulting mode as fit. It's also okay to tip your hat and take your leave when consulting isn't what you expect to be doing.

It's not okay to get angry and blame one another just because we don't understand each other.