“God, grant me the serenity to accept the things I cannot change, Courage to change the things I can, And wisdom to know the difference.” – Reinhold Niebuhr
About The Journey
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 should we?” 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 of a fit-for-purpose organizational culture which is covered by the Foundation.
Of course, this all doesn’t just happen by itself. As Dr Seuss said, “Unless someone like you cares a whole awful lot, nothing is going to get better. It’s not.” It takes lot of care and attention, time, effort and perseverance, which is covered by in this article “The Journey”.
Organization transformation
Transforming the organization basically means transforming its culture. According to Schein, though we observe an organizational culture via behavior, rituals, artifacts, espoused values, it is in essence a set of basic (implicit) assumptions. We cannot simply ‘create’ a new culture, we can only encourage a certain way of thinking and acting which will lead to new assumptions if considered ‘better’ than the previous ones. There is a famous Peter Drucker quote saying “culture eats strategy for breakfast”. While strategy defines direction and focus, culture is the habitat in which strategy lives or dies. Strategy by itself is a merely an expression of where to go and how you think that should unfold. By itself this is not enough.
Transforming a culture, particularly one that has stabilized, is not an easy feat. The culture has led to the historical success of the organization. Besides that, transforming means learning new behavior, ways of thinking, new tools, etc. and, even more challenging, unlearning old habits and ways of thinking. This unlearning causes ‘leaning anxiety’. It’s the fear of temporary incompetence, the fear of punishment for incompetence, the fear off loss of identity, the fear of loss of group membership. These fears lead to defensive responses like denial, scapegoating and hiding or too busy, maneuvering and bargaining. It gets even more difficult when the organization is under pressure to deliver, it’s like changing the wheels of a train running at full speed.
Setting the stage
As explained in the goal, the want or need for change are either driven by the promise of something better, or by the fear of a threat, crisis or dissatisfaction (e.g. financial, technological, scandals, joint ventures) which is also know as survival anxiety. Unfortunately, it seems that survival anxiety is typically a stronger force. However keep in mind that it looses a lot or all of its ‘pushing’ power when the threat has been mitigated, where a strong long term vision can keep ‘ pulling’. A lot of this has to do with timing. Too early and most people do not understand or see the need, too late and you may be too busy putting out the flames of your burning platform. Depending on the current organizational culture and other circumstances, the sweet spot may be near the opportunity side or the threat side.
Besides the so-called progress-making forces (push and pull), we also have to deal with opposing forces resisting change. There is the anxiety for the new situation like “can I do this?”, “what if it fails”, “how will I fit in?”, etc. And there is the comfort of the current situation that is known and also there may be benefits lost in the new situation since nothing is perfect.
Change only takes place when the progress-making forces are significantly bigger then the progress-hindering forces. There is a certain inertia to overcome to make it worth the investment. Depending on the circumstances, it is often a better idea to reduce the anxiety than to inflate expectations regarding pain and gain, which may lead to increased defensive responses. The road to reducing anxiety is by providing a safe environment which has the following elements: a convincing positive vision; training, coaching and experimenting; path of least resistance and consistency.
A convincing positive vision
Since there are a lot of unknowns and even unknown unknowns, people are looking for something to hold on to. Probably the most appreciated thing we can do is to provide those involved with clarity on what we’re heading for and what’s expected of them. And even better as in the words of Confucius: “Tell me and I will forget, show me and I may remember; involve me and I will understand.” A powerful vision has the following elements. There has to be some kind of challenge in it, and at the same time achievable, so neither a walk in the park or an impossible dream. It should be compelling and unique enough to make them want to pursuit it and challenge the challenges. All addressed should feel included and understand, so not wondering what it means to them. Provide rich details like expected behavior, values, way of thinking, artifacts. Use examples of detailed scenarios and what-if situations. Add emotional detail by addressing people’s feelings on the subject, cultivating a sense of new identity, and ‘shrinking the change’ in smaller ‘victory-steps’. People spreading the vision must understand and support it themselves, have sufficient authority, and preferably some charisma or presentation skills. Last but definitely not least, repeat, repeat, repeat in any way, any medium, any opportunity, in a crowd, one-on-one, etc.
A very helpful tool for providing a rich ‘cultural’ vision, is the Competing Values Framework. This framework can help you to identify the current (IST) and desired (SOLL) culture and will show the gap between the two. For more details on the framework read Foundation – Competing Values Framework. It is important to realize that in order to be successful, an organization will need a fit-for-purpose mix. Looking at the values, or qualities, 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 probably suck at it first and feel very uncomfortable. As these are not core values they may always remain somewhat challenging and it’s easy to overdo them 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.
Training, coaching and experimenting
People should have access to formal trainings that help them understand the new ways of thinking, skills, attitudes, etc. There should be professional training upfront to provide them enough information to get started. Then provide them with opportunities to experiment with the learnings in their own preferred way while supporting them by coaching, support groups and feedback sessions with experts and/or peers. For some challenging new roles or responsibilities, it helps to have a role model, someone with experience that they can relate to, demonstrating what’s expected. After they’ve been on the job long enough to cover the basics and get some context, provide them with more formal training to go to the next level. Besides the formal trainings, there should also be informal training sessions with entire groups (like team or department) to provide all the same context and feeling that they’re all in it together.
Path of least resistance and consistency
People typically follow the path of least resistance, so make sure the path you want them to follow is the easy one. For instance, when installing a new ordering system, make sure it’s easy to use (easier than the old one) and has quick and good results. You could also make the old route more difficult, but that easily results in frustration and undermines belief in the new way of working and honesty of the organization. Another example is when promoting cross-functional teams, to provide enough desks to be able to co-locate the team members, and only if unavoidable, remove their old desk. It would even be better if the organizational structure is changed to be consistent with the new team setup.
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. For these organizations, it is vital that rewarding and discipline systems are consistent with the new way of working and thinking. For instance that team behavior is rewarded, and contra-team behavior may actually lead to disciplinary actions. This should however be a last resort, people should be motivated in different ways first, for instance the ‘reward’ that the new way of working is more fun, brings better quality and speeds things up.
Managing the transformation
When we have set the stage, it is time to manage the transformation. By installing new artifacts and behaviors like agile cross-functional teams, TDD, open space, 3D printing machines, train people for model based engineering, express the agile manifesto values, etc., we start creating new experiences which, when successful, lead to new values, beliefs and assumptions. Keep in mind though that, like in the video of “the backwards bicycle” it’s hard to change what you’ve doing for years, and it might be even harder to go back, even if you want to…
An organization is a complex adaptive system and trying to introduce a new mindset and way of working like agile hardware, requires an agile approach. Or put differently, build your organization like you would build any other complex system: incrementally and iteratively. We should define a strategy and a global roadmap with, depending on the gap between the current and aspired culture, some intermediate value based objectives and take sufficient time for the organization to catch up. for a very uncertain transition, it could be difficult to impossible to look far ahead and the roadmap would be short with very little detail.
A change strategy might be to split using the main parts of the business value stream, Development – Operations – Service, and view these as levels of enterprise hardware agility. Usually agile starts in the development department because that makes perfect sense: it’s a complex environment developing a complex product at high speed with its own subculture. However, for development to be truly agile in hardware, they are highly dependent on operations to make this possible (e.g. supply chain). A good step here is DevOps in form of working closely and iteratively with operations. The next step would be that operations becomes truly agile themselves to support customer needs (e.g. agile manufacturing). The final step is making service more agile to enable agility after delivery (e.g. easy upgrades / retrofits / add-ons / overhauls). In the end all should welcome change and be able to respond fast.
The transition will commence based on improvement ideas. For every improvement idea, there will be trade-off decisions to be made: how much does it improve the organizational performance (speed & agility)? How much does it improve quality? How much does it cost to implement? How much time does it take to implement (cost of delay)? What are the risks involved? The biggest trade-off however, is typically between investing time and resources in developing product features OR developing improvements to the organization…
Defining proper outcome based KPI’s and visualizing them on a dash board helps to identify areas for improvement and make data driven decisions. On the same dashboard you also want to see if there are any issues and risks so attention is drawn to fix fast.
Depending on the size of the idea, they may have to be split into a flow of smaller improvements which needs to be managed using features / stories, sprint goals, prioritizing work, limit work-in-process, etc. For managing the actual flow of improvements, a simple board like in the image below can be used. For larger, more complex transitions, especially in a controlled environment, a more advanced board may be required.
Central are the objectives to be obtained for the next couple of months. These are made concrete via improvement features and stories. Features usually span several weeks, stories several days. When working in sprints, you can extend the board with a sprint backlog and goal.
Kaizen, Kaikaku, Kakushin
Adding value mostly happens step-by-step (Kaizen). It’s the continuous every day hard work of all involved to make it better. Then every once a while, as David Lloyd George said “Anything can be achieved in small, deliberate steps.
But there are times you need the courage to take a great leap; you can’t cross a chasm in two small jumps”. When you’re reaching the limit (‘glass ceiling’) of a solution (mostly the effort outweighs the value), it may be time to take a different approach (Kaikaku).
Sometimes even this isn’t enough and a technological or paradigm shift may be needed (Kakushin). This is also known as disruptive innovation, a term coined by the late Clayton M. Christensen and explained in his book The innovator’s dilemma or start by reading the HBR article What Is Disruptive Innovation?. For an in-depth article on how the theory of disruptive innovation compares to agile transformation, check out Growing agility – The disruption dilemma
Metrics
To plot and re-plot a course, you need to know where to go, where you currently are, and what you expect to encounter in between. Metrics help to provide us with answers to the first two questions. Looking ahead, experience and knowledge help answer the third. Leadership puts them all together to plot the best heading. The quality of information and ability to make decisions based on that, determines how well you will proceed and how close you will get to your desired destination. Metrics in itself do not provide any answers, like the speedometer in your car won’t tell you if your going to fast, just how fast you are going.
A clear vision will help getting where we want if we can somehow translate it to something measurable. The better we do this, the better the chance of actually getting there. We can distinguish two basic metrics: directly or indirectly. If we can measure something directly it gives the best results. Many times however, we have to measure indirectly (also known as proxy) and make assumptions. Just think about concepts like value, quality, responsiveness. It is important to be aware of what you are measuring because as Deepak Chopra said: “What you pay attention to grows” and if we pay attention to a proxy and/or fail to keep a systems view, we could well be heading the wrong way.
So what can we measure for the transition to agile hardware? How do we measure this? How do we make sense of it and decide what to do? For starters we can use the structure of FlashDev™ to define categories (e.g. Goal, Architecture). Next, for each category we can define metrics and how to measure. An important step will be to combine, filter and present the results in an effective way while keeping a systems view.
For more details, please read the in-depth article Metrics for the transition.
Elephant, rider and path
An excellent model for guiding change is “The Switch” by Dan and Chip Heath. The model has three main topics, Elephant, Rider, and Path, respectively the emotional side of the brain, the rational side of the brain, and the circumstances. Usually, we address only the rational side (the rider) by trying to convince people based on facts, figures, and common sense. However, when Rider and Elephant disagree about which way to move, you’ve got a problem. The Rider can’t win a tug-of-war with a huge animal for long, we need to motivate the elephant. It helps a lot when you shape the Path to you make change more likely. In short, Direct the rider, Motivate the elephant, shape the path. The rider can be directed by: showing how others have done it, by explaining what type of behavior is expected and rewarded, and show where we are heading. The elephant can be motivated by: addressing people’s feelings on the subject, shrinking the change to bite-size (smaller objectives/goals), cultivating a sense of new identity (how we would love to be and can be). The path can be shaped by: making actual changes to organization and environment like cross-functional teams and scrum rooms and new roles/responsibilities, building habits e.g. via checklists and regular events, rallying the herd by spreading the word and showing behavior which is contagious.
Kotter’s 8-step Process for Leading Change
There are many books and theories on guiding a transformation. One of the most famous is Kotter’s 8-Step Process for Leading Change.
It all starts by creating a sense of urgency which is partly done by making people aware by explaining what it means, why we should and what if we don’t. Next, you need high level support and guidance from a guiding coalition. Creating and repeatedly communicating a vision is next. As you can’t do this alone, you need to motivate many people to collaborate and help out, so-called change agents who act as catalysts for change. Now the real work starts and one of the most important tasks is to keep the road clear so change can continue on its way. To keep people motivated, you regularly need small and bigger successes (Kaizen, Kaikaku) via objectives/sprint goals or resp. features/stories. Once the show is on the road, we need to keep it going or it will loose momentum. When changes have been achieved, we need to make sure they stick because it’s all to easy to fall back to old habits when the organization hasn’t really changed.
Leading the transformation
“Do not follow where the path may lead. Go instead where there is no path and leave a trail.” – Ralph Waldo Emerson
Organizational change, as is the case for agile hardware, is all about finding new paths and that requires leadership. It’s up to leadership to know where to go and why, and lead the way to challenge the challenges. To be able to do that, they need to learn and understand what it is they can and must do. As Deming said “Support of top management is not sufficient. It is not enough that top management commit themselves for life to quality and productivity. They must know what it is that they are committed to — that is, what they must do. These obligations can not be delegated. Support is not enough: action is required.“
Transition leaders continuously invest in understanding the concepts of lean, agile and systems thinking, and the FlashDev™ framework and practices. They can learn by following training, read books, watch webinars, talk to experts, get coaching, and most important of all, do it! With this growing knowledge and experience, they guide the improvement flow by building and sharing a vision and determine objectives. They manage the improvement flow, provide a safe and collaborative environment, manage risks, remove impediments where needed, coach and teach and empower others to become leaders themselves.
To guide and manage a team, team-of-teams, department, or even an entire enterprise, towards agile hardware requires different styles. For example, leading a new team unfamiliar with agile requires a different style then when they have prior experience. Another example is, leading a taskforce to speed-up supply of proto parts requires a different style than advocating a new way of working for a department.
Changing an organization to agile is a big change that requires leadership and support up to the highest levels. As Edward Deming said: People are already doing their best. The problem is with the system. Only management can change the system. It is not enough that management commit themselves to quality and productivity, they must know what it is they must do. … Such a responsibility cannot be delegated.
For more details on leadership, styles and models, please read the in-depth article on Leadership.
Challenge the challenges
Of course we want to improve. That’s a no-brainer we say. But when shove comes to push… “Many managers and developers are stretched so thinly just trying to finish what they have already been assigned that any improvements must wait until ‘tomorrow.’” – Reinertsen.
When explaining Agile hardware we mostly explain where we want to go. This is sometimes referred to as ‘ bounty island’ where everything is exactly as you want it and life is good. However, we do not start on bounty island and may visit many islands in between before ever getting there. This is sometimes referred to as ‘paving your way through the rain forest’.
 |
 |
Changing your way of working is no easy feat. But fortunately, as the late Virginia Satir, author or the ‘Satir Change Process Model’ (1st image below) said, “I know people can change-right down to my bones, through every cell, in every fiber of my body-I now that people can change. It is just a question of when and in what context.” The Satir Change Process has a lot of similarities to the Kübler-Ross Change Curve, as well as to the Hersey-Blanchard Situational Leadership model, and to the Eijnatten Discontinuous Growth Model. As visible in all the models, things typically get worse before they get better. This takes time and requires guidance which is covered in Leadership.
For Agile hardware, there are many challenges to overcome. As you can see in the image below, there are 3 main groups of challenges: change in general (e.g. sorry, too busy), change to agile mindset (what is agile?), and specific challenges for dealing with hardware when going agile (e.g. lead times). For more details, please read in the in-depth article Agile Hardware Challenges.
