Question Your Assumptions

“Is there any knowledge in the world which is so certain that no reasonable man could doubt it? This question, which at first sight might not seem difficult, is really one of the most difficult that can be asked. When we have realized the obstacles in the way of a straightforward and confident answer, we shall be well launched on the study of philosophy — for philosophy is merely the attempt to answer such ultimate questions, not carelessly and dogmatically, as we do in ordinary life and even in the sciences, but critically after exploring all that makes such questions puzzling, and after realizing all the vagueness and confusion that underlie our ordinary ideas.”

— Bertrand Russell

Rebellion, Bigotry, and Due Process

To build a legacy that will truly last, we need consistency of self-identification in addition to experimentation. This takes balance. An over-reactive system may adapt quickly, but it will fail to scale in complexity.

A complex system too rigorous in its resistance to change, cutting down strange attractors and emergent organic leadership that opposes its orthodoxy, will find itself maladaptive. Such a system, if made of relatively independent actors, will produce schisms, splits, and offshoots due to the excessive fundamentalism of its self-identification process. Instead, we systems builders want the robustness, strength, and adaptiveness that results from the tension between tradition-rooted cultivated practices versus the spontaneous pursuit of fashion and buzz. This tension is healthy so long as it drives the continuous experimentation engine of the organization, allowing signals to emerge and backpropogating message errors. In other words, we should expect “just enough” sibling rivalry at any level of the organization. We should expect triangulation and escalation of signaling.

Experimentation requires tension, but discovery requires due process – the fair treatment of both sides in a conflict resolution.  The essential role of the systems builder is the promotion of self-awareness. A system unable to recognize its own constructs and correct them is unable to change. We see all too often that power need not be taken from someone so long as they believe they are powerless. Similarly, an executive order is rarely an effective mechanism for introducing lasting adaptation, but it can be quite effective as a signal for the system self-organize against.

A cultivator of adaptive systems does not generate unrealistic and unreasonable new rules in an effort to artificially push the system in a new direction; rather, we make the existing rules of interaction and exchange visible and known equally. Where the rules allow differentiation, we make the logic behind such distinctions known, trusting that an adaptive system will correct itself. We do not employ attrition warfare – one ideological information system against another – instead we maneuver against the broken logic of the enemy system. In this way, organic leadership does not pursue the wholesale destruction of an opposing nation, religion, economic institution, or political party. This is folly, as the diminishing returns of attrition warfare depletes energy, resources, and public support. Those are people on the other side of our wars, after all, and our monstrosities in the pursuit of victory easily turn public support against us.

Instead, wherever there is differentiation the systems builder ensures there is equal access to knowledge of the logic behind apparent unfairness. We encourage open rebellion and take even the least realistic signal seriously, as this is preferable to letting the system stagnate while an insurgency is festering behind closed doors.

To maintain our persistence, to balance tradition and stability with experimentation and responsiveness, we must above all ensure due process and the faith of the public that due process provides fair treatment in any conflict at each level of the system. It is decentralization of local process enforcement that allows systems to experiment. Equal access to escalation of justice will resolve critical reinterpretations. We do not need, as a systems-builder within an overarching complex adaptive system, to control the rebellion of progressives and early adopters nor the backward quasi-bigotry of instinctually late adopters. We must only ensure the system is healthy enough to re-inform itself based on the outliers, trends, and signals.

The “Priority” field in JIRA

The Legacy We Build Upon

The topic of lean metrics requires an understanding of the influence of Kanban and the Toyota Production System. Scrum, as an agile process framework, was built as a lightweight version of the TPS Kanban practices that anyone could use, while Atlassian developed JIRA to enable visualization of any process, regardless of its complexity.

The “priority” field originated as part of Jira’s oldest legacy as an issue-tracking system. Greenhopper was a plug-in that enabled the issue-tracking database and web services to be used for Lean-Agile teams. Greenhopper created a new front end for the data in JIRA – namely, the work-in-progress board and the product backlog – so that a Scrum team or Kanban team could use JIRA for agile.  Ultimately, this became synonymous with JIRA and the today it ships with the agile front end OOTB.

In Scrum, the Product Backlog is used for prioritization, so the “priority” field has little meaning. In Kanban, the priority field is used to create swim-lanes based on Classes of Service.

Expedite Anything That Blocks Value Creation or Capture

“Blocker” would indicate that WIP limits can be violated and workers should interrupt their current work in favor of Expediting the blocker through the system so it doesn’t not cause long-running damage to continuous flow. The equivalent in Scrum is building out a process for stories, tasks, or bugs that are allowed to violate the Sprint commitment. In either case, the goal is to recognize that this is costly and unhealthy, an exception to normal rules. Unless it is a production defect, some element of the expedite cost should levied against the person demanding special treatment.

Flush the System of Any Critical Items that Disturb Continuous Flow

“Critical” would indicate that a card should “jump over” all other items at each step in the process, but it should not interrupt work or violate WIP limits. These items get to cut to the front of the line, but are not allowed to interrupt completion of existing efforts. The equivalent in Scrum is building out a process for what items, if any, are immediately prioritized to the top of the Product Backlog. It is typical for this to be a “Fixed Date” class of service – because fixed dates are the most consistent destroyer of sustainable flow, we want to get those things out of the way quickly so that the system can return to normal.

Everything Else Follows the “Normal” Process

“Major” and “Minor” and “Trivial” are typically part of the same Standard (aka normal) Class of Service. If used in Scrum, it is primarily for the benefit of the Product Owner to visualize previous conclusions about prioritization. In Kanban, these are meant to respect all WIP limits and follow a First-In-First-Out (FIFO) method at each step in the process.

Scaling Like Organic Systems

A System

A system – as we will define it – consumes resources and energy to produce something that is more than the sum of its parts. Not only does is produce value it does so in a way that sustains its own existence. If we consider Henry Ford’s early Model-T production system that assembled automobiles, the raw materials – rubber, coal, plastic, steel – were meaningless as an unformed heap. Along the way, the “intrinsic” economic value of the raw materials were destroyed and could no longer be sold for their original price as raw materials. At the time, there would have been no resale value for many of the assembly pieces, because Ford created an entirely new value network and disruptive business model to create a market that could properly assess the value of the non-luxury automobile. Yet, once assembled, the assembly line put these pieces together to create value greater than the sum of its parts.

An example of a relatively simple organic system is a single-celled organism like some species of Plankton our oceans. A plankton lacks sophisticated embryogenesis, there is no differentiation of multiple tissue types, no embedded systems, and no coordination mechanism across cells. Nevertheless, the simple biochemical processes and the internal workings that complete these processes have continued for billions of years by not only producing its own self-maintenance, but also by managing to reproduce. There is a surprising large amount of DNA for such a simple, small, organism – but why did this legacy of code begin amassing in the first place? Whether we venture to call it “divine” or not, there was certainly a spark of some kind that began an explosion that has yet to collapse back into chaos and the dark.

Even with these simple systems, where we can trace each exchange in the value-transformation process, including materials, structures, energy, and ecological context, the sum total of the Model T and the factory that produced it is more than its parts heaped separately in a pile. Our difficulty in understanding such systems is a problem of multi-fractal scaling. For now, let it suffice to say that making a variable in a system better may not result in a linear change in outcome.

 

A Complex System

We have major issues understanding how (or worse yet, why) a system consumes resources and energy to produce value in excess to the sum total of the elements and energy amassed in the absence of the system that produced it. This problem is only compounded when we begin embedding specialized sub-systems within an organism. In the example of an automobile factory, we could say that every cell of every person is a system, that each person is a system, and that each distinct functional area, separated by distance, is a system. The accounting and finance “system” and the inventory and assembly “system” must interplay as part of Ford Motors, a system in its own right.

So we can define a complex system as having embedded sub-systems, causing the observer to not only see that the whole is greater than the sum of its parts, but the observer may also slip into a “confusion of levels” if they attempt to manipulate a part of a system to shift the outcome of the whole. Worse yet, confusion of levels can have disastrous, non-linear results that are the opposite of the intended change due to confusion of cause and effect. When sub-systems are embedded within each other, their interrelationships may act on differing scales, either in time or place. So we must careful when attempting to improve a complex system. We must use empirical process control to chart the change in systems outcomes rather than simply optimizing subsystems in isolation.

 

Multi-Fractal Scaling

A fractal is a pattern that repeats self-similarly as it scales. One of the most common fractal scaling patterns in nature is branching. From the trunk of a tree, to major its major limbs, to twigs, and finally leaf structures, this fractal scaling pattern enables a lifetime of growth cycles. Leaves can bud purely based on opportunism, in a relatively disposable manner. This is because the tree, as a seed, has all the legacy of generations of trees locked inside it. The tree does not aspire to be “the perfect tree” or assume that it will grow in perfect sunlight, humidity, soil pH, and water availability. The tree does not get angry when a major branch is broken off in a storm or struck by lightning. Instead, its fractal scaling pattern is prepared for intense competition for sunlight in the sky and resources from the ground. The tree’s scaling pattern has risk mitigation “built in” because it grows the same in the middle of a field with frequent rain as it does in a dense forest.

We see this branching strategy throughout nature, from ferns to human blood vessels. However, an even more effective approach to self-similarity comes from multi-fractal scaling. The ability to adaptively select between more than one repeating pattern or differentiated patterns based on scale requires a different kind of fractal: time-cycle. It is not just the branches of a tree that result in an environment-agnostic strategy for growth, it is the adaptation to cyclical daily growth, scaled to cyclical annual growth, than scaled to multiple generations of trees that grow. This final step is an important one. Multi-fractal scaling is not only the source of novelty and adaptiveness “built in” for a single tree, it repeats at an even larger scale as a species competes for dominance of a forest. Multi-fractal scaling encourages “just enough” opportunism to enable small-scale experiments that can be forgotten without loss at a greater scale, or thrive when conditions change.

 

Adaptive Multi-Fractal Scaling

The strength of multi-fractal scaling, from branch to tree to forest, is its total reliance on empirical process control.  The legacy code is a confusing jumble of competing messages that a human mind, attempt to “engineer a perfect tree” would attempt to simplify and beautify. That legacy code, however, wasn’t written with any intention of crafting a perfect tree. That code was written to create a minimally viable reproductive system. It is built for one thing: continuous experimentation.

Continuous experimentation happens at each level of multi-fractal scaling, risking economics appropriate to its scale to find asymmetric payoffs. An Oak tree risks very little per leaf that grows over the entire course of its life. In a dense forest, however, that continuous experimentation of growing leaves higher and more broadly opportunistically based on local returns on investment can suddenly break through the forest canopy or unexpected fill the hole left by another tree’s broken limb. An Oak tree does not require centralized control of where leaves will grow or which limbs to invest in. Instead, the legacy of continuous experimentation enables multi-fractal scaling that competes locally and opportunistically.

Again, we do not need to understand what spark set this fire ablaze, we only need to see that it is still spreading and we are a part of it. Over-simplification of superficial outcomes will lead to poor decisions about inputs. Organic leadership relies on context, structure, and enablement of continuous experimentation. Organic leadership is a “pull” system that relies on scaling patterns for decentralized empirical process control. Artificial “push” systems force requirements and attempt to bandage the inevitable inefficiencies of a non-adaptive system.

 

A Complex Adaptive System

A complex adaptive system does not merely take in resources and energy to produce itself and reproduce itself as a unified “whole” that is greater than the sum of its parts. It does not merely embed subsystems with multi-fractal scaling and decentralized control. A complex adaptive system also operates with a continuous experimentation system built in to its normal framework of activities. When we make the leap from an Oak tree to the human body (or any other mammal on Earth), we can truly appreciate just how complicated it is to improve the health of an individual, or an entire population, when we observe the interrelationships of various physiological and socioeconomic systems and sub-systems. Creating lasting change is not only complicated in terms of finding the correct level and understanding the full ramifications across the entire system, each complex adaptive system is also continuously experimenting and will adjust against such changes based on short-run, local, decentralized opportunism.

To care for a complex adaptive system requires not only an understanding of inputs, processes, and outputs, but also the multi-fractal scaling of continuous experimentation that maintains long-run viability. When short-run economics are working against long-run viability, it is not sufficient to reward “correct” behavior to counteract short-run opportunism.  Instead, we must shift the context of local decisions so that short-run opportunism serves long-run viability.

Accidents Will Happen

Accidents may seem to the observer to be unintentional, but continuous experimentation is built to test the boundaries of success, to ensure that precise empirical process data is also accurate for the needs of viability. In other words, if you’ve ever accidentally tripped and fallen, or accidentally loosened your grip on an egg and dropped it on the kitchen floor, this was a natural element of complex adaptive systems quietly running experiments.

Embedded in our own human code, our sub-systems are all built for continuous experimentation as a method of calibrating precision to accuracy, using multi-fractal scaling on short, long-short, long, and distributed cycles. A short cycle is an immediate reference point for an event, using data held in working memory, and is reactive to immediate changes. A long-short cycle compares current data to immediately recognizable patterns of events, more embedded memory or conditioned responses that have proven useful over time even if we assume the event is an occasional outlier. More significant, painful events can skew our “normal” for decades and even become passed to the next generation as part of our genetic code. A long cycle has been stored to our genetic hard drive for future generations. A distributed cycle is a socioeconomic artifact that requires a medium of exchange and may last for centuries.

As humans, our multi-fractal scaling of continuous experimentation results in the creation of complex adaptive socioeconomic systems. Our legacy code drives us toward exchange, tooling, building, and reproduction because the experiments that are in motion are far from complete.

Like our occasional fumbles and falls, our social systems produce results that appear to be accidents with no guilty party, pure coincidences of circumstance, which occur due to failed experiments. Organic leadership harnesses this natural propensity for decentralized opportunistic experimentation by encouraging it but setting boundaries for it, feeding it but ensuring checks-and-balances from opposing interpretations, and guiding it by changing context and opportunity rather than directly managing outcomes.

Orienting is Essential to Agility

Responsiveness and disruptive influence are the cornerstone of agility, because change through continuous experimentation is fundamental to life. Healthy and viable systems maintain their complexity far from equilibrium, relentlessly fighting collapse and death. After all, “poised” on the brink of chaos, there is an obvious business definition for agility:

Responsiveness to signals in a market with imperfect information and imperfect competition.

This context necessitates process control that keeps identity and novelty in constant tension – even against our most brilliant ideas. Thus, our tactical principles for general preparedness, quick orientation, and powerful responsiveness will be rooted in the need to orient faster than the enemy system, our ideological competition. Only the working product of our efforts can provide a pragmatic judgment of the value we have created, so the ultimate measure of our success as a Disruptive Influence is the actual change in behavior we have caused.

Because individuals and interactions are inherently complex, adaptive, and difficult to predict in the reality of socioeconomic competition, we value knowing them directly, studying them and interpreting their position ourselves. We value this over relying on their predictability, likelihood of adherence to an agreed-upon process, or correct use of the best possible tool for any given job. Although we assume processes and tools taken at face value will deceive us into a false sense of stability, we also recognize that individuals and interactions cannot always be taken at face value either.

Because responsiveness, both in decisiveness of action in an unexpected situation and as adaptation over a long-term investment horizon, will consistently be awarded with asymmetric payoffs, we can only trust a plan to the extent it includes contingencies, delays commitment, and distributes control to the individual with the best understanding of the situation at the time a decision must be made.

Because compromise is the inevitable and unsavory outcome of “contract” negotiation, while creative endeavors in contradistinction rely on the energy of tension, cognitive dissonance, intra-organizational paradoxes, and conflicting interpretations, we invest our time and effort in social exchanges while delaying formalization. A contract relies on an external locus of control for its power and validity, whereas we must prioritize a social and socioeconomic view of the complex system we hope to lead into adaptation.

Because a socioeconomic “factor of production” is defined by its output, evaluated on how much more value “the whole” can add in excess of its “parts”, and because digital products are continuously created and maintained but never mass-produced, we take the tangible product of our endeavors as the only valid measure of its worth.  However good the product design looks on paper, however well-defined the future state is documented, only exchange in the marketplace can determine the economic value of the product we have actually created

7 Simple Steps to Agile Transformation

I am never sure how to answer someone who says “What is agile?” After all, my mind is racing so fast that my ultimate, simple explanation – “A way to innovate and deliver products more effectively” leaves me wishing I could kidnap people for a 3-day course on lean-agile and continuous delivery.

What I can simplify (for someone who has a basic understanding of agile) are the steps in a true transformation, so that they can let me know where they are in the process.  Note that I have ordered these quite logically, while the real world is full of resistance, grey area, and co-evolution.

  1. Establish a cadence of synchronization (typically, this is scrum). Hypothesize the results of every change ahead of making it, test it, and validate or invalidate the hypothesis.  Inspect and adapt.
  2. Change from a human resource allocation mindset to a well-formed team mindset.
  3. Change from a finite project mindset to a living product mindset.
  4. Sell who you are, not what you plan to have on a shelf in X months.
  5. Change from a P&L and ROI mindset to an Economic Value Flow across the organization mindset (including upgrades in equipment, training for knowledge workers, benefits that raise barriers to exit).
  6. Change from centralized (top-down) market research, innovation planning, and risk assessment to distributed control over prudent risks.  This requires a framework for self-validation of discoveries, exploitation of opportunities, and communication of results.
  7. Change from performance tracking and formal leadership to systems optimization and organic leadership.

Hit Contact if you’d like to discuss your scenario or any of these points – I’m always available.

DevOps Athleticism

Let’s face it – being small makes it look easy to be nimble.  Look at your average kindergartener: they may not always be graceful, but their capacity for unexpected action or a rapid spontaneous change in direction at full speed is frequently mind-blowing (for each of mine, it was usually a sudden jump into the risk of oncoming traffic).

So it’s understandable for the established enterprise to look at the youth (and occasional hyperactivity) of startups – and small companies who never grew up – and feel a little fat, a little old, a little bit brittle.

That metaphor doesn’t need to end there, though, because there are also large companies maintaining a portfolio that balances finding new opportunities on the one hand and exploiting new opportunities on the other.  These are two very different operations, though, and companies find balance difficult.  Just like hyperactivity is internalized in the executive function of adults who had physically hyperactive childhoods, that rebellious startup creativity can survive unscathed within the mature organization. By doing so, you can simultaneously continue category-killing through innovation despite staying the course and reaping decades of fruits on already-mature markets and products.

Likewise, to extend the agility metaphor, life is full of athletes in the top quartile of height and body mass index. They top the BMI charts compared to average scrawny-but-chubby adults despite doing it with rather lean body composition.  They are practically outliers, and definitely don’t fit the “standards” set by statistical BMI.  More importantly these individuals put “nimbleness” to shame; and just look at those kindergarteners revere them. Look at the heroes of the NFL: agility doesn’t begin to describe their mastery of movement.  Look at star hockey players in the NHL: they move with the power of an elephant, the stamina of a gazelle, and the grace of a ballerina.  The stereotypical Hollywood karate master black belt may have a very thick, potbelly body-type, but the master needs very little movement, in just the right places at just the right time, to send an opponent flying.

So it’s simplistic at best to “think like the startups” or “be more agile”.  You cannot transplant a culture.  Size alone is not their advantage, strength alone is not their advantage, tenacity alone – as much we love a good underdog story – is not their advantage.  To emulate any ONE  attribute of the lean-agile startup on the rise is foolish.

Stop talking about enterprise at-scale agility like you’re trying to be that kindergartener veering into the street unexpectedly. 

It’s more than being lean, or gaining experience or agility. At scale you need to build repertoire of enterprise-grade DevOps Athleticism!  It’s one thing to have an impressive vertical jump but quite another to jump over a fence, hurdle over a tackling safety, or parkour up a building,

Training for Obstacles

For the support engineer team, kanban looks a lot like an Olympic marathon team.  You constrain WIP (focus/movement pattern), create a sustainable pace, and fuel as you go – you train for the long haul by (basically always) running for distance.  It may be fragile spaghetti code built over the decades, but you your crack team knows it inside out.  But that’s not the majority of your at-scale enterprise.  As you get further from a continuous flow of relatively similar requests and move toward innovation and greenfield disruption efforts, kanban and even scrum are going to fail unless you include the assumption of uncertainty and churn in your overarching process.

This is like the difference between a New York marathon versus Tough Mudder or another obstacle-rich competition.  If you don’t build your capacity for speed-strength and coordination against unexpected obstacles, you’re likely fall short. The long and short of it is, if you can count on a marathon, kanban your way to glory.  If unpredictable obstacles and risk-taking for glory are fundamental, stop whining and start training. Look for extra opportunities to beat down tough challenges instead insisting on a slow and steady pace.  Speed and sustainability need to be loosely coupled in a strong DevOps process.

Jumping the Fence

I can tell you from experience that maximizing raw strength in the barbell squat does not correlate to jumping higher.  If you need to jump higher to make a layup, you do things like box jumps.  If your really daring, leverage your box jump into jumping over a 3-4′ fence (or hurdle) from a standing position.  Raw strength on the one hand and sprint speed on the other don’t give you the actual agility, coordination, and explosive power you’d need.

Similarly, coordination of multiple teams is more complex than strengthening, quickening, or improving communication with each team individually.  Establishing a cadence of synchronization and opportunities for cross-pollination of ideas – even as you increase the independence of each team  

This extended metaphor has a great caveat – go find a 3’ tall picket fence, stand in front of it, and try to jump over.  Assuming you haven’t been practicing, I bet your body stops you.  The same is true of a healthy DevOps system – when you try to launch into a painful bout of stupidity, the developers stop you.  If you’re smart, you don’t force yourself into a giant failure.  Instead, you practice a bit and ramp up your agility to get your entire body confident you won’t end up in the hospital.

Throwing a Punch

You don’t throw a punch with your arm.  You throw it from the ground up, leveraging the perfect twisting launch of one square inch of fist powered by your entire body.  If you’re the square inch that gets to land the winning knock-out blow, don’t get cocky.  You’d be nothing without the support and power of the entire body.

Breakthrough Agility

The Olympic sprinter is the perfect metaphor for the lean-agile enterprise.  Being small is not sufficient for winning in a sprint.  Being strong is not sufficient for winning in a sprint.  Speed and agility are the outcome of a pursuit of mastery around which everything else is valued (including size, speed, and composition).  The agility of the sprinter is the rate at which an incorrect or suboptimal step or technique is noticed and corrected while remaining in motion.  It requires that the billions of near-instantaneous corrections in balance, force, positioning, and movement have been so intensely practiced that it can occur with very little thought.  The athlete achieves flow.

Perhaps that’s where the metaphor scares some people.  It suggests that when a Superorganism achieves mastery and fulfills its purpose, when a company is winning, in a state of “flow”, the brains of the company, the leader, in that moment becomes a passive observer of self-fulfillment.

If you want to win in the software industry, that exactly how you must lead.  Discipline, practice, continuous improvement, repetition, until you reach a state of economic flow.  Your eye on the finish line is all that is necessary and the body – through proper resources, experience, and focus – does the rest.

The Virtue of Collaborativeness

This is part of a series on the key virtues of excellent Product Ownership.
The Virtue: Collaborativeness

Collaboration is, by definition, the ability to work with someone to produce or create something. This excellence, as I like to describe it to people, is the ability to “delight and inspire” a mix of engineers and artists to empathize with the end user and work together to address their pain. This also requires trusting others to do their job well to the extent of their expertise.  

If you slip into a mode where you have too little active participation in building a common understanding with your team, the outcome of their work and the pace at which it is produced will suffer. At the other end of the spectrum, micro-managing and looking over shoulders sends a clear signal of distrust. You might be able to have a nice relationship-building moment sitting with a developer and showing you care what the code does that she is staring at – just don’t overstay your welcome. You have a backlog to manage.  

Without getting overly disruptive of other people’s work, be sure to get feedback. Don’t get in people’s faces, but when you are getting coffee and one of your developers comes into the kitchen, it doesn’t hurt to genuinely care about things like: “Do you think I should be sizing any of the stories differently?” Or “Is there anything I can do to make your life easier today?” Somewhere between ignoring people or annoying them lies caring about what you produce together.

What this really requires of you is genuinely caring about the customer, the end user, and the people building the product for you. Don’t care about your product. Genuinely care about whether your developer knows who’s pain is being alleviated and why. If you don’t care, it shows. Why would anyone follow you or stay engaged in their work if you don’t believe in it? Sort that out, then find a balance that builds a great dynamic with the team.

Scrum Backlog Zombies!

Product Owners – Do you really want an algorithm to take all the thought out of backlog prioritization? You do?


You’re fired.

Pack up your things and request an immediate transfer to a different department. It’s over. You’re a zombie worker. Purposeful prioritization is your one wildly important purpose in the role!

You MUST prioritize the inter-party flow of information between stakeholders, customers, the development team, and your ever-storied users.

You MUST prioritize the flow of disciplined experimentation as the only scientist who can connect “innovative solution” supply with “ever-evolving pain-driven-need” demand.

You MUST prioritize the flow of economic value-add with enough vision and discipline and multi-partisan politics that the agile train doesn’t come off the rails.

Oh by the way, you’re definitely not fired.

What I meant to say before was, you’ll need to light a fire under your ass because you’re insanely important. Product Ownership may not matter to SOME people, but it’s VERY important to the REST of US.

You know, if you are a Product Owner in a large company, I get it if you didn’t ask for all this power that no one fully explained to you. In fact, I’m sorry. It is serious malarky that you’ve been empowered SO MUCH but nobody will tell you until after you fail. That’s because you’re the single point of failure in a system they didn’t want, and they definitely don’t understand what to do with. They don’t know your great power or your great responsibility, how can they possibly help you?

Your boss probably hates agile.

Maybe you hate agile.

But hey, here you are, a bridge between two broken systems, prepared to be blamed as the “single neck to choke” because a ScrumMaster said so.

I’m here for you, and I’m not giving up on you. Whatever tips, tricks, or advice you may need, just reach out.

(Image credit Walking Dead)