Lean & mean innovation machine • 3
In the world of software/product development, waste refers to any team activity that does not add value from the customer’s perspective. By continuously identifying and eliminating waste, agile teams can dramatically boost productivity and improve quality of work. What are the implications for x-functional teams working in the fuzzy front-end of service innovation?
In this blog post, I will introduce three types of waste that might may have an impact on quality of work in upstream service innovation projects. The following two blog posts will cover the remaining six types of waste.
Wastes 1–3 in upstream innovation projects
W1. The cost of incongruity. The team is creating project deliverables, assets, and solutions (for value creation, facilitation, and co-creation) that do not seem to fit organizational quests, cultures, and/or capabilities.
W2. The cost of irrelevance. The team is creating deliverables, assets, and solutions that service actors (customers, frontline employees, backstage teams, etc.) do not seem to need, want, or use.
W3. The cost of complexity. The team is creating project deliverables, assets, and solutions that service actors find too complex to understand, implement, adopt, adapt, and/or reuse.
Three big reasons why W1–3 may occur in upstream projects
► Suboptimal ways of working (inspired by Bau, 2020; Sedano et al., 2017; Mersino, 2015; Martin, n.d.; The Global Metacognition Institute, n.d.)
Lack of clarity. Unclear/shifting project scope, purpose, goals, and priorities. Unclear/shifting project roles and responsibilities. Ambiguous/volatile market conditions.
Lack of contextual awareness. Flawed/insufficient knowledge of long-term trends, external environment, organizational quests, organizational culture (and sub-cultures), stakeholder needs, etc.
Lack of empathy. Flawed/insufficient knowledge of service actors (due to arrogance, erroneous assumptions, blind spots, limited research, flawed personas, instable markets, flawed/biased data, etc.).
Lack of critical thinking. Inability to question/challenge briefs, problem statements, hypotheses, requirements, constraints, boundaries, assumptions, labels, etc. – even in the light of new/overwhelming evidence.
Lack of lateral thinking. Inability to generate and screen multiple alternatives (perspectives, options, ideas, etc.) throughout the process.
Lack of simplicity. Inability to address scope creep, verbosity, cluttered thinking, conflicting perspectives, bloated ideas, convoluted segmentation, fuzzy target groups, feature creep, etc.
Lack of modularity. Inability to create solutions based on the notion of interchangeable modules and shared platforms.
Lack of feedback. No/slow/insufficient feedback from project owners, sponsors, and stakeholders during the project.
Lack of metacognitive skills. Inability to identify gaps in knowledge and understanding inside and outside the team. Inability to critically evaluate the validity, credibility, and reliability of knowledge & information sources. Inability to continuously reflect, learn, and adapt during the project. Etc.
Lack of knowledge transfer. No/limited knowledge transfer between team members, between teams, and between team and organization.
► Internal barriers to adoption (inspired by Abernathy & Clark, 1985; Johnson & Scholes, 1999; Day, 2007)
Lack of institutional & technical knowledge. Flawed/insufficient understanding of the organizational capabilities and technical requirements required for the delivery, implementation, and maintenance of envisioned solutions.
Lack of suitability. Project owners feel that envisioned solutions are not aligned with organizational purpose, vision, goals, strategies, portfolio strategy, etc.
Lack of familiarity. Project owners feel that envisioned solutions are distant to existing business models, technical competencies, and markets.
Lack of feasibility. Project owners feel that the organisation/ecosystem lacks the necessary resources and capabilities to utilize project deliverables and deliver envisioned solutions.
Lack of acceptability (in terms of the risk-reward balance). Project owners feel that the chance of success is too low and/or the projected impact is not substantial enough (see blog post Get the balance right! • 5).
Lack of motivation/commitment. No/flawed/insufficient onboarding, training, and incentivization of onstage employees and backstage teams. No shared sense of purpose and meaning in either the work or the impact delivered.
Lack of urgency. No/limited sense of urgency for change across the organization. No purpose-driven, aspirational vision (North Star) that can provide meaning, focus, and direction.
► External barriers to adoption (inspired by Rogers, 2003; Linares, 2021)
Lack of simplicity. The new solutions are perceived by change agents, influencers, and service actors to be difficult or challenging to understand, specify, buy, use, store, and recycle.
Lack of differentiation (or relative advantage). The new solutions are not perceived by change agents, influencers, and service actors to be different or superior to existing solutions in the market.
Lack of compatibility. The new solutions are not in harmony with prevailing norms, values, and beliefs. The new solutions do not fit seamlessly into existing lifestyles and experiences. The new solutions do not fit with existing ideas, networks, and solution ecosystems.
Lack of trialability & observability. The new solutions are deemed difficult to try, test, and experiment with (before purchase). The new solutions (and/or outcomes) are not visible, detectable, or perceptible to non-users.
Lack of familiarity. The new solutions may require onboarding, training, education, and incentivization (of change agents, influencers, and service actors) to encourage uptake and optimize usage.
Lack of representation & equity. The new solutions intentionally or unintentionally exclude marginalized groups from gaining access (equity of access), engaging fully in the end-to-end experience (equity of experience), or benefiting equally from potential outcomes (equity of impact).
Wastes 4 to 9 will be covered in the next two blog posts.
References
Abernathy, W.J. & Clark, K.B. (1985). Innovation: Mapping the winds of creative destruction. In: Tushman, M.L. & Moore, W.L. (Eds.), Readings in the management of innovation (2nd ed.). Harper Business.
Bau, R. (2020). Nine types of waste in software development [unpublished]. Assignment in PROJ_PMI 403-0. School of Professional Studies, Northwestern University.
Day, G. (2007, December). Is it real? Can we win? Is it worth doing? Managing risk and reward in an innovation portfolio. Harvard Business Review.
Johnson, G. & Scholes, K. (1999). Exploring corporate strategy. Prentice Hall.
Linares, M. (2021, April). Frameworks for measuring product inclusion and product equity. Medium.
Martin, T. (n.d.). All you need to know about modularization. Modular Management.
Rogers, E.M. (2003). Diffusion of innovations (5th ed.). Free Press.
Sedano, T., Ralph, P., & Péraire, C. (2017). Software development waste [Conference paper]. ICSE 2017, Buenos Aires, Argentina.
The Global Metacognition Institute. (n.d.). What are metacognitive skills?
3/6
