Category: Lean

The “Priority” field in JIRA

Leave a comment

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.

A Shared Economic Framework in 3 Simple Steps

Leave a comment

What is a shared economic framework? 

First, it is needed for “economic” decisions – any exchange of time, materials, goods, or services that requires  a supplier and a demander to agree upon a shared understanding of value. In microeconomics, we discuss this about goods. Through exchange using currency, they attain to an equilibrium price.

The further we get from material goods with well-understood pricing in a stable currency, the less likely we are to use a shared economic framework. We see this frequently in information products. From insuring events of dubious probability to bundling free mobile apps with existing operations, an inability of the consumer to properly evaluate… value. That, in turn means they can only establish willingness-to-pay based upon conformity with previously paid prices. 

This allows entire industries to mature into homogeneous – nothing but plain vanilla – product offerings. This is increasingly dangerous as additional information products and services are bundled, compound information asymmetry. 

Occasionally, it becomes doubtful if anyone can make a rational economic decision. The consumer doesn’t understand the complex product or the value stream necessary to produce it. With no understanding of US-China relations, microprocessors, operating systems, coding, or information economics, millions with a high school education are expected to make rational decisions about a pocket supercomputer that is nearly sorcery. 

However, this problem begins much earlier. In digital and tech products, this problem starts within the organizations that create them, long before being exposed to the market.

Information asymmetry – the possibility of one side to know much more than the other in an exchange – begins early and within each value stream creeps in very often. It happens on multiple fronts. Between the business model planning and funding mechanism and its market there is an inability to properly signal for proper valuation. Moreover, neither the business-side product designer or the marketplace consumers are likely to be fully equipped for rational exchange of complex, sophisticated, new technology.

In fact, it is safe to say that such a market is imperfect. Information and competition cannot work effectively to establish equilibrium price.

Even deeper within the value stream, the problem continues. The product marketer  suffers from business-to-technical information asymmetry with the development vendor or IT organization, and vice versa. 

Neither is speaking the same language. 

A shared economic framework attempts to extend beyond money to actual value. It creates a shared understanding of how centimeters translate to miles and how yards translates to millimeters.

A shared economic framework is an “exchange rate” for ideas that cannot otherwise be understood.

Between SWOT analysis and Git branching, between lifecycle profits and architectural runway, we can find exchange values for ideas. Sometimes we can look at strong proxy signals like completion rates and canary metrics to find a balanced understanding of value creation. Other times, we can use relative estimation and workshop-based collaboration to ensure that even if we lack numbers, we at least take time for conversation.

So here are the steps:

  1. Have the conversations to find out what you don’t know and how to translate “value”
  2. Establish product-oriented metrics that represent whether or not decisions are on the right track. 
  3. Start from the assumption you are wrong and imperfect, then prove this assumption incorrect. 

Drawing the Line Between PO and BA

Leave a comment

The Scrum Business Analyst

I have heard more than once “There is no BA in Scrum.” Imagine how your BA’s feel when a transformation starts!  At best, they are uncertain what their role ought to be. At worst, it is made clear by everyone else in the process that the BA is no longer needed or wanted.

The irony, for an agile coach viewing this as an outsider, is that numerous individuals throughout the value stream who are also struggling to cope with the shifting sands of transformation, frequently report that mistakes, lack of prioritization, failure to clear dependencies, and miscommunication are due to “being too busy.”

Obviously, just from this “too busy” problem, there are two important things the BA ought to do as an active member of a Scrum Team in a scaled environment:

  1. Act in a WIP-clearing capacity to the extent their t-shaped skills allow.  To whatever extent they do not have T-shaped skills, the moment they are not clear on how to utilize their time is the perfect opportunity to develop these skills.
  2.  Capture the very broad “reminders of a conversation” about a story that, in a large enterprise, occur across a larger number of individuals, over a longer time period, and in more geographically distributed locations than “core scrum” implies.

Roles and Accountability

Now we can draw the line between the Product Owner and the Business Analyst.

The Product Owner is accountable for decomposing an Epic or expressing a single enhancement as User Stories.  The Product Owner creates a Story card in JIRA for this initial Story list that includes a JIRA Summary and the User Story in classic format:

As a {user persona} I want {action} so that {expected value to the user}.

This is an expression of “Commanders Intent” and represents why the story is being developed and who cares whether or not it is developed.  Thus, the User Story is an expression of product strategy, and represents trade-off choices and prioritization.  The decision to expend finite on and expiring resources – time, energy, money, and talent – on one product change versus another is the most critical accountability of the Product Owner.

Although the what and how is negotiable, the intention of the Product Owner serves as a litmus test for all subsequent decisions.  The what and how are the realm of operational effectiveness rather than strategy.  It includes the framework of economic decision making and the processes, practices, and tools that streamline communication and align strategic direction of a distributed control system.

The Business Analyst uses the Description to succinctly express the what and how that has already been determined so that no context is lost in subsequent decisions.  The what and how remain negotiable to the extent these better serve the “Commanders Intent” of the User Story.

In an analog Scrum board, there is typically an agreement on “front of the card” and “back of the card” content that serves as the “reminder of a conversation” for the team.  In a scaled environment relying on a digital board like JIRA, the Summary and Description fields serve a similar purpose.  As the number of individuals contributing to the value stream increase, the need to detail the conversations that have already occurred increases as well.

In the process of detailing each Story Description, it will often be apparent – due to test data or testing scenario coverage – that a Story ought to be split into two or more stories.  The Business Analyst completes this activity and is accountable for communicating the split to the Product Owner.

 Stories may also be further split during Backlog Refinement or Sprint Planning based on additional insights from the team. Attendees should collaboratively decide who will capture this decomposition within the tool, but the Product Owner is accountable for prioritization decisions (if the split impacts this).  

Purpose of the Story Description

So, to meaningfully define the role of the Business Analyst, we need an understanding of what value is created if one individual “owns” capturing the elements of a Story Description as the number of these predetermined elements continue to grow. To the extent at scale that the team is unable to economically interact with every other value add activity in the value stream, the purpose of the Description is a succinct expression all value-add activities and decisions that have influenced the User Story prior to development. While we want to express these in the fewest words possible, and work toward distributed control of decisions, we do not want previous insights “hidden” unnecessarily from the Scrum Team.

Several important activities have likely occurred prior to our Sprint:

  1. Business decisions fundamental to the economics of our interaction with the customer.
  2. Funding based on an overarching strategic initiative.
  3. Customer research and analysis of product metrics.
  4. User Persona definition and Empathy Mapping.
  5. UX Proofs of Concept and/or A/B Testing.
  6. Stakeholder meetings.
  7. Success Metrics defined.
  8. Technical dependencies fulfilled (such as a new or updated web service API).
  9. User Story decomposition.
  10. Other Stories already developed related to the feature.

Thus, many details needed “downstream” should be easily expressed in advance of the Sprint:

  1. Why are we building this story?
  2. Who is the User?
  3. How is this User unique in our Product (i.e. relate persona to an account type)?
  4. What Test Data will need to be requested to test the story?
  5. What steps does the User follow to obtain the value of the story?
  6. What will the User see when they finish the story?

7 Simple Steps to Agile Transformation

Leave a comment

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.

Do Project Tasks go in a Scrum Product Backlog?

Leave a comment

I get this question frequently when training agile and scrum teams:

Do Project Tasks Belong in a Scrum Product Backlog?

YES.

Since answers to this question I have seen in chatrooms are typically insufficiently argued as part of a crazed political debate full of comments taken out of context, this very pragmatic question deserves a bigger picture answer – because the need to ask the question is a symptom of a stagnating transformation.

A successful shift from stage-gate or waterfall development processes to agile, Scrum, or Kanban requires a fundamental change organization-wide: from maximizing ROI and shareholder value to maximizing Economic Value Creation and sustainable competitive advantage. If this shift does not occur, the improvements gained from agile practices will inevitably stagnate.

Jez Humble refers to this state as Water-Scrum-Fall, that unfortunate state where most agile and DevOps initiatives plateau.

Most often when I talk to development teams, Product Owners, and ScrumMasters, this is often blamed on a lack of executive buy-in.

I completely disagree.  

I have also blamed a manager or two for the imperfections in the agility of a company, so I can relate to this view. To show you why you might not even want executive sponsorship, let’s revisit the view of a corporation as a minimum viable superorganism.

Complex Adaptive Systems Leadership

A corporation is not a machine with various parts to replace or maintain in isolation, it is a superorganism. It is a biological phenomenon that is not sufficiently explained by social contract theory or through monetary theories of motivation. Judgments about this reality are very easily clouded. Unfortunately, once measurement and monetary incentives change the natural behavior of the superorganism, it is difficult to change back – making it easy to fallaciously claim this as proof of their effectiveness.

Quantum physicists have suggested that undisturbed systems in the universe naturally stay in multiple states simultaneously, unless someone intervenes with a measurement device. Then all states collapse, except the one being measured. Perhaps what you measure is what you get. More likely, what you measure is all you get. What you don’t (or can’t) measure is lost.  – H. T. Johnson, “Lean Dilemma”

So when you hear “We need more buy-in from management” this is absolutely incorrect.  It is even counter-productive!  Adaptations by a complex system, that disruptive creativity and innovation agile champions desire, can only occur through organic, emergent leadership – a tribal, heretical rebellion. Adaption to a new stimulus may have a focal point, a “leader” who organically builds up energy in a new direction – but this leadership is an emergent property the complex system. In contrast, formal leadership (“management”) is a crystallization of a complex system, an attempt to reinforce a desired “normal state” – a force that exists counter to emergent leadership and adaptation. By default, formal leaders at all levels of an organism are incented (through power, money, and Agency Dilemma) to maintain homeostasis – i.e. the status quo. Even if a formal leader becomes the emergent leader of adaptation, this will be odds with her formal leadership. Unless she is willing to risk the loss of formal leadership, she will dissolve her capacity for emergent leadership and resume promotion of homeostasis – no matter how much it dampens creativity, innovation, and sustainable competitive advantage.

Evolution of a superorganism through disruption – whether a lean or digital or agile “transformation” – cannot occur if any one piece of the system is optimized in isolation from the whole because any superorganism, as a complex adaptive system, will exert tremendous energy to maintain homeostasis. The larger the superorganism, the more likely that optimization of one function or team will result in a net loss of desired adaptation (whether the desirable “adaptation” is called innovation, process improvement, or “growth”).

So, when a formal leader blesses a piloting of lean and agile practices by a completely isolated team, this is the superorganism equivalent of a mother’s amniotic sac – the team can establish itself as a unique complex adaptive system while in isolation, fed by the resources of the maternal superorganism but shielded from the homeostatic processes of the parent system. The moment this new team is re-integrated into the larger system, continued adaptation is unlikely. The company attempts to spread the innovation and creativity culture they achieved but instead can only formalize a shift in a subset of practices.  These practice, outside the context of psychological safety, a well-formed collaborative team, flop. No single activity of the pilot team will have the same value implemented outside the context of the pilot team’s “bubble” that safeguarded it against the homeostatic forces of the superorganism!

But wait – what about that “net loss” in innovation, creativity, and efficiency I claimed?

In practice, a company that adopts an agile process (let’s say Scrum) as a change in behaviors isolated to the teams developing software causes the rest of the system to expend energy maintaining homeostasis, and even more energy wasted by agents accommodating these homeostatic forces so that the development teams can preserve their no-longer organic place in the system.

I think you know exactly what that looks like:

  1. Updating documentation processes without seeing them as “artifacts” that emerge from an adaptive process rather than social contracts that require formal sign-off.
  2. Replacing one tool with another, causing a new set of employee workarounds to occur.
  3. Increasing frequency of software releases without changing the size of organization commitments.
  4. New meeting names that don’t change communication patterns or the homeostatic, status quo, “normal” flow of information.
  5. Continuous backlog decomposition as a manual transfer of a large-batch investment into small-batch development items.
  6. Oops! Another manual transfer at the end –  of small batch engineering back into large-batch approval processes.
  7. Changing job titles without addressing diffusion of responsibility and the lack of psychological safety inherent in the culture of the system.
  8. More overhead and forced “transparency” than if nothing had changed, through extra meetings, reports, metrics, and analysis, due to the natural distrust between formal leadership and emergent leadership, and the lack of trust in information flow between the homeostatic processes and the aberrant nomenclature of the development teams.

In the middle of all this, a large organization grabs their Project Managers and their Business Analysts, or anyone cheap who is around and doesn’t have the “status” a Product Manager, Director, or VP, and switches around their responsibilities to call them “Product Owners” and “Scrum Masters”.

What a debacle.

The newly-minted Product Owner receives Project Plans full of important tasks and milestones and big nasty Use Case document and an even bigger, unapproachable set of Technical Specifications – and is told to manage what the team delivers with User Stories.

Now in the midst of all this, should the Product Owner include Project Tasks in the Product Backlog?  Or to get down to brass tacks, could a task ever be a Product Backlog Items?

Absolutely!

But not all of them.

Some “Technical” Tasks (specifically not User Stories) are still Product Backlog Items

Technical tasks that create demonstrable economic value that the organization can capture, a known cost of delay, but are completely invisible to the user STILL NEED TO BE PRIORITIZED relative to other potential Product Backlog Items.

This, of course, is why the question of if these belong in the backlog is sign that a systemic shift in thinking has not occurred. If you are optimizing for project ROI, then these tasks just don’t have the marketable, monetizable potential of each Use Case. If you have a systems view of optimizing the flow of economic value creation, these tasks are judged relative to any other potential investment. Economic investment is continuous, the economic value created can be judged continuously, delivery and value capture is continuous, and you can prioritize based Weighted Shortest Job First or another collaborative decision making process about the of Cost of Delay.

“Artifact” Tasks are an Agile Anti-Pattern

There is, however, another kind of project task in Water-Scrum-Fall that SHOULD NOT be in any development team’s backlog: artifact tasks. These are things like “Complete wireframe for new home page” and “Document Social Integration for PokemonGo”. No matter how you small-batch these tasks, these are not Product Backlog Items. These are not even artifacts. Artifacts are the tangible leftovers of the creativity and innovation of a strong agile software team. A documentation, design, or planning task is antithetical to economic value flow. It is a trap. A box you put your money in and bury. It takes all the value-add, throws it in a pile, and lets it sit there, unused, as it become gradually less valuable.

This mini-waterfall process – this outrageous, lean-agile anti-pattern – surfaces in three ways, all of which I whole-heartedly reject and will actively undermine the capacity of others to pursue it in hopes that my heretical tribal rebelliousness will gain emergent leadership support:

  1. Business Kanban and Program Increment Planning tasks that lock up all creativity and innovation prior to the development team passively receiving instructions (as you see in shoddy implementations of the Scaled Agile Framework)? FAIL! TRY AGAIN!
  2. Tasks for non-developer “members” of the development teams completed as Sprint Backlog Items separate from the User Stories, thereby formally dividing cross-functional collaboration and preserving us-them Guilds (whether in dual-track Scrum or within even the shortest sprint)? FAIL! TRY AGAIN!
  3. Sub-tasks that formally divide up User Stories into function-specific tasks to complete? FAIL! TRY AGAIN!

These are all agile anti-patterns that prioritize tools, social contracts, and “process” over collaboration, communication, relationships, and creativity. You will never disrupt your organization, and your organization will never disrupt your industry, sorry.

“Milestone” Tasks are a Continuous Delivery Anti-Pattern

Since we started this asking if the BA / PM as PO ought to put Project Plan tasks into the Scrum Product Backlog, I’d hate to leave out “milestones”. Now you may say, “Andrew, that’s ridiculous, no one would treat a dependency as Product Backlog Item!” Indeed, ridiculous. But that’s the ultimate sign of your Continuous Delivery anti-pattern. Truly optimizing the flow of economic value creation across the entire complex adaptive system would completely remove “milestones” and “dependencies”. If you can’t get rid of Project Plans completely, and continuously deliver and validate Finished Story Benefits for ALL work that the organization takes from identified pain to economic value capture, whatever you started pursuing in your agile, or digital, or lean, or devops transformation, you’ve plateaued as a company.

And this is the really the paradox that made the lengthy description of complex adaptive systems leadership necessary. This hurdle is NOT something that “Needs executive buy-in.” This is something that is accomplished through outright insurgency, tribal heresy, and fait accompli rebellion.

That’s because Continuous Delivery takes more than agile ceremonies and user stories. It takes developers who are proud of knowing business context. It takes refactoring that no one approved. It takes a team move to Git from Subversion without telling anyone. It takes a handful of people setting up a Continuous Integration server no matter how often the nay-sayers tell them it’s useless. Continuous Delivery is a change in engineering practices and development culture that tend to happen without formal leaders needing to approve anything.

It just takes the right people having enough pride in being BETTER that they draw a line in the sand and defiantly announce “THIS IS OUR CRAFT!”

A Heartfelt Epilogue: Real Creativity, Innovation, and Disruption is MESSY

Now listen, human-to-human, if all you know about “agile” comes from that one book you read, YouTube, or a two-day certification, I won’t be surprised you’re thinking, “Wait, Andrew, that’s nothing like agile! How do I report you! How do I get you stripped of all your certifications?” That’s great. That reaction means I hit a nerve. Fantastic! Contact me and let’s talk about taking agility to the next level.

Truth is, I don’t look to my four certifications, five training course, three conference, my blog, OR EVEN my five years of attending, speaking at, and hosting MeetUp’s on agile as the proof of my legitimacy on these topics. I measure my expertise in the number of experiments, including the major failures I have been through with my development teams. The reason is simple: complex adaptive system leadership is an emergent property that require deep entanglement and shared experiences in the trenches. And, as it turns out, I’ve been in the thick of every kind of good or bad lean or agile possibility, trained people in that context, debated ferociously about it in multiple companies, and I have compromised my values or experimented with teams to directly challenge every single principle your little YouTube summary glossed over.

If at this point you think some teacher let me down and it’s a real shame, I’ll be happy to give you a recommended reading list and YouTube list and introduce you personally to other thought leaders that dive, like I just did, into the MUD of how you actually achieve: creative innovation, strategic and operational agility, and lean, continuous delivery of disruptive economic value.

Either way, reach out so real dialogue can get started.

You do NOT want Transparency

Leave a comment

Disruption and Transparency

As a custom app dev consultant I constantly get inserted into the space between organization silos – between marketing and accounting, between sales and operations, between IT and product management.  The agency life makes you a fly on the wall in meetings where groups who avoid each other are forced to work together directly for the first time. Maybe it is the nature of disruption, whether it is a lean, agile, or digital “transformation” – but it creates immense hoopla about and demands for “transparency”.

Transparency is promised all around, named as a priority in meetings, and complained about when people feel like they’re out of the loop. As the old bard said, “Ay, there lies the rub.”

Transparency is not what anyone wants.

Requesting transparency, instead, represents the desire for visibility and proper prioritization of important information as it flows to the people who will be impacted by it.  If someone doesn’t have an understanding of what information they want prioritized, “transparency” is really just an expression of distrust.

Transparency is saying “I don’t know what information is important, I don’t trust you to prioritize it for me, so give me access to all of it.”

Now don’t get me wrong, this post is not about how to allow or restrict access to data. Instead, if you are part of a disruption-in-progress, keep an eye out for communication anti-patterns.  When a complex system is creating new cultural repertoire, adapting to disruption, new information flows must be created.  New decision patterns emerge.  Some people like the change and others are oblivious to it until the day it hurts them because they personally failed to adapt. 

Examples of Communication Anti-Patterns:

  • Email notifications that are really just internal company spam.
  • Managers who request to be added to meeting invites “just in case” they want to pop in.
  • Sending someone a raw (and sort of meaningless) export of data in spreadsheet form as an “answer” to their question.
  • Stakeholders who demand access to the agile tool (JIRA, Rally, Trello) but never look at it.
  • You get a casual question about status and answer by forwarding several email chains.
  • Making up new KPIs and performance metrics that don’t matter.
  • Virtually every version of reports on “utilization” that I’ve seen.
  • Anonymous complaints to executive leadership about secrecy around financial status.
  • Weekly meetings that review numbers that only change quarterly.

I’m sure you have another hundred examples, just like I do.

So whether you adopting a new tool, some kind of “enablement” software, in your aspirations for lean scalability, changing your agile or DevOps processes to encourage innovation, or embracing digital transformation as a path to new business models and potential revenue: be human.  When nonsensical requests for transparency happen, let it inspire a dialogue (or several) about what information is most important to each person and the best way to present it.  If you didn’t see the future and have all those conversations up-front, guess what?  No one does. Start driving human dialogue as soon as you notice there is a communication anti-pattern.

Visualize Your Work – and Show it off!

And, if these aren’t problems you’re having right now, you should still think about the best ways to visualize your work in progress. You will benefit psychologically, someday you’ll be able to answer new but important questions to a manager or colleague more appropriately, and you’ll discover what you can teach to other who are earlier in their professional journey.

Are You Ready for the HaaS Economy?

Leave a comment

Internet of Things innovation is diving hard and fast into the hype cycle’s trough of disillusionment (Check last August’s Gartner’s Hype Cycle).  After all, we have a fridge that can stream video to my phone and…. okay not much going on really.  The real potential for IoT has been in the industrial and B2B space where big “dumb” machines could work together much better with a little “smart” tech.

The cultural quirk that has made innovation in IoT is the enormous emphasis on consumerization of new tech.  If the drone isn’t a personal flying car or the IoT can’t be purchased as a smart home upgrade, people have a tough time caring I guess.  So all the hype is focused on the B2C market while most of the potential for innovation is in the B2B space.

Enter the Hardware as a Service economy.

Having played in the IoT space with several early adopters as a consultant, this is definitely huge.  Essentially, we will see more smart hardware suppliers for both consumer and B2B markets enter.  Containers, logistics, irrigation, experience marketing all have immense potential for startups that can bear the risk of innovation and maintain the expertise of servicing and implementation.  That’s the heart of what makes this a no-brainer – “HaaS transforms an up-front capital expenditure into an ongoing operating expense, which also allows for more accurate cost/value comparisons” via TechCrunch

That’s three huge differences HaaS will make in IoT:

  • Finance is Simpler: Companies don’t need to bear all the risk of innovation in tech they don’t understand.
  • Accounting is Simpler: Companies don’t need to bear all the risk of investment in a massive purchase of tech they don’t understand.
  • Economics is Simpler: Companies can more accurately trace the value-add to their ongoing operations investment, rather than calculating a BullShit ROI for projects based on tech they don’t understand

Your ROI is Total BS

4 Comments

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

DevOps Athleticism

Leave a comment

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.