The Agile Tragedy of Commons

There's a socioeconomical dilemma called, "Tragedy of the Commons" which effectively means, "In unregulated systems, local optimization may become so extreme that the system becomes unsustainable."
And here's why you need to understand it in order to understand "agility at scale."

Before we get started, though, let me explain the dilemma:

The Tragedy of Commons

Imagine there's a huge, pristine green pasture. The lord of the land has decreed that everyone is free to use this pasture for shepherding their flock.

The first shepherd who arrives finds a vast green pasture, and the flock is happy to graze on the fields.

Soon afterwards, another shepherd arrives, and their sheep graze happily on the lush pasture as well. Both shepherds are happy, as their sheep have ample food to eat.

In the excellent conditions, the flocks multiply.

As the flocks grow, there is no longer an overabundance - the sheep of the two shepherds begin competing for food. The first shepherd's sheep had more time to multiply, and the second shepherd's sheep lack the required conditions to multiply freely.

Both flocks compete over increasingly scarce food: the sheep lack nutrition and are threatened from starvation. The first shepherd feels that the second shepherd's presence has caused this threat to their flock. The second shepherd considers the first to be using their unfair advantage of having a bigger flock to drive them off the pasture. Quarrels arise.

The feudal lord settles the dispute by dividing the once lush green pasture into an allotted segment for each shepherd, based on the size of their flock. Both shepherds now have access to less land than they could access before - but each now has full control over their flock.

Should the lord have settled the dispute in this way? Should the lord have found another solution? Take some time to think. What would have happened - had the lord not intervened?

Tragedy of Agile Commons

There are many, and massive, applications to the Tragedy of Commons in the realm of software systems - moreso in scaled environments. In the land of Agile, they're much more visible than in the land of Waterfalls, where the lots are already divided before they exist: Agile teams incrementally and empirically discover their next best move based on where they are today - perfect preconditions for the Tragedy of Commons.

Common Code

Teams who haven't learnt discipline in code will find it highly irritating to see one developer interfering with another developer's code: "my" coding style is always better than "yours."

Quickly, quality problems begin arising on the Common Codebase: quarrels over style, functionality placement, inconsistencies and many others.

As more and more developers enter the scene, the tendency for code silos built around personal preference, coding style, technologies, or even domains increases.

Whereas one team can often be left to freely roam the green pastures of service implementation, the field quickly turns into a brown quagmire when multiple teams all play their preferences, until the code base becomes entirely unworkable.

Once teams build fences around their codebase, Collective Code Ownership becomes a thing of the past, and Component Teams find themselves entertaining a dreadful nightmare of coordination meetings.

Better approaches could be:

• code conventions
• linting rules
• cross-team Pairing sessions
• Code dojos
• Continuous Integration / Continous Delivery

- but these things are all topics large organizations struggle with after the code has been divided into silos.

Common Innovation

A green field project is often a great way to introduce new, more powerful technologies that allow teams to do less with more.

As the development organization matures, and standards begin to shape the landscape, new ideas becomes exotic and marginal, struggling to overcome inertia.

Imagine - just for example - introducing agent-based logic into an architecture driven by RPC's and SOAP requests: There will be few takers for such an innovation.

The Tragedy of Common Innovation is that new ideas have to find a really small niche when the field is already taken by old ideas. Many good ideas go extinct before they can catch a hold.

With a constant decline of innovative ideas, organizations eventually find themselves investing massive efforts into servicing outdates ways of working and technologies, incapacitating their ability to deliver high value to the customer in the same ways others do.

Better approaches might be:

• innovation allotments
• hackathons
• innovation sessions
• innovation champions
• cross-team collaboration on innovation
• intrapreneurship

Common Meetings

Have you ever been in a 2-hour meeting with 40 people? Did you ever pay attention to how many people actually speak? Hint: it's most likely not an even distribution.

Small organizations find their meetings very effective, but as more and more people appear on the scene, meeting effectiveness quickly declines. And there's a reason.

In an effective 3-people, 1-hour meeting, every person gets to speak roughly 20 minutes. That's a lot of time to voice ideas, offer feedback and draw conclusions. That's a 33% activity ratio. And everyone has pretty much the same understanding afterwards.

When we constrast this with a 30-people, 2-hour meeting: Simply by dividing clock time, we see that every person gets to speak an average of 4 minutes, while being forced to listen for an average of 116 minutes: The ratio of ideas contributed versus passivity is staggering for each individual - the activity ratio has dropped to a mere 3%! In such a scenario, the tragedy of common meetings becomes that some of the more experienced people take the stage, and everyone else becomes decoration.

Solution approaches might be:

• focus sessions
• using a need-to-know principle
• Law of Two Feet
• breakout sessions
• topic ownership

Specialisation also removes the need for everyone to participate in all discussions.

The tradeoff is mainly between not everyone getting firsthand information and people suffering through hours of only marginally relevant meetings. To any solution, there's a downside.

Common Work

A single developer can work on any code at any time, and there will be no unpredicted side effects like merge conflicts caused by others' work. Small teams will usually learn quickly how to coordinate so that they minimize mutual interference.

Without good engineering practice, delivering a larger, integrated piece of software means lots of simultaneous changes in many places. Teams will either get into a Riverdance of constantly stepping on each other's toes, or they will require so much coordination that things get really messy. Of course, the "solution," is - once again - code silos and dependency hell: productivity tanks as risks and delays rise skywards.

Every developer joining an organization that hasn't managed to deal with the Tragedy of Common Work adequately, will make every developer's productivity decline - up to a point where the net productivity gain of hiring additional developers may be negative, i.e. with each new hire, the organization gets less productive overall!

Potential solutions could be:

• visual dependency management
• domain separation
• decoupling
• joint roadmap planning
• cyclical synchronisation points
• communication by code

Now what?

These are just four examples of how the Tragedy of Commons matters a lot in a Scaled Agile setting, and there are a vast number of potential commons.

Regardless of whether an Enterprise is new to agile ways of working or have been doing so for a while: you need to establish overarching rules that mitigate the conflicts, lest you run afoul of the Tragedy of Commons.

The "Tragedy of Commons" is entirely evitable in a holistic system where every participant sees themselves as an integral part of the whole. The solution is coexistence and collaborative conflict resolution rather than competition.

Ground rules address unregulated, harmful growth, a lack of discipline, and myopic actions, but each rule comes with a drawback: it reduces flexibility. While Team Autonomy needs boundaries where these are for the Greater Good, it's important to set these boundaries wisely, and revisiting these where they aren't useful. That can't be done by only one group - in a common system, it has to involve all those whom it concerns.

Which boundaries will you set to prevent your organization from suffering the Tragedy of the Commons, and what is their cost?

Culture Conversion

Many times, I hear that "SAFe doesn't work" both from Agile Coaches and companies who've tried it, and the reasons behind the complaint tend to boil down to a single pattern that is missing in the SAFe implementation - culture conversion. Let's explore why this pattern is so important, what it is, and how to establish it.

The Culture Clash

Many enterprises are often built upon classical management principles: Workers are seen as lazy, selfish and disposable "resources". Decisions are made at the top, execution is delegated. We have a constant tug-of-war between "The Business" and "Development". All problems are caused by "Them" (irrespective of whom you ask) - and the key objective is always to pass the next milestone lest heads roll.  There is little space for face-level exchange of ideas, mutual problem solving, growth and learning.

If you try to use an agile approach, which is built upon an entirely different set of principles, practices and beliefs, you'll get a clash. Either workers care, or they don't. Either people are valuable, or they aren't. Either they can think, or they can't. You get the idea. Behind that is a thing called "Theory X/Y." 

Self-fulfilling prophesy

When you treat people like trash, they'll stop caring about their work. When you don't listen to your developers, they fall silent. When you punish mistakes, workers become passive. And so on. This lose-lose proposition turns into a death spiral and becomes a self-fulfilling prophesy.

Likewise, when you create an environment built upon mutuality, trust and respect, people will behave differently. Except - you can't just declare it to be so, and continue sending signals that the new values are "just theoretical buzzwords that don't match our reality." Because, if you do that, this will again be a self-fulfilling prophesy.

Breaking the vicious circle

You can't change everything overnight, especially not an entire organization. Some people "get it" immediately, others take longer. Some may never get it. Even when you desire and announce a new culture, it can't be taken for granted. You have to work towards it, which can be a lot of effort when dealing with people who have built their entire careers on the ideas of the old culture.  

Resilience over robustness

A lot of this doesn't happen in the realm of processes, org charts and facts - what's truly going on happens mostly in the realm of beliefs, hopes, fears. As such, problems are often difficult to identify or pinpoint until a dangerous symptom becomes manifest. Hence, you can't simply re-design an organization to "implement" this new culture. The best you can do is institute checks and balances, early warning mechanisms, buffer zones and intentional breaking points.

Buffer Zone

Often, you may need time to collect striking evidence that would convince others to let go of certain un-helpful practices. These might include, for example, HR policies, project management or accounting practices. When you can't quite yet eliminate these things, it's quite important for the culture conversion to also include a conversion of such activities, so that they don't affect the teams. At the same time, you need a strategy laid out with clear targets for abolishing these things, lest they become "the new normal" and culture converters start believing them to be right or even essential.

The Culture Conversion Pattern

When you operate in an environment where cultural elements that conflict with the intended future culture exist and will likely interfere with the sustainability of the change, you need mechanisms that let you:

• Establish the desirable culture
• Minimize undesirable culture infringement
• Mitigate damage from culture infringement
• Breaking points when undesirable culture gets too strong
• Identify culture clash

Specific people must take on this responsibility, it's not sufficient to say "We should do this." Someone must be in control of these activities and the entire organization must rigorously apply the above mechanisms, inspecting and adapting relentlessly upon failure.

Failure on any of these will provide a backdoor for the existing, undesirable culture to quickly usurp the new culture, and the culture change will fail.

The SAFe Zone

A healthy SAFe organization would institute the "Program Level" to provide exactly this resilience for culture conversion. The Product Management function would protect the agile organization against low value work and overburden, the RTE function would safeguard against Command and Control, and the architect would be the bulwark against unsustainable engineering. Product Owners and Scrum Masters would provide an additional safety cushion to protect the teams.

These roles must unite to drive the need for transparent, un-political value optimization, mutual collaboration and quality-focused development practice both towards the teams and the non-agile surrounding organization.

Failing Culture Conversion

Let's say your Program Level is being pressured to introduce cultural dysfunctions from the previously existing surrounding organization into the Agile Release Train, and they can't push back. In their function as a culture converter, they are now converting the new culture back into the old culture, and as such, working against the Agile Transformation. If you do not identify and deal with this issue swiftly and strongly, you're setting the fox to keep the geese: The fledgling new culture will be steamrolled by the existing culture in no time.

Summary

When you are using SAFe, ensure that the ART Roles are both willing and able to act as culture converters, and give them the support they need to function properly as such, mostly by relieving them of any and all responsibilities that relate to the "old" culture you want to abolish.

By overriding, short-ciruiting or ignoring the culture conversion function, you're dooming the culture transformation, and since the new ways of working rely on the new culture, you're going to train wreck. 

SAFe sucks when you mess up the culture conversion.

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.

Know your customer!

The Agile Manifesto states "Customer Collaboration over Contract Negotiation". But that's not easy to practice without understanding who the customer actually is.
As organizations grow, the question "Who is the customer?" becomes increasingly difficult to answer, and the answer is often hidden in plain sight. 
In this article, we will discuss how to identify and classify customers, using the practical example of an e-Commerce Platform.

Product Customers

The most obvious category of customers are those who actually use the product. However, even they come in two categories: Those who actively go out to use the product - and those who get to use what others got for them.

Primary Customers

This is the kind of customer you can actively reach out towards. When they like the product, they will be generating revenue for you. It's a good idea to build a direct feedback cycle with them.
These could be web users who like to do online shopping.

Secondary Customers

This is the kind of customer you may not even know to exist. Whether they like the product or not is out of reach. If anything, they would give feedback to the Primary Customers - but you don't have much control over that.
These could be the workers in a company who has decided to get their supplies from our online shop.

Value Stream Customers

How does the value stream "Order to cash" map for your company? Typically, it's not the same people who have an idea, deliver it - and have to live with the consequences. In big companies, ideas are collected, then brought into a type of solution design, then implemented, launched - and then become "business as usual".
Depending on how your organization looks like, that will usually involve different departments, teams and people. Each person involved in product creation has a place in the value stream, and to know "who will receive the result of my work" is a good idea. These people are the value stream customers.
Yes, they are also customers! Life can be quite miserable if you ignore this fact.

(Other) Internal Customers

Sometimes also called "Stakeholder", but let's be explicit here. These are people in the company who actually want something from the product and who will usually assign a portion of (their) company budget towards the realization of a request.
For example, that could be Marketing or Sales desiring access to business performance metrics - or Customer Service asking for a functionality reducing the amount of service calls.
These people usually do not actively use the product, but they do have an important impact on how it is being used.
Since they are in the "large" revenue chain of the Product and receive services from Software Development, they are clearly also customers and it's a good idea to keep them happy for mutual benefit. One thing you should never forget: They do not actively create value for the product, they merely assist in value creation. No matter how many features you build for Marketing, there is no benefit unless you actually see an increase in Product Customers!

Indirect Customers

Living in a society, there is a whole bunch of people who neither want your product, buy your product - or even care about your product, but still place demands on your product.
For example, that could be the Better Business Bureau, the legislature around Data Security - or even the IRS. There is no way to "Please" these customers, but they will kill you if you don't fulfil their requests. The best thing to do is invest minimal effort to keep them off your back.

Summary

In large organizations, the relationships between supplier (you) and customer are often either unknown or agreed in contractual form. If they are unknown, there is a huge risk of misfiring. Hand-Over Contracts (responsibility lists) are good to create transparency, but do not help to solve problems or grow the business. To be successful, you have to go beyond the contractual level with your customer - and collaborate with them for mutual benefit.
The simplest Customer relationship every Scrum team should be aware of is that with the PO. The interface contracts are Definition of Ready (PO => Team) and Definition of Done (Team => PO). There are more customers - how do you handle your relationship with them?

Project Managers and Agility

The statement "Now we're agile, we don't need Project Managers any more" - causes fear in those who used to have a PM role and leads organizations to a very difficult question: "What do we do with our Project Managers?" - sometimes, they hastily conclude "Get rid of them". Let us discuss why this conclusion might be too hasty.

The Ugly

Let us examine first what is wrong with Project Management. For brevity sake, we will only list a few points:

• Gantt Charts presume an organization form that doesn't work in practice
• Role Separation which presumably increases productivity when all it does is add waste
• Perverse incentives, such as rewarding testers for finding defects rather than stopping the root cause
• Watermelon Reporting,  e.g. "we know we're Red, but report Green because that's what management expects" 

In short, Project Managers spend a lot of time setting up a highly wasteful structure and then deceive themselves and the organization that they're doing the right thing.

The Bad

Again, for brevity sake, let us examine briefly what causes the underlying problems in Project Management:

• The Plan: A project Manager gets paid to make and follow a plan. However, there is always some stuff you can't plan: The elements subject to exploration and/or unpredictable change. 
• Complexity: People who fail to make the perfect plan aren't imbeciles, because the world is too complex, with a notion of unpredictability sprinkled in: Planning is good, flexibility is better.
• Detail: Project Manager must work on a certain level of abstraction. Unfortunately, "the devil is in the detail" - i.e. the tricky part can often only be decided by people who are lower in the hierarchy: Only by delegating critical decision authority into the team can a PM succeed.

In short, the world around the Project Manager requires them to do an impossible feat. Only by putting slack ("big gray areas") into the plan and permitting the team to do what they actually should not - i.e. deviating from the plan and breaking the chain of Command - can a project be successful.
As such, the PM role is inherently broken.

The Good

Project Managers do actually bring some skills to the table that are always needed to be successful in an organization. These are:

• - Organizing: Discipline and doing the right thing at the right time are important for success. Nobody has as much experience in organizaing stuff as the PM. Agile teams find a good organizer very helpful - as long as they don't organize things nobody asked for!
• - Breaking down work: Both backlog refinement and Sprint Planning are work breakdown activities - one on a strategic, the other on a tactical level. Poor work breakdown will result in missed goals and frustrated teams and customers. The only question remaining: How do you do it appropriately?
• - Creating transparency: Status reports are only one way to create transparency. However, the PM is used to creating an appropriate level of transparency. Once they rise beyond the non-valuable metrics, the PM will be very useful to help the team be better understood in the organization.

In short, a PM is very useful for getting the right things done rightly - and helping the team get the necessary credibility in the organization to succeed.

Summary

Whether the organization needs a PM or not - is not a question based on the role of the PM. The PM's skills are needed, while the activity a PM did do in the past are not. A PM may add value to the organization in the roles of Product Owner, Scrum Master / Agile coach or team member. However, the PM must unlearn certain prejudices, notices and abandon practices to rise into their new role. Likewise, they must learn agile practices and adopt a new mindset. A PM who is ready to leave their former title and old behaviours behind will be very valuable to an agile organizations.

3 characteristics of outstanding Product Owners

The success of your product depends to a large extent on your Product Owner. If the PO directs the product in the right direction, your success chance will be maximized. If not ... your product may well fail.

How do you decide the future of your product?

Here are three characteristics of outstanding Product Owners:

1 - Obsessed with customers

Customers are not merely those who pay for what you produced. They will use the product - they know what annoys and what pleases them. They are not just consumers. They have opinions, ideas.

Every Product Owner must understand their customers, how they act, what they think, what they want.

Good Product Owners have a good understanding of who their customers are and how they use the Product - and what they will pay for.

Great Product Owners drive this to obsession, constantly looking for new and better ways to understand their customers better, to get closer to their customers.
They become the personification of "the customer" when discussing the next Product Increment - and they become the avatar of "the Product" in their interactions with the Customer.

Outstanding Product Owners are emotionally attached to the Customer and the Product. They feel joy when something is done well, but they also suffer when customers suffer, they feel pain when the product is inadequate - and they can't "not take it personal".

2 - Caring for numbers

Numbers are not everything, but numbers are important. You can't be a good Product Owner if you only groom and discuss user stories. You must correlate them to the needs of the customer and the business.

Every Product Owner must understand the Product Vision, communicate it clearly and base Releases, Epics, Stories and Features on this vision. They must always be able to draw lines forward and backward between these items and be ready to restrict everything that is not in line with the product vision.

Good Product Owners are not only able to map stories. They can relate them to business figures. They understand which Epic, story or feature delivers how much business value. They can clearly discriminate between "gold plating" and Minimum Viable Product. They will deliver the highest value first and cut discard items which do not have a good bottom line.

Great Product Owners will go one level beyond that: They do not only attach a business figure to features, they relate Performance Metrics, such as Clicks, Conversion Rate and hard cash earnings. They do not only predict which feature is most valuable - they build a product that lets them measure, so that they can inspect and adapt their product to maximize value and customer satisfaction.

Outstanding Product Owners transcend all of that - they have the data and are ready to produce accurate analysis at a fingertip. Additionally, they understand the large scale implications of a change: They do not focus only on the product, but on the ecosystem in which the product exists. This includes being aware of potential on short-term gains that might decrease future sustainability - for example the phenomenon called "Mudflation" in MMO's.

3 - Disregarding agendas

Of course, the Product Owner works in your organization. But the loyalty of the Product Owner lies with the Product, not with a specific portion of the organization. They own the product and the product directs them - not management!

Every Product Owner must be in charge of their product. If you're looking for someone to whom you can spoonfeed what to do when, you're not looking for a Product Owner - you're looking for a Project Manager. That's OK, but don't call it Scrum, don't claim to be Agile - and don't wonder why you're wasting lots of money on a failed product: It was a management decision.

Good Product Owners take ownership, just like the title of the role proclaims. This means that they will do what, based on their understanding, is the right thing to do. If management wants the Product Owner to do a certain thing with the product, they will provide clear information on why they want that - and must be willing to accept a "No". A good Product Owner will tell management if an idea is stupid.

Great Product Owners care more for the product than for themselves. They will do the right thing, even if it is a personal disadvantage. They can not be threatened or scared by backroom politics or titles. Neither will they be swayed by personal gain - you can not bribe them with pocket money or promotion. If a suggestion is bad for the product, it will be rejected. Likewise, just because a suggestion is good, it will find it's place in the Product Backlog based on product value, not on someone's title or rank.

Outstanding Product Owners are beyond your company. They choose to dedicate a portion of their life to the product - if you want something from them for a political reason, be prepared for rejection. If you have a suggestion that would destroy their product, be prepared for fire. If you want to gut the product for short term gain, you have to accept that they will make the product successful without you.

Summary

The decision making process of an outstanding Product Owner is driven by customers, numbers and value. You can't own an outstanding Product Owner - and they own the Product.

Before you hire a Product Owner, decide if you really want a Product Owner. Your choices are still to hire a Project Manager, an Analyst or a Requirements Engineer. None of these are Product Owners.

An outstanding Product Owner is not a person to whom you simply delegate work in the development process.

3 things you won't get from me as a Product Owner

The Product Owner is the "single wringable neck" in Scrum. Their understanding of the product and the vision combined with their ability to decide determines success or failure of a product development team.

So, it's only fair that the Product Owner should be able to provide every information about what's going on? No.

Here are 3 things which you will not get from me when I'm a Product Owner.

Assignments

If you are a team member, do not ask me to give you an assignment.

I don't assign stuff because I couldn't. I could. Easily. But I don't. Here is why:

Even before the Sprint, I determine what matters most to the Product. During Sprint Planning, we mutually agree on the team's priority. Your top priority is visible on the Scrum board. It's the topmost item that is not in the "DONE" column.

If you are uncertain which task to pick, you have team members to help you out. Again, during Sprint Planning, the team has agreed on the necessary work items required to get the Stories or Features properly done. I let you, as the team, break it down because you know your trade. And I expect that when you do that, you know what's most important and what is the next step from where you currently stand.

If you don't understand the context of something you work on, I'll gladly discuss with you. If you don't know if something is necessary in order to deliver the value, I'm also open. But I won't tell you what to do - or how to do it.

If you, as a team member, don't know what to do next, I see a serious impediment in team communication. That's something to discuss with the Scrum Master or cover in the next Retro. But the Product Owner is really the wrong person here.

Gantt Charts and Reports

If you are a manager, don't ask me for a Gantt Chart or a % progress report on your backlog items.

I don't produce these because I couldn't. I could. Easily. But I don't. Here is why:

I decide what gets done and when the team engages. I can't tell you when it's guaranteed to be done. You wouldn't want a trash product - you want quality.
Percent Progress Reports are a distraction. You already know from Windows Installer, "The last 1% may take longer than the first 99%". It takes as long as it takes.

I can tell you how big your chunk is and where it sits in my backlog. I can give you an estimate if we'll tackle it in the next sprint, within this quarter - or not.

If you're not satisfied with my answer, we can re-negotiate priority and scope, thereby getting your stuff through the door faster, but we can't negotiate quality or delivery date. Sorry.

Performance Appraisals

If you are Human Resources, don't ask me for individual performance appraisals of developers.

I don't give you an assessment because I couldn't. I could give you my opinion. Easily. But I don't. Here is why:

First, because it's just my opinion. It's tainted by how much I have interacted with that person. It does not reflect total contribution.

Second, is the team producing significant value or not?
If not, that's my problem. If they do, they are doing a good job and then that's your assessment.

Third, let me ask: Why do you even need individual appraisals? Is it "rationalization"?
Let me be witty here: You don't ask your dentist which of your teeth works best, so that you can pull those out that contribute least. You'll want to keep all of them, unless you want to reduce your diet to pulp and soup.


A team is a team. Teams have very complex mechanics. Teams work as teams. If they don't, ask the Scrum Master what they are doing. If they do, then each person has their part.

If you want any information about the team, ask the team. They know best.

Summary

As Product Owner, I will give you the most valuable product in the shortest possible time. I am not the Team Leader or a Project Manager, despite the fact that I have significant experience in those things.
We will never get anywhere as long as I act as if I were the brightest bulb in the lamp.
I trust the self-organization of highly competent individuals to do what is right.
If that is not happening, that's something to improve upon - not to undermine.

Shared Vision over dedicated Product Owners

The first value of the Post-Scrum Manifesto states "Shared Vision over dedicated Product Owners".

To understand what this means, we must briefly glance at why we even have Product Owners in Scrum.

The role of the Product Owner

The primary role of the PO is to communicate the product vision with all stakeholders and maximize product value. When there is a misunderstanding or dispute, the PO facilitates the dialog. Moreover, the PO owns the Product Backlog. They decide what will be part of the product - and what won't. They set the priority and are accountable for making the right calls. Customer facing, the PO is responsible for what the team delivers. Team facing, the PO is responsible for what the customer wants.

What happens when you don't have a Product Owner

Let's just assume we have a textbook Scrum team, but the PO is missing. The first thing that will practically always happen is that stakeholders start bombarding the team with feature requests, everyone considering their own requirements top priority. The team now has the job of juggling all those requests while delivering working software. 

If the team is lacking a person who is capable of calling shots on either-or options, they run a great danger of implementing inferior solutions, dissatisfying the customer. 

On a more positive note, the responsibilities of the PO will typically be picked up somewhere, either through the customer side or the team. Unfortunately, there is no guarantee this will happen before the product failed.

Why having a dedicated Product Owner is bad

Having a dedicated PO communicate stakeholders on the product vision and making tough calls on value choices is good, but it's still a bottleneck. Since being agile is all about never ever maneuvering yourself into a corner, it simply doesn't make sense to enforce a bottleneck.

The need for a dedicated PO actually indicates symptoms for a number of problems:

Different levels of understanding

It's good if someone can explain the product vision to others, it's better if everyone shares it and product vision communication should never be a unidirectional process. 

Single Point of failure 

When someone needs to call shots, it means that this person is can singlehandedly cause an otherwise successful product to go awry. A good PO will never be a dictator, but since the PO will always filter information through their personal viewpoint, unsound decisions may be made. The more decisions PO doesn't need to make because the team has the knowledge and ability to make them, the lower the risk of having a SPOF actually failing.

Also, developers may become paralyzed or make wrong decisions if the PO is unavailable for clarification.

Stakeholders management over consensus

When someone needs to call shots, it means that different stakeholders set different priorities. This may always happen, but is a situation where one person has the final say really better than being able to come to consensus? 

Translate: Business-Developer, Developer-Business

The PO facilitates the dialog between team and customer, especially in situations where business expectations are technically unsound. In theory, this sounds good. In practice, we have an agile value "Customer collaboration over contract negotiation". Nowhere does it say customer collaboration is limited to the PO. If every developer collaborates with customers on a daily basis, the mutual understanding will be there without having a facilitator in the middle.

Assumption of incompetence or apathy

We get taught in Scrum classes that PO's understand the business value and know which increment is best to advance the product's value. Superficially, and in an immature organization, that is true: Oftentimes, developers have no understanding of business value. But that shouldn't be considered a given law of the universe. In Programmer Anarchy, there is a radical shift: Developers not only understand what is the best value for the customer, they are so closely interlinked with customers that they drive: They deliver working software and let the customer decide whether they're getting their money's worth. Sounds odd? Making developers business savvy, instilling them with a keen sense of where the money lies is sure better than simply assuming they're either idiots who know squat or who frankly don't care how their living is earned.

Just consider yourself as a developer: Which would you prefer? Having someone tell you that you have no sense of business - or having someone bring you to the point where you can do everything they can?

It is good if the team has a product navigator - it is better if everyone can read the compass to the pot of gold.

Summary

It is not wrong to have a PO. But don't focus on establishing and strengthening the role of the PO- Raise up the entire team to fulfill the responsibilities of the PO, and the dedicated PO will be superfluous.

The Bottleneck issue

Are you terrified of going on vacation? Can you already guess all the disasters that will happen when you're out of office for more than 2 days?
If yes, you're not alone, but there is something you should do about it.

Oftentimes, new Agile teams have the "Problem" that the intensity of work is so high that people are somehow stuck in their role.

For instance, the Scrum Master may not even get to coach the team because impediments and ceremonies already fill their schedule: The installation of the Continuous Improvment Process may become secondary.
Or, the Product Owner is spending fulltime answering questions of team members to ensure the product is terrific: Good, but the grooming of future backlog items and stakeholder management may suffer.
The worst case is developers taking so many stories that they lose time to hone their agility: The delivered product may be great, but we didn't implement any ways to do the same thing faster and easier.

The Solution

Agile methodologies try to eliminate "Single Points of Failure", i.e. having success or failure hinge on one single person.

• Developers should ideally pair up to make sure that there is no capability required in the project which only one person has. Why? Isn't it more easy to replace you if some else possesses your skills? No! On the contrary: if you can chip in wherever something needs to be done, your value to the company increases!
• The Product Owner, "owns the product" and needs to call shots. However, they should not feel obliged to create a structure where every minute decision entails them.On the contrary, the PO should communicate the vision so clearly that the team can independently decide what is the best way to advance the product. 
• The Scrum master, "owns the process" and is responsible for ceremonies and managing the impediment backlog. A good Scrum Master will not spend their days running after individual impediments and arranging meetings. Ideally, they will coach and empower the team to do this by themselves. 

For both the Scrum Master and the Product Owner, I would refer to an important proverb about aid: "The most important job of a helper is to make themselves superfluous", with the intention "If you enable and empower others to fill your role, you did a good job, otherwise you missed the mark".

Sustainability is one of the Agile Principles, and you will not have sustainable development unless everyone actually strives to enable others to do what they are doing.

The "Project Manager" Game

Project managers are important contributors in Waterfall projects and there is an incredible weight on their shoulders. Good project managers will go a great length to make their projects successful.

Then again, in Agile we don't have Project Managers. And we don't miss them. No offense.

So, how can we be successful in Agile without a Project Manager?

Truth is - everything that is needed still somehow gets done.

I learned the "Project Manager" game from Jeff Sutherland's CSM course.

It's a fun pastime and takes only about 15 minutes. You may even throw this into a retrospective to lighten up the mood and dig for some insights!

Here's the rules:

Round 1: Everyone on the team brainstorms responsibilities of a Project Manager(5 Minutes)

Do not add things which a Project Manager should probably be doing but doesn't do.

This is not a test of whether the team qualifies for PMI certification.

Round 2: Assign to each responsibility at least one of the labels (5 Minutes)

1.  "Team Member" (T)
2. "Product Owner" (P)
3. "Scrum Master" (S)
4. If you think that the activity is not needed in Agile, label it: "Waste" (W) 

There is no "right" or "wrong" in this game. It's about the team's perception!

This is an example of what the result may look like:

Here are some things you should look out for in the results:

•  "Every responsibility goes to the PO / SM": you have a vested Project Manager and are probably missing serious collaboration benefits.
• Process relevant topics solely within the SM domain: your Continous Improvement project may be impedited.
• The team can quote the PMBOK by heart and can't find a single activity that is "Waste": there are probably severe organizational impediments towards agility in the organization
• Planning related topics (scope, budget, objectives, timelines) aren't even on the agenda: Dig deeper to find out how the team conducts planning in the agile implementation!
• There is an excessive focus on non-value adding activity such as listing myriads of different reports, and these are all assigned to the Scrum Master: Maybe the team's level of self-organization should be increased?

Power to the Product Owner

We call the Product Owner "single wringable neck" of any agile project.
It's a good thing to have one person who is responsible for leading the product to success.

But what happens when you don't let the Product Owner lead the product to success?

The situation has been explored by many agilists, such as in this blog or in this presentation.

My team was tasked to deliver B2B Interface platform.
The team did the coding and got the solution tested. Then, we hit a brick wall: IT Operations.
The department was making issues with topics like firewall clearance, hardware, maintenance windows, capacity management and ... don't even ask. It wouldn't even be right to say that they were wrong with their reservations.
Anyways - we had a delivery date, we had potentially shippable software, but no server connected to the other side.

Long story short, when the CTO realized that this was endangering the product launch, he simply declared "Use whatever resources you need, you have complete control over the department's processes and priorities".
It didn't even take 2 days and the server was up and running!

Lesson Learned

It's not enough to have a PO who understands the product and grooms the backlog. The PO needs to have the full power to make the product successful.
If your organization brickwalls the success of the product with politics, structures or anything else, then don't strangle the PO for not delivering. You need to have a PO who can make the calls whenever necessary, whereever necessary.