“A seed needs a fertile soil to grow.” ― Lailah Gifty Akita

What is the foundation?

The purpose of FlashDev™ is to help organizations flourish into a more rapid and responsive organization with respect to hardware development. It starts with asking “why” we should change which is covered by the Goal. Then, like seeds to plant, FlashDev™ provides several artifacts and behaviors like value based flow, agile team, model based design, etc. are covered in the 4 pillars of the framework: Flow, Virtual, Physical, and Organization. For these and future seeds to grow, you need a fertile soil which is called the foundation and in essence is a fit-for-purpose organizational culture, or, looking from an individuals perspective, a fit-for-purpose mindset. Of course, this all doesn’t grow overnight, it requires a lot of care and attention which is covered by The Journey.

Edgar Henry Schein, an American organizational psychologist, has defined organizational culture as “a pattern of shared basic assumptions that the group learned as it solved its problems of external adaptation and internal integration, that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems.“
Below you see the model he created which has three levels: Artifacts, Espoused values, and Basic assumptions. Artifacts like office layout and behavior are visible, tangible or otherwise easily identifiable to anyone. The espoused values are often a bit more difficult to identify. They are the answers to “why do you do what you do?” They may be written down in company statements and can be inconsistent with what is actually observed because of window dressing or they are projections of a desired future. The basic assumptions are the deepest level of the culture. They are hard to identify, even for insiders. They originate from the values, beliefs and assumptions of the founders and other influential people in the organization, that have led to the organizations success in the past so must be ‘true’. When starting a transition, they would consist of the aspired values and principles that over time, in case of improved result, will lead to basics values and principles.

There are no ‘wrong’ or ‘right’, ‘ better’  or ‘inferior’ cultures, only can there be a wrong fit to whatever the organization is trying to accomplish in a certain environment. So when circumstances change, you may need to change culture.

Competing Values Framework

The Competing Values Framework (CVF) emerged from research to identify the organizational effectiveness criteria (Quinn & Rohrbaugh, 1981). It is a very useful model for understanding organizational culture by its qualities, strength and effectiveness in a given environmental situation, as well as guidance for cultural change. The framework has two dimensions. The first is the organizational orientation, ranging from internal to external, second is the organizational preference for structure, ranging from stable/controlled to flexible. Plotted on two axis these form a matrix where one can identify four different types or models of organizations.
The internal orientation is about collaboration, development, integration of activities, and coordination, whereas the external orientation is about acting upon market developments and customer needs, technology developments and competitor actions, focus. Control is about clear structures, detailed planning, budgets, and predictability, whereas flexibility is about rapid adaptation to changing circumstances via flexible structures and funding, rolling wave planning, and progressive insight.

The Human Relations Model, or “Clan”, is a friendly and cohesive working environment, like a large family. Its all about people first, needs of clients, morale, loyalty, involvement, empowerment, engagement, mentoring and coaching, teamwork, participation, partnerships, conflict avoidance, long term change and consensus. You typically find this in health care, education, non-profits.

The Open Systems Model, or “Adhocracy”, is a dynamic and creative working environment. Its all about readiness, risk taking, innovation, experimenting, individual initiative, freedom, entrepreneurship, visionaries. You typically find this in technical start-ups, technology-driven industries, and disruptive services.

The Internal Process Model, or “Hierarchy”, is a formalized and structured work environment. Its all about procedures, formal rules and policies, efficiency, first time right, smooth operation, stability, results, reliable delivery, cautious, precise analysis, careful decision making, incremental change, continuous and detailed planning, and low cost. You typically find this in medical devices, medicine, military, government, banking and insurance, transportation.

The Rational Goal Model, or “Market”, is a results-based no-nonsense work environment. Its all about targets, deadlines, getting things done, fast change, fast decisions, solve problems, competition and rivalry, goal focus, high expectations, demanding and commanding, drive to win, reputation, success, customer satisfaction, shareholder value, market dominance, competitive prices, outsourcing. You typically find this in consultancy, accountancy, sales and marketing, services, manufacturing.

Depending on their history and most prominent environment, a predominant culture model can usually be identified. There is no best model. Each model has qualities and in order to be successful, an organization will need a fit-for-purpose mix of the four models. Looking at these through the lens of Ofman’s Core Qualities Model, we know that some are the organizations core qualities, the more natural culture defining qualities. By overdoing these, they turn into pitfalls. For instance, flexibility turns to capricious, control to rigid, internal focus to navel-gazing, and external focus to disconnection. and some are challenges. The qualities that do not come so naturally and one has to learn and master, are called challenges. When we want to change culture, we typically need to unlearn our pitfall behavior and learn new behavior by facing our challenges. Like riding a bike for the first time, you will suck at it and feel very uncomfortable. As these are not core values they may always remain somewhat challenging and it’s easy to overdo it leading you to so-called allergies, the too-much that you typically dislike but serves as a good indicator of where you could learn and grow.

Generative culture

Ron Westrum proposed a very interesting view on organizational culture types and how they mature. For getting the most out of agile (hardware), a generative culture is what we should strive for. According to Ron Westrum: “In a generative organisation alignment takes place through identification with the mission. The individual ‘‘buys into’’ what he or she is supposed to do and its effect on the outcome. A sense of ownership is a natural consequence of identification with the leaders and the team. Accordingly this person will try harder for and care more about the outcome.”

Read more in this paper by Ron Westrum: A Typology of Organisational Cultures (Researchgate).

Mindset

FlashDev™ is founded on Lean, Agile and Systems thinking. Lean to guide delivery of benefits to society and value to individuals while eliminating waste. Agile to explore complexity and quickly respond to changes. Systems thinking as a holistic approach to complex systems. On top of this an agile hardware specific mindset enabling us to face the many additional challenges.

Lean mindset

1. Define Value – Before we can deliver value we first need to understand what value is. According to Cambridge Dictionary, added value is an improvement or addition to something that makes it worth more. According Reinertsen the value added by an activity is the change in the economic value of the work product, or in other words, would the customer be willing to pay more? This could apply to a brand new feature, but just as well to something like reduced fuel consumption or cost price more accurate delivery time, and even to a risk assessment leading to higher reliability confidence. Especially for hardware development it is important to go back to the basics of what value actually is. Another way of looking at value is through the eyes of the main stakeholders: customers, business and employees.
   Customers want a development organization with a high level of service delivering high quality products. Employees want to be proud of what they deliver (craftsmanship), work on something that matters to them, have fun doing it, etc.
   The business cares about return on investment and growth, how robust and responsive the organization is to changes, etc. Of course, there are strong relations between them: happy people produce more and better, happy customers buy more and make proud, happy business invests in people and customers.
2. Map Value Stream – Typically there are many steps (activities) in between identifying value and actually delivering it and processing the feedback and learnings. These steps in between are known as the value stream. Value stream mapping is a very simple yet powerful technique to visualize the value stream and identify improvement opportunities. By identifying the steps and what their contribution is in terms of added value and non-added value, known as waste, we can identify opportunities for improvement. Waste should be eliminated or reduced as much as possible. In hardware development we typically find a lot of waste in dependencies and long lead times.
3. Create Flow – We prefer continuous flow over irregular start-stops and bursts. Flow provides us shorter cycle times with lower cost of delay and higher motivation, lower variability, better quality, lower risk, and less overhead. Removing waste is one step, but for good flow we need to do more like: visualize the flow and queues, split/splice value, reduce batch size, reconfiguring process steps, limit and manage work in process, reduce rework, leveling out the workload, T-shaping, etc.
4. Establish Pull – One of the biggest wastes comes from pushing work into a system. It leads to high work in process causing task switching and inventory waste. A pull based system works backwards and is based on actual need rather than forecasts. For instance, a team will only pick up new work when work at hand is completed, or in case of a blockage, when work in process limit (capacity) still allows for it. This repeats itself further upstream and prevents new work inserted into the system before old work flows out.
5. Pursuit Perfection – In lean the pursuit of perfection is the foundation for a mindset of continuous, relentless and never ending improvement. Many times when we address one problem, we tend to find new ones. Instead of letting this demotivate us, we should celebrate the improvement and be grateful for finding a new opportunity. As Vinci Lombardi ones said “Gentlemen, we will chase perfection, and we will chase it relentlessly, knowing all the while we can never attain it. But along the way, we shall catch excellence.” Most times this means a little better every day. Sometimes however, when we reach the limits of the path we chose, we need to transition to a path that takes us to a next level. For more details see the section on Kaizen, Kaikaku and Kakushin.

Agile mindset

1. Customer Satisfaction – “Our highest priority is to satisfy the customer through early and continuous delivery of valuable product.” This is about early as in rapid, short cycle time, minimum viable/marketable to keep the time between request or idea and delivery short for low cost of delay, but always as part of the trade-offs with costs, quality and risks. This is also about delivering continuously where the Lean Mindset helps us a lot. And it’s about customer satisfaction being highest priority which means we need to identify what our customers want and need in short learning cycles of orient, observe, decide, act (OODA). 
2. Welcome Change – “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” Instead of crafting a detailed plan at the beginning where we have least knowledge and understanding and then stick to this plan, we acknowledge that both we and our customers need to learn as we go go and adjust to those learnings. Depending on the uncertainty and risks we use a more intentional or emergent plan with typically a mix of the two.
3. Deliver Frequently – “Deliver working product frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” As they say “the proof is in the pudding” meaning we wont know if something works to the satisfaction of the user until we deliver and let them try and validate it. The longer we ‘stay under water’, the bigger the chance of waste. Short feedback cycles provide our customer and ourselves with information and learnings, early earnings and motivation.
4. Business & Development – “Business people and developers must work together daily throughout the project.” Typically many people are involved in development and many decisions need to be made. By building quality in, providing clarity of intent, and trusting the developers, many of these decisions can be decentralized increasing speed and motivation. When interaction between business and development is needed, e.g. high impact decisions, alignment, clarification, and solving blockages, we should create frequent interaction and collaboration. 
5. Motivated Team – “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” There is still quite a lot of debate around extrinsic and intrinsic motivation. In modern workplaces it’s becoming more common to motivate people intrinsic (via purpose, mastery, autonomy) instead of extrinsic (‘carrot and stick’) as for complex tasks rewards can fail to improve people’s engagement with these tasks, and may even damage it. However, in many companies extrinsic motivation still is deep-rooted, particularly among older employees who are accustomed to it.  
6. Face-to-Face – “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” First of all, face-to-face allows others to see facial expression, voice inflection, emotion, body language which conveys a lot more information and helps the person to understand the message in better way. Also, it allows direct interaction meaning people can respond immediately in case of unclarity, adjust their tone of voice, throw a little humor in, etc. which generates more mutual understanding, trust and relationship building. When conversing face-to-face it is easier to keep all active in the conversation, especially in group conversation. When co-located, it enables osmotic communication, meaning that people in the vicinity, consciously or unconsciously, pick up relevant information from background conversations. When using face-to-face in combination with for instance a whiteboard to draw pictures and mind maps, etc., it becomes even better. Face-to-face isn’t always better though. Sometimes people need time by themselves to think and put their thoughts to ‘paper’ may help. It could still be an option to get back face-to-face later of course. It can also be that the effort of bringing people together outweighs the value of the conversation.
7. Working Product – “Working product is the primary measure of progress.” As they say “the proof is in the pudding” meaning we wont know if something works to the satisfaction of the user until we deliver and let them try and validate it.
8. Sustainable Pace – “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” For personal health and happiness as well as business health, we need to prevent stressful bursts of work (burnout, exhaustion) and long periods of boring work (bore-out). Instead, we look for short cycles of interesting work at a sustainable pace. To keep it sustainable, we may use work-in-process limits, built in quality, developer driven planning, etc.
9. Good Design & Technical Excellence – “Continuous attention to technical excellence and good design enhances agility.” To make sure we can be agile now and in the future, we need design that supports it. For instance, it should be easy to make modifications locally or automatically. The so-called cost of change (CoC), the cost involved to make a change, should remain low. This starts with pro-active intentional design: modular design, overdesign, standardization, automation, etc. And emergent design as we progress and learn: clean-up, refactoring, redesign, etc.
10. Simplicity – “Simplicity – the art of maximizing the amount of work not done – is essential” To be able to respond and deliver fast, we should not get entangled in time consuming big efforts which tend to grow even further by snowballing and future-proofing, Instead, we should focus on and build what is most important and imminent in small simple steps to prevent spending a lot of effort building something that has little or no value.
11. Self-Organization – “The best architectures, requirements, and designs emerge from self-organizing teams.” Self-organized teams set their own goals based on maximizing value and as a team do what it takes to meet them in any way they seem fit. To be able to do this, they have autonomy and mastery, are aligned with the larger business intent, and constantly find ways to improve.
12. Reflect & Improve – “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” As we tend to focus on short term goals and put the customer first, we get so busy that we struggle to find time and energy to reflect on and improve our way of working. For similar reasons as why we value feedback and learning while building our product, we should do the same for the team, process and work environment. We should look at what went well and what did not go so well. Acknowledging what went well has a positive psychological effect and what didn’t go so well is food for improvement.  By keeping the interval short, we can better remember what happened and keep it specific and small. Also the improvements should be kept small enough to fit in the next interval. Remember, a little better every day, is a lot better every month and a whole lot better every year.

Systems Thinking

1. Chaordic – According Eijnatten, a chaordic system is a system composed of elements connected in a complex and dynamic form, forming a whole whose behavior is simultaneously unpredictable (chaotic) and standardized (having order). The world is not simple, it is not complex all the time either. Looking at Dave Snowden’s sensemaking framework called “Cynefin”, see image below, we find 4 distinct domains: Clear, Complicated, Complex, and Chaotic. Our world is a combination of all four, hence the name Chaordic. However, in a given situation you will find yourself predominantly in one of the four. When things are obvious and you just have to pick the right solution, you are in the Clear domain. When you require expert analysis to help identify a proper solution, you are in the Complicated domain. When you are unable to analyze your way to an existing solution and need to experiment until a patterns hinting towards one emerges, you are in the Complex domain. When you find yourself in a situation where cause and effect seem to have no connection at all and complete new solutions come into existence out of the blue, you find yourself in the Chaotic domain. Finally, if you are unaware or unclear in which domain you find yourself, you are in the center domain of Confused. Together they are sometimes referred to as “the 5 C’s of Cynefin”.
   
   There is no ‘right’ or ‘wrong’ domain. Each serves a purpose and is the result of circumstances. Each domain requires a different type of thinking, acting, and leadership. As said, our daily life consists of a mix of situations where we need to be able to switch our mindset and behavior accordingly. In hardware development we see this for instance when developing a new solution. When really new, we get into brainstorm sessions where sometimes a wild new idea is born (Chaotic), we then start experimenting to find if and how it could work (Complex), when we like the idea, we are applying it more but still requires expert knowledge, until we have understood and simplified the process that we can write it in standard operating procedures or automate it. Development is usually a complex mix of many small ideas varying from obvious to complicated, complex and even chaotic. For more details seeProduct Development Complexity.
2. Holism – Popular said, the whole is greater than the sum of its parts, or 1+1>2. The name originates from the Greek word Holos meaning all, whole or entire. Holism is about understanding the whole and the parts at the same time, along with the relationships and the connections (synergy) that make up the dynamics of the whole. The whole has features (functions/behaviors, characteristics) that where not part of its components. In contrast to reductionist thinking, a system cannot be explained or verified/validated by examining its parts, nor can you create a system by simply ‘Frankensteining’ together some parts without considering the whole. For example, the parts of a break system (pads, disc, etc.) by itself do not have a breaking function, only the system has. Systems are mostly composed of components that are systems by itself, repeating into different levels of subsystems where each level (system) is a whole with its own features.
3. Interconnectedness – Everything is somehow interconnected. Inside the system, for instance, a break system where the break pad needs to be connected to break disc and pressure device. But also outside the system, for instance, an electric drill needs electricity distribution to power it and its plastic parts are made of plastic from oil from dead plants. Instead of looking at systems from a structured and linear ‘mechanical worldview’, we shift to an interconnected and circular ‘systems thinking worldview’. As Reinertsen put it, “the value of a system lays in its interactions and these interfaces determine the majority of complexity of a system because they grow exponentially with the number of components in a system.” When we close the loop in systems we create feedback in contrast to open loop systems. The advantages of closed loop over open loop are that it enables them to respond to changes (instead of fire and forget) and it is less dependent on the stability or quality of each component. On the downside, a closed loop system has more parts and interfaces, and therefore more complexity. Also, trouble shooting is more difficult as the system responds and changes constantly and also to any intervention as in measuring. Finally, feedback loops may be balancing where the system returns to an equilibrium after a disturbance, or reinforcing where it could result in instability and even chaos. Connections vary from easily detectable to well hidden, making it possible to get a reaction where you least expected it. In combination with reinforcement this may lead to non-linearity like the ‘butterfly effect’.
4. Emergence & Adaptivity – Emergence is, according to Jeffrey Goldstein, “the arising of novel and coherent structures, patterns and properties during the process of self-organization in complex systems.” When parts are integrated, e.g. via mechanical assembly or organic growth, a system with new features is emerging. Systems that are adaptable to their environment, like an organization or organic creature, may adapt to changing circumstances, where historic growth may influence how they grow and adapt next. Adaptation may be enforced, e.g. via new rules, encouraged, e.g. via low resistance paths, or attracted, e.g. via rewards. Technical systems may also be adaptable. In its simplest form by having someone replace a part where the person becomes part of the system, or, a bit more sophisticated, by making the system have sensors and respond to different circumstances via for instance pre-programmed routines, or even via complex artificial intelligence.
5. Discontinuous Growth – Complex systems grow and develop in cycles. From birth or start, they grow and develop until they reach a maturity growth limit (‘glass ceiling’) after which the system may jump to a higher level of complexity and start a new cycle, or fail to do so and at some point will go to end of life. When it reaches the growth limit, the system will start to bifurcate, and enters a period of relative instability. This is a period where ‘old thinking – old doing’ gradually makes place for a challenging and confusing period of alternate ‘new thinking – old doing’ and ‘new doing – old thinking’. This continues until the ‘new thinking – new doing’ sets in and becomes the new dominant pattern starting a new development cycle.
   

Agile Hardware mindset

1. Can Do – Hardware has many challenges which make it seem hard to become more rapid and responsive while keeping risks and costs acceptable. It requires a can do (or growth) mindset to make it work. We need to believe we can do it while not having all the answers yet. It requires perseverance and discipline to challenge the challenges and turns problems into solutions. To keep going we must choose our battles carefully and bite-size.
2. Balance – There is no perfect world, no perfect product, no perfect organization. Depending on the circumstances you have to decide which way to go next and keep a systems thinking mindset. Becoming more rapid and responsive is a solution to a increasingly complex and fast changing world, how much depends on your specific circumstances and is part of a larger picture where trade-offs are often unavoidable. Part of this picture are different stakeholder groups like customers, business and employees, with subgroups in each group and individuals in each subgroup, and all have different wants and needs. We also have to find a balance between the disciplined drive for perfection (‘bounty island’) and the reality (‘rainforest’) where we need to have some lenience and hope to find excellence on the way. Last but not least, being responsive is not the same as being reactive. It actually requires a delicate balance in the trade-offs of benefits, costs and risks to pro-actively prevent what we should and respond fast and effective to everything else.
3. Iterative and Incremental – Incremental is where we add a new feature, iterative is where we improve an existing feature. Each feature has to be ‘born’ at some point where we go for the minimum viable feature, and then iteratively improve it. For hardware we typically see more iterative then incremental value creation. The resulting value stream is a combination of new minimum viable features and small feature improvements which enable us to deliver in small packages of value.
4. Team of Specialists – Hardware has many different specialists, typically more than for instance in software development. Like in a soccer team it’s ok and even important to have specialists as long as all play together towards a common goal and are flexible where needed.
5. Reduce and Manage Dependencies – A lot of the lead times and high work in process in hardware are caused by the many dependencies. It is therefore also one of the best opportunities to shorten lead time and improve flow.
6. Architecture and Design for X – As development of a product evolves, the cost of change (CoC) tends to rise. For hardware development the increase tends to be higher then for instance for software so we need to pay extra attention to keeping it low. For instance by architecture and design, model based, etc. In hardware we also find many “internal customers” like sales, manufacturing and service. Design for X means to design with these multiple views in mind with specific attention for agility. The usually longer lead times in hardware make it crucial to keep recovery time low in case an idea fails to deliver needed results. Instead of going all of the way back to the drawing board, for high risk developments we develop multiple solutions in parallel as long as economically sensible. This is also known as set-based design or preserving options.
7. Atoms to Bytes – It takes time and resources to build and test something physical. In the virtual world this can be reduced enormously and at the same time open up new possibilities and opportunities. The good news is that in many cases hardware is already software. We design and even test using CAD and other models and simulations, and store product data and documentation digitally in PDM systems. To become more rapid and responsive, we need to push this to a much higher level. In short: design, build, and test in the virtual world where feasible, and go physical where needed.
8. Bytes to Atoms – When you do have to go physical, only create the part you really need to the level needed and use the fastest route possible. For instance: use a paper model, use stubs, have parts on stock, use fast technology like 3D printing, create local where possible via desktop factory or workshop, etc. In short: just think about the next best thing besides a Star Trek like replicator.
9. Hyperautomation – Particularly in hardware development, it takes a lot of time and resources to analyze, experiment and test. On top of that, repetitive work is demotivating and error prone. Automate repetitive tasks as much as possible, virtual and physical.