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?

---

Jidoka

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.