The self-preservation of Corporate systems

Can we fundamentally change a company culture? If so, how can we approach it lest the self-preservation mechanisms snap the system back into its former status quo? Let us examine the joints and levers within a typical corporate system with a causal loop diagram - and what we would need to tackle to make a lasting change.

A stable corporate system

Before we take a look at the slightly scary diagram, let me explain the basic representation model:

Defining the model

Black rectangles represent organizational artifacts and/or structures.
The colors red and blue represent negatives and positives, so respectively:

• A red circle represents a negative system variable of which you probably want to have as little as possible.
• A blue circle represents a negative system variable of which you may want to have as much as possible.
• A red arrow represents a negative causation, which means by adding more of the source, you get more of the target.
• A blue arrow represents a positive causation, which means that adding more of the source means you'll end up with more of the target.

With this in mind, take look at the model:

Example 1: Titles and hierarchies

Why do organizations assign titles and positions? You may find numerous reasons,such as a way represent responsibility, denote boundaries, indicate paycheck size or soffer prestige as a non-monetary reward or incentive.

Regardless of the initial reason for creating a title, the title or position derives meaning from the privilege it provides. Any such privilege indicates that a hierarchy is formed.
For example, you can't have a Ministry of Silly Walks if there's nobody in charge of Silly Walks - so the organization gets divided into those responsible for Silly Walks and those not.

As long as the position and the title exist, the organizational boundary continues to exist, and as long as the organizational unit exists, it needs someone in charge and some executive function to take strategic responsibility.

As the years go by, it becomes impossible to discern whether the Ministry of Silly Walks exists because the company needs it, but since it has a function, it needs to continue to exist - and when someone from that unit leaves, another person is hired to fill the role: The position exists because the hierarchy has a place for it, and the hierarchy has a place for it because it exists.

As more organizational units are added, the hierarchy becomes stronger - and a strong hierarchy needs clear separation of responsibility to function: a positive reinforcement loop.

Example 2: The mindset of a hierarchical organization

As soon as a hierarchy has been defined, people start to think in terms of that hierarchy. "We need a Silly Walker for the Ministry of Silly Walks".

It doesn't stop at needing someone who meets the requirement of Silly Walking: we wouldn't want to hire just anyone for Silly Walks - we need someone who is good at Silly Walks, who has experience and who is the perfect fit for the position. Rather than consider the myriad of ways in which a person can add value to the organization, the position of Silly Walking would be given to a person with proven track record of Silly Walks, a person with a history in Sales and Marketing wouldn't even be considered.
Likewise, a person who worked in Silly Walks for years is "obviously" best suited for Silly Walks. It becomes ludicrous to entertain the idea to place such a person in IT or customer care. The pervasive mindset becomes that people can only be good at the things they did before - a "fixed mindset":

As titles become more important, people themselves stop entertaining the idea of changing roles - why would a VP of Silly Walks want to take the role of "Developer" or "Scrum Master"? So instead of moving towards a system where people can learn and contribute the highest value to the organization, the system preserves its hierarchy: "Because I have this position, I will fight tooth and nails to preserve its existence."

We end up with a vicious circle where a fixed mindset entrenches itself and becomes a self-fulfilling prophesy.

Example 3: Transitive preservation mechanisms

When an organization would take steps to fix their problems one by one, they could do something about it - for example, let's say the organization would choose to get rid of the hierarchy in an attempt to remove the need for Resume/CV processing:

They will soon discover that the hierarchy isn't what led to the need for CV processing, although by direct causation, the primary construct which made Resumes necessary no longer exists. Even if the entire management layer would leave, people would still think in titles and positions, would still feel a person's value to the organization could be defined by their CV - and would think that CV's are still a good idea. Eventually, people would resort to "fixing the problem" of absence of hierarchy by - reintroducing hierarchy.
The transitive nature of systemic dependencies would rengenerate the system back to former status quo.

The complexity of the system

We just took one small example on three items from the system model - and there's a whole lot more to it. For example, large hierarchies with clear boundaries set people apart: "Those sales peeps" or "That's an IT problem" are just examples of common statements we often hear.
To control this separation, reports are introduced - and reports without consequences are meaningless, so systems of reward and punishment are introducted - which induces fear, both on punishment and reward (Fear of Missing Out) - which leads to shoving problems under the rug, which reduces transparency, which makes it more difficult to trust -- yada yada.

Regardless of where we look, a corporate system makes sense when looking at it from within the system: if we would abolish any single component, there would be more problems, so we need to re-introduce said component.

The real issue behind such a complex system is its tendency to meet the Laws of Irreducible Complexity.

Self-Preservation

A corporate system preserves itself due to a number of closed and transitive feedback loops: for example, even if we would remove the "Reporting" and "Rewards/Punishments" components from the system, there would still be the problem of distance and absence of trust, which seems most logical in the Enterprise world to fix via introducing the abolished mechanisms.

Delayed effect

Change isn't instantaneous. An organization suffering from strong negative system variables or weak positive system variables won't spontanenously fix their problem by changing their components. For example, if we have a high fear factor, stopping extrinsic incentives isn't going to remove the fear - removal of fear takes a long time, and some people might never overcome the specters of the past.
Removing a systemic component and dealing with the systemic variable by introducing a "repair construct" (such as coaching) need to go hand in hand - yet aren't a guarantee for successful change.

Change your mind!

Startups and small companies get by quite well without any of these mechanisms, and many larger organizations (such a volunteer organizations etc.) can also do without such artifacts.
Why does it work there? Because the basis is completely different. Instead of investing into hierarchies and titles, they invest into getting meaningful work done. Instead of introducing reports, they work on creating transparency and trust. Instead of creating a value plaque to hand into HQ, they talk about what matters to them. Instead of hiring for fit, they hire for value - and so on.

You can't reinvent a corporation by abolishing or fixing one mechanism - you have to start with the mind and work on everything at the same time!

Complex, yet simple

This model contains a lot of assumptions and simplifications. Organizations are significantly more complex, and the mechanisms which make people tick could be innumerate. I wouldn't be able to fit all important factors into this model and still let it be readable.

When attempting to make changes to a complex system, we need to understand the important components, variables and levers. What we consider "un-important" and neglect in our modeling might crawl out of the cave and bite us at the most inconvenient moment. Even with the above model, careful consideration needs to be exercised before trying to change a system.

Conclusion

There is no simple way to change an established organization, even when that organization is a dreadful place to work.

It's much simpler to build up a new organization with a blank slate and without all the harmful constructs than fixing an existing system.
Where this is not an option, the process of change relies on constant feedback about the current state of the system and permanent discovery of the hidden systemic factors which would snap the old system back into place.

Finding the right Product Owner

An important question to answer, especially when launching your first Scrum team: "Should we choose of our own employees as Product Owner, and if so: whom - or should we find a contractor?" The answer is a clear: "It depends". And here's why:

Value Optimization

The most important function of the Product Owner is to optimize the value of the delivered product. Everything else is subject to that. Especially the first couple of Sprints should have a visible impact and give stakeholders the impression that the team is doing things which matter.

And here is the first splitting point:
A member of the existing staff is already familiar with the business, knows the important stakeholders and understands the work done by the organization within the product domain so far. This put them at a real advantage over a newly hired contractor.
A long-term employee might approach Product Ownership with a "Yeah, I know this" mindset, whereas a contracted PO will actively seek out what they don't know - and thereby explore important areas a current member of the staff could have skipped.

Value Organization

To build the best possible product, the backlog must be in shape. The backlog is an itemized and prioritized list of what you know. Split, slice and sort, extract value and prioritize by need. A good analyst should be familiar with most of these activities, so the PO should be able to get some support with that as needed without even being an expert in the product domain.

The second splitting point:
People who are suitable for the PO role can separate essentials from nice-to-have and need to be pretty harsh to descope even things they themselves might consider necessary. Employees of an organization who for some reason need to play favorites with specific stakeholders in disfavor of the product aren't a good fit.
Another plus for a contractor: They might not have to please one specific audience and can descope anything which has only career-political, but no business value. A note of caution though: This becomes dangerous when their paycheck hinges on a single stakeholder!

Taking Risks

Many organizations are inherently risk-averse, and so are their staff. Especially conservative enterprises where employees have learned over the years to avoid taking risks at all costs will be challenged to suddenly find people within their organization who are happy to go completely new ways, work with uncertainty and prioritize things where success or failure can only be known after the fact.
A PO who shies away from taking risks will be highly unlikely to build anything exciting and most likely will end up building something as close as possible to something which already exists.

This is the third splitting point:
The PO role isn't for perfectionists. The proverb "Perfect is the enemy of the good" comes in at this point. Most highly qualified people in organizations default on the PO role because they try to build a product based on what they know and shy away from building a product based on what they don't know.
A contractor who knows very well that they can't know everything may be much more open to explore feasible options others might never consider with their organizational shutters.

Role Assignment

Rather than start with the question "Who should be PO", we need to look at the activities which are required to be effective as a PO, then determine how we plan to make them happen. While skills can be acquired, the challenge is more in un-learning the things one has always done than it is in learning that which is now required.

By picking a member of your existing staff, there's a risk that the PO role isn't filled adequately.
Here are a few common choices for internal PO:

• Analyst as PO
  Analysts are great at supporting a PO, yet they tend to struggle with independent splitting and value-ordering. Especially if your Scrum Master is also inexperienced, such a setup has massive challenges to begin with. Try to avoid this scenario and let the analysts do what they do best: analyze the prioritized items for the team.
• Project Manager as PO
  This scenario is extremely dangerous, as PM and PO have completely different job descriptions. A PM will have to un-learn so many things in order to be effective as a PO that a new hire is probably the better fit. PM skills are still valuable, although a PM is better suited as a team member than as PO.
• Line Manager as PO
  An almost surefire road to disaster, as the Line Manager's responsibility is oriented in a different direction. This will most likely end up with either line management or PO duties being dangerously neglected. Likewise, line managers often tend to be challenged at creating, maintaining and communicating a Product Vision.
• Marketing/Sales as PO
  In some cases, this works like a charm. The danger is that Marketing mioght have very little contact with real users, risking to build the wrong thing - and Sales might be too focused on delivery and neglects strategy. Both are important stakeholders with valuable perspectives, yet they may not have what it takes to be a PO.
• Senior Manager as PO
  The worst part about the Senior Manager being PO is that they often don't have enough time to spend with stakeholders and team members to ensure the right product is being built and that the most valuable things are being done. A better setup is that the Senior Manager backs and supports a PO who is fully focused on Product Ownership.
• PO as a title
  The worst choice organizations often make is assign the PO role via "appeasement politics", i.e. give this important role to someone who would otherwise begrudge the transition to Scrum. Just don't. Instead, find out what their gripe is and coach them to find their place in the new organization.

Then - who's suitable to be a PO? 

A PO is a PO, and while any member of existing staff can learn Product Ownership, they weren't born as PO. The role of the PO must be learned, and this learning process takes time. A lot of failure learning is involved, so the main question isn't "Whom should we choose as PO?" than a series of questions about the goal of Scrum in context:

1. How fast do we need to produce something?
2. How is our organization prepare to identify value?
3. How do we know we build the most valuable thing?
4. How do we know we are building the right thing?
5. What happens when we built the wrong thing?
6. Which challenges will the product itself face?

After discussing the organizational constraints, we need to discuss the context of the Product Owner:

1. Which support can we give to the PO to learn their role?
2. Which support can we give to the PO to be effective?
3. Can our PO be politically neutral, i.e. unbiased from departmental priorities?

Finally, I would shortlist a list of candidates who might be suitable to take on the role:

1. How close are they to the required skills of a successful PO?
2. Can they formulate and communicate a Product Vision?
3. Do they have a standing of high respect within the organization?
4. Do they have an entrepreneureal mindset?
5. Will they act in the best interests of the product?
6. Do they understand business?
7. Are we willing to relieve them of other responsibilites?

While there's no "perfect PO", there are some people who are more or less suitable to fill the role. Any available person who comes sufficiently close to a good fit should be considered.

Assigning the Product Owner

Based on all the above, consider the following question:

How likely can we get an internal PO prepared for the role? 

If there's a decent likelihood, find one and give them the necessary support to succeed.

This "necessary support" will require a set of decisions and changes within the organization as well as training and coaching. It might require contracting an experienced PO to "teach the ropes" and potentially onboarding a PO coach to keep the ship afloat during the turmoils which will come.

If odds look dim, you might prefer contracting a PO.

While they are around, you should be working on resolving the organizational impediments which necessitate an external expert in this position. As soon as possible, find a staff member who can fill the role and let them learn on the job by working with the contracted PO.

Summary

The key challenges for finding the right PO include:

• Freedom from organizational structures and politics
• Entrepreneurial thinking

Most staff members would have issues with either or both of these challenges, but they're more suitable because they will be more likely to stick around for a major portion of the product's lifetime.

A contracted PO is a workaround for problems that might not be tackled on a short notice. Finding and enabling the right person within an organization to be PO is a major challenge, so a contractor buys time here without solving the issue. 

In the long term, a PO should always be a permanent ember of your organization - although supporting them with a contracted Product Owner Coach might be a great idea to maximize the value of the product they're building.

The Scrum Master role

What's a Scrum Master - what do they do all day?
Many companies seem to have trouble identifying the proper role for the Scrum Master, their job descriptions already hint that they're looking for something other than a Scrum Master, which implies that a successful hire is unlikely going to help the team succeed with Scrum.

What's not a Scrum Master?

A Scrum Master is definitely not a rebranded management role in any form or fashion. They are not available to help managers retain command or control of the Scrum team. Their role is not intended to do any work either on the product or on the process. They also are not a secretary or a kind of errand person for the team.
Also, contrary to popular belief, the Scrum Master is in no way responsible for the delivery - neither in terms of quality, nor quantity.

Even terms like "Evangelist" or "Enforcer" might hint at behaviours a that could cause potentially detrimential behaviour.

A Scrum Master's power, as odd as that sounds, comes from not having any power. By empowering the Scrum Master in any regard, they lose this superpower.

Then what is a Scrum Master?

As hinted in another post, a Scrum Master's responsibility is primarily the people and their interactions - helping the team focus on their goal, deliver effectively and support the resolution of impediments towards higher performance.

Most notably, a Scrum Master would create transparency, visibility and thereby awareness of key impediments more than they would actively resolve them. Why? Everything the Scrum Master does reduces the learning effect of the team or the surrounding organization.
In knowledge work, learning leads to understanding, which then becomes the baseline for performance. Therefore, the main responsibility of the Scrum Master is to make learning happen.

In one sentence, the Scrum Master is a "Learning Maximizer".


To support you, here is a list of traits that you might want to be on the look out either in being or in choosing a Scrum Master:

Not helpful	Helpful
Project Manager	Help management change from moving teams to work towards moving work to teams
Release Manager	Assist Product Owner and Developers in defining and tracking releases
Delivery Manager	Remind the teams of their responsibility to deliver
Process Manager	Reflect on the process
Team Manager	Remind people when they break their Working Agreements
Problem solver	Support the team in solving their problems
Scrum Evangelist	Teach Scrum in and around the team
Meeting Organizer / Moderator	Help the team have effective meetings
Technical / Subject Matter Expert	Expert in regards to Scrum, change management, coaching
Jira Admin	Support the team in discovering and using appropriate tools
Bouncer	Help people realize which interactions aren't helpful
Enforce Scrum	Remind people when they break Scrum
Track team‘s progress	Support the team in making progress transparent
Produce reports	Create transparency
Threaten, manipulate, coerce	Encourage the team to do their best

To wrap it up, here's an illustration of what a Scrum Master does or doesn't:

The Product Owner role

What's a Product Owner - and what do they do?
There are a lot of opinons out there, so let me just throw mine into the ring as well.

What's not a Product Owner?

The Scrum Guide is quite clear that a Product Owner and a Business Analyst are not the same roles. Neither is a requirements engineer or a project manager a Product Owner. A Product Owner is not responsible for "writing user stories". Neither proposing solutions, architecture or design. Nor for tracking developers' progress, the quality of their work or the approach they use in generating results.

Likewise, there's a huge misunderstanding that the PO is a kind of go-between, mediator, between stakeholders and developers. Oddly enough, the Scrum Guide doesn't say any of that.

Indeed, a PO who acts in any way as above is more likely to negatively impact the outcome than to add value.

Then what is a Product Owner?

When taking a close look at the Guide, the Product Owner can delegate almost everything to the Development team. They only need to make sure that transparency on a product level exists, that developers know what is important and why. How they do this - no constraints.

In one sentence, the PO can be called "value maximizer". How do they do that? They learn and understand customer needs, problem statements and expected benefits from having such a need met by solving said problem. To be most effective, it helps if they have an understanding of what their development team is capable of, have a knack on linking the solutions of the team back to the problems that exist and can make clear business-oriented decisions based on cost and ROI.

Like customers own the "problem space", developers own the "solution space". The Product Owner brings these two spaces together by linking them via value and priority. No more, no less. The more the development team can contribute here, the more the Product Owner can focus on exploring further needs that can be met to make the product more valuable.


So here's a short infographic as a summary:

Agile in the Value Stream

Many organizations claim to be agile without ever having understood what makes a company agile. They bought an "Agile Transformation" - and think that afterwards, agility is achieved. What does this look like, why is it fake - and what is the difference?

Fake Agile

Let's take a look at a typical organization value stream for software delivery:

Being agile without customer contact never worked!

In the beginning, there's Marketing, Presales and Sales, all talking with the customer, discovering what the customer needs and is willing to pay for. Once a contract is signed, the project is planned, requirements are formulated, some code is written, tested and then deployed.  All straightforward.

When the organization realizes that customers aren't getting what they want and/or are getting it too late or expensive, managers are looking for a way out. Enter: "Agile", most notably: Scrum. Scrum uses terminology like "Development team", and since most people equate "Coding" and "Development", Scrum is being introduced as the miracle pill in the Coding stage of the value stream and the organization expects all problems to be solved.

Developers are still not in touch with customers, work off specifications and hand off bulk increments into testing, where then defects are discovered, reworked, launch is delayed - and nothing has improved.
Even though this form of "Agile" might improve the amount of work done by developers and slightly reduce the overhead of getting code finished, in the big picture, even a 100% effort reduction in Coding would still only reduce the overall effort of getting a project to "Done" by a mere 12%.
Since a 100% capacity increase in coding - which is a massive stretch for most organizations - performance is merely a 50% reduction in duration, it's almost impossible to achieve a statistically significant (thereby, visible) improvement in organizational performance across the value stream.

This kind of organization tends to be trimmed for efficiency, where each department tries to both maximize utilization and minimize their own cost.

Even if coders were absolutely perfect, worked in zero time and for free, the overall approach would still be staggeringly slow, ineffective and not satisfying to the customer. This is why such an approach to agility is fake.

Genuine agile delivery

An agile organization is most notably different in one aspect: The customer is at the heart of each activity. Not "fake customers" like sales who, although demanding something, are not those who actually will be using the product - but the real customers who are interested in using the product themselves:

Customer Centricity in everything we do

What makes things slow, unreliable and expensive are the handovers, where delay is introduced and information is lost. We need to drop organizational barriers and let everyone talk with the customer as needed. Departmental priorities need to be replaced by product priorities. Everyone needs to collaborate with each other and the customer in achieving one common goal: maximizing the value delivered while minimizing overall effort.

Coding is no longer the focus of being agile - not even IT as a whole. Indeed, the focus shifts away from activity to outcome. What matters to business success isn't that IT can get their job done, but that the customer gets what they need! Everything else will fall into place accordingly.

In this kind of organization, some things don't appear to be efficient. The same discussion may happen multiple times (which is still better than working against unfounded assumptions) and cost is fixed, irrespective of workload.
Agile organizations optimize for effectiveness, i.e., getting things Done in a way that pleases the customer.
This only makes sense from a system's perspective, not from a departmental perspective. Hence, it's important to include everyone in such a process. Any function not included will end up a bottleneck and could block the flow.

Fully agile enterprises

I omitted "Operation / Maintenance / Customer Service" functions in the above model, even though these are equally (and potentially more) important. This breaks down the final barriers beyond "Done", integrating practical experiences with the product into the feedback loop as well.
In the ultimate stage, every action is aligned with customer needs and every piece of learning harnessed for competitive advantage.

Conclusion

Contrary to popular belief, "being agile" isn't something limited to software development. It's a way of running an enterprise that revolutionizes how we think about value streams and value generation.

While the first hurdle in an agile transition is often rewiring the brains of developers to move away from meeting requirements to understanding customers, it by far isn't the biggest. The biggest hurdle is breaking out of a limited IT setting - and opening the doors for the collaboration of all departments for one common goal: business success.