How to use the Lean Canvas for App Planning

Lean Canvas

The Lean Canvas via

The Product Vision Imperative

Imagine a Ferrari with no steering wheel and no tires – no amount of horsepower or torque will win the race if a car has no direction. Increasing resources or efficiency without alignment and traction on a common strategic vision is utterly ineffective.  While agile, scrum, and XP will maximize velocity, it is critical that we ensure the well-formed team has ultra-clear, laser-like focus on the goal.   After all, no increase in velocity or decrease in impediments can supplement a lack of understanding of what to build and why it should be built.  This is why the ability to clearly articulate the product vision of an app is critical to ensuring we don’t just build the right app and build it fast – we build it for the highest possible impact.

There is a natural 3-level taxonomy to an app.  The app Narrative (the entire app) is made up of Epics (major features), Epics are made up of Stories.  Because an app (as we’ve previously defined it) is a relatively small and ultra-intuitive tool with a highly focused outcome, stating the Narrative is the Lean way to succinctly express the workflow being created, who will use it, and why.  It conveniently looks like a massive user story:

  1. The Narrative – A a sales rep, I want to support customers without having to turn my back or leave the room so I can build better rapport as their consultant.
  2. Some Epics – Check inventory, Answer questions, Take payment, Notify inventory team
  3. A User Story – As a sales rep on the sales floor I want to use Apple Pay to accept payment from my customer  (Part of the Epic “Take Payment”)

The simplicity of this description will help align the team on the product vision, but it glosses over the business case that justifies the vision.  This can be done efficiently for multiple apps using the Lean Canvas approach to documenting the business case for an app.

1 – Identify the Problem

Because the scale and scope of any given app MUST be laser-focused we must start with identifying the key problem we want to solve.  Building the right app – A Billion Dollar App – means we don’t build a hammer and start hunting for nails.  We identify the nut, bolt, or screw, take stock of the complex setting in which we find it, and build the right tool for the job at hand.

“Customers care about their problems – not your solution.”

-Dave McClure

This begins with the Problem Statement.  The top three major pains for a single (existing) operations workflow often tie together in one overarching “problem”.  The Billion Dollar App for an enterprise should also have no feasible existing alternatives.  We aren’t reinventing the hammer!  Instead, we want to identify the problems that are unique to the organization, making a custom solution the best approach.  If a SAAS product for a non-core process is available for a client’s pain, we do the right thing and suggest the correct existing solution.

2 – Know the Target User

An appropriately sized and focused app must have a well-defined target user base.  In marketplace consumer apps, this means identifying the target market segments in which an app will compete.  For enterprise apps, this is typically limited to single business function (e.g. sales).  While there may be a subset of users that have customized versions of the same experience, we avoid creating apps that lose focus by combining multiple unrelated workflows.  For example, if managers want a dashboard for their sales rep app, the manager narrative (focused on analytics and the big picture) should be separate from the sales rep narrative (focused on point-of-sale conversion).

This is often accomplished by creating User Personas that describe an imaginary but likely user for the app.  In order to properly determine Minimum Viable Product, it is essential to know the “80/20 rule” for the target user base.  There are three personas that will assist with effective planning discussions:

  • The Early Adopter – Knowing your early adopter is critical.  Whatever initial revenue or increased productivity the app will drive, the early adopter will drive it and provide the initial wave of feedback that can inform a pivot.
  • The Average User80% of people will use 20% of the app.  That first 20% of features will also deliver 80% of the value created.  Prioritize the high-impact feature that the average user will make use of and defer the rest until later. 
  • The Power User – This user is both useful for building out the longest-term set of possible features and for helping define what type of person will likely not get everything they want.

3 – Summarize the Unique Value Proposition

Once we identify the problem at hand and who it impacts, we quantify the value a solution has the potential to generate.  In enterprise process improvement apps we call this “Impact” – the time or cost savings potential or the potential increase in revenue associated with solving the pains we have identified.  A business case is incomplete without this.  It is easy to gloss over this in the excitement of imagining an app solution, which is why the App Roadmap Workshop is specifically designed to maintain this discipline – we need to know the value proposition before determining the solution.

Once we know the value proposition we are in a position to move from problem to high-level concept.  This is often easiest to do by drawing from apps familiar to the audience, identifying both similarities and differences that we would expect to see. 

4 – Provide the Solution

With a high-level concept and a quantified value proposition, we are ready to brainstorm the solution.  The goal at this stage is to determine what an app would do for each of the pain points identified.  At this stage, avoid over-thinking whether the solutions are separate apps or features combined in a single app.  Instead, focus on the Narrative that uniquely solves the Problem for each User with an identified pain.

5 – Determine the Product Channels

Determining the Product Channel for each app means determining which devices and operating systems will be supported and how the app will be distributed to users.  For web apps, we need to define the internet browsers that will be supported based on the target demographic or based on insights from IT.  For enterprise iOS apps distributed through a Mobile Device Management (MDM) platform this will require an Apple Enterprise Developer Account that may take several weeks to secure – do not delay this process.  Android, iOS, and Windows consumer apps each have a unique consumer marketplace with their own policies for content and distribution as well as unique marketing requirements (description fields, screenshots, etc).  Regardless of which channel is right for the solution to the problem, add to your to-do list to look through the policies, terms and conditions, and Human Interface Guidelines for that channel.  If your personal device or browser is not the product channel for your target market, be sure to look up a few “Top Ten Best Apps” and “Top Ten Worst Apps” to get a feel for trends in design and performance.

6 – Revenue Streams

The next step in the Lean Canvas method is determining revenue streams for the product.  In the consumer mobile app marketplace this is often referred to as “monetizing” and may be a combination of selling a paid app, using in-app purchases, making space for iAd, sponsored content, or selling data that is collected.  When planning web or mobile apps for the enterprise, the App Roadmap Workshop looks at how much cost or time savings or additional revenue (of the potential identified at the Unique Value Proposition stage) can likely be captured by the business given the possibility.  This is part of an overall Balanced Scorecard that ranks the apps the business has identified in order of Return On App.

7 – Understanding Cost Structure

As part of the App Roadmap scorecard, we work with clients to identify the impact of the cost structure of the business processes we will impact.  This can be done using relative estimation by rating a handful of subjective influences:  switching costs, disruptiveness to employees, cost of waiting, and timeline to capture the value created.  For example, if our goal is to improve the in-store sales process to increase revenue, we need to understand any costs associated with training employees to use the app, costs to change the layout or technology infrastructure of the stores, and the extent to which the change will be disruptive in a way that has a negative impact on revenue as the employees adapt to the new process requirements.

When planning a consumer app, fixed and variable costs associated with the longer-term product strategy are important to identify – an information website, hosting fees, product support, and ongoing development costs should all be taken into consideration.

8 – Identify Key Metrics

Because we identified the numbers associated with the problem we will solve, understand the unique value proposition, and have planned our monetization or impact, agreeing on key metrics should be relatively straightforward.  If an app is tightly focused, there is typical “one number” that we want to move and a few numbers that we are certain contribute to our goal.  Secondary metrics are important because our primary metric is often a trailing indication of success or failure and is therefore difficult to use for short-term planning.  For instance, if the “one number” is increased quarterly revenue, the impact of new features may not be represented for several months.  Secondary metrics like increased traffic conversion, increased items per sale, and increased revenue per sale may provide insights more quickly.  

While the business case metrics identify the how we measure success or failure of the app itself, the Lean Canvas method can be repeated on a per-feature basis to prioritize Epics on the app roadmap.  Key metrics at this point are typically called “analytics” and focus on the impact of any given feature on the user.  This may include a combination of time-to-completion, time per screen, crash-free users, and user-provided subjective ratings (i.e. 1 to 5 stars).

9 – Competitive Advantage

While identifying revenue streams or process impact and establishing the key success metrics for an app allows us to prioritize and understand feasibility, identifying “unfair” or competitive advantage is essential for determining how to sustain long-term margins.  At this stage, a Five Forces or Resource-Based strategic analysis can help determine how barriers to entry can be raised and also identify what quality about the new product or process improvement will be difficult for competitors to copy.


Enterprise App Strategy: The Resource-Based View

The Resource-Based View of Corporate Strategy

In my post Porter’s Five Forces for Enterprise Mobile Solutions I reviewed the classic but powerful theory elaborated by Michael Porter, a key thought leader in what is known as the Market-Based View of strategy.  This externally-focused view of competitive strategy is predicated on analyzing the industry in which a firm competes, the position a firm takes as one of many competitors, and the economic implications of that position.  This is often easier in hindsight and can be difficult to employ for strategic planning for some businesses – because the Five Forces method focuses on the economic value captured by a firm after external pressures erode the value created, rather than why or how that value is created in to begin with, the Market-Based View can leave business leaders scratching their heads.  Moreover, even when the impact of the Five Forces is clear at the business level, it becomes extremely problematic when looking at a multi-business corporation.  When a publicly-traded corporation has a diversified portfolio of unrelated businesses, what value does the corporation create for its shareholders independent of the businesses competing in their unique markets?  How does the multi-business corporation position each business in a way that creates synergy and sustainable, long-term competitive advantage?

Collis and Montgomery have dedicated their careers to answering the difficult questions in corporate strategy as thought leaders for the Resource-Based View.  They provide valuable guidance in answering the problem of how multiple businesses can create more long-term value together rather than separately.  In this post, I will summarize key elements of the Resource-Based View and apply them to enterprise mobile app portfolio strategy.

Sustainable Competitive Advantage

Businesses exist to create economic value that can be consumed in exchange for capture of a portion of the value created.  While Porter’s Five Forces focuses on the pressures that erode the value a firm can capture, the Resource-Based View looks at how to plan competitive advantage at the corporate and business level so that the competitive positioning a firm takes has long-term sustainability.

Let’s start with the their definition of corporate strategy:

“Corporate strategy is the way a company creates value through the configuration and coordination of its multi-market activities.”

Whether the corporation manages multiple product lines within a single industry (such an automotive corporation that competes in both the low-price and luxury markets) or manages multiple businesses in disparate industries, a firm must align the core value-creation processes to maximize efficiency, effectiveness, and longevity.

While I will revisit the topics of administrative context, scope of the firm, and the role of culture and managing change in future posts;  the fundamental key to maximizing sustainable competitive advantage is understanding the resources that make your firm competitive and how to organize around them.

For a resource to be a source of sustained competitive advantage, it must be valuable, rare, inimitable, and non-substitutable:

Valuable – A resource must enable a firm to employ a value-creating strategy by either outperforming its competitors or reducing its own weaknesses. The value factor requires that the costs invested in the resource remain lower than the future rents demanded by the value-creating strategy.

Rare – To be of value, a resource must be rare by definition. In a perfectly competitive strategic factor market for a resource, the price of the resource will reflect expected future above-average returns.

Inimitable – If a valuable resource is controlled by only one firm, it can be a source of competitive advantage. This advantage can be sustained if competitors are not able to duplicate this strategic asset perfectly. Knowledge-based resources are “the essence of the resource-based perspective.”

Non-substitutable – Even if a resource is rare, potentially value-creating and imperfectly imitable, of equal importance is a lack of substitutability. If competitors are able to counter the firm’s value-creating strategy with a substitute, prices are driven down to the point that the price equals the discounted future rents, resulting in zero economic profits.

Via: Boundless Management – “The Resource-Based View.” Retrieved 27 Jul. 2015

In Porter’s Five Forces for Enterprise Mobile Solutions I showed how custom enterprise mobile solutions can be employed against each of the Five Forces by protecting the efficiency, effectiveness, and consistency of organization’s core processes.  To plan an entire roadmap of apps, it is critical to judge the resources in each core process according to their unique value, rareness in the industry, difficulty to imitate, and resistance to substitution.

Resource-Based Strategy for Enterprise App Portfolios

We have seen that multi-market corporations must organize around unique resources to create high-margin value.  This is also why I discuss “enterprise” mobile app “portfolios” – the core operational processes at the team-level must come together seamlessly at the business level, while these business-level app “suites” or must come together in at the enterprise level.  The business level may be a separate competitive market for the operations process or the unique functional group in the corporate processes.  In either case, these processes are “proprietary” and deserve protection through custom solutions only insofar as the resources in each process are valuable, rare, inimitable, and non-substitutable.

Thus, the two critical questions that must guide your enterprise app portfolio investment strategy are:

  1. How does any single app upgrade your key resources?
  2. How does each app create and capture value as part of a portfolio in excess of the value it creates as an individual tool?

Because the driving vision of an app portfolio will only be as coherent and consistent as the strategic alignment of organization that creates it, planning a roadmap needs C-Level champions and cross-functional buy-in.  That said, what does it mean to find the “right” apps?

Upgrading Resources

Let’s use two examples as we explore the idea of “upgrading” resources to increase competitive advantage, one that has a product that is primarily service-based, one that has a physical product that results from manufacturing processes.

  1. Example A: Service provider –  A national hospital corporation with several medical centers, acute care, surgical, and other facilitates that operates in multiple geographic regions.
  2. Example B:  Product manufacturer – A US-based die forging company that shapes metal parts for other manufacturers across several industries.  Through high quality standards and technological investment, the company has “locked-in” several large clients that rely on them exclusively.

First, let’s analyze what is similar about these two corporations.

  • Both corporations have three main meta-processes – Operations, Business Development (including sales, marketing, and advertising), Corporate Overhead (including corporate leadership, accounting, finance, HR, legal).
  • Both corporations have skilled laborers and a strong culture of shared values.
  • Both corporations prioritize quality as a differentiation metric and believe in maintaining unmatched transparency.  Internal and 3rd-party audits are common.
  • For the sake of this example, business development and overhead are industry-homogenous and are not a source of competitive advantage for either corporation

Next, let’s identify and evaluate the top three resources critical to the competitive strategy for our example hospital corporation.  To select the right workflow that can be improved with a custom mobile solution, we must first know what resources are scarce, demanded by the market, and difficult to appropriate so that we not only upgrade the value creation of the resource but also capture economic rents long term.  This is our path to sustained competitive advantage through investment in a custom mobile app portfolio.

Example A:  Hospital Corporation 

Skilled Labor (Doctors, Nurses, and Technicians)

  1. Valuable – Doctors, especially nationally acclaimed surgeons, are in high demand.  The skilled nurses, medical technicians that support the doctors as part of the hospital’s value stream are all well-educated, heavily trained, and uniquely qualified to create specific value-add
  2. Rare – A top surgeon must have high aptitude, a long and successful academic career, and years of residency and practice in order to gain their skill and reputation.  Because the cost and time for education and training are a major barrier to entry into the field, and medical school enrollment is tightly controlled, the surgeon is an extremely scarce resource.  While the nurses and medical technicians are less scarce and education is less of a barrier to entry, competition remains high in geographic regions that have large competitors.
  3. Inimitable – Hiring and training practices are easily copied by competitors.  Corporate leadership expresses that strategic alignment, a shared value system, and the intense focus on quality differentiates their services.  While these could also be copied, late adopters would have significant learning curve disadvantages.
  4. Non-substitutable – While direct competition from small primary care practices and geographically-near hospitals (per market) is high, substitution for acute or surgical care is extremely low.

Cutting-edge technology 

  1. Valuable – Investment in specialized equipment is not only a major barrier to entry, many advanced treatments that this hospital system provides cannot be accomplished without this equipment.  As such, announcement of a new program and its associated technological investment is a common Game Theory technique for avoiding direct competition.
  2. Rare – Because hospitals avoid direct competition for advanced treatment by limiting duplicate investments, the scarcity of supply to the market is high.
  3. Inimitable – Although hospitals avoid direct competition, the approach of announcing investments ahead of time make imitation easy.
  4. Non-substitutable – There is no risk of substitution of advanced technology for this market, because substitutes were typically ruled out or attempts prior to demand for the advanced treatment.

Reputation for Quality

  • Valuable – Investment in business intelligence, consistent transparency to investors and the medical community, and a long history of audits by multiple 3rd parties has made the Reputation for Quality a critical differentiator in the competition for market share and for human resources.
  • Rare – Due to the extensiveness of focus and investment, this corporation’s care quality metrics are unmatched.  However, not all consumers are sensitive to this as a decision.
  • Inimitable – Although this approach is at risk of imitation, the late-adopter would always be years behind in building a history of transparent, verified data.
  • Non-substitutable – The only substitute for quality is quantity.  The highest-margin specialized treatments are not at risk, while acute or emergency care is at high risk of substitution.

Distinctive Competence

While every business has core competencies, only distinctive competence – highly demand, scarce resources value streams that are difficult to appropriate – will result in competitive advantage.  For our Example Hospital Corporation, the clear resource to upgrade is the is the doctors and surgeons that provide the highest-margin specialized care.  To upgrade the specialized treatment physicians as an economic resource, the competitive strategy of the Hospital must make the doctor, as a human resource, more valuable, rare, inimitable, and/or non-substitutable.

We can see some obvious tactics for upgrading the economic value of this resource:

  • Increased value to the market – by continuing to be a first mover for providing advanced technology for research and practice, these key resources will not only be attracted, but may be monopolized.  High barrier to entry from competitors into highly specialized treatment programs will likewise create high barrier to exit for the surgeons practicing these treatments.  Monopolizing a service, in this case, will monopolize the resource pool allowing high economic rents.
  • Increased scarcity in the market – by monopolizing any given hi-tech, highly specialized services as above, the market will be in a state of information asymmetry and economic rents can be preserved long-term.
  • Reduce imitation – To whatever extent the hospital can own the rights to Intellectual Property surrounding the training and practice of specialized services, the market will not be able to copy through resource appropriation.
  • Eliminate substitutions – in this case, substitutions are not a major risk so focus should be on reducing transferability of knowledge and raising barriers to exit for the physicians.

Although we have clearly established that technological investment is the right approach to upgrading this resource (the high-profile, ultra-specialist doctor) by increasing scarcity and information asymmetry, raising barriers to transferability and imitation, and increasing the value of the information property that is created, we have not found a compelling case to add a custom mobile solution to the existing technological investment.

While a high-performance, beautifully-designed app aimed at these world-class care providers may increase the effectiveness of existing resource upgrade plans, this is a perfect example of an “obvious” app that may be perfect as part of broader app portfolio strategy but is not the best first app in the Example Hospital Corporation’s roadmap.

“Businesses are full of pain points and apps today are hitting the obvious, low impact problems. We have to understand what the business impact of the problem really is and quantify why it is worth solving.”

– Alex Bratton, Founder and “Chief Geek” of Lextech Global Services

Via  A Good App Still Needs to be the Right App 

Instead, using the Resource-Based View of strategy, we need to look for resources that do not have an effective upgrade plan in place, resulting in transferability and negative economic rents.



Porter’s Five Forces for Enterprise Mobile Solutions

Porter’s Five Forces:

In the Market Based View of competitive analysis, Michael Porter’s The Five Competitive Forces that Shape Strategy provides the seminal framework for understanding where and how a firm ought to compete.

The Five Forces are:

  1. Threat of New Entrants – The threat of new competitors entering an industry is high when initial cost, in time or money to enter an industry, is low.   Common barriers to entry are:
    1. Learning Curve Disadvantage – A landscape in which only an expert can compete and training is either restricted or difficult to obtain.
    2. Economies of Scale – In an industry that compete based on price, businesses that have grown large can drive down operational costs and leverage their market influence against suppliers.  Firms competing on differentiation may also take advantage of Economies of Scale tactics to maintain margins and process repeatability.
    3. Technology Protection – In many industries, such as pharmaceuticals, the cost to do business requires Intellectual Property or significant investment in operations technology that must occur.
  2. Threat of Substitution – The threat of substitution is high when a product or category outside the industry could fill the demand for a good if supply were short and prices too high (e.g. if coconut water prices triple, bottled water could play the substitute role).
  3. Supplier Power – The threat of supplier power is high when there is resource or information asymmetry.  This is especially true when a consolidated mature industry is the supplier for a fragmented industry with no clear leader.
  4. Buyer Power – The threat of buyer power is high when there are fewer buyers than suppliers, or lower when demand is less than supply.  Any firm producing a B2B good or service is susceptible to this risk if there is extreme reliance on a single buyer, such as a chipset manufacturer that is one of several vendors for a much larger company that integrates, markets, and distributes.
  5. Competitive Rivalry – The threat of competitive rivalry is high when a market becomes saturated and homogenous firms compete based on price.  This threat is especially high when industries have players that begin engaging in price wars despite originally competing through differentiation in niche markets.

Mobile App Portfolio Strategy:

The Lean Enterprise approach to mobile solutions can take competitive strategy to the next level.  At the core of any firm, however large, a very small number of key processes are the “heart” of the value created.  Knowing and nurturing these core processes drives the competitive advantage of the firm – the output may be similar, but the throughput must become unique in the industry and difficult for competitors to copy.

To effectively compete in today’s economy, the core value creation processes must be proprietary and continuously improved.  Applying Lean Enterprise Kaizen – continuous improvement – through mobile solutions will raise barriers to entry, increase operational effectiveness, and shift bargaining power in your favor.  Pressure from each of the Five Force’s can be reduced:

  1. Minimizing the Threat of New Entrants – Investment in a mobile-first approach to Lean Enterprise Kaizen will not only raise barriers to entry against new competitors, it will also create learning curve disadvantages against existing rivals that are no longer as efficient or effective.  Read more on Lean Principles for Agile Stakeholders.
    1. Economies of Scale – As your mobile portfolio begins standardizing work, level-loading process blocks, and driving Just in Time operations, the cost of operations will drive down.  The goal will be to reach Minimum Viable Production – doing more of the high-margin activities that differentiate your organization while standardizing the work, focusing the worker, and reducing takt time.
    2. Technology Protection – The core processes at the heart of your competitive strategy will only provide competitive advantage so long as they remain proprietary, consistent, and scalable.  Any business has non-core processes that will benefit from off-the-shelf solutions (i.e. don’t reinvent payroll, several providers specialize in that).  By identifying a key process that can be transformed, protected, and optimized, higher revenue and margins, better leadership proprioception, and instant data access will disrupt the industry in your favor.
    3. Learning Curve Disadvantage – Although adoption rates for mobile devices has never been higher and companies everywhere are investing heavily in mobile, whether responsive or optimized web, native apps, or hybrid, very few companies are focusing on process transformation and even fewer on proprietary enterprise solutions.  This gives a multiplicative affect to the competitive advantage driven by an enterprise app portfolio:  competitors will need to learn what you do differently, how you built an enterprise app portfolio, and adopt a prioritization of disruption and transformation just to keep up.  
  2. Minimizing the Threat of Substitution – Threat of substitution is minimized through differentiation and quality assurance.  To the extent a product or service is perceived as unique and consistently valuable, the price elasticity of demand can be manipulated in your favor.  Mobile apps can facilitate the role of your core processes to this end:
    1.  Differentiation – streamlining processes that impact consumers will set you apart as an early adopter.  Maintain direct communication, make data instantaneous.  The consumer is becoming more sensitive to time-to-gratification.  Mobile solutions can remove every time a consumer-facing employee turns their back, puts a user on hold, or walks to a back office.  This turns sales reps into consultants, fully empowered to get the right product in the consumer’s hands with minimal time, confusion, or hassle.
    2. Quality Assurance – For both internal operations and consumer interaction, mobile solutions establish an intuitive guided workflow that standardizes the work to be done, focusing interaction on small batches of the overarching process.  Through Business Intelligence analytics driven by the application itself, key insights into bottle necks are simple to find.  Furthermore, when kaizen and “standard work” are facilitated by the tools built to make the employee’s work faster and more enjoyable (rather than a process document and managerial oversight) updates to the core process are implemented as part of updates to the app portfolio.  This is more than MDM version control, it is version control for process transformation.
  3. Minimizing the Threat of Supplier Power – The threat of supplier power is high when there is resource or information asymmetry.  Real-time data, and becoming a firm that demands it, shifts this balance.  You will have the freedom to determine whether you “put all the cards on the table” or maintain an information asymmetry of your own.  Knowing yourself and your suppliers with real-time data as it impacts your core processes will keep supplier power over resource prices at bay.
  4. Minimizing the Threat of Buyer Power – Unless you have exclusive access to a resource or protected rights to intellectual property, the only way to reduce the threat of buyer power is to diversify your revenue stream across a larger portfolio of consumers, whether product or service, B2B or B2C.  If your current buyer portfolio is skewed to a small number of large purchasers, streamlining your core processes, standardizing the work, and maximizing (operationally efficient) differentiation will provide a repeatable, scalable business model.  If you’re contractually obligated not to serve additional buyers, process improvement efforts should focus on heijunka (level loading) and delayed differentiation.  The ability to maintain operational efficiency despite the ebb and flow of suppliers and buyers will insulate against the threat they pose.
  5. Minimizing the Threat of Competitive Rivalry – Direct competition through pricing wars kills margins industry-wide.  To any extent “coopetition” can occur, margins can remain healthier for everyone.  Each player positions themselves in the industry such that they compete for a specific market – Player A competes for the price-sensitive, Player B for the luxury experience, Player C for a reputation for the highest quality.  Across a large geographic region, these three strategic positions can be focused territorially.  Every mobile app in your portfolio is a tool with a specific purpose.  Every tool has one number that defines it:  Gross Revenue, Conversion, Items Per Ticket, EBITDA.  Mobile app solutions need to maintain laser focus on the strategic position you intend to maintain and the one number that indicates if your solution is succeeding:
    1. Competing on Price – Whatever your industry sells, part of the market skews more price-sensitive.  If your position in your strategic landscape is focused on low costs, your focus for mobile enterprise solutions should focus increasing operational effectiveness.  The goal is to maintain current price and revenue increasing gross margin. This is especially true if your industry is already in a state of no-growth, zero-sum competition.
    2. Competing on Quality – Every product or service has quality as a perception of value created.  For a car, this may mean low maintenance or high safety ratings.  Competing on quality is one form of differentiation and pricing should be higher than price-based competitors.  Mobile solutions for these enterprises should focus on real-time analytics, providing transparency to management and the market into actual quality scoring.  This “dashboard” is really a marketing tool, whether it is aimed at your executives, investors, or consumers.  The other side of this solutions should be process analysis and notification, making any part of the workflow capable of automatically alerting someone that quality is at risk.  For more on the fundamental principles of “autonomation”, the Toyota Production System is the best introduction.
    3. Competing on Luxury – Every industry has conspicuous consumption.  For products, these are the premium buyers and early adopters.  For services, this is the “concierge treatment”.  Typically, you’re combining both tactics when competing on luxury – creating the most pampered experience for the luxury consumer.  Mobile solutions in this enterprise space should focus on enabling maximum attention to the consumer, and assist in consistency of the consultative nature of the employee workflow.


This high-level overview of how to apply Porter’s Five Forces to your plans for Enterprise Mobile Solutions should be a conversation starter.  If you specific questions about your industry context, target market, or what custom enterprise solution would be right for you, reach out at

Lean Principles for Agile Stakeholders

The Problem:

Last week, a colleague and I were discussing the gap in information and training materials surrounding a commonly reported challenge in agile product delivery: Stakeholders who have no experience succeeding with agile.

In Defense of Stakeholders:

The “stakeholder” role in Scrum has no training class.  This is because the “stakeholders” in Core Scrum is not a role, it is a symbol that signifies “that which causes demand-backlogs”.  There are multiple ways this emerges in agile processes:

  1. Core Scrum:  The “Heroic” Product Owner is also the Business Owner.  The stakeholders are paying customers.  Here, stakeholders don’t need training, the need a voice.
  2. Single Organization, Multiple Programs:  The “stakeholder” is one or more Product Marketing Manager that plans and advertises what the delivery organization with create.  The Product Owner must drive heijunka or “level loading” to balance out the demands that can be intelligently fulfilled by the teams available.
  3. Vendor Organization, Multiple Clients:  The “stakeholder” is one or more decision-makers for one or more external clients.  The Product Owner is plays a consultant role, facilitating prioritization and backlog decomposition.
  4. Large Scale Scrum:  The “stakeholder” is a business owner for single emergent product offering delivered by multiple teams.  The Product Owners either become specialists on specific features or may be responsible for specific platforms.

Why is there no “role” for the stakeholder?  Let’s define what a “role” is:

Unlike a position or a title, a role is the single-most important “thing” at the confluence of responsibility, empowerment, and accountability.

In each of the scenarios above, the stakeholder is not responsible for the product, has not been empowered to produce it, or does not have final accountability for what is produced.  However, whether one or many people play the part of stakeholder, there are several Lean Enterprise concepts that can encourage alignment and effective product planning.

Lean Concepts as a Stakeholder:

The first concept to grasp in Lean planning as a stakeholder – as I discuss at length in Applying Lean Kaizen to your Enterprise Mobile Strategy – Kaizen is the process of continuously breaking down a process, removing unnecessary effort or waste, and rebuilding it as a more efficient and effective process.  In manufacturing this progression has been underpinned by technology:  specialization around tools, mechanization of movement, automation of production.  With mobile solutions, we minimize the time and effort in turning social information into actionable data.

As a stakeholder starting the kaizen journey, use these Lean principles to guide your ongoing investment in a portfolio of mobile application programs.

Just In Time

A delivery team uses “just in time” in the Scrum framework as an approach to ensuring the most valuable features are produced “next” by delaying commitment to user stories until it is necessary (Sprint Planning).  This allows the shortest possible feedback cycle between demand and supply so that the Product Owner can adapt feature delivery to the most recent information from stakeholders.  Just-in-Time is a central concept from the Toyota Production System:

Supplying “what is needed, when it is needed, and in the amount needed” according to this production plan can eliminate waste, inconsistencies, and unreasonable requirements, resulting in improved productivity.

via Toyota

Just-in-Time (and just-enough) is not only a useful principle for the delivery team, it is central to effective feature and user experience planning, at the product, program, and portfolio level.  Conveniently, your target audience is increasingly mobile-first, but mobile solutions are fundamentally Just-in-Time!  Social information becomes actionable data on demand and on the go using a highly focused and intuitive user experience.  The ability to ignite a chain reaction from 3 taps of an iPad is an incredible time and cost saving.

PRO TIP for Stakeholders:  The most important way a great agile stakeholder can encourage Just-in-Time principles is through comfort with uncertainty and an understanding of “priorities” versus “prioritization”.

  • Don’t promise more certainty than is justified by market conditions.  The mobile strategic landscape and technological environment rapidly evolves – if you have planned ahead more than six months, have realistic expectations that some of those longest-term plans and promises are likely to change.
  • Plan to Pivot – The more short-term your commitments, the easier it will be to change the plan if market demand shifts.  Over-promising long-term plans to users may restrict the ability to pivot in the future.
  • Know your industry – What level of documentation do you really need?  Do you need comprehensive documentation at the end of the delivery process for regulatory compliance?  Do you need a user manual or should that time and effort provide training and cues in-app?


From the Toyota Production System, the concept of jidoka – “automation with a human touch” means that machines are “smart” enough to identify their own failure, empowering human operators to rectify the problem before faulty parts enter the production line.  Typically, these were only tested at the end of the production line, so a single machine creating bolts for engines could make an entire day’s work unshippable!  As a stakeholder, think of features that support a safe-to-fail environment rather than a fail-safe environment.  Construction workers wear helmets because the ability to create a fail-safe environment is impossible.  Instead, the helmet reduces the overall risk of failure.  Everyone has a responsibility to be careful, but the consequences are minimized.

PRO TIP for Stakeholders:  In mobile, the ability to focus a user on completing a single workflow quickly and objectively is your goal.  This creates a powerful ability to lead subjective observation into objective judgment.  Anywhere your employee is asked to supply critical information, drive what is captured toward Business Intelligence that can inform them and your organization about decisions being made and their impact on safety and profitability.

Standard Work

Because the mobile enterprise user is able to follow an established workflow of interactions, this is a time to analyze current best practices and standardize them.  Standardizing what is done, how it is done, and consistency of output not only reduces the necessity of identifying and addressing under-performers, it creates a context for the employee in which output quality is held constant for them, reducing stress.  Even more importantly, once work is standardized with a mobile application (e.g. instead of a document template) the consistency of output and capture of Business Intelligence will allow an objective review of “best” practices, removing some of the emotion and politics from the kaizen process.

PRO TIP for Stakeholders:  One changes are identified, effective MDM enables your organization to control the shift to a more effective practice by simply releasing a new version of the software.  Build any training (using interstitial screens) and feedback (with modal feature ratings) directly into the application.

Heijunka (level loading)

The Lean Lexicon, 4th Edition defines heijunka as:

“Heijunka is leveling the type and quantity of production over a fixed period of time. This enables production to efficiently meet customer demands while avoiding batching and results in minimum inventories, capital costs, manpower, and production lead time through the whole value stream.”

For an enterprise mobile solution, it is important to know a) what element of a process is most time consuming and b) when separate applications make more sense than adding features to an existing application.  In Lean Enterprise consulting, we compare the “Cycle Time” of each process block to the “Takt Time” of the workflow.  For a mobile application, cycle time is often the time spent per screen while Takt time is the total time from launching the app to completing the workflow that would need to be achieve in order to meet productivity goals.  If any step “as is” in the workflow is exceeding Takt time, its complexity must be reduced, it should be divided into separate features, or your may need a separate application.

PRO TIP for Stakeholders:  Clearly, you will not know any of this without including analytics in your application!  The testing completed by the product team and key stakeholders already familiar with the application will not show which features are causing a bottle neck for your actual users.  Use analytics!

Minimum Viable Product

While I touched on how to plan investments in the original Minimum Viable Product in Lean Startup Principles in Custom Application Development, this is narrow view in Lean Startup theory.  Once the initial release is live, the true principle of Minimum Viable Product – meaning anything that is produced by a process, not just the “product” you intend to market!  As a stakeholder, it is important to understand that you are not driving a single minimum viable product, you are part of a process that must maintain minimum viable production.  This is why we focus final testing on the user’s value from the workflow and look for sticking points in completing the desired output.  Minimum Viable Production Planning will means that throughout the delivery cycle, every increment is the confluence of minimal effort and highest viability.  In Scrum this is represented by the Product Backlog prioritized by the Product Owner.  Working software every sprint is the ultimate test and highest priority for the Scrum team, so Sprint Planning must establish the Minimum Viable Product (Increment).

PRO TIP for Stakeholders:  The goal is not to deliver less – the goal is to invest only the amount needed for any given product increment before diminishing marginal returns begin to erode the investment.  The goal is to invest in as many high-ROI production increments as possible rather than expending immense investment on process waste.  The more you are able to align with the idea of 2-week mini-projects (Sprints), the higher the overall ROI on the aggregate product.

Applying Lean Kaizen to your Enterprise Mobile Strategy


Kaizen is a Lean principle that lays the foundation of choosing the right enterprise mobile application solution.  Loosely translated from Japanese, kaizen means “change for the better”; but this principle is bigger and bolder than tacking on an improvement to an existing structure – it is the process of continuously breaking down a process, removing unnecessary effort or waste, and rebuilding as a more efficient and effective process.  In custom enterprise application consulting, kaizen underpins the process we follow in finding the right enterprise workflow that is both proprietary to an organization’s competitive advantage while also a source of waste.  Because this seems contradictory, companies rarely ask for the application that will make the biggest difference to their organization.  In fact, the need for mobility-based kaizen is not always an easy concept to see without an outside perspective.  When a unique process is driving so much success it is often assumed untouchable and treated as though infallible.

The fear of change in an organization is powerful, especially when combined with an “If it ain’t broke don’t fix it” mentality.  Unfortunately, operational effectiveness is not strategy and either a) your competitors will overcome the learning curve disadvantage and adopt your workflow or b) a small tech-savvy startup will render the proprietary workflow irrelevant.  Adopting a technical solution to maximize your unique process will give you a proprietary edge that will not be easily copied.  Adopting an innovation mindset as a strategic position will put you permanently ahead of the pack.

So how do we find the right enterprise mobile application, even more so build a portfolio of application programs?

The 3 Gen of your Enterprise:

Lean consulting begins with finding the 3 Gen or “actuals” of your enterprise.  Kaizen is impossible without direct insight into the organization, so the three “actuals” are key in finding the right application that can succeed big and drive the adoption of innovation and mobility as a competitive strategy:

  1. The Genba – By visiting the Genba or “Actual Place” where business is done, products are built, revenue is generated, an enterprise solutions consultant can view and understand the operations that create revenue, whether in a factory, a medical facility, or a sales showroom.  Through first-hand observation, rather than conversation, so much more can be learned about what an organization does, how it is done, and why it is done.  Whiteboards and conference calls can never convey the real heart of an enterprise, the “What’s the point?” or the “What’s it worth?” so coming to the actual place is critical to building out XP User Stories that speak to the pain felt by people performing the work on account of the inefficiencies they will otherwise protect out of a fear of change.  The employees, as users, must capture real value in order to drive higher revenue and operational cost savings.
  2. The Genbutsu – If possible, a great consultant doesn’t just watch, it is even better to directly interact with the genbutsu or “Actual Thing” – the real equipment being moved throughout a hospital or the customer “hand-off” artifacts.  In Lean Manufacturing, this often focused on the actual parts being assembled, the path those parts travel in a factory, and finding ways to simplify repetitive motions, reduce unnecessary travel distances through better placement of the work stations, or reducing the complexity of a step in the process by changing the order in which pieces were added to the whole.  In enterprise mobile solutions the “actual thing” is often information and the path it takes before and after that information becomes data and drives actions that produce revenue.  Information is easily decontextualized, so minimizing context-switching in the information-data-action flow is critical.  Mobile solutions drive context-awareness that turns social information into actionable data immediately and cuts out waste.
  3. The Genjitsu – Jitsu is an art, skill, or practice, a word that evolved etymologically from the characters meaning “a step along the middle of a road”.  As a Lean consulting concept, this means we must grasp the “actual situation” as it pertains to one process as a step in an overall flow.  More importantly, we must quantify the reality as objectively as possible, separate from emotional responses due to ego, social status in the organization, or feelings of blame.  We do this by obtaining data, making hypotheses, documenting workflows, and validating assumptions.  The goal is to not only make a well-informed decision about the most valuable application that can be created, but to validate the features that will be part of it.

Once the three “actuals” are known, sources of waste can be objectively identified, solutions crafted and prioritized, and a Minimum Viable Product is determined.  For more details on delivering a Lean MVP, see my post Lean Startup Principles in Custom Application Development to see when to release and when to pivot.

Agile Priorities: Keeping Documentation Lean

Agile Transformation

If you want your agile transformation to fail, allow the development team and all supporting functional teams to focus on the waterfall deliverables and dependencies to which they are accustomed.

In “Fixed Budget, Fixed Scope? Be Agile Anyway.”  I argued that agilists, especially newcomers, must understand that the Agile Manifesto is a statement of priorities – at times, tools and interactions, comprehensive documentation, contract negotiation, and following a plan are all part of the product that is created by the process that keeps your teams in business.

In software development, this is the exception rather than the rule.  

For “core” Scrum, the proverbial “one-team-in-a-garage”, this is pretty simple.  Everyone you need is in one room.  When scaled, a delivery organization is often “compound-complex” – it is “compound” when two or more independent functional knowledge areas must cooperate and “complex” when at least one knowledge area has dependency on another (these aren’t fancy concepts, just basic grammar).  The moment a delivery process moves beyond one-team-in-a-garage Scrum, there is compound-complex value stream:

The web team and mobile team will build a user-facing experience, while the middle tier team provides RESTful services, only after sales executes the contract and the Product Owner builds the backlog; meanwhile, UX, BA’s, and QA’s will provide documentation.

In this value stream, the “Wildly Important Thing” is the software that a user will consume in order to drive revenue.

Because Communities of Practice have their own traditions and methods of proving extrinsic value, shifting their priorities is much more difficult at scale.  Plan to change the physical distribution in order to overcome the functional “clumping” that Waterfall encouraged.  Moreover, agile transformation will require finding and eliminating the agency dilemma of managers who built their kingdoms around waterfall values.

Resolving Wasted Effort

If agile at scale has not improved company-wide quality and velocity, it is likely due to waste in the overarching process – you must remove any activity that does not drive value creation that a user consumes and the business will capture.  This is the central rule of the User Story – if it does not make a difference to the user (and occasionally the owner) it is wasted energy, a distraction.  You find this clearly stated, often, in Jeff Sutherland‘s various descriptions of “Bad Scrum” – without delivering working software that matters to the user an organization will be stuck in a self-reinforcing cycle of inefficiency and ineffectiveness.  No one is making a difference in the world, selfishness increases, velocity never improves, no software is delivered.

For a compound-complex process to stay agile, the Lean principles of Just-in-Time and Just-Enough to must be applied to all forms of documentation – business rules, persona descriptions, wireframes, UI designs, sliced assets,  value mapping, technical constraints, market conditions – all are a means to pleasing the user, not the end goal (software that a user values).  The User Story is the cornerstone of efficient, effective product delivery because it is a “reminder of a conversation” about a result from which a user will derive value.  For some teams, a set of wireframes can all but replace “cards”.  An image of a login screen is sufficient to drive the conversations a team needs to have about client-side validation, security requirements, and authentication method.

The Product is Everyone’s Deliverable

To move to next-level agile, at scale, an organization will need to blur its understanding of “business planning”, “requirements documentation”, and “UX Design”.  While there may be a need for full, distinct teams of experts at each of these disciplines, these approaches to defining what the software will be should converge on a single goal – building great software.  A popular article on Lean for UX, Lean UX: Getting Out Of The Deliverables Business leads with this statement:

Wireframes, site maps, flow diagrams, content inventories, taxonomies, mockups […] crystallized the value that the UX discipline brought to an organization. Over time, though, this deliverables-heavy process has put UX designers in the deliverables business — measured and compensated for the depth and breadth of their deliverables instead of the quality and success of the experiences they design. Designers have become documentation subject matter experts, known for the quality of the documents they create instead of the end-state experiences being designed and developed.

Having started my career as a Business Analyst, this is painfully resonant.  It is unfortunately easy for management move from training “the tools of the trade” – spreadsheets, slide decks, requirements documentation, technical specifications – to judging the tools independent of the software to be delivered.

Here are a few rules to follow to get UX, UI, and BA’s out of the deliverable business and into the well-formed team:

  1. Never say “final sign-off” regarding artifacts – whether working for internal stakeholders or external clients, if software is the deliverable, it is the only item requiring sign-off.  Every other artifact is is a tool for getting working software in the hands of users.  Make sure you are “responding to change” at the request of real users of working software – no amount of planning or documentation will survive contact with the user.
  2. UX/UI Refinement should mirror Backlog Decomposition – Prioritizing working software does not mean there is no product roadmap, it does mean that time and resources should only be invested in the software most likely to be built in the near future.  This starts as a process diagram of all possible Epics that could be built, and how the user gets to each of these features.  The upcoming 2 to 3 features should have relatively actionable wireframes.  The team should feel certain about the UI design of the current and next sprint.
  3. Create paradigms, not screens – the most important expectation to break is the annotated UI composition per screen.  Some screens absolutely benefit, many do not.  A well-formed team should have enough shared understanding of technical constraints, design paradigm, and business context that a conversation is sufficient to drive the whiteboard-to-working software process.  Wherever possible, establish a paradigm for a product is intuitive to build.  If it isn’t intuitive to the developer without extensive documentation, how likely is is it the user will find it intuitive?
  4. Document releases proactively, but in accordance with your level of certainty – If there is a product that will require knowledge hand-off, a support guide, or other formal documentation, maintain the tension between what makes sense to proactively document (so you don’t spend a full week post-release) while wary of what will change (likely anything more than a sprint in the future).

Following these rules, the software development process in an at-scale, compound-complex organization can focus on the user enjoying a working product.  Aligning vision and expectations along the agile priorities will remove fear of failure or criticism, increase team velocity, and result in the best possible products.  Then, your team, business, and enterprise can pursue kaizen – and the real magic can happen.

What Westside Barbell has taught me about Scaling Agile

Agile Portfolio Management:

There is a new way of doing things in delivering a complex product portfolio.  It focuses on delivering value both incrementally and iteratively.  It utilizes empirical process control and hypothesis-driven planning.  It utilizes test-driven development in both convergent and emergent delivery, even when budget and scope are fixed.  It utilizes a Lean kaizen approach to maximize velocity.

This philosophy is by nature, object-oriented and modular.  No one framework is right for every product, so it is highly customizable.  It may sound new to you, but it has been around for quite awhile.  But wait – I’m not talking about Agile, Scrum, or Lean software principles – I’m talking about Westside Barbell’s approach to powerlifting.

Waterfall Weightlifting:

Powerlifting is a sport in which the lifter competes for the highest single-repetition maximum in the Squat, Deadlift, and Bench Press for their weight class.  The traditional approach to training powerlifters relied on linear periodization – a method still very valuable for beginning athletes because each phase builds on the last while progressing toward competition-specific strength.

At a basic level, here is a 12-week competition plan:

3 Week Hypertrophy Phase (muscle size, stamina): Sets of 12 to 15
3 Week Strength Phase (movement form, ability to move weight): Sets of 5 to 7
3 Week Power Phase (Explosive speed, maximum weight at progressively higher volume): Sets of 1 to 3
3 Week Peak & Rest (Highest weight, lowest volume): Sets of 1 to 3, tapering off to a few rest days
Competition: Three chances to get three lifts correct, competing against others who are doing the same

As agilists, this correlates perfectly with the “waterfall” approach we try to leave behind:

Hypertrophy phase: Business planning, creative design, and thorough documentation
Strength phase: Database layer, middle-tier
Power phase: Client-side logic, front end development
Peaking phase: Testing, beta release, focus group and stakeholder reviews
Rest days: Code freeze and marketing
Competition: Release to the market, in which you may not recover from failure

Then the lifter starts over.  If there was a big loss (e.g. an injury) pre-competition, the weight lifter might not compete at all – just like software project that gets cancelled after key engineers leave or technical debt gets too high to meet the release date.  More problematically, if there is a big loss or injury at the competition, the lifter may never compete again- just like the software team with a botched release that gets “reassigned” or laid off.

Repeating the Cycle:

The weightlifter who perseveres, win or lose, still has big “waterfall” problems.  The lifter rests a little and repeats the linear progression cycle, an exercise in bodily context-switching.  When the next hypertrophy phase starts post competition, most of what was developed in the previous cycle is gone!  The same is true of each phase.  When the lifter resumes focus on 3-rep max, some hypertrophy and stamina is lost.  As the lifter peaks for competition, the 1-rep max may increase but the 5-7 rep range decreases.  Studies show that after a few weeks in the subsequent hypertrophy phase, up to 15% of single-repetition strength is lost.  The disconnect between foundational planning (by increasing stamina and size) sacrifices a considerable amount of value captured (ability to perform the same single-rep max).

What does this specificity-switching cost the lifter?  As a beginner, not very much – any work will improve size, conditioning, and maximal strength, and fantastic progress can occur.  The discipline of repeating the movement pattern likewise increases maximal strength even with little planning.  However, once the lifter goes from a beginning athlete – a time when nearly anything will improve the lifts – to an intermediate athlete – subsequent peaking phases will see little or no increase.

The process requires disruption if total stagnation is to be avoided.

If this sounds like delivering software in waterfall, it is!  As you read this quote from a strength coach describing the “waterfall” lifting approach, think about the Waterfall PMO:

Having now gotten away from this type of training and looking back as an outsider, I can see where the program is lacking and why I had so many problems. I used to feel it was the only way to train (mostly because it was all I ever knew). It was also the only type of program for which I could find a lot of research. Some of the limitations to this linear style of periodization include:

  • It’s a percentage-based program
  • It starts with a high volume
  • It only has one peak
  • Your abilities aren’t maintained
  • The program has no direction to the future

– Dave Tate via

Here are the parallel problems we see with waterfall:

  • “It’s a percentage-based program” – accounting-based statistical process controls are applied to an emergent system
  • “It starts with a high volume” – a significant portion of the budget is spent planning, designing, and fighting about features that no user wants (and if the project is cancelled, 100% of this sunk cost never drives user- or owner- value capture)
  • “It only has one peak” – A major release attempts to market itself to all segments simultaneously and a flop may kill the product line completely
  • “Your abilities aren’t maintained” – once the waterfall project plan is set in motion, market evaluation, user feedback, and stakeholder review is non-existent
  • “The program has no direction to the future” – a waterfall project plan is delivered based on the knowledge available at the beginning of the project when the least is known and has no intrinsic method of looking to the future relationship between the user market that might exist and the software that could be produced.

Westside Barbell’s “Conjugate Method”

The Conjugate Method attempts to balance all phases across preparation for competition. At the “enterprise level” three movement patterns are continuously tested as the measure of the process. At the “business level” a new variation of a similar movement may become the focus for 3 to 5 weeks (e.g. training rack pulls instead of full deadlifts when “lock out”, the upper portion of the movement, is the weak link). At the “team level” (the lifter + coach), the two-week sprint has a consistent set of ceremonies and artifacts (workout plan, workout log, the workout, etc).

Here is an example:

Week 1
Monday – Max effort lower body day (squat + low back + hamstrings), focus on strength and power
Wednesday – Max effort upper body (bench press), focuses on strength and power
Friday – Dynamic effort lower body (squat, deadlift), focuses on speed and hypertrophy
Sunday – Dynamic effort upper body (bench press), focuses on speed and hypertrophy
Week 2
Monday – Max effort lower body day (deadlift + low back + hamstrings), focus on strength and power
Wednesday – Max effort upper body (bench press), focuses on strength and power
Friday – Dynamic effort lower body (squat, deadlift), focuses on speed and hypertrophy
Sunday – Dynamic effort upper body (bench press), focuses on speed and hypertrophy

This correlates nicely with “core” Scrum concepts:

  1. Maximal strength is tested every week – working software every sprint
  2. The metric (1-rep max / story points delivered), is improved (strength / velocity over time), through hypothesis and experiments (empirical process control)
  3. The entire body is trained for size, stamina, strength, and power per every week – vertical slicing and user stories
  4. The lifter gets to experiment with new exercises without fear of wrecking a 15-week cycle – sprint retrospective, sprint planning
  5. The coach focuses exercise planning on addressing weak points – a ScrumMaster, removing impediments
  6. The Power Lifting competition is not a unique event with a long lead time – working software every sprint, TDD, XP, continuous integration and release

Now the lifter, like our Scrum team, gets to plan, experiment, and deliver often.  The overall roadmap (Lean + Scrum) might have a basic end-game or vision (increasing 1-rep competition max performed on 3 lifts the same day is equivalent to convergent product delivery), but planning only looks forward up to 5 weeks, commitment at 1 to 2 weeks.  Likewise, the lifter and coach is always looking at the most recent data, the newest lessons learned, and quickly reacts to whether a behavior, practice, or process should be continued or not – just like the Product Owner, ScrumMaster, and Team are always planning and executing based on the most recent market and team data.

Applications to the SDLC:

Now we can extend the metaphor and draw conclusions.  The powerlifter’s body equates to a complex large-scale digital portfolio.  The lifter needs to increase value three programs that focus on convergent product delivery while also developing several programs that utilize emergent product delivery.  In waterfall these two program methods are separated by functional division and project lifecycle, in conjugate (Scrum) these two are handled in tandem.

For the powerlifter, the three convergent products are squat, deadlift, and bench press.  Quality must stay constant or the increase in value does not qualify.  The same is true in software products – adding a high-value feature while allowing a 50% increase in crash on launch is absolutely unacceptable.  Your users will disqualify you!  Whether your have a three-application enterprise CRM program or a three-iOS app consumer program (see LinkedIn or Facebook as examples), adding an exciting feature to an app that causes mass user drop out is a risk no business can tolerate in today’s market.  The competition is too fierce, barrier to entry too low; someone will blow you away.

At the same time, the powerlifter needs to maintain several emergent delivery programs, some for function (increasing grip strength), some for fun (increasing bicep size).  Ongoing workout plans, building size, stamina, and maintaining joint health, addressing weak points by focusing on a new accessory exercise for 5 weeks – all of these priorities must be balanced and evolved.  Keeping a workout log is the only way to be sure that exercise volume, intensity, and density are increasing.  The relationship between the convergent product value and the emergent product investment is the only metric rationally applicable.  The same is true in software delivery.  Emergent-delivery programs like R&D, marketing, UX, product planning are all critical to the health and success of the portfolio as a whole – but the end goal must be clear.

  • Over-planning and under-delivering is not acceptable.
  • Over-researching and under-user-pleasing is not acceptable.
  • Over-designing and under-testing is not acceptable.
  • Over-marketing and and under-releasing is not acceptable.


The Conjugate Method as an analogy for Agile, Scrum, XP, and Lean at scale works for me because I love lifting.  I realize it may not be right for you, especially if neither agile or weightlifting are familiar territory.  So, like everything, find how this applies to your life so that you can find inspiration in ordinary – then start a conversation about it.  I’m happy to discuss anytime:  224.223.5248

Incremental AND Iterative Product Delivery

Highly-effective agile teams deliver user-valuable software incrementally and iteratively. What’s the difference?

Incremental Delivery:

An increment is “something added as part of a series of regular additions.” Scrum relies on incremental by employing the user story (originally promoted by Extreme Programming and written about extensively by agile champion Mike Cohn).  The user story is the fundamental building block of how sprint commitments in Scrum are managed.  Incremental delivery relies on intra-sprint-based “vertical slice” delivery, in which new features are divided up like sashimi – as thin as the skill of the chef can accomplish.  Effective vertical slicing is a best practice in Scrum and XP because incremental delivery minimizes uncertainty in any given sprint and release, throughout the development of a complex product.  Vertical slices follow the INVEST rules for user stories:

  • Independent, end-to-end, “shippable” increments of the emergent whole.  The slice could be delivered fully tested without any other product increment and create value for the user or owner.
  • Negotiable, in planning and expectations with users and stakeholders, allowing delayed incorporation of enhancements or, if a major pivot becomes necessary, easily removed from the product roadmap (without previous over-engineering, over-planning, or over-documentation).
  • Valuable to the user or owner, likely in a way that is sufficiently noticeable that it is monetizeable.
  • Estimable by the delivery team because the User Story does not generalize or hide uncertainty.  An inestimable story is often an Epic.  It is either complex enough to warrant a technical spike or compounds enough feature work that it should be broken into independent, smaller, user stories.
  • Small enough to be estimated by a team, with certainty, and deliverable fully-tested within a single sprint.
  • Testable by virtually any team member because the expected outcome is qualitatively or quantitatively noticeable (as part of its being value) to the target user.

The INVEST method for user stories ensures that planning and development occur just-in-time so that the emergent product can regularly evolve in response to changing stakeholder demands.  More importantly, in the fast-paced markets in which agile/scrum/lean/xp programs compete today, incremental delivery maximizes the freedom to release the Minimum Viable Product and pivot in a new direction based on real-time feedback from users.

Iterative Delivery:

An iteration is “a repetition of successive approximations in which progressive versions evolve to a desired level of accuracy.”  Iterative delivery relies on an openness to prioritizing value that is good-enough rather than perfect.  The perfection of a single feature or a single screen, as defined by one Stakeholder, Architect, UI Designer, or Engineer and taken out of the context of the overall emergent product leads to unnecessary delays, lack of decisiveness, and delayed time-to-market and ROI.  The Scrum team avoids working in a silo through collaboration, entrusting the Scrum Product Owner with accountability for decisions.  In contradistinction, over-analysis and churn prior to meaningful user feedback is utterly inefficient and ineffective.  Thus, while Just-in-Time vertical slices maximize the freedom to bring Lean MVP’s to market and pivot as appropriate, iterative and “just-enough” Lean delivery is equally critical to ensure that increments can evolve based on user feedback instead of non-plans made due to (unnecessary) fear of scrutiny.

Connect With Me:

LinkedIn       Twitter

Enterprise Application Portfolios: Getting Started

Enterprise Applications:

If you are not using custom-crafted enterprise applications yet, investing in proprietary tools exclusive to your organization is the key to taking Operational Efficiency to the next level – creating competitive advantage that is not easily reproduced by your peers.

As the leader of your company, you have built a successful business model, established strategic positioning, found a niche market, and your revenue relies on coopetition.

If you have not invested in a proprietary portfolio of web app and mobile app programs, the unique sets of workflows driving your niche revenue has enormous opportunity for streamlining and standardizing.

“Mobile is becoming not only the new digital hub, but also the bridge to the physical world. That’s why mobile will affect more than just your digital operations — it will transform your entire business.”

– Thomas Husson, Vice President and Principal Analyst at Forrester Research

Getting started:

  1. Watch your organization:  At every level of the organization there are activities that are constantly repeated that could be easily automated.  Part of the success of the Lean philosophy in the Toyota Production System was Kaizen – workers would be assigned a place to stand for the day watching for inefficient workflows.  Luckily, throughout your organization there is likely someone already noting these inefficiencies, eager to provide that information.
  2. Listen to your customers:  When you miss a key opportunity, is “timing” a consistent reason?  If that opportunity relies on a complex process, focus on a technical solution instead of assuming there is a human problem.  Find a way to gather feedback that can be aggregated – any trending complaint or suggestion may be key insight into an opportunity in workflow efficiency and effectiveness.
  3. Look in the mirror:  Many of the roles and routines – even in a large organization – seem very unique to a small group.  Despite this, look at your own behavior patterns throughout the day.  Whether you are a CEO or Mid-Senior manager, if a tool or process you rely on is inefficient and shared across the organization, your pain is a pain everyone most likely shares in.

Connect With Me:

LinkedIn       Twitter