Your ROI is Total BS

ROI is meaningless.  GP% is meaningless.  Signups.  Clicks.  Views.  None of these tell you anything meaningful or actionable.  None of this ensures survival.  In fact, it is through sheer mass that some enterprises survive.  It is the churn of hype cycles and perceived value that keep new customers fooled.  But it is definitely not sustainable.  Big investments end with big blunders that result in mass layoffs and enormous bankruptcies.  The name is the only thing that survives. Is that the company you set out to build?  No.

Let’s assume you are a software company selling enterprise SAAS.  Your entire company is the value stream.  The ongoing operating costs are less than ongoing revenue.  Investing in the sustainability of your model of economic value creation and capture is every dollar you spend.  Those dollars, little by little, react with the market either creating or negating value creation.

The problem is that most enterprises work from the assumption that large investments equate with economies of scale.  While this may be true of investment in automated manufacturing there are no economies of scale in software development.  It is the individual knowledge workers that create innovative software.  The velocity with which you can adapt as a system combined with superior understanding of problem-solution fit in the market is the key to competitive advantage.

The question of how to invest should be quite simple when you are a large company that has revenue growing at the same rate as costs – small investments per opportunity with maximum ability to correct an incorrect investment.

That is enterprise agility.

Enterprise Agility is the speed at which an incorrect decision is recognized corrected.  The smaller the investment decision, the faster the return is known. Lean trims the excess weight, off-balance feedback, and poor technique that undermine agility.  The effective flow of information across the creative process of knowledge workers is essential.

This is where you must realize that unless you layoff staff, you’re investing the same amount continuously.  The ROI of a project is as meaningless as the ROI of a developer day.  The input of resources is relatively static, maximizing the value stream as a system is essential.

This is why the a right-place/right-time, brilliant, socially-savvy entrepreneur-engineer is the most agile and lean possibility: perfect and instantaneous knowledge-sharing internally (in the brain), distinct competitive advantage through the extremely unique skill set (s)he has grown to master.  That is the sprinter that you want your Superorganism to become.  In the right place, at the right time, with the correct knowledge and materials, with instantaneous information flow across the value stream.

So if ROI is meaningless to decisions (because we are paying for individual pursuit of knowledge-worker-creativity regardless of rate of return), how do we possibly make rational financial decisions about innovation, discovery and exploitation of economics rents?  In fact, lean manufacturing has studied this for decades.  When the rate of investment (the cost of production) is held constant, prioritization of economic value added rather than expected rate of return should be our focus.  In a zero-sum competitive game with uncertain returns and asymmetrical information, the time between investment and value capture is the only meaningful variable we can impact.  While cost of delay versus product lifetime return on investment may be more difficult to understand when looking at Toyota and the Prius, this is easy to see with Software as a Service, because the continuous addition of value in exchange for subscription-based fees creates two roughly stable lines. The only meaningful way to improve investment is to exploit information asymmetry more effectively than your competition.  Since you are investing the same amount continuously, you must minimize the cost of delay of value capture.

To put it another way: In a system with continuous investment, only the opportunity cost incurred due to delaying an investment matters. This is not first-mover advantage at the new product-market level, this most-effective exploiter of innovation as an a competitive advantage.  This requires a shift to systems thinking and investment in strength of culture. Money is not your scarcest resource. Brilliance-time (that you’re paying rent for daily) is your scarcest resource.  To maximize value capture, you must maximize the time spent in a state of market information asymmetry.  At the current pace of innovation and obsolescence, the only way to maximize value capture is to minimize cost of delay due to incorrect prioritization.

This implies three goals:

1 – Minimize the impact of an incorrect investment of system-brilliance-time by reducing size of each commitment

2 – Increase the adaptiveness of the system to maximize throughout and future adaptiveness

3 – Minimize the time it takes to receive feedback (primarily through analytics) from the market

4 – Make appropriate risk-taking and experimentation a normal part of every creative process

Enterprise Toxic Waste

In a complex adaptive system of knowledge workers, the ability of a group to creatively adapt to an external stimulus becomes impossible once all of the organization’s energy is expended on maintenance of internal homeostasis. To the extent that leadership is an emergent property of the system – in which an individual organically focuses collective energy into new adaptation in response to an external stimulus – it can distribute the pressure to innovate across the entire organization.  When all potential energy is focused on individual self-protection, emergent leadership is stifled. The superorganism “behaves” exactly as any evolving species “behaves” – when conditions are favorable, individuals focus resources into reproduction, increasing the likelihood of variation and aggregate potential for adaptation as a species.  When conditions are unfavorable, resources are dedicated to individual self-preservation, reproduction is reduced, and the species is “culled” leaving only the adaptations that best fit the pressures of the current unfavorable context.  This ebb and flow of creativity and narrowing is seen within the organism as well: in favorable conditions, the cells work toward reproduction, maintaining the health of the system (the body) while in unfavorable conditions the individual cell maximizes its own self-preservation to the detriment of the body (cancer).

“Tech” – currently represented by software, apps, and the web, thrive on innovation and disruption.  The industry as well as organizations attempting to compete through innovation is driven by the desire to maintain a continuous state of innovation at the superorganism  level; instead, most superorganisms (companies, the enterprise) even in the software industry remain cancerous, slowed to a near-death state, presenting painful symptoms far removed from the root cause of dysfunction.

This wasted potential for innovation, sustainable competitive advantage, minimum viability, and adaptive survival is not the fault of any individual and is not strictly caused by the official mission or formal structure of the organization.  This is a cultural issue, not a policy issue.

The formal leaders of a complex system, the managers and executives who are synthetically, socio-contractually positioned to act as the official drivers of innovation (or “vision” or “strategy”) for the organization cannot bureaucratically force creativity and adaptation, as these must emerge organically from favorable conditions across the whole.  Often the formal leaders are charged with being the exclusive source of adaptive creativity despite the fact they are typically in the worst position possible far removed from the external stimulus – to be relied upon for the emergent leadership that drives innovative adaptation.  The inherent waste then is two-fold: the official manager is unlikely to consistently display emergent leadership while the presence of a formalized leader prevents others from organically emerging.  Whether the creative adaptation desired by a manager is valuable and likely to succeed or not, the manager must  force action against the system, as a toxin, a betrayal of the natural state of the system.  In response, the complex adaptive system protects itself against the likelihood of a failed adaptation through cancerous self-preservation of maladaptive patterns.

Unfortunately, if this continues in the context of increasing demand, the growth to supply it exacerbates the likelihood of failed formal leadership and the need for individual or self-preservation.  The waste only grows.  To counter the failure of fewer, more detached formal leaders, the existing formal leaders of many organizations continue to add formal layers in hopes that elevating “high-performers” to official power can mitigate the systemic failure to adapt properly.  This is problematic because the optimization of formal management further decreases the likelihood that any enmeshed individual could organically emerge to lead systems adaption – every individual is progressively more disconnected from the system as a whole.  Silos arise, stage-gate processes are crystallized, and creativity – without needing to be actively stifled – is now unlikely to impact the system as a whole.

Before we move on, promise me you understand:  lean does not mean layoffs.  Toyota’s dedication to the individual on the factory floor is central to its success.  If you try to mimic their process improvement, focus exclusively on eliminating waste, and then cut staff to save money, you’re doing it wrong.  That’s a huge leadership failure. Hacking off a portion of a complex adaptive system will direct any energy gained from increased efficiency toward self-protection.  It is never worth it.

Game Theory shows us that the best way to build sustainable competitive advantage is to invest in resources that create and maximize information asymmetry against our competitors.  On the other hand, we must also raise barriers to exit and increase switching costs for our scarcest resources, people. The more scarce, unique, and hard-to-steal your people are, the more defensible your unique value proposition and the higher your economic rents.  This requires a culture in which the individual has psychological safety in which to take prudent risks.  Trust – the kind that is earned through time in battle together – really trusting in peers, superiors, and subordinates is essential. The individual must be invested in and given the resources necessary for their pursuit of mastery, autonomy, and purpose.  Only then can teams organically self-organize around new forms of adaptation.

Inside that organization, you need the opposite conditions compared to the outward-facing competitive landscape in order to maintain margins and economic value captured.  Maximizing market information asymmetry requires close to perfect internal symmetry of knowledge – in other words, alignment.  Real alignment of understanding of the problem, the objective, and the acceptable risks in pursuit of a solution.  You need continuous throughput that maximizes value add and minimizes waste.  You need low barriers to meaning and purpose and high barriers to exit.  You need slack and creativity.  You need to encourage the tension and paradox and dissent that creates new ideas, while ensuring the organization as a whole is respect-based and disciplined about change.

In Lean we call this Minimum Viable Product. The “product” that must be minimally viable is not a product on the shelf that a consumer buys. The “product” is the sustainable business model that creates economic value that can be captured.   Whether there is one product for sale or hundreds, built by 15 people or 5,000, the minimum viable product is minimal if all consumers receive more economic value than their transaction cost at a price that is great than the cost of production; it is viable if there are enough consumers and enough demand to make the business model of production sustainable.

Seen in this way, the upgrading of any resource across the value stream to maximize minimum viable production should be considered as part of a single improvement roadmap, regardless of its handling by accounting “on the books” – whether it is an enhancement to a software product, brand recognition, acquisition of a competitor to gain market share, or training developers on a new programming language or delivery methodology.  In the end, all of these initiatives are the investment of capital for the purpose of economic value creation protected from competitive influences through creation and protection of unfair advantage.

This is critical – and why vanity metrics are so dangerous.  Even a very unhealthy, unsustainable company can create conditions of information asymmetry that protect its existence in the near-term, but touting a graph that shows increasing revenue, increasing company size, and increasing market share / number of customers does not paint a sufficient picture of the sustainability of the business model.  These numbers are a given. When they aren’t, companies love to find some other numbers that comfort them instead.

What a toxic, carcinogenic waste.

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.

Defect Prioritization

Defect Prioritization: Everything you ever wanted to know but were too afraid to admit that you needed to ask.

One of the biggest agile religious debates that seems to get people up in arms is backlog prioritization when planning has to balance known defects (especially in production) against new feature work.  Let’s dig in and find a sensible approach here.

First of all, realize that it isn’t a fun situation for developers: fixing a defect older than two weeks, even if you wrote the code yourself, is like looking at someone else’s work.  Especially if it is the cause of a problem, it hurts inside to look at it.  You wish you could re-write the whole thing because you’ve grown and learned and you’re a better developer than you were then!  I get it.  Naturally, it sucks that you can’t do that because you’d end up down a refactoring rabbit hole due to all the other code that depends on your code.  So you end up feeling like you’re adding duct tape to a hole in the hoover dam.  If you’re fixing a bug in code you’ve never seen before, its like your Product Owner told you to fix a hole in the Hoover dam, but said it in a language you don’t speak, while handing you a box of duct tape and shoving you in the opposite direction of where you need to go.  Support engineers – if they actually like what they do – are a very special breed and should be your best friend.  Get them a Snickers bar and a thank you card sometime.

Second, the “triage” work for identifying the importance of bugs (if that happens at all) in which a manual QA tester writes up a ticket and picks a “Criticality” level is a joke.  Even if you had an elaborate definition for each one, who cares?  A crash that impacts 70% of users is “critical” why?  The defect is critical to… what?  To who?  How many people?  How much money?

Now, the lazy moral high ground of newly trained agilists is to insist you should’ve never let the bugs out at all.  Six Sigma Quality baby!!!  That’s a nice thought, and a very valuable standard if you are starting a completely new project on the latest and greatest stacks.  You know, an iOS 9+ iPhone 6s or later mobile application from scratch.  Then, I do advise you to build less than you think you should, think harder about whether or not each feature is actually important, and ensure that no defect gets into the App Store. 

That isn’t most software and that isn’t the problem established software companies are grappling with while in the middle of an agile-at-scale transformation.  If are a Product Owner for 10% of an application older than three years, you definitely have defects and you definitely need a rule of thumb for what to do about them.  It isn’t your fault, but it is your responsibility.  Operating systems evolved underneath you.  Hardware was replaced.  Vendors changed.  SDKs stopped getting updated.  People changed.  Deprecations occurred.  Now you have a list 1,000 decisions to make.  In that scenario, the moral high ground “you shouldn’t have made any defects!” is lazy and unhelpful.  That’s not the reality and it provides no answer for what to do once you already have defects in production.  There’s really four approaches to consider.

1 – All About the Money:

On the one hand, calculating the ROI of every User Story then attempting to apply the same methods to your production or other leftover defects will require a pretty rigorous approach to finance, accounting, and statistics.  A simple example – if a LinkedIn share crashes every 100th time I cross-post to Twitter, what is the ROI of fixing it?  I’m not a paying customer nor is Twitter.  Should I just leave the crash and hope people don’t complain too much?  No, I don’t think anyone would suggest that.  That said, there definitely is a statistical algorithm for whether or not that crash is likely to impact my decision to become a Premium Member in the future.  But if the crash takes 11hrs to fix, test, and deploy while the data mining, analysis, etc takes 60hrs to gain a certainty of 75% – why on earth would anyone not fix the defect and move on?  Eric Reis popularized the saying “Metrics are people too” while Ash Maurya adapts this to say “Metrics are people first.”  That is to say, if you have crash count of 13, not a very actionable metric.  If you have a percentage of engaged users experiencing a crash in version 1.9.3 – you have an actionable metric, but that metric represents real people who are annoyed in real life about that crash!  Quantitative data needs to drive qualitative insight, not ever-more-complicated quantitative analysis.

On the other hand, there are important occasions when the money makes a difference.  If you have customers with a Service License Agreement or paid SAAS users threatening to leave or your actionable product metrics are moving in a scary direction on account of a defect or the perception of poor performance, the money should be the incentive you need to prioritize fixes over any new feature.  Once a customer is gone they are incredibly unlikely to come back.

2 – Actionable Product Metric: Oops

Oops!  We stopped talking about money and started talking about product metrics!  There is a good reason for that – if you prioritize the development effort that improves Acquisition, Activation, Retention, Referral & Revenue (AARRR!) then you are by default increasing the money.  ROI is not even the money question to solve, is it?  If you have a fixed team contributing to the revenue of a product, ROI variability or Gross Margin variability is what you actually want to track – as long as the costs per month to maintain and improve my product is outpaced by the growth of revenue from paying customers, the ROI is there and the Margins are there and everyone is happy!  The problem is that revenue, ROI, and Gross Margin are extremely lagging indicators of success.  They are a good indication of the stability of the performance of a company over time, which gives investors the confidence they need to keep the money there, but multi-year lagging indicators are very poor metrics for the decision-making of the teams that managing, maintaining, and improving the product.  Growth of total users or active users can be a great indication of possible network effects long-term.  Both of these long-term performance indicators are symptoms of competitive advantage.  NOT the cause.

Now we have the cart before the horse though.  If you have legacy production defects in your backlog and want to move to cohort-based split-testing, your defects are the NOISE in your SOUND.  In the example crash above, if you knew cross-posting to Twitter was an important proxy metric for Referral, the possibility of a crash is also the possibility that I don’t try to engage a second time.  If that defect existed before you began using cohort analysis and split-testing, your viral coefficient is already distorted.  So if your agile release train is making an exciting and important stop at the actionable metrics station, make sure to prioritize any defects that could distort the reliability of your pirate metrics and future experimentation.

3 – Fuzzy-Weighted Economic Value Algorithm: 

A core concept for how the backlog should be prioritize in a lean-agile environment is maximizing the flow of value-add and minimizing waste.  If you are continuously deploying, the scope of feature releases can take a back seat to actually committing to the long-term awesomeness of the product.  Of course, as Ash Maurya says, the product isn’t the product, the product is the sustainable business model – and that’s not a fixed-duration project, that’s a commitment to continuous improvement of your unique value proposition.  So in good lean-agile, at any given Program Increment planning session, you do not need to be certain that your ROI calculations are perfect or your developers will be fully allocated or your that your schedule is on track.  You have a fixed release cadence, only scope may vary.  You have a large backlog, selecting the best possible thing to build matters.  As we said above, if your revenue growth outpaces your cost growth, the ROI takes care of itself.

The Weighted Shortest Job First approach is very useful for exactly this.  Because everything else is a lagging indication of good decisions, the Relative Cost of Delay and the Relative Job Size are the most important factors in job sequencing.  Let me reiterate.  Sequence = prioritization.  Under the assumption that small legacy defects require small individual effort while large value-add features take multiple sprints to roll out, you’ll likely always fix your bugs FIRST.  Which is good.  No one likes a crappy product, no matter how much “SOCIAL!!” you add to it.  Burn your customers long enough and they will abandon you.  Every software product is replaceable if you make the pain of use greater than the pain of switching to an alternative.

Over time, three things will happen.  You’ll get to a point where the outstanding defects will require large-scale refactoring effort while your stakeholder (hopefully) get wise to the fact that a smaller improvement with more certain economic value add is more likely to get prioritized.  At that point, you have flow and hopefully rational planning and discussion will rule the day on deciding what to do next.  On that note….

4 – Politically-Intelligent Fuzzy-Weighted Economic Value Algorithm: 

If you aren’t entirely lean-agile, aka you are still mid-transformation, aka “the top” still works using their old plan-driven paradigm while somewhere down the line an agile-savvy person tries to smooth the flow of that work, you need to add something for portfolio-level politics that impact your program-level prioritization.  In this case, while you may not share it too publicly, adding more scores for which stakeholder you are pleasing should be considered.  You can then weight each of the relative scores, like proxy-voting for your stakeholders.

Yes, that means the old-school problems will be continued because you are giving the important people at the top some blank-check preferred stock when it comes to your backlog prioritization.   The unfortunate alternative is that you live in silly denial that their perception matters or that backlog prioritization is not a political question as much as an economic value you question and the people “at the top” or “in the business” continue to hate agile and second-guess every decision you make.  Concessions to a powerful VP today help earn you the trust you need in order to move prioritization to a more rational approach later.  Admit where you are, challenge it bit-by-bit, and work to improve it.

What does that look like in practice?  Hopefully there is an IT leader at the top too in your large-scale silo-heavy organization.  Hopefully that IT person or a Quality person up “at the top” can be one of the political variables in your weighting approach.  Don’t pit the CEO against the CTO as a Product Owner, that just makes you look like a chump who can’t make difficult decisions yourself.  Gain buy-in and provide enough visibility before planning sessions that no one gets blindsided by your decision to prioritize refactoring over that VP’s screams for “SOCIAL!” 

To reiterate – THE BACKLOG IS A POLITICAL ARTIFACT. 

Your solution is only partially economic or financial or social.  This is not a democracy.  Don’t go asking for votes.  It really isn’t a democratic republic, either.  And it is definitely isn’t just user story meritocracy.  Slapping a relative business value tag and sorting is begging for failure and distrust at your methods.  It looks lazy and it is.  You have to influence the right people to make the right decisions and that takes work.  If you’re lucky, its close to a full-time job and you have job security now.  Congratulations.  But seriously go fix those bugs.  They’re lame.

Scrum Backlog Prioritization

“Portfolio management is the art and science of making decisions about investment mix and policy, matching investments to objectives, asset allocation for individuals and institutions, and balancing risk against performance.” – Investopedia

How do you manage your backlog?  The strategists at the top are often accustomed to trusting their gut, while the engineers below insist on absolute scientific certainty.  Handing priorities down that game of telephone is a circus side-show of bull whip effect and sociopolitical contract theory.

Not that it doesn’t work out just fine….

Meanwhile, accountants and financial analysts, with the help of algorithms, benchmarking, and actuaries, have been tracking the present value of an asset, mid-investment, with all risks taken into account for a VERY LONG TIME.

The real question is, do you need all that certainty?  Should you be focusing on human interaction and the existential plight more?  I guess that’s a separate discussion…

I mean, at one extreme, do you care about your customers so much that you feel an ethical duty to fix every little bug no matter how much it costs you, your employees, and the families they feed?

At the other extreme, do you love churning out features so much you don’t care how many of those features aren’t wanted or how unsustainable your product has become?

No, I assume neither of those are you (I hope).  Instead, you are trying desperately to strike a sensible balance that lets you sleep at night while feeling good you pleased a small group with their favorite feature.  You’re really in the business of political and emotional backlog prioritization.

I want to let you know that I’m okay with that.  Relationships and society and worth building.  That said, when you are the bridge between the c-suite and several thousand staff member salaries, you may want to find ways to think harder about whether or not you are building the right thing, at the right time, for the right reason.

Thus, I will give you some science on backlog prioritization, but I wanted to let you know that I completely understand where you are with your current methods.

The Lost Product Owner

The Lost Product Owner

At scale, the “Hero-Scrum” paradigm falls apart.  A product becomes too large for one team, then the number of teams becomes to large for the Product Owner & CEO model to work.  A company working toward agile transformation could slowly restructure toward mini-CEOs; but the truth is, the organizational switching costs are too high to make this a realistic option.  Be honest – those that own the customer relationships and those that own the technical communication are, respectively, too specialized – and great at their jobs – to start mashing them together as peers.

That said, I see a clear skew in agile transformation consulting and especially entry-level Scrum training toward protecting the team against the more powerful Product Owner.  While this may be a tactical prejudice when the role is played by your boss, my first-hand experience has been the opposite.  In scaled transformations, the more likely scenario is that Business Analysts,  Project Managers, Jr. Product Managers, Quality Assurance Analysts, or Support Engineers of the organization are asked to rise to the occasion and somehow, instantly and powerfully, lead a team to greater autonomy, mastery, and purpose.

{inspirational anthem plays in here}

Let’s be real.

The two fundamental hero images intrinsic in most Scrum courses – the ever-vigilant, time-protective ScrumMaster and available-part-time, drunk-with-power Product Owner – is meaningless in the more complex patterns of large organizations.

After studying LESS, SAFe, and Lean Enterprise theory, while speaking to representatives or directly working with several dozen organizations, it is clear that there are enough job title “Product Owners” that more attention to the profession (in separate consideration from the role) is a worthwhile pursuit.

Although I initially wanted to pursue the shock value of entitling my first book AGILE IS DEAD: HOW TO GET WHAT YOU MEANT YOU WANTED – it is plain to me that the audience for that book is too poorly defined, the pain is therefore not shared by the entire audience, and the text would be a fantastic (agile) train wreck.

Instead, I can see there is a compelling need to teach the lessons many of us learn the hard way then become agile coaches and lose touch with.  There is a very large guild of professional Product Owners that need hands-on tactics for not only how but why specific practices work well in an agile, lean, scrum setting (as part of a larger enterprise).  Amazingly, many of the hardest questions for running agile trains have analogs with well-established practices in professions and industries so antithetical to innovative software development that we all collectively forgot to look (and our executives understandably would never pay the handful of thought leaders who were looking to come give us a PhD in the topic).

So be on the lookout for the table of contents, the rough-draft blog posts, and the invites to MeetUps and workshops.  I’d love to hear from you on the topic in advance of those things – so reach out to me at andrewthomaskeenermba@gmail.com

Photo via Jaxon Stevens

Winning Product Ownership Tactics

Editorial note: My blog’s ScrumMaster let me know that this post was a super-epic with poorly-defined target user personas, so I will decompose this into more actionable User Stories.  I’m leaving this draft in place because I want my Product Owner followers to know that it’s okay to admit you didn’t size or prioritize things right the first time…be genuine.

So now you’re all agile…

At scale, the “Hero-Scrum” paradigm falls apart.  A product becomes too large for one team, then the number of teams becomes to large for the Product Owner & CEO model to work.  A company working toward agile transformation could slowly restructure toward mini-CEOs; but the truth is, the organizational switching costs are too high to make this a realistic option.  Be honest – those that own the customer relationships and those that own the technical communication are, respectively, too specialized – and great at their jobs – to start mashing them together as peers.

That said, I see a clear skew in agile transformation consulting and especially entry-level Scrum training toward protecting the team against the more powerful Product Owner.  While this may be a tactical prejudice when the role is played by your boss, my first-hand experience has been the opposite.  In scaled transformations, the more likely scenario is that Business Analysts,  Project Managers, Jr. Product Managers, Quality Assurance Analysts, or Support Engineers of the organization are asked to rise to the occasion and somehow, instantly and powerfully, lead a team to greater autonomy, mastery, and purpose.

{inspirational anthem plays in here}

Let’s be real. 

The two fundamental hero images intrinsic in most Scrum courses – the ever-vigilant, time-protective ScrumMaster and available-part-time, drunk-with-power Product Owner – is meaningless in the more complex patterns of large organizations.

So here are the top three winning tactics that can help mid-senior managers and individual contributors succeed.


#1 – Startup Principles are Worth Your Time:

As I’ve mentioned before, the ability to ensure work is meaningful to the user-in-pain and the customer paying to resolve that pain (occasionally but not always the same person) is super important to the health and motivation of the engineers.  The shorter the time between empathy and resolution, the more meaningful the work, the more likely the direct correlation with revenue, and the safer the jobs and projects of the engineers become.

The big “evil” business “side” in a large company doesn’t need any of that in order to maintain risk aversion and product agility.  Cancelling a three year project before a customer saw it because a better project was two years in WAS their agility. 

Congratulations on your agile transformation, but when you said “agile” you really meant lean concepts like “small batching” and “level-loading”.  As a Product Owner what you really must have is lean startup principles.  The moment your team became an agile team, you became a new venture.  You now have to proactively validate all learning about three things:

  1. Product risk – The right thing was built to solve the pain of large (enough) but narrowly (enough) focused group.
  2. Market risk – The ability to build and continuously improve the viability of your product’s business model.
  3. Customer risk – The ability to get the solution into the hands of the customer.

Project risk – as you once knew it – is gone.  You don’t have a deadline to track against, you have angel investments from your Product Manager(s).  You don’t have technical risk that your estimates were wrong, you risk the loss of “investor” (c-suite, VPs) confidence that you know what you’re doing.  Can good forecasting and transparency help?  Sometimes.  Unfortunately, some of us get promoted from T-Ball to the Majors with no notice that it even happened. 

Product Owners – strengthen your relationship with your Product Manager like they are the venture capitalist and this is your first company.  The expected return is 10X due to the risk.  Many of them are having to let go against their will and trust that you know what you’re doing. 

Key skills to learnThe Lean Canvas, Innovation Accounting, Validated Learning


#2 – Everything is Marketing:

There is a java team, and a product management team, and an inbound sales team.  Marketing is not a department.  In a large company, yes, there is a corporate group in charge of advertising, branding, messaging, and copy.  As a Product Owner, embrace the idea that the marketing team is only 1% of the marketing the company does.  Everything is marketing – and you just became a sales(wo)man.  Every time you let a critical defect through and an engineer complains to their spouse and their spouse bad-mouths the company to their friends at a cocktail party – that’s marketing.  The world is a small town.  What you do matters and nothing is in the shadows.

Treat memos like Tweets with a million followers.  Fake your own notoriety if you need to.  As it turns out, you are uniquely positioned to make an enormous difference in how effectively your team meets the needs of customers.  Luckily, you don’t have to just make that stuff up from scratch!  Other people at other companies in roles you never thought to cross-pollinate against have ESSENTIAL skills that are PROVEN to work.  Decades old.  Seriously.  And most of them give that training away just to get you to spread the word!

Key skills to learn:

  1. For Roadmap / Release Planning – Talk to a Custom App Dev guy.  I can make intros if you like.  Most of them are so desperate for attention, you could make up a fake product and string them along for months.  Anyway.  The good ones do Story Mapping and MVP scope for FREE as PRE-SALES.  Lucky you – you already have a product manager to building software for!  You still need to be consultative to ensure collaboration and rational planning occurs.  Same advice as your personal life.  Date your spouse.  Start the courtship over again occasionally.  Things have changed, don’t act like you’ve memorized everything and communication can stop!
  2. For Stakeholder Alignment – Study the super hot topic of starting your own company.  You’ll be glad you did.  On ramps.  Assumption mapping.  Balanced scorecards.
  3. For Sprint Planning – Its a solution pitch.  PLEASE have an agenda.  PLEASE gain all necessary information and buy-in for prioritization prior to involving your developers.  Want an example?  Google “SAP Digital Transformation” and you’ll see that they have an example solution pitch for every industry.  This isn’t new territory you’re exploring, just a new town with a new bar but your old friends came with you.e
  4. Sprint Reviews – There is an art to the tell-show-tell demonstration.  Engineers and engineer leaders can be especially bad at this (and I’ve learned from plenty of terrible webinars as well).  The attitude “you paid me to build it, look its right here, no questions?  great….” is going to erode whatever influence you aspire to have.  Tell your stakeholders what you accomplished.  You know, business goals.  Product Pirate Metrics.  Tell them why it matters.  You know, to revenue and the sustainability of the business as a whole.  Give them numbers if you know them. Then anchor your demo against a pre-defined roadmap.  Lead feedback as you go with open ended questions.  Follow the poll / show of hands, individual follow-up routine.  Most importantly, this means taking it seriously enough to prepare in advance.  Everything is marketing!
  5. Sprint Retros – Until you start making falsifiable hypotheses, you have no experiments.  Without controlled changes to variables, you are not engaging in empirical process control.  You’d be amazed what a 4th grade poster about the Scientific Method could do for your team.  Test at least two assumptions “changing X in the product will influence Y positively” and “changing practice A as developers will impact outcome B as a team”.  There is no learning without defining what a successful outcome is prior to conducting the experiment.

#3 – Show Your Work (Too):

No really, make a scene.  Draw a picture.  Use a kanban board on your wall.  Write haikus.  Whatever you do, show it off in progress.  Disappearing to document things makes you irrelevant.  Show people what you do, how you do it, and why you do it – aspire to be like the great chefs.  You might even realize that people actually care how the sausage is made.

The best way to do this is to teach others.  The only way to build cross-functional teams in an ultra-specialized environment is to show people how much it benefits them to become cross-functional team-mates. 

If you don’t have time (you think) for reading anything intense, just pick up some Austin Kleon.  Savor it slowly.  Sip it.  Like egg nog.   Then tell people the compelling secret to the best homemade sausage anyone every made Tuscan soup with (metaphorically, of course).

How the Sausage is Made

Conventional wisdom: “No one cares how the sausage is made.”  I’m sure you’ve heard this before as well. Maybe it gets followed up with more assumptions: “The consumer cares about the product.  They want the solution.” However, that’s not really true either. They care about their pain. The solution is irrelevant unless the pain is relieved. If you’re really great, you replace pain with pleasure, and build a lasting relationship that your customers are excited to tell others about.

The Sausage

So let’s talk about this proverbial sausage.  When you are hungry at a game and a sausage wrap stand is the only food or you’ll miss the entire game?  No. You probably don’t care about how the sausage gets made. You care about your hunger. You care about the solution. You care about the price. 

Luckily, we don’t live in the local monopoly conditions or restricted logistics of that example.  There are true artists of the craft, solving new pains everyday.

Have you seen how a master chef makes tantalizingly delicious and unique sausage from scratch?  If you love sausage, you do care how it’s made.  You would buy recipe books, watch reality shows, do factory tours, and attend sausage festivals. There is a huge difference between being an artist with a following versus a monolith with a secret. Which company are you building?  Naturally, I didn’t write this post to discuss sausage (though after talking about it so much I’d really love to fry up a batch now).  This is really about sharing your product backstory and software delivery methods. 

Think about a great chef. The kind that writes recipe books, heads up gourmet restaurant chains, blogs about food, hosts a show, and even gets invited as a guest to cook on other people’s shows.

Imagine Martha Stuart or Emeril Legasse teaching their audience about homemade sausage from scratch.  They smile and cook with their pre-measured bowls of colorful ingredients, hand-grinding the sausage.  The sight and sound of the fire, and sizzle of butter in the pan make you certain you’d want to eat not just any sausage – that sausage.  The great chefs care how the sausage was made whether you care or not. They make the best sausage they can and teach others to try their methods even if most people will never bother to make it the same way. 

So, even though what we are really discussing here is either 1) ”no one cares why your product was made” or 2) ”no one care how your software is developed” – I think that’s drastically incorrect. More importantly, when someone says “no one cares how the sausage is made” to me, I know it’s a symptom of something terrible in the prestige economy of the superorganism that could someday bring it to its knees, never to rise again. 

Now we can qualify that old saying…

“No one cares how a faceless factory makes boring sausage.”

Don’t let your factory remain faceless. No matter how boring the boots-the-ground element of your product delivery may seem, those are people who are representing you.  You can either take the Ice Road Truckers and brewery tour approach to your product delivery or you can hide it away. Even the most faceless factories have tour guides. They have a script, sure. This is a marketing opportunity for your customers who are most likely to give a referral. If they show up to see how the sausage is made, give them a taste of the experiments that you aren’t mass-publicizing yet. This let’s you find your early adopters.  That’s a special relationship that you should encourage, invest in, and keep personally engaged.

Go take a tour of a big beer factory and a small craft brewery, compare the two and imagine what a “brewery tour” of your software company would look like.  The big beer companies have a loyal fan base and brewery tours. The ingredients are well-known.  You can even try it at home.  Operational effectiveness, consistency and quality, and reliability are the big beer maker’s keys to success – not proprietary ingredients.

Don’t be afraid to demo upcoming features before they are finished.  Your opportunity to learn and from customer interviews during an alpha release cannot be understated – give them a tour before you make them work for you.  Don’t just make a website, make a fan page too.  Show people you care about what you build as much as they do. Make the digital delivery part of the human dialogue.  As it turns out, you can’t make people get interested in you by yelling “I’m interesting!”  Telling people your product is the best (today) doesn’t say much at all.  Showing them that real people are making sure the product will continue to get better, teaching them what you wish you knew 2 or 5 years ago about the pain you solved and how they can solve it too – then they might be interested. 

“No one cares what the ingredients in the sausage are if they can’t see and hear the artist who uses them, the special process for preparing and cooking it, and insights in why decisions were made.”

The individual lines of code you write aren’t proprietary. Maybe one or two shouldn’t be public knowledge for security reasons.  The rest are meaningless without the rest of the code base and all the people that create viable product-market fit.  Your accounting KPIs, eCommerce analytics, or SDLC aren’t that special on their own either. Your templates are common knowledge to anyone with experience. 

Your people – coming together to do something bigger than themselves -THAT’S special, and while you can lose that no one can steal that. I suspect there are some companies that would never approve a marketer posting a photo of coding-in-progress on Instagram for fear contents of the screen is proprietary. Yet, any developer would tell you that turning frameworks into a worthwhile platform people can reuse is incredibly challenging. No, nobody cares what your product planning meetings or your Scrum process is, unless the people who make it special are front-and-center.  You can make an official statement – like so many companies – that your people are your greatest asset; but when you hide your people and how they work from the public eye, the message is clear, not only to your people but to your customers as well: you don’t take any pride in the sausage-makers, so the sausage probably isn’t that special. 

This is the difference between posting on Twitter “My apple pie is made with 20 apples” versus a video explaining which apples to use and why, the process you use when you pick them out at the store, why you bought them where you did, etc. Teaching the generations coming up behind you makes you matter, not protecting a secret that isn’t even a secret worth stealing. 

“People don’t care how the sausage is made unless they trust you share their love of great sausage.”

The difference between having consumers and having an audience is sharing their pains, pleasures, fears, and passions. Don’t sell to people, mentor them. Don’t market to people, teach them. Is it possible that some people want to know how you make gumbo but not how the andouille sausage was made?  Absolutely.  That’s the line between retention and referral – if you say secret to great gumbo is making the sausage yourself, the real advocates who trust you as an artist and an expert will pay to learn your sausage-making methods.  The opposite is true too.  If you don’t share the passion or demonstrate your expertise, no one is going to listen.  They can spot you as a fake from a mile away.  They know sausage isn’t a priority for you and nothing you say about making sausage is worth sharing with their friends. 

“No one cares how you make the sausage if YOU don’t care how you make the sausage.”

This is probably the most on-point.  Teams who think no one cares how the software is made also don’t have much pride or faith that their process is worthwhile. Sometime the biggest challenge is just showing the engineers how great they are. As the leader, you have to be like a head chef: It’s not just that you love and take pride in the craft, it’s your time-in-the-fire and belief in the process itself that give people the confidence to follow you.  Sure, your customers may not want to sit and watch code being developed for hours on end, but throwing a montage, hosting meetups, YouTubing behind-the-scenes footage, and some exciting reality show commentary is something people love and look for as part of the complete package. That type of messaging let’s people know you care about the work it takes to solve their pain. By giving some visibility into how much diligence, care, and work is put into the next release, your customers can feel they were part of the experience and have a better appreciation why updates and new features can take awhile to release.

If you want the inspiration I had when I wrote this, go read these books:

Rework

Steal Like an Artist: 10 Things Nobody Told You About Being Creative

Show Your Work!: 10 Ways to Share Your Creativity and Get Discovered

Photo via The Digital Marketing Collaboration

Identify Existing Alternatives

Identify Existing Alternatives

When you’ve identified a pain that is shared by a sufficient group, don’t start solutioning yet!  There is actually another crucial step.  Identify the existing alternatives.  If a pain is already perfectly met, it may not make sense to add that new feature, create that new product, or start a new company.

Understanding Workarounds

With Emphatic, some existing alternatives were Tweeting just a photo of the book with a caption, typing notes or quotes manually while fumbling with the book, and (for the research paper student) Microsoft Word does have a tool to help with your citations.

Each of these cases are examples of a workaround, since none of them really solve the key pains – frustration and wasted time typing notes, citation grey areas, relying on my brain’s “file system” for tracking and relating insights over time.

If you have ever emailed a document to yourself, that was a workaround.  AirDrop is an amazing solution to the specific pain “I want these three photos shared from my iPhone to another device Apple device.”

To find workarounds, you need to take a gemba walk.  Go to the place where the pain occurs.  Observe, ask questions, listen.  The closer you are to the pain you need to solve, especially if it is as critical to you as it is to your customers.  This isn’t all user experience fluff.  The workarounds and nearly-good-enough products you see today are the “Threat of Substitution” part of Porter’s 5 Forces after the new feature/product/business exists.  If you make scissors and someone cannot find them or afford them, tearing the paper is a viable substitute.

Competitor Research

The usability and customer interview part of competitive research is both easier and harder than ever due to the internet.  Where there is pain that is significant and shared by a group of people, there is guaranteed to be a place on the internet where you can observe what has been said, what people advise each other to do, etc.  Don’t fall into the temptation of trusting this as the only insight you need.  You need to get involved in the discussion, ask open questions, and listen (even on an internet forum).

As it turns out, Emphatic does have a competitor.  Although I had searched for a direct solution to my pains and found nothing, this week while searching for a workaround I found Quotle.  This is very exciting.  You see, Quotle is exactly what I had initially thought I’d build to solve my pain before I read Rework and Running Lean. It is an OCR scanner for paper books that looks like Instagram. 

I had envisioned artistry and community and got a technical proof of concept. 

Unfortunately, that’s the disconnect that accumulates into a product/market misfit as a demand to alleviate a pain moves from the user through the stakeholders and Product Owners to the development team and back to the user.  More on that later:  in the mean time, download Quotle, try it out, and send me what works and what doesn’t work about it.  I’ll be asking the same of people at the library.

Agile is dead.

Agile is dead.  Not the way your goldfish dies as a kid.  “Agile” is dead the way Marxism (as a socioeconomic political stance) is dead.  The dilution of the meaning of the word through excessive use, improper use, and deconstructionism, has made it not-worth-speaking-about.

Pragmatically speaking, there are really two ways people killed “agile”:

  1. As part of a movement, several institutions adopted the language of agile without changing their structure, values, or goals.  This made it necessary to explain your use of the word agile.
  2. Many of the practices that made “agile” marketable have become the normal way of developing software due to market demands, even in companies that expressly claim they will never practice “agile”

That latter disconnect is why you’ll see I’ll still write about things that sound like “agile” as a noun, the kind consultants charge money.  I’m going to be more specific about how innovate new products, encourage logic in product management decisions, and help you not destroy the team that makes you successful.  As dave Dave Thomas, one of the original authors of the agile manifesto said:

Agile is not a noun, it’s an adjective, and it must qualify something else. “Do Agile Right” is like saying “Do Orange Right.”

Having built my career around agile and scrum, the dread I began to feel roughly six months ago when someone started talking to me about agile in software development was meta-disheartening. 

Now, instead, I’m beginning to see that getting very specific about what I would improve in a company’s strategic planning, management tactics, and organizational psychology is extremely important.  After all, when was the last time that you used “agile” the noun-and-buzz-word-for-sale in the same way you used “agile” the adjective?

ag·ile

adjective

1.able to move quickly and easily.

“Ruth was as agile as a cheetah”

synonyms: nimble, lithe, supple, limber, acrobatic, fleet-footed, light-footed, light on one’s feet

Does that sound like your company?  Does it sound like your software team?  Product strategy?   Only if you are small, most likely.

If you work at a very large company, I have a hard truth for you.  The nimbleness of a body with extreme mass is internal. In a startup, you cancel a feature when it has a detrimental impact on a key metric.  Choosing one feature over another in a new product can pivot you into an entirely new competitive landscape, target market, and revenue stream.  In a very large company, you cancel the entire project.  You lay off an entire division.  You sell off everything tangible about the business process that are no longer part of your corporate strategy.

Remember how I said Marxism is dead?  Do you hear much about communism as a US social movement?  What about socialism?  Probably not.  Instead, in the ongoing internal dialogue of the USA superorganism, opposers and supporters alike rallied their opinions and held debates and made decisions using the words from the movement until the original words no longer accurately described the problem at hand.  Now socialism is part of our capitalism and capitalism is part of our socialism.  The only people who really care about the words as they were originally meaningful are the people either using them as a weapon or avoiding them out of fear of it hurting their reputation.

So when I stop fighting for “agile” don’t worry, my core values didn’t change.  I’m just targeting the problems more specifically, empathizing more with the people affected, and resolving their pain directly rather than fighting for revolution.

Here are a few things to do right now that will make your company better:

  1. Plan your business decisions (project-based investments) in smaller increments.
  2. Decompose development tasks so that they are less than a week of coding.
  3. Require continuous code integration (and pull-before-you-push, etc).
  4. Empathize more with users, and show your early adopters your work-in-progress.
  5. Ensure division of labor – “specialization” – isn’t leading to alienation.

 

Photo via davide ragusa