Sunday, January 29, 2023

Don't be Joe!

Working with Joe is a pain. If it was up to me, I wouldn't hire Joe. And I would advise every employer to also not hire Joe. Not because Joe would be a bad person. But Joe does and says bad stuff. Stuff that's bad for Joe's team. For his company. For the credibility of Scrum, even for "Agile" as a whole. And for Joe. Joe has good intentions - and "the road to hell is paved with good intentions." So - don't be like Joe.
Joe isn't a real person. Joe isn't a single person. Joe is what Joe does.
Joe is a collection of antipatterns that I quite often observe with inexperienced "Agile Coaches" or newly minted "Scrum Masters." We're all learning, and you might even have spotted Joe in what I did. I'm no better - just a little wiser. We need to have empathy with Joe, and Joe needs to reflect on their actions, as well as the consequences of their actions.

Maybe you got pointed to this page with a "don't be Joe" comment? Don't consider it an attack. Consider it a learning opportunity. We're all Joe on occasion. What matters is what we do about it. The less Joe we are, the more successful we will be.

Here comes Joe

I believe that Joe wants to do a good job. Unfortunately, Joe doesn't know what "doing a good job" in coaching means. And that spells trouble. 

Joe is certified

On their very first Sprint Planning session, Joe's team asked why they had to do Planning Poker. Joe answered, "I am a CERTIFIED Scrum Master, and that's the way you have to do it in Scrum." The team couldn't trust their ears: Joe's CSM certificate made him an authority on Scrum? They shook their heads, but obliged. The next morning, when Joe entered the office, he was shocked.

The entire back wall of the office was plastered with certificates. Joe thus learned that two developers held a CSP, two had obtained PSM-II, and everyone had gone through Scrum training years before Joe. Above that list of certificates, the team printed a big banner, "We know what we're doing, and if anyone has doubts - we have the certificates to prove it."

Joe was humiliated, and he could never establish any form of credibility with his team. Within just a few months, Joe left - and the team clearly told management that they'll never accept a Scrum Master who borrows authority from a silly certificate.

What should Joe have done?

Scrum training is really just something that gets us started on our learning journey. Joe should respect that others around him had their own learning journey, and it could be that they are much further than he himself.

Joe should be humble in order to build trust: "I am new here. I don't know who you are, how you work - or why you work this way. I would like to learn. How are you currently planning? How does that work for you?" These are simple, yet extremely effective ways to figure out where real problems are. We don't need to make changes "because Scrum says so." We'd like people to be successful, while reducing unnecessary pain.

If the team doesn't know about Planning Poker, and they have one of the problems it can address, Joe might start the conversation with, "I learned a technique in my training. Would you want to give it a try?"

And most of all - Scrum doesn't even mention Planning Poker. It's an optional, supportive practive. Joe should learn what makes or breaks Scrum before making bold claims.

Joe focuses

During a Retrospective, Joe went into great lengths to explain to the team that developers need to be "T-Shaped," or even better: "M-Shaped:" They should have a broader horizon, not only doing software development, but also learn how their business works, how to test, how to engineer requirements - everyone should be able to do everything.

One developer asked what Joe understands about software development. He answers, "I am a Scrum master. I don't need to understand. My focus is Scrum."

Another one inquired what Joe understands about the product. Again, "My focus is Scrum."

How about the company culture? Yet again, "My focus is Scrum."

Developers shook their head, then proceeded, "Isn't that hypocritical? You expect us to understand things you yourself don't understand, and you allegedly have a reason, but not us? How come?"

Joe reasoned how the Scrum Master's role is ensuring Scrum is done properly, and how challenging that is. The team wanted to have none of it, asking "Do you really believe that your stupid little 17-page guide is more complex than all of Software Development, our product, and the entire company around us?" - Joe countered, "The Scrum Master is a very special role, and if I'd get into those domains, I couldn't meet my own role properly."

What should Joe have done?

The true value of a Scrum Master is their ability to lead meaningful change. The question, "but what is meaningful?" - requires the Scrum Master to know enough about the context to ask the questions that need to be asked. At a minimum, Joe should be curious about what the team is currently doing before proposing any changes.

While Joe doesn't need to be a senior developer, Joe should show some openness and try to learn just enough about development to determine whether any of his suggestions even make sense to someone who does. It's all right if Joe doesn't understand anything about development: sitting down with a developer and having them explain how they work is a fast and easy way to figure out what the team is currently doing. Quite often, when people explain things, they already realize that something "we've always done" just doesn't make sense.

Joe also won't need to understand the details of every single one of the product's features. Without ever having managed a product before, however, Joe's advice to the Product Owner will be of limited value. Joe could start their own pet project - for example, running a Kickstarter campaign. The learnings will be invaluable for Joe.

Joe also should do a reality check: Understanding the organizational context is Joe's job. Indeed, that's the most important thing Joe has to do in order to help the team become effective.

Finally, Joe should invite rather than impose. Instead of telling his team to change their ways of working, Joe could create a link between a pain that people have, and how a specific change could make their life better.

Joe highlights complexity

Joe has learned from coaching that "in complex, adaptive systems, you can't know the outcome until you after tried." Joe uses this line to discourage any form of plan-driven approach, as well as any prediction of outcomes.

When management asked for a delivery forecast, Joe suggested - "we don't know, it's done when it's done." When developers discussed an implementation, Joe suggested - "Why don't you just get started? You'll know later if it worked." Joe's team was unaware of good engineering practice. Joe took it easy - "In the Complex Domain, we don't even know until afterwards whether we needed them."

Eventually, Joe's team got into a real pickle: the low quality product irritated stakeholders. Joe argues, "That's uncertainty. We use Scrum because of uncertainty."

Joe never mentioned that neither complexity nor uncertainty are binary: Things can be more or less complex, and more or less certain. Joe pushed his team into Chaos by removing whatever certainty they had, and making things complex that could have been simple.

What should Joe have done?

Joe's doesn't need to highlight the existence of complexity - success isn't knowing about complexity, it's simplifying until things become manageable.

"Complex" isn't an absolute. Planning, forecasting and good engineering practice could all help to make things simpler. It's just that we shouldn't bet on them.

When Joe's team has to make a forecast, Joe needs to learn what the forecast will be used for, and what the simplest way of providing the necessary information is. Clarifying margins of error and the tradeoff between accuracy and value reduces the complexity of forecasting.

When Joe's team wants to discuss implementation, Joe could probe where the team is uncertain, and what the consequences of a wrong choice are. Planning ahead just enough to avoid poor choices that could be hard to reverse is smart. If Joe was smart, he would even encourage the team to ask, "What will be the long-term consequence of this choice?" - and coming up with possible alternatives before implementing anything. That would reduce the impact of technical debt, which in and of itself causes complexity in other areas.

Equipping people to do the work they need to do can remove a whole layer of complexity in the "How."

Joe shows flexibility

Whenever someone addressed a question to Joe, he displayed his zen-like wisdom by always answering "it depends."

Joe's team eventually got fed up with this answer, because - of course: it depends. They knew that already. But: on what? Joe was missing that part.

During a Sprint Review, a senior developer proudly announced that they had fully automated Joe - the team presented a website with a free form field, and when you hit Enter - a text would appear: "It depends." Joe's manager rolled her eyes - it became Joe's last working day: his default answer wasn't earning him any respect - neither within, nor outside the team.

What should Joe have done?

Yes, it's true that "it depends." The question is: on what does it depend? What are the important factors that we need to focus on? Where are the forks in the road? What makes A preferable to B - and why?

The answer, "it depends" avoids commitment to the inquiry. A conditional answer is only valuable when it reveals viable alternatives or relevant risks.

If Joe doesn't know an answer, the best option might be - "I don't know - let's find out together?"

If Joe knows only one answer, he might state, "The only thing I'm aware of is this. We could research alternatives."

If Joe has limited experience, he might answer something like, "I have experience with this. I know there are alternatives, but I have no experience with them."

Finally, a coach doesn't get paid to be a dictionary. Stating, "I don't know" is not a character flaw. Much rather, it would be a character flaw of Joe to make it look like he has an answer, when really - he doesn't.

Joe keeps the rules

Joe took his responsibility very serious to make sure that his team had a proper Scrum environment where the rules were followed.

Joe's Scrum Team had visitors from other teams during their Daily. As one developer mentioned that there was some issue with a component being worked on by another team, that person couldn't stay silent any more and stepped forward. Immediately, Joe stepped in, "The Daily is only for the team. Nobody except for them speaks." The silenced developer raised his hand and barely could open their mouth before Joe escorted him out of the room: "If you can't follow the rules, you're not welcome."

It later turned out that Joe's team was building incompatible features and their sprint's work could not be integrated without major rework: Joe had successfully stopped the only person who could have helped from speaking up.

What should Joe have done?

Communicating the right things right at the right time is extremely difficult - even if we dedicate our entire life to this topic, we still get it wrong more often than not. The journey starts with a realization that communication tends to be pretty messy almost everywhere.

As a Scrum Master, Joe has to work on helping people communicate more effectively. When they don't know how to do this, Joe has to find out. Blocking necessary communication is never the right solution - someone will always end up with bruises.

Joe's first responsibility isn't simply to make sure that the rules are followed: Where team members lack essential information, or they aren't providing necessary information to others, that's a high-priority impediment that dramatically reduces their effectiveness - and Joe is accountable for the team's effectiveness.

Joe should try to discover where, how and why information flow between the team and outside actors is broken, and work on fixing that. Scrum has very little to say about information flow across team boundaries. When people outside the team are part of the same system as Joe's team, Joe has to find ways to help everyone communicate more effectively, not just the team amongst themselves.

If in the short term, this means breaking the rules of Scrum, Joe should accept this breach, point it out, and ask, "How should we deal with this next time?" Otherwise, Joe risks being called a Scrum Fanatic, who inists on rigorously following the rules, "without reason and against all reason."

Joe protects the team

During a Sprint Review, one of the stakeholders mentions that they're not happy with the outcomes of the Sprint. Immediately, Joe intervenes to point out that the team acted based on available information, and "if you don't give us the correct information - you need to work on that."

On another day, there was a full server outage. It turned out that someone entered data that corrupted the database. Again, Joe was ready: "You have to train users properly. It will take us days to clean this up. You can use that time to train your users properly, so this doesn't repeat."

Yet another day, finance needed some figures to calculate investments. Joe shot down the request, "If we'd help you with that, we're not going to meet the deadline for the trade fair."

Joe was slippery like an eel. Whatever problem stakeholders faced, Joe always found a way to flip it around and make sure that the problem landed somewhere else. This indeed protected his team both from overload and blame. One day, though, a sales executive mentioned to a board member, "They're not helping at all. Each time I meet them, I wish I hadn't wasted my time." - that was also the team's last Sprint.

What should Joe have done?

"Protecting the team" is a responsibility that needs to be considered in context.

Sheltering the team is a short-term mechanism to stabilize the environment. By pushing the problem elsewhere without defusing the conflict, Joe sets the stage for drama that will make things worse for the team in the long term.

Joe needs to show courage by taking ownership of the conflict, and guide parties to resolve it.

Likewise, Joe needs to create an environment where everyone from his team feels confident to courageously say, "Yes, we didn't think of this. Let's work on this and find a solution that works for everyone."


Did you realize how I managed to sneak the five Scrum Values - Courage, Commitment, Focus, Openness and Respect - as well as the foundation of trust - into the article? Joe becomes a beacon of all that Scrum is, not so much by what he knows - but by being. Every day, Joe can take a few minutes off to reflect in silence, "Which of the things I did today reflect the Scrum Values, and which of my actions don't? What could I do tomorrow, so that I am a living example of what the Scrum Values mean?" Joe could also invite his team, his peers and his management to give him feedback on how they see the Scrum Values in what he does.

We make mistakes. We have setbacks. We act based on what we know today, and tomorrow we may cringe at what seemed like a good idea today. We progress not by trying to be perfect, but by dedicating ourselves to learning. If Joe keeps this in mind, then one day - Joe will be a Master of Scrum.

Meditate on Scrum

Thursday, January 26, 2023

Is "Agile" just smoke and mirrors?

 The "Standish Group Chaos Report" is often quoted as the reason why companies should undergo an "Agile Transformation" and adopt Agile Ways of Working. It supposedly proves that "Agile" is essential to survival. But when you look at the data, you may get some doubts ...

Before we dig in, I must add a huge disclaimer to this article:

It's incredibly hard to find accurate information about the Chaos Report on the Internet. For example, infoq quotes 29% success for 2011, whereas Wikipedia quotes 34%, whereas a paper I found directly at Standish Group quotes 39%. A youtube video quotes that period at a success rate of 32%. Another souce writes that "33% of projects are successful, but only 21% deliver a benefit."

Since I didn't want to spend a couple thousand bucks on original reports, I went with "most likely accurate source" in collecting data. If anyone has the reports, I'd be happy to correct my data where it is wrong.

That said, here goes the image based on the data I found:
Is "Agile" really the cause of success?

What does the data really say?

That it's not nearly as clear-cut as we might want it to be. It doesn't send an irrefutable message that "Agile changed the world, software development is now much more likely to succeed.

There's no proof for anything - only an absence thereof. We have levels of variation that indicate we still have too few data points to make any statement with certainty. The only statements we can make with certainty:

  • The data does not prove that "Agile" made the difference.
  • It also does not prove that potential improvements could be attributed to a framework like Scrum or SAFe.
  • It also does not prove that "Agile" benefits are sustainable.

Factors commonly ignored

Looking back into the beginnings of the Standish Group Chaos Report - that was the 90's: Things other than Agile have changed as well. Here are just some of the major changes that happened since then:

Software was still "new."

Many people never operated with computers back then. They didn't know how to use them, much less how to formulate their needs in a way that made sense in the digital age. Nowadays, everyone knows what a computer is.

The Internet.

Not sure about anyone and everyone - but in the 90's, I didn't have Internet. My only reference was written books, usually published years before. There was a massive asynchronity between encountering a problem and finding an information source that could help solve it. Even as late as 2008, I was still developing for clients that restricted/disallowed using the Internet at work.

IT advanced

Back in the 90's, it was just much harder to process large volumes of data reliably. Back then, we struggled with challenges modern developers are hardly aware of. That included stuff for real nightmares, such as a CPU wrongly processing a correctly compiled piece of source code. Many sources of inexplicable failure have since been eliminated.

IT infrastructure advanced

Some of my early projects were extremely challenging, because "production like environments" were so expensive that it was impossible to afford one for each project member. Indeed, there was often only a single test environment for everyone - even that cost millions. Developers often didn't know what their code would be doing until it was live, simply because of environment constraints.

Transaction costs plummeted

Back in the 90's, we were often shipping literal CD's at project end, there was a final "golden build." Especially for consumer software, that "golden build" could make up for over 95% of the project's cost. I'm sure Atari's ET could have led to very different outcomes if they could've just made a few post-release updates at near-zero cost.

IT Project Management advanced

IT Project Managers also learned how to use these advances to become more successful. Project Management also adopted new and better ways of making their projects succeed.

What does all of that mean, then?

Restating the obvious: there were many factors at play, each of them certainly significant to boost success rates from about 15% in 1994 to the 30% we see today. But there's no one single factor that could be isolated to say, "This factor brought us to 30%, and if we just do more of that, it'll bring us to 50% or higher!" If anything, the data shows that no single factor has been identified that has the potential to boost success rates any further than what we already had in the early days of the Agile Manifesto.

"Agile" most certainly hasn't proven to be the Silver Bullet that will singlehandedly fix the industry.

Closing remarks

We don't have undisputable evidence based on publicly available, reliable sources to argue for or against Agile based on the Standish Group's research. In statistical lingo, "we can't reject the null hypothesis". That is: there's not enough evidence to reject any statement for or against.

There's a fact problem that amazed me: I would have expected that accurate data from the Standish Group's research would be more widespread. But it's not. It's a rabbit hole. I need this huge red disclaimer. I don't even know who's telling the truth or who's misunderstanding presented information (that could also include me - mind you!) Who's stating facts, who's simply pulling numbers out of thin air, and who's deliberately lying to drive an agenda?

Maybe if I had all of the data, undisputably, from its source, the picture could change?

But for now: I can't scientifically state that yes, the Standish Group has provided irrefutable evidence that Agile made a difference. 

So - I'd say that we need to drop Standish Group or Chaos Report from the list of "Reasons for Agile."  There may be others, but this one doesn't make the cut.

Saturday, January 21, 2023

The Blurb transformation

Recently, there's been a lot of buzz about Blurb being the future of work. According to Blurb thought leaders, the adoption of Blurb makes companies more successful by operating faster, better and cheaper.

Company X wants to give it a try and starts a Blurb transformation. During initial training, Blurb practitioners explain that all the current problems only exist because of the current management paradigm - and how much better everything would be if everything would be moved to Blurb.

Management takes their hands off, lets Blurb practitioners do, and observes.

Blurb practitioners begin to do exactly what management did, ableit very inefficient, ineffective and infantile. To management, it appears that Blurb practitioners neither understand what a manager does, why they do it, nor how to do it properly. But - benefit of doubt: Maybe this Blurb thing really is the future, and managers just need to wait and see how it turns out?

At some point, management begins to question the advantage of doing Blurb - the actual outcomes could be achieved much easier and faster without Blurb? Blurb practitioners say that's management doesn't understand Blurb, because they're stuck in a non-Blurb mindset: you can't be Blurb without Blurb.

Eventually, management calls and asks what benefits has Blurb actually brought? Blurb practitioners explain that they have made a lot of progress doing Blurb and helping others do it. They emphasize that in order to get the benefits, you must be Blurb, not do Blurb. And that the key benefit of Blurb is that you become Blurb.

Management begins to get dizzy. They decide to cut funding for Blurb.

If you were a manager of Company X - what would you have done?

Friday, January 20, 2023

What's the value proposition of Agilists?

CapitalOne just fired all of their professional Agilists. They state that Product Managers can just take on Agilist responsibilities on top: Why?

The role of Agilists

Many Agilists think that their role is a subset of:

  1. Introducing "Agile" ways of working by training, teaching methods and launching teams.
  2. Supporting execution by organizing schedules, facilitating events and resolving impediments.
  3. Doing managerial tasks such as monitoring and reporting team health, progress and performance.

Even the people doing these three are often different folks:

  • Category 1 folks are a temporary role. It's better to contract them on demand: What do you do with them after everyone has been trained and is working in an agile team?
  • Category 2 folks could give senior management the impression that "a Scrum Master is just a Junior project assistant with stickies and Sharpies." Self-organized teams shouldn't need them. They are clearly overpaid, and probably not doing their job.
  • Category 3 folks are considered redundant by many developers, there are often also complaints that they're stopping developers from doing what really matters - they're contributing to the problem that "Agile" set out to solve.

When an organization sees agilists as defined by the three points above, all I can say: Firing them all is justified. An entire job family is technically designed for "doing efficiently that which shouldn't be done at all" - is redundant.

They don't have a long-term value proposition.

The Value Proposition

There are three pillars to every company: product development, organizational development and technology development. Scrum focuses exclusively on Product development, and SAFe somehow also blends Technology development in. But who develops the organization?

The real role of agilistas 𝘴𝘩𝘰𝘶𝘭𝘥 𝘣𝘦 in organizational development: build organizational capabilities, and improve systemic collaboration and communication.

Resolving delivery impediments is not enough - the organizational system must be ready today for the challenges of tomorrow: New business opportunities arise, existing business models become obsolete, even entire markets collapse. Having the capability to deal with that is critical to company survival. And yet - few agilists are working on this. Their approach is "hope and pray" that no major disruption will occur, and so they walk like lemmings to the cliff.

Learn about the TOP Structure

The failure of "Agile" roles is can be avoided with the TOP Structure: It gives Agilists a clear, indisputable value proposition, and meaning to their work.

And that's the very reason why every Agilist and manager should be familiar with the TOP Structure

Thursday, January 12, 2023

The highest priority?

 "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" - What if it isn't? What if this "highest priority" is myopic?

Ultimately, the goal of every organization is to "survive and thrive."
In product development, we do this exactly by satisfying the customer.
And in software development, we do it in small bites - sooner is better, so that we have data on what's actually valuable.
All that said, the first Agile Principle is merely a means to an end.

I must highlight this because many agile teams - and organizations - aren't built to survive and thrive. They're built to deliver. Deliver earlier, deliver faster, deliver more. Focus on customer value. Ignore everything else.

The result? A dysfunctional organization that subordinates sustainability and growth on a personal and technical level towards the delivery of "business value."

And the result of that? Technical and organizational debt, which at some point incapacitate the delivery of value - people get fed up and leave. The real problems were never addressed, and when this realization hits, it's too late: the team is already broken beyond repair.

"Agile processes promote sustainable development." - they indeed should, but who reads the fine print, when the promise is all about more value faster?

"Doing Scrum" alone is no guarantee that you get sustainable development - not for the product or its technology, but also not for the organization. Organizational development is work exactly like product work. Indeed, the organization *is* also a kind of product. But Scrum Masters and Agile Coaches are often ill-equipped to develop an organization. They lack the competencies, and the mandate, to do so. And managers, whose role is to shape better systems, don't know how to deal with agile teams properly.

Instead of developing better systems, many companies struggle to maintain them while they're degrading and struggle to prevent the eventual collapse.

If that's you - don't despair:

I have summarized 9 principles in the TOP Structure that serve us in ensuring that everything important is considered, helping us avoid treading an unsustainable path:

You can find the official TOP guide here.

They don't replace Scrum or the Agile Manifesto, they focus and highlight the often-forgotten or underappreciated third pillar of "_Product_ _Development_ _Organizations_" - the organization.

Friday, December 16, 2022

Optimize at the Constraint - only!

The Constraint of a system, in a nutshell, is "the most limiting factor." By definition, it determines the capacity of the entire system: if the Constraint is underutilized, the entire system is underutilized. However, if the Constraint is overburdened, no amount of additional input into the system will lead to more output. Many organizations struggle with this - and that has dire consequences!

Let's start by taking a quick glance at the Constraint:

In our example, the third step (C) is the Constraint - because it has the minimum capacity in our system. An important consideration is that we're not talking about investment or staffing here, our concern is the ability to generate throughput.

As an example, if we have a single A costing $100k to generate 50 Throughput, but ten C costing $1m to generate 30 Throughput, then the Constraint is C, not A.

This simple truth has tremendous consequences:

Don't work more than necessary

All of the capacity in our entire system in excess of the Constraint won't help us generate additional throughput. Let's examine what this means in practice:

  • Excess capacity behind the Constraint is "idle." It exists, but can't generate throughput. Adding more capacity at this point has no effect.
  • Excess idle capacity in front of the Constraint doesn't generate throughput.
  • Excess busy capacity in front of the Constraint adds overburden to the Constraint!

The third point is critical - because of the consequences: Let's say our Constraint is a specialist, and work is piling up at their doorstep. Work waiting at the Constraint generates no value for our company. Since someone was asking for that work in wait, these people will start wondering when their request gets served, i.e. they become unhappy. Eventually, the Constraint will be tasked with managing their undone inventory. At a minimum, some capacity gets diverted away from doing actual work - into managing work. At worst, it will reduce their capacity with each piece of work in wait, until they are fully incapacitated and spend their entire time in status meetings, explaining why nothing gets done.

And that brings up an important question:

Assuming you are not the Constraint: should you optimize your own work?

The astonishing answer is: No. And here's why.

Where's your Constraint?

This image visualizes four possible scenarios:
  1. You're stream-aligned. The only people depending on you are the customers. 
  2. You're behind the Constraint. There's someone, or something, that determines how much work arrives at your desk, and you get less work than you could do.
  3. You're before the Constraint. The more you work, the bigger the "waiting for" the Constraint pile grows.
  4. You and others are working in parallel. What you do, they don't. What they do, you don't need to.

The image doesn't display the scenario that you are operating at the Constraint, because that's equivalent to being unconstrained: the more you do, the more throughput you get. So - let's examine the above four scenarios.

In scenario 1, you are operating as if you were the Constraint, until you get into a "Before" or "Behind" scenario by overburdening your customers. Here, improvement works in everyone's favor until customers start to scream.

In scenario 2 - you have excess capacity anyways. Customer throughput is limited by the Constraint, so the only thing you can spend your optimized capacity on would be gold-plating. At best, nobody notices. At worst, you'll get scolded for wasting company assets. In any case, your optimization efforts won't win you a medal.

In scenario 3 - your capacity outmatches the Constraint. If you want to optimize the Whole: do less. You can only make a difference by reducing burden on the Constraint, that is: by taking work away from them. If you optimize in ways that allow you to do more work, you'll either get scolded if that makes you idle, or your extra work won't lead to extra customer value. In the latter case, you'll get scolded for not delivering more (even though you did, but the customer doesn't see that.)

When optimization doesn't work

In scenario 4, you're acting similar to scenario 1 - you're essentially the Constraint yourself and optimize accordingly.

That leaves scenarios 2 and 3. In both scenarios, you lose by winning.

Any optimization you do when you're not the Constraint will evaporate, be invisble, or make things worse for the Constraint, and thus for the system, and thus, in extension: for you.

When teams try their best to optimize their ways of working, and see that it either does nothing, or backfires - eventually, they get change fatigue: "Why should we change anything that doesn't help us?"

And that's a core problem with Scrum: The Scrum Guide suggests that teams should identify improvements in every single Retrospective, without considering whether the team is even the Constraint. If you aren't - you won't see anything coming out of your changes. To make  Retrospectives meaningful, identifying and enacting change is insufficient. You have to make sure that the changes are actually beneficial to the organization as a whole.

What now?

Here are four simple checks you can do:

  1. If you are the Constraint, do whatever it takes. Do less, do more. Simpler. Faster. Better. It will be noticable immediately, and you may even generate massive leverage. If you're five, and you have 100 people in your organization, every minute you save will have a twenty-fold impact. You'll be celebrated like heroes for even minor improvements.
  2. If you're pushing work "downstream" for other teams to pick up, and you see work piling up, do not try to discover ways to do more: Do less. Use the free capacity to pick up work that would otherwise happen downstream.
  3. If you're not receiving enough input from "upstream," don't try to do whatever you do better. Instead, pick up work that would otherwise happen upstream.
  4. If you see that "downstream" is challenged, and you receive flowback, i.e. defects, complaints, questions or anything that makes downstream wait for you, then you have to improve how you work, so that there's less work to do downstream.

Wednesday, December 14, 2022

Look after the BRO's

 One reason why many agile teams are challenged is because their Coach or Scrum Master isn't looking after the BRO's.

Too many coaches and Scrum Masters focus on framework rules, roles, events, facilitation, process, practice, tickets ... But while they're doing that - who's paying attention the BRO's?

A coach's value isn't in being a nanny for grown-ups. It's not in enforcing a framework or process. It's not in telling people what or how to work. All of these are ultimately irrelevant - or worse: impediments.

A coach is there to make a difference. And if the only difference a coach made after a year is that now people are correctly doing X, they made none. A coach needs to work with the BRO's.

Agile Coaches need to know their BRO's, keep them in sight, and work to improve them. A good Coach always pays attention to their BRO's and makes a difference for them.

Ok - so what are BRO's?

Business Relevant Outcomes.

Tuesday, December 13, 2022

What "Fail Fast, Move On" stands for

There's some confusion as to what "Fail Fast" means - it's caused some disturbance in the force. Let me give you my perspective. 

I'm going to use a business example for illustration. The message won't change if you apply the ideas to a product, a way of working - or even just a task.

The Fail Fast Move On Philosophy

Of course, we would like to maximize our probability of success. But - sometimes, we just can't know.

Let us use a restaurant as a showcase: I haven't seen any restaurant owner ever who opened a deli in order to go broke. And yet, almost 90% of restaurants don't survive their first year. Worse yet: the average restaurant owner loses at least $50k on the ordeal. Which, by the way, is the reason why I haven't opened a restaurant. For me, the upfront investment plus bound capacity (it's a pretty taxing job) isn't in sound relationship to possible benefits. But I digress ... but only slightly.

Fail Fast

During the "Fail Fast" stage, we start by figuring out what we're trying to do, what we know and what the unknowns and risks are. We exhibit a healthy skepticism of facts, for example, "Do we really know people in this part of town like Sushi?" and ask critical questions, such as, "What will happen if they don't?" We can then classify how much we're risking in case our assumptions turn sour. That gives us an analyzed, itemized list of risks which could make our endeavour fail.


With our risk list, we propose a counter to our business idea, and we try to prove that the counter is false:

Returning to our sushi example, "We will offer a piece of Sushi to 100 pedestrians and ask them whether they'd visit a Sushi bar offering the same level of quality. [Counter:] Fewer than 10 positive answers mean that there's not enough interest in Sushi here."

Next, we're not even going to try to open a Sushi bar: all we want to do is disprove the pessimistic notion of an empty Sushi, our key risk of failure.  (We could still be wrong - but now we know that there's a possibility of being right.)

We're not trying to succeed, we're trying to rule out predictable failure.
If our counter-experiment succeeds, we just saved all followup effort: Why should we rent a facility, purchase decoration and cutlery, hire a cook and waiters - if we already know that we won't have enough customers? When we learned that we can't deal with known challenges, we need to change our goal and backtrack.

If we succeeded at failing the counter-experiment (yes, that's a double negative!) - we can proceed further.

Move On

In our restaurant example, we know that 90% of restaunts fail, and we'd like to be in the 10% that don't (like everyone opening one of the failing 90% of restaurants.) But: when we can't, we definitely don't want to be lose some $50k+ on the attempt. Hence, we move step by step, keeping the cost of each step low, and accept that everything we invested up to this step is money lost. We're not trying to recoup it - especially not by investing more in order to get some of it back.

"Moving on" means that everything we invested up to this point is "sunk cost" - investments we will never recover. Sunk cost hurts, and it makes us uncomfortable. Yet, there's something worse than sunk cost: "Throwing the good money after the bad."

In order to practice "Move On," we avoid hedging our bets by binding unnecessary assets, so that we have less pain when discarding them.

Moving on

Moving on requires us to let go of what we invested.

The 3 Steps of Fail Fast, Move On

Applying Fail Fast, Move On goes far beyond validating a business idea - it goes for any idea, and thus is all-encompassing for all creative work. Fail Fast, Move On could be considered a 3-step process:

  1. Pull risk forward
  2. Rigorously inspect and adapt
  3. Minimize and write off sunk cost

That, of course, doesn't mean that we either:

  • Generate unnecessary risk by negligence or unprofessionalism.
  • Act without a prediction to validate.
  • Waste our energy on doing things we know we could do smarter. 

To the contrary - "Fail Fast, Move On" is the notion of avoiding these three antipatterns by systematically eliminating failure points.

Proper "Fail Fast, Move On" saves you energy and maximizes your opportunity of success.

You can learn more about succeeding with "Fail Fast, Move On" in my Lean Startup classes.

Feel free to set up an appointment with me using the PAYL coaching mechanism (on the left) to discover more.

Sunday, December 4, 2022

Performance matters!

Performance is one of the most important factors for an agile organization, even though the topic is often viewed with suspicion. Yet, a proper understanding of - and close attention to - performance is critical to success. Here's why:

On Stage

Let's say you go to a concert. You were thrilled with anticipation, you booked the tickets half a year in advance, made an Instagram story about all your preparation, and on the day of the event, a sleepy, un-enthusiastic singer shuffles on stage and sings without any emotion at all. What's your next post going to be? "This was a terrible performance! So disappointed!" Okay, now let's say we sanitize out the word "performance." That leaves your impression at "That was terrible. So disappointed." Well, that feedback won't help the band improve: What was bad? The location, the food, the music? If I was part of the band, I'd just disregard it, because nothing is ever perfect.

In the workplace

Of course, a stage performance isn't the same as workplace performance. Still, we work for people who have expectations on what we do, and to whom it matters whether we achieve something or not. That said, let me briefly define, 

Performance: the ability produce desirable outcomes.

Thus, inattention to performance sends a strong message, "your outcomes don't matter" - in extension, "you don't matter. There is no better way to demotivate people!

We should strive to build high- and hyper-performing teams, and create an environment where each individual is able to perform at their best. We need to constantly ask ourselves, "How can we perform better?" - and relentlessly fix any problem that stops us from performing better.

Aren't "performance measurements" detrimental?

Three remarks - 
  1. Goodhart's Law (A measure that becomes a target ceases to be a good measure
  2. Attribution error (Correlation doesn't equal causation
  3. Weaponization (Everything is harmful when used as a weapon)
That is: what gets you the bad outcomes is a misdirected measurement system, not performance itself. Don't throw out the baby with the bathwater! 

How does performance matter?

The result of keen attention to performance is pride of craftsmanship and sense of accomplishment: going home after a challenging day of work, we are satisfied with our achievements, and we feel that our time was worth it.

Low performance, in contrast, means that we go home and wonder what we just wasted our time with. It leaves us demotivated, disoriented, burnt out.

And regardless of whether we give it a name, or not: the feelings will be there. We would like to have more sense of accomlishment. Hardly anyone looks forward to feelings of uselessness, worthlessness or pointlessness.

"Performance" is merely the label we attach to these feelings.

If you've ever worked on a hyper-performant team, you will remember that experience for the rest of your life. The experience will continue to boost your self-esteem, your desire to grow, and make you both more professional and a better person. Likewise, if you've ever worked on a low-performance team, you will also most likely remember the experience for the rest of your life - but most likely as a chapter you'd prefer to never repeat.

Performance is paramount.

Monday, November 21, 2022

The TOP Structure - how it all started

As you may already be aware, my latest project is the "TOP Structure." Let me give you some insights into how it all started. Back then, it wasn't very refined, just some thoughts in my head.

The world of traditional IT

Traditional IT organizations typically separate themselves into a development and an operational area. To execute, they again separate into line and project - commonly resulting in matrix organizations. Requests for delivery of new stuff are typically thrown over the fence by "business," or - in more advanced companies - negotiated by Business Analysts. In any case, once a project was scoped, we task a Project Manager with ensuring delivery in TQB. That leaves Project Managers with a wide range of work: setting up a capable team, prioritizing and distributing work, coordinating schedules and tracking progress. Unfortunately, as the proverb goes, "if everything is important, nothing is." Many project managers drown in schedules and tracking, leaving them little time for taking care of the people doing the work.

Scrum changed the game

The move to "stable teams" and continuous "product development" led to the need for a different way to structure teams, and Scrum provided it. In a Scrum context, the line no longer "provides resources" to "projects." And there's no more a final delivery thrown over the fence at the deadline - software in an agile setting is never "finished." Features become available in a continuous flow of value.

Still, line managers have a role - and oftentimes, business initiatives are still funded as pre-packaged projects scoped for "Agile Delivery."

Why is all of that relevant? Because of the resulting interactions.

Scrum teams learn to self-organize themselves, and how to manage their interactions with their surrounding organization. The person accountable for this is the Scrum Master. Often being neither technical nor understanding the product in depth, Scrum Masters focus on Organization. Their value proposal isn't in any code they write or anything sold to customers - it's enabling their team, focusing on "Who" and "How." (i.e. people and process)

The second key of a successful Scrum team is the Product Owner, focused on the Product. Both organization and implementation aren't their concern, only ensuring that the "What" and "Why" are clear and prioritized, so that stakeholders are happy and the team does the most valuable thing at the most suitable moment.

And finally, what would be a good Scrum team without competent developers? They take care both of development and outcomes, that is: they do everything technical. Developers own their Technology.

SAFe repeats the same

Let's do a simple relabeling exercise to demonstrate how SAFe copy+pasted Scrum in this regard, at a level of abstraction.

Competency Scrum Role SAFe Role
Scope Scrum Team Agile Release Train
Technology Developer Agile Team
Organization Scrum Master Release Train Engineer
Product Product Owner Product Manager

(Now - we could formidably debate whether SAFe's copy+paste approach at scale is appropriate and smart, but that's not my point.) I'd like to highlight that if we gloss over implementation details, then Scrum succeeds most likely when there's sufficient attention being paid to all of Technology, Organization and Product (TOP) - and SAFe must repeat the same thing at a higher level of abstraction.

From this, the idea was born of the TOP Structure as a universal pattern: To succeed with a sustainable software organization, you must ensure that all three domains receive sufficient attention.
Thus, the idea behind TOP is first and foremost that we have to build a structure that pays appropriate attention to all three domains, staffs them with sufficient competency, and doesn't force us into making either-or choices between them. Which is what often got traditional Projects into trouble - a PM rarely has time to fix organizational issues, as deadlines are constantly pressing.

TOP Dysfunctions

Let's turn this around, and take a quick peek at what happens when we pay too little - or no - attention to one of the core TOP competencies:

Illustration Dysfunction Consequence
Exclusive Tech Focus Technical excellence disconnected from people and their needs - technological wonders that nobody needs.
Exclusive Product Focus Ephemeral, great ideas that eventually get killed by the inability to execute.
Over-focus on Organization Having the right people working effectively means little when it's not the right thing.
Lack of Product Focus An over-focus on methods and implementations could lead to missing the needs of the customer entirely.
Lack of Organizational Focus A "bias for action" mindset that bulldozes over people and their needs in order to "move fast and break things." Gets things done in early phases, leads to unproductive (and potentially extremely costly) chaos in the long term.
Lack of Technical Focus Emphasizing value generation and order, at the expense of technical sustainability. Most such products incur fatal technical debt at some point in the future.
(none) Technology, Organization and Product all get sufficient attention, nothing gets shoved under the rug and energy is distributed wisely in each domain.

The TOP Question

And thus, the idea of the TOP Structure was born as a simple, yet effective mechanism of asking the question: "We have 100% of our energy. We can distribute it in any way that we want. Where should we put how much?" There's no fixed or perfect ratio such as, "60% T, 10% O, 30% P" that would serve as a recipe for success. Instead, the first answer is often, "We currently spend too much energy on (X) and too little energy on (Y).
TOP thus started as a simple tool for teams, teams-of-teams and entire organizations to determine whether sufficient energy was invested into the different areas in the past - and whether we should redistribute that energy in the future. For example: "We'd need a bit more time for process improvement, and a bit more for Refinement. That's only possible if we invest a bit less of our time for development - can we do that? How? Is there something in any of the competencies we're currently doing that we could discontinue?"

How it evolved

As you can already see from the three circles - they overlap. Initially, I put "management" into the center, with the intent of stating that management has the responsibility that all three competencies get adequate staffing, funding and attention. Then I decided that this isn't what we'd like in self-managing teams. So I decided to put "Teams" into the center, indicating that a self-managing teams should do all of that. It didn't feel right, either. And thus, the current version of the TOP Competency Spectrum was born:

The TOP Competencies

The model of the TOP Competencies Spectrum is mostly a reshape of the circles into one segmented circle, giving names to the different intersects of the circle:
As you move further away from pure technology towards organization, you enter the domain of Architecture, concerned with the question of "Do we have the right means of doing what we do, and is how we do it the best way of doing it?" - Architecture, in the TOP Competencies model, isn't a separate thing from either Technology or Organization: it's the discipline that brings both together!
Likewise, Design fuses the question, "Why do people need it?" with "How do people need it?" - crossing the chasm between user perspective and technical implementation. Thus, the TOP competency of Design requires connecting technical and product competency for best outcomes. Which is needed to which extent at which time - may vary, and as the color indicates: it's a blended mix.
The other TOP Competencies are similar: At the outer part of the circle, activities are more "domain specific," and the closer we get to the center of the circle, the TOP Competencies blend and become indistinguishable. 

Quality, at the core of the TOP Competencies, is much more than "product quality" - it's quality of everything: how we communicate, how we work, what we produce, and any other outcomes we get (including, of course, satisfaction with our jobs.) As quality is everything in a TOP Structure, it's also everyone's responsibility, and everyone constantly contributes towards it, be it consciously or unconsciously, positively or negatively. The TOP Structure should remind us of this, and inspire us to replace unconscious poor quality choices with conscious good quality choices.

This extended model of the TOP Structure focuses less on the question of "Where do we assign our energy?" - somehow, the entire circle makes up for 100% of our energy, with fluctuating investments across the week - it focuses more on People and Interactions: In our current organization, how do we interact with ... Architecture? Is it smooth, do we have boundaries? Where is it: is it part of the team, or outside? Does information flow freely from and towards that domain, or is it thrown over the fence? 
Is there a continuous exchange between developers and product people, or is it a stage-gated Waterfall? What does our relationship between design and quality look like: Do we design for quality, or do testers consume the result of a design process for test case creation?

The TOP Structure, in this regard, makes no imposition of what you must do - much rather, it guides us in the questions we can ask to identify where we've got improvement potential and where we're potentially missing something important.

What's next

And that's how I formed the basis for the entire model of the TOP Structure you can now find on my official company page. I invite you to sign up to my newsletter and follow me, because I have big plans for the TOP Structure: I believe it should be a staple tool for any Coach and Consultant supporting organizations on their journey of Continuous Improvement - regardless of which framework, or no framework, or the approach they choose.

My own journey with TOP has just really begun to get exciting - you're still in time to be an early adopter!

Wednesday, November 9, 2022

There's always a bigger context!

Have you wondered why so many people, organizations - and even humanity as a whole, constantly find themselves in a mess that's hard to scramble out of?

The reason is quite simple: because we are quite short-term oriented, and we either don't see - or discount - the bigger context we're acting in!

Virtuous Cycles

When we want something that we don't have (or: not enough from), we change something in a way that we predict that we'll get what we're looking for. We then see if that did work, and we'll continue doing more of that until we have enough. And we do the opposite when we don't want something that we do have. 

Feedback loops help us to pause, stop or course correct while we're at it.

A trivial example of a virtuous cycle might be lunch: When we're hungry, we want food. We get our portion, like it, and eat some more. (If we don't like the food, we might get something else instead.) We continue eating until either our portion is gone, or our stomach signals "Full."

Vicious Cycles

A vicious cycle isn't the direct opposite of a virtuous cycle - it's when we do something, and get something we don't want. For example, if we'd really like that wild honey, and put our hand into the beehive: the longer we leave our hand in there, the more we'll get stung.

Short term and long term

In the short term, we complete one action and observe the immediate results. For example, we grab a candy bar, and it satisfies our craving. We can repeat this cycle again and again, and we get predictable and repeatable results (well, until our stomach tells us we had too much candy.)

In the long term, however, we get other results than in the short term: while one candy satisfies our craving, one hundred days of repeated snacking will lead to some weight gain, and two years' worth of snacking will result in a wobbly tummy.

Thus, the virtuous cylce of "craving satisfied" is embedded in a vicious cycle of "gain weight."

Inseparability of cycles

In our simple example, it's impossible to separate the short-term virtuous cycle from the long-term vicious cycle: as the proverb goes, "you can't have your cake and eat it, too." The action that starts the virtuous cycle will also set the vicious cycle in motion. 

The desirable short-term outcomes of the virtuous cycle are immediately visible, so we're tempted to set it in motion. On the flip side, the long-term outcomes of the vicious cycle are invisible at the moment, so we're tempted to discount them in favor of the proven and tangible short-term benefits.

Shocking consequences

We find ourselves continuously repeating the virtuous cycle, with the firm belief that what we're doing is beneficial, until - one day, in our example, we get a Diabetes diagnosis: It's impossible to attribute the diabetes to any single piece of candy we consumed. Even worse: simply stopping the virtuous cycle of meeting our craving isn't going to change the situation we're in, and the process of reverting the vicious cycle will be difficult to impossible. There's no easy "undo" action related to anything we did in the past.

We were caught by the embedded larger context of our visible virtuous cycle: the invisible vicious cycle.

What does our little example imply for a software organization, then?

What you see isn't what you get!

Take a look at this diagram which illustrates the larger systemic context we may find ourselves in:

We always get positive feedback from our immediate action, so we learn that our action is good.

For example, let's say the developer who's always fastest (by skipping tests) learns that they get praise by customers and management, whereas the developers who are always slowest (by building quality in) learn that they'd get more appreciation by cutting short on quality.

The short-term virtuous cycle is that developers learn how to deliver faster and meet tight deadlines.

Unfortunately, by the time we realize the effects of the vicious cycle, our product is probably almost dead: it might take months, possibly years, to trace out and fix all the bugs in the code, and that's not even calculating the effort (and frustration) of adding tests to an unmaintainable codebase.

And worse than that, we only have developers left who have - over the years - learned that building quality in is bad for their careers.

By the time we've come to realize that the vicious circle has taken over, there's no quick fix any more, and the cost of change, at this point in time, is overwhelming.

Scrambling out of the mess

When we realize that we got something that we don't want, we have a myriad of problems to address:

  1. We must discover a way to re-wire the outer vicious cycle by disrupting it, and replacing it with a vicious cycle.

  2. We must become conscious that the presumed virtuous cycle did spin off a vicious cycle, and must stop triggering more of the vicious cycle.

  3. We must un-learn and stop the old virtuous cycle, despite the visible short-term benefits.
    This step is very hard, because we must actively reject the benefits we attributed to it.

  4. We must actively pursue the new virtuous cycle, despite it being slow, and the benefits being less visible than the benefits of the old virtuous cycle. This requires strong discipline, because it's easy to lapse into old habits, potentially eliminating months of progress with a single act of carelessness.

Unfortuntately, since we saw short-term benefits in the past, we tend to look for a new way that undoes all of the damage caused by the vicious cycle in the blink of an eye: instead of actively doing the hard work of behavioural and belief change, we often hunt for a miracle pill. And thus start another vicious cycle.

Let me put it like it is:

If a physical building has collapsed because it was built using poor materials, you can't just swallow a pill to rebuild the entire thing. The only way forward is to clean up the rubble, get better materials, and construct a more stable building.

And that's how you get sustainable change:

  1. Become clear what got you into the bigger mess.
  2. Stop doing that, even if it gave you results you were looking for.
  3. Clean up the shambles.
  4. Create something new that avoids the vicious cycle.

Wednesday, October 5, 2022

10 Things a Product Owner shouldn't waste time on

There's quite a bit of confusion about the Product Owner role - and a lot of Product Owners spend most of their time on low-value, or even detrimental activity, thus having little or no time to succeed in their role. 

Here are ten timekillers that a Product Owner shouldn't waste time on:

10 - Writing User Stories

Too many Product Owners are caught up in "writing user stories," at worst matching all kinds of templates, such as the Connextra "As a ... I want ... so that ..." and the Gherkin "Given ... When ... Then" templates. Unfortunately, the better the PO gets at doing this, the more understanding they amass in their own head before transferring information to the developers. At best, the developers are degraded to a "feature factory," and at worst, they no longer understand what or why because someone else did the thinking for them. A PO is a single point of failure and bottleneck in Scrum, hence they should try to offload as much of what could go wrong as possible.

9 - Defining Implementations

Especially Product Owners with technical aptitude quickly fall into the trap of spending a lot of time on explicitly defining the "How" of solution implementation. Not only do they thus assume a Scrum Developer role, but also they disempower and disenfranchise their team. In a great Scrum team, the Product Owner should be able to rely on their developers for implementation - the PO can reduce themselves to discovering the relevant problem statements.

8 - Writing Acceptance Criteria

Probably the biggest time sink for Product Owners is detailling out all Acceptance Criteria for all Backlog Items to be "ready" for the Sprint. Where Acceptance Criteria are needed, they should be defined collaboratively, using a Pull mechanism (i.e. developers formulating, and then verifying with the Product Owner). 

7 - Ticket Details

Depending on which ticket system you're using, a lot of details are required to make a ticket "valid." That could include relations to other tickets, due dates, target versions - none of these are required for Product Ownership. They're part of the development process, and belong to the Developers. (Side note: Sometimes, Scrum Masters also do these things - they shouldn't have to do it, either.)

The items 10-7 are all indicators that the Product Owner is misunderstood as an Analyst role - which is a dangerous path to tread. By doing this, the PO risks losing sight of the Big Picture, leading the entire Scrum Team off the wrong tack, potentially to obsolescence.

6 - Obtaining precise Estimates

Estimation in and of itself is a huge topic, and some organizations are so obsessed with their precision of estimates that they completely forgot that there's no such thing as a "precise estimate." As I like to say, "If we knew, they weren't called Estimates, but Knows." - Estimates should take as close to no time at all, and if a Product Owner finds themselves spending significant amounts of time on getting better estimates, something is seriously out of tune. Try probabilistic forecasting.

5 - Planning for the team

Team Planning serves three purposes: Getting a better mutual understanding, increasing clarity, and obtaining commitment on the team's Sprint Goal. Many Product Owners who used to work in project management functions before fall into the trap of building plans for the team to execute. This defeats all purposes of the Sprint Planning Event. The Product Owner's plan is the Backlog, which, combined with whatever sizing information they have, becomes the Product Roadmap. Content-level planning is a Developer responsibility.

4 - Accepting User Stories

A key dysfunction in many teams is that the Product Owner "accepts" User Stories, and is the one person who will mark them as "Done." Worst case scenario, this happens during Sprint Review. Long story short: When the team says, it's "Done," it should be done - otherwise, you have trust issues to discuss. And you might have had the wrong conversation about benefit and content during Planning. Acceptance is something either part of the technical process, i.e. development, or something that relates to the user - that is, developers should negotiate with users. The Product Owner is not a User Proxy.

3 - Tracking Progress

Yet another "Project Manger gone Product Owner" Antipattern is tracking the team's progress. A core premise of Scrum is that developers commit to realistic goals that they want to achieve during a Sprint. The Product Owner should be able to rely that at any time, the most important items are being worked on, and the team is doing their best to deliver value as soon as possible. Anything else would be a trust issue that the Scrum Master should address. At a higher level, we have very detailed progress tracking in Sprint Reviews, where we see goal completion once per Sprint. If teams can reliably do that, this should suffice - otherwise, we have bad goals, and that is the thing the PO should fix.

2 - Generating Reports

Reporting is a traditional management exercise, but most reports are waste. There are three kind of key reports:

  • In-Sprint Progress Reports, as mentioned above, they are pretty worthless in a good team
  • Product Roadmap Reports - which should be a simple arrangement of known and completed mid-term goals, presented in the Sprint Review for discussion and adjustment.
  • Product Value Reports - which can be created by telemetry and should be an (ideally automated) feature of the Product itself.
Question both the utility of reports and time invested into reporting. Reports that provide valuable information with little to no effort are good. Others should be put under scrutiny.

1 - Bridge Communication

The final, biggest and yet most common antipattern, of the Product Owner is what I call "Bridge Communication" - taking information from A and bringing it to B. Product Owners should build decentralized networks, connecting developers and stakeholders, avoiding "Telephone Games" that come with information loss and delay. 

When the Product Owner has their benefit hypothesis straight, developers can take care of the rest. Developers can talk with stakeholders and obtain user information by themselves. A Product Owner shouldn't even be involved into all the details, because if they wanted to, they'll constantly find their calendar crammed, and they become a blocker to the team's flow of value - the opposite of what they should be doing!

The Alternative

(About half of the points in this article describe the SAFe definition of a PO, but that's an entirely different topic in and of itself)

After having clarified what a PO should not do, let's talk really brief about what is a better investment of time:

A Product Owner's key responsibility is to maximize the value of the product at any given point in time. That is, at any time, the Product should have the best Return on Invest - for the amount of work done so far, the Product should be as valuable as possible. That requires the Product Owner to have a keen understanding on what and where the value is. For this, the PO must spend ample time on market research, stakeholder communication and expectation management.

From this, they obtain user stories - which are indeed just stories told by users about problems they'd like to have addressed by the Product. The Product Owner turns stories into benefit hypotheses - that is, the benefit they'd like to obtain, either for the company or the userbase. They then cluster benefit hypotheses into coherent themes: Sprint and Product Goals. These goals then need to be communicated, aligned and verified with stakeholders. By doing this Product Owner successfully, they'll maximize the chances that their Product succeeds - and the impact of their work. 

The Product Owner can free time by minimize the time spent on implementation. Successful Product Owners let their development team take care of all development-related work (including Analysis, Design and Testing) and trust the team's Definition of Done. That is, their only contact with Work in Process needs to be renegotiating priorities when something goes out of whack, a value hypothesis is falsified or new information invalidated the team's plan.